Rendering method for generating dynamic visual monitoring

Abstract

The invention discloses a rendering method for generating dynamic visual monitoring. The method comprises the following steps: acquiring initial data, executing baseline modeling, and generating a rendering cache, a layer dependency graph and an initial layout solution; in response to real-time data change, carrying out differential arrangement by utilizing a rendering cache and a layer dependency graph, defining a minimum influence domain and generating an execution sequence through dirty region propagation and neighborhood cutting of dependency perception; according to the minimum influence domain and the execution sequence, calculating stability measurement including indexes such as displacement increment and edge crossing increment, and performing decision submission based on a preset gating condition to obtain gated layout candidates; and generating a final presentation frame according to the gated layout candidates, and binding generation of the presentation frame and issuing of the equipment control instruction into a single transaction adopting a two-stage submission mechanism. According to the method, the rendering performance, the visual stability and the operation reliability of the dynamic monitoring system are improved by accurately defining the influence domain, introducing quantitative stability gating and guaranteeing the consistency of visual control transactions.

Description

Technical Field

[0001] This invention belongs to the field of energy monitoring and data visualization technology, and in particular, it is a rendering method for generating dynamic visual monitoring. Background Technology

[0002] In critical infrastructure sectors such as the energy internet, intelligent manufacturing, and data centers, dynamic visualization monitoring systems are core supports for ensuring safe production, improving operational efficiency, and enabling scientific decision-making. These systems need to present the complex topology of the underlying physical devices, the high-frequency changes in real-time monitoring data, and the massive amounts of alarm events to monitoring personnel in an intuitive, accurate, and stable graphical format. Therefore, researching a rendering method that can efficiently process dynamic data, ensure the stability of visual presentation, and maintain consistency in human-computer interaction can improve the overall performance and reliability of modern industrial control systems.

[0003] For dynamic visualization monitoring systems, existing technical solutions include implementations based on predefined template libraries and graphics engines for graphics rendering and cross-terminal display. Specifically, the system matches the device type with a preset template to complete the initial drawing and layout of the monitoring graph. During operation, the system monitors changes in the real-time data stream. When a data update is detected, it identifies the graphic elements associated with the changed data, redraws the layer containing that element partially or entirely, and presents the updated image to the user using techniques such as double buffering. To accommodate display terminals of different sizes, strategies such as proportional scaling of the entire canvas or simple dynamic adjustment of layout spacing are also employed to achieve cross-terminal display. These methods can meet basic visualization needs in scenarios with static or low-frequency changes.

[0004] However, with the increasing scale and complexity of monitoring systems, existing technologies face challenges in dealing with high-frequency, concurrent dynamic changes, including uncontrolled impact range, lack of stability in layout updates, and a disconnect between visual presentation and device control. Because existing technologies lack corresponding impact range control mechanisms for high-frequency, concurrent dynamic changes, and lack guarantees for layout update stability and collaborative design between vision and control, further research and innovation are needed to address these issues. Summary of the Invention

[0005] Purpose of the invention: In view of the above-mentioned problems in the prior art, this application provides a rendering method for generating dynamic visual monitoring.

[0006] Technical solution: According to one aspect of this application, a rendering method for generating dynamic visualization monitoring includes:

[0007] Acquire initial data, perform baseline modeling, and generate rendering cache, layer dependency graph, and initial layout solution;

[0008] In response to real-time data changes, differential orchestration is performed using rendering cache and layer dependency graph to define the minimum impact domain and generate an execution sequence;

[0009] Based on the minimum influence domain and execution sequence, and referring to the initial layout solution, the stability metric is calculated, and a decision is made based on the preset gating conditions to obtain gated layout candidates.

[0010] The final rendering frame is generated based on the gated layout candidates.

[0011] Beneficial effects: This invention introduces rendering caching and layer dependency graphs to achieve differential orchestration, defining the minimum influence domain and solving the problem of uncontrolled change impact range; it ensures stable layout updates through stability measurement and gating condition decisions; and it generates the final rendering frame to achieve coordination between visual presentation and device control, solving the problem of their separation, while improving the flexibility, real-time performance, and scalability of the energy monitoring system. The related technical effects will be described in detail below with reference to specific embodiments. Attached Figure Description

[0012] Figure 1 A flowchart illustrating the rendering method for generating dynamic visual monitoring provided in this application embodiment.

[0013] Figure 2 This is a flowchart illustrating how a submission decision is made based on preset gating conditions and gating candidate layouts is obtained, as provided in this embodiment of the application.

[0014] Figure 3 This is a flowchart for performing differential arrangement and defining the minimum influence domain, provided for embodiments of this application.

[0015] Figure 4 This is a flowchart illustrating how a final rendering frame is generated based on gated layout candidates, as provided in an embodiment of this application.

[0016] Figure 5 This is a flowchart illustrating a method for calculating a stability metric, as provided in an embodiment of this application. Detailed Implementation

[0017] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. 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 should fall within the scope of protection of the present invention.

[0018] It should be noted that the terms "first," "second," etc., in the specification and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "including" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0019] To address the aforementioned issues, the applicant conducted in-depth searches and analyses, and discovered:

[0020] Existing technologies have a coarse-grained approach to assessing the impact of changes, relying on dirty area labeling based on engineering experience. They lack a formal description of deep dependencies between primitives, leading to situations where even localized, minor data changes can trigger large-scale, unnecessary chain redraws along implicit dependency chains, wasting rendering resources and causing unnecessary screen flickering. Furthermore, existing rendering methods primarily focus on machine performance metrics such as frame rate, neglecting the impact of layout updates on human perception. For example, system updates may cause drastic changes in node positions, a surge in the number of crossovers, or disruption of user-preferred port sequences, all increasing the cognitive load on monitoring personnel and potentially leading to misjudgments. Existing technologies lack mechanisms for quantifying and proactively intervening in such visual instability. In addition, the separate execution of visual interface updates and control transactions sent to physical devices lacks atomicity guarantees, creating an inconsistency between visual perception and physical reality, which is detrimental to the secure and reliable operation of the system.

[0021] To solve these problems, combined with Figures 1 to 5 The present invention will be specifically described through the following embodiments.

[0022] Example 1 describes the technical solution of a traditional energy monitoring visualization method, which is used to illustrate the technical problem to be solved by the present invention and the beneficial effects it brings.

[0023] Traditional dynamic visualization monitoring and rendering methods specifically include the following steps:

[0024] Step S1.1: Maintain the templates. Correspondingly, the system has built-in device templates for several common smart energy units, such as air conditioning units, water pumps, and photovoltaic panels, which also have preset corresponding energy data models, such as basic readings like temperature, power, and voltage.

[0025] This step supports adding, deleting, and modifying equipment templates, as well as modifying and customizing energy data models. For example, data such as current and cumulative runtime can be added to the water pump template, or operations such as start / stop control and frequency adjustment can be added. When editing the data model, it is possible to set whether certain data items are displayed by default in the monitoring graph. However, the templates are predefined, and when encountering entirely new equipment types or proprietary protocol equipment with significantly different data structures, custom development is still required, limiting flexibility.

[0026] Step S1.2: Create a monitoring chart, including: obtaining equipment files, a preset equipment template library, and equipment energy data models. Based on the equipment type contained in the equipment files, filter out the corresponding equipment templates from the template library. Manually select the specific energy data model to be displayed for the equipment in the current monitoring chart.

[0027] Furthermore, the one-click mapping function generates a monitoring map on the canvas based on the template and selected data, saving the binding configuration of each device and the energy data model under the current monitoring map. It can be seen that this process relies on manual selection and fixed mapping logic. For scenarios with complex or frequently changing topological relationships between devices, the generated connection relationships may not match the actual situation and cannot dynamically adapt to topological changes.

[0028] Step S1.3: Render the monitoring graph. Specifically, obtain the latest device files, saved monitoring graph configurations, and default display items of the device energy data model. Generate a dataset for rendering by parsing the tree-structured device files. Based on this, load the renderer and draw the monitoring graph.

[0029] To optimize rendering performance, this method also employs several optimization techniques, such as off-screen rendering and multi-layer rendering. In terms of layout, a layered layout algorithm is used for the initial layout, and the spacing between elements is dynamically adjusted based on the screen size of different display terminals. When real-time data updates are detected, this method only updates the layer corresponding to the data to reduce the scope of redrawing. This update method is relatively coarse-grained; when data changes cause changes in the local topology, it may still lead to large-scale redrawing of the entire layer or multiple related layers, resulting in noticeable screen flickering or jumps. Furthermore, the method separates visual updates from device control commands, which may result in situations where the interface shows the device is on, but the actual control commands fail to be sent due to network issues, causing inconsistencies between visual and control.

[0030] Example 2 provides an overall framework for a rendering method to generate dynamic visual monitoring, serving as the general outline for all subsequent examples. Specifically, it includes:

[0031] Step S2.1: As an example, obtain initial data, perform baseline modeling, and generate rendering cache, layer dependency graph and initial layout solution.

[0032] Specifically, this step is the initialization process when the system is first loaded or undergoes a cold start. The initial data acquired may include a tree snapshot T of the device topology. _0 1. Device template library M; 2. Template and view binding relationship table B; 3. Initial real-time data stream R _0 And the viewport parameter V of the current display terminal _0 The baseline modeling process performs consistency checks and type resolution on the device tree, mapping device attributes to visual primitives (i.e., view primitives) based on binding table B, thus constructing the initial rendering dataset. In the current viewport V... _0 The initial layout solution L is obtained by solving a layout algorithm (e.g., force-guided layout or hierarchical layout algorithm). _0 This solution includes the positions of all nodes, the order of ports, and the routing paths of edges. Simultaneously, the system analyzes the reference relationships between templates and constructs a layer dependency graph G to describe the dependencies between rendering layers. _layer Furthermore, the generated data, including parsed device data, view elements, historical routing information, port order baselines, etc., are stored together in a centralized state container, namely the rendering cache. _0 This provides a stable and consistent baseline state for subsequent incremental updates and stability calculations.

[0033] Another example, baseline modeling and initialization, can also be: reading a device tree snapshot T. _0 Template library M, Template-view binding table B, Real-time data stream R _0 Terminal viewport parameters V _0 According to B, T _0 Perform the initial matching with M to complete the construction and layout of the initial view elements and establish a rendering state cache. For T... _0 Perform consistency checks and type resolution, generate the initial rendering dataset by pressing B, and then render it in the initial viewport V. _0 The basic layout solution is obtained; at the same time, the layer dependency graph G is initialized. _layer With rendering cache _0 .

[0034] Another example of baseline modeling and initialization can be: reading the device tree snapshot and template view binding table, performing compliance checks on hierarchical relationships, port types, and required attributes, generating a standardized set of device nodes and connections, forming the basic data surface for the rendering cache. Importing the template library and template view binding table, mapping device attributes to geometry, color, port, and interaction capabilities, constructing the primitive list required for the first screen, and writing it to the view surface of the rendering cache. Summarizing template reference relationships, establishing a layer dependency graph, and labeling dependency edges with three granularities: geometric references, semantic references, and interaction references, producing a dependency model for subsequent propagation and pruning. Collecting viewport parameters, generating an initial layout solution (including node positions, port order, and edge route vertices), and writing the port order and routing history to the rendering cache for subsequent stability assessment. Solidifying the current rendering cache and the initial layout solution, obtaining the first fallback point, providing a baseline for differential comparison and failure rollback.

[0035] Step S2.2: As an optional implementation, in response to real-time data changes, differential orchestration is performed using rendering cache and layer dependency graphs to define the minimum impact domain and generate an execution sequence. Alternatively, when real-time data changes, differential orchestration operations are performed based on rendering cache technology and layer dependency graphs to define the minimum impact range of the data change and generate a corresponding execution sequence, ensuring that the system only operates on the necessary impact domains during data updates.

[0036] In this embodiment, this step is triggered when the system receives new real-time data or detects a change in the device topology; it is not a full redraw, but a fine-grained incremental update. Accordingly, the current data state (T) is updated. _k R _k The previous cycle's data was stored in the rendering cache. _k-1 The state (T) _k-1 R _k-1 By comparing the results, the changing atomic operations are extracted and compiled into a structured differential package D. _k Using this differential packet as the trigger source, based on the layer dependency graph G _layer Dependency-aware dirty region propagation is performed, meaning dirty markers are only passed between layers with dependencies. After propagation, neighborhood clipping is performed on the marked dirty regions to determine the minimum impact region Ω required for redrawing in this update. _k The influence domain is a minimal set with clearly defined boundaries that contains all affected primitives.

[0037] To handle high-frequency data streams, the system can also aggregate multiple differential packets directed to the same minimum influence domain within a very short time window (e.g., 50 milliseconds), simplify them according to semantic merging rules (such as equivalent coverage and mutual cancellation), and finally generate a conflict-free, ordered execution sequence P._k This step strictly limits changes to a minimum, reducing unnecessary rendering overhead and laying the foundation for high-performance, low-latency refresh.

[0038] As an alternative implementation, differential orchestration and incremental rendering with minimum impact domain are performed, specifically including: receiving the rendering cache from the previous cycle. _k Layer dependency graph G _layer Current device tree snapshot T _k Current real-time data stream R _k Previous cycle equipment tree T _k-1 With data R _k-1 By comparing and generating formalized differences and limiting the scope of influence, incremental updates have a verifiable upper bound. Let T... _k With R _k relative to T _k-1 With R _k-1 Compile into differential package D _k (Set of atomic operations), according to G _layer Dirty area propagation is performed, and the minimum impact domain Ω is obtained by trimming. _k Semantic merging of co-domain differences is performed within a short-time throttling-merging window W to generate an execution sequence P. _k .

[0039] As another optional implementation, differential orchestration and incremental rendering with minimum impact domain further include: comparing the device tree snapshot from the previous cycle with real-time data, extracting atomic changes such as additions, deletions, attribute changes, data changes, port reordering, and route updates, and summarizing them into differential packets with causal order identifiers. Combining the layer dependency graph and differential packets, affected areas are marked layer by layer according to the granularity of geometric references, semantic references, and interactive references to obtain a candidate dirty region set, avoiding cascading redraws of unrelated layers. Based on the dirty region set, affected primitives are selected as seeds in each layer, and the neighborhood range of one to two layers is limited according to the routing cross-layer situation, merging them into a minimum impact domain across layers, and providing a verifiable upper bound on the impact. Multiple changes within the same minimum impact domain are aggregated within a short-term throttling window, and semantically merged according to the rules of equivalent coverage, mutual cancellation, and idempotency preservation. Conflicts are linearized according to causal order and topology priority, generating an executable execution sequence and an auditable intent record. Based on the minimum impact domain and execution sequence, the layers and tiles that need to be redrawn off-screen are listed to form a pre-rendering plan, which prepares for subsequent stability gating and transaction commit processes.

[0040] Step S2.3: Optionally, based on the minimum influence domain and execution sequence, and referring to the initial layout solution, calculate the stability metric, and make a submission decision based on preset gating conditions to obtain gated layout candidates. Alternatively, within the minimum influence domain, combine the execution sequence and refer to the initial layout solution to calculate the system stability metric value; judge this metric value based on preset gating conditions to decide whether to submit a change, and finally output a layout candidate scheme that meets the stability requirements.

[0041] To avoid severe screen jitter and negative impact on user experience and operation caused by directly applying incremental updates, this invention introduces a stability gating step. Specifically, the system will perform a stability gating process within the minimum influence domain Ω. _k Inside, the pre-execution application execution sequence P _k Changes in layout state before and after. Referencing the layout solution L from the previous cycle. _k-1 (or initial layout solution L) _0 A series of incremental indicators for measuring layout stability are calculated, such as node displacement, changes in the number of edge intersections, and the degree of disorder in port order, and these are summarized into a stability metric J. _stab Next, this metric is compared with a preset gating threshold τ.

[0042] If J _stab Meet the gating conditions (e.g., J) _stab If the value is less than or equal to τ, it indicates that the update is stationary and acceptable, forming a gated layout candidate L. _k If the conditions are not met, a direct update will cause severe fluctuations. In this case, the system will trigger a correction strategy, such as performing a small-scale local perturbation search within the minimum impact domain, or temporarily reverting to the previous stable state to generate layout candidates that meet the gating conditions. This step, by quantifying the stability of the layout and actively intervening, ensures that the visual monitoring interface maintains high readability and operational continuity even in scenarios with high-frequency data changes.

[0043] Optionally, the stability objective and transaction consistency commit include: receiving the execution sequence P. _k Minimum influence area Ω _k Previous cycle layout solution L _k-1 Template-Data-Control Ternary Binding Rule C _bind Current viewport parameter V _k By gating upcoming partial updates with measurable stability targets, layout and control are written into the same transaction, ensuring consistency between the visual and control layers. In Ω _k Within the scope, calculate the stability objective J for the layout that is about to be redrawn. _stab (Including displacement increment, edge crossing increment, port sequence change, and routing history change, etc.), a gating threshold τ is used to determine whether submission is possible; if not satisfied, then Ω is..._k Execute a local perturbation search and rollback strategy. Use a two-phase commit to bind layout updates and control operations into a single transaction, recording the transaction log. _tx It is used to support failure rollback and idempotent retries.

[0044] Optionally, stability goals and transaction consistency commits also include: collecting the layout results of the minimum impact domain and the previous cycle, calculating displacement increments, edge intersection increments, edge length increments, port order changes, and routing history changes, and summarizing them into a stability metric vector. The stability metric vector is mapped to a weighted stability goal, and a gating threshold is determined based on the quantile statistics of the running history. When the stability goal is not higher than the gating threshold, it is marked as committable; otherwise, a local correction process is initiated. For cases marked as uncommittable, constrained small-amplitude coordinate adjustments and edge routing fine-tuning are performed within the minimum impact domain. If the gating threshold is still not met after adjustment, the execution sequence is split into batches and rolled back to the previous rollback point, then committed batch by batch. Under the pre-rendering plan, a joint verification of layout and control (including capabilities, permissions, and interlocks) is performed first. After passing, the atomic commit stage is entered, simultaneously replacing the front-screen display and issuing control commands. If any step fails, a bidirectional rollback of layout and control is triggered based on the transaction log, forming a new rollback point and updating the rendering cache.

[0045] Step S2.4: In some embodiments, a final rendering frame is generated based on the gated layout candidates.

[0046] Accordingly, receive the layout candidate L that has been stability-gated. _k The system will store the layout candidate and execution sequence P in the off-screen buffer. _k The update content defined in the code is used to redraw and composite the primitives within the minimum impact domain. After compositing, the content of the off-screen buffer is atomically replaced onto the front screen (i.e., the interface seen by the user) in one go, generating the final rendering frame. _k This method avoids the tearing and flickering caused by progressive drawing on the screen. Simultaneously, this step also synchronously writes the updated state back to the rendering cache, forming a new cache. _k This serves as a baseline for the next rendering cycle. Furthermore, this step records performance metrics for the current rendering cycle, such as rendering latency and jitter, for long-term adaptive calibration of the gating threshold. It should be understood that this is a closed-loop process, ensuring the system's continuous and stable operation.

[0047] In other embodiments, cross-terminal adaptation and final presentation can also be implemented as follows: receiving gated layout candidate L _k Viewport parameters V _k Rendering Cache _k Transaction log_tx Without violating the gating criteria, fine-tuning and off-screen compositing across terminals are completed, and then atomically submitted to the front end for presentation. According to V... _k Perform rule mapping and constrained fine-tuning (provable fine-tuning of monotonic and Lipschitz constraints, only in-range smoothing) on ​​node spacing, font size, and edge thickness, and then... _k After compositing is completed off-screen, the previous screen is atomically replaced, based on log. _tx Complete the synchronous submission of control and view; synchronously update the rendering cache. _k+1 .

[0048] In other embodiments, cross-terminal adaptation and final rendering can also be implemented as follows: Read the current viewport parameters, calculate the initial node spacing, font size, and line thickness according to human readability and congestion control rules, forming an adaptive style baseline. Perform fine-tuning of monotonicity and smoothness constraints on the style baseline to ensure consistent visual experience across different terminals. After fine-tuning, recalculate the stability target and verify the gating threshold to ensure that fine-tuning does not amplify jitter. Perform layer compositing and effect overlay in the off-screen buffer according to the execution sequence and fine-tuning style, replacing the front screen with the composite result in one go to generate the final rendering frame. Summarize statistical indicators such as rendering latency percentile, jitter index, and number of failures, and feed the statistical results back to the self-calibration logic of stability weights and gating thresholds to update the rendering cache for the next cycle.

[0049] Example 3 provides an optional implementation of differential orchestration to describe the process by which a system responds to real-time data changes, limits the update range to a verifiable minimum boundary, and ultimately generates concise and ordered execution instructions.

[0050] One example of differential arrangement to define the minimum influence domain includes the following steps:

[0051] Step S3.1: Compare the real-time data changes with the rendering cache and compile them into a differential package containing atomic operations.

[0052] In this embodiment, an atomic operation refers to the smallest, indivisible unit of modification to the rendering state, such as adding a device node, changing the color of a connection, or updating the value of a monitoring data point. A differential packet is a collection of one or more such atomic operations, recording all changes that occur within a monitoring period in a structured form.

[0053] Specifically, the system continuously takes a snapshot of the device tree T for the current period. _k With real-time data stream R _k The same as the previous cycle, it is fixed in the rendering cache. _k-1 Device tree snapshot T _k-1 With data R _k-1Perform a deep comparison. This comparison process is carried out layer by layer, node by node, and attribute by attribute. For example:

[0054] By comparing the set of device identifiers, it was identified that in T _k It exists in T _k-1 For devices that do not exist, generate atomic operations to add a new node (add_node) or add a new edge (add_edge).

[0055] By comparing T _k-1 With T _k For devices with the same identifier, but whose parent-child relationship or connection relationship has changed, a combination of operations to delete the edge (del_edge) and add the edge (add_edge) is generated.

[0056] The set attribute (set_attr) operation is generated by comparing the static attributes (such as device model, rated power, etc.) of the same device in different snapshots field by field.

[0057] By comparing R _k With R in the cache _k-1 The monitoring data is used to generate setting data (set_data) operations.

[0058] A reorder port operation is generated by comparing the order of port definitions on the device node.

[0059] The reroute edge operation is generated by comparing the routing path identifiers of the connected lines.

[0060] Furthermore, based on the timestamps of each atomic operation and the topological dependencies between associated devices, the atomic operations are causally linearized and ordered to form a deterministic execution order within the differential packet, supporting the determinism and traceability of subsequent processing. In other words, the atomic operations within the differential packet are not an unordered set, but a precisely ordered sequence. During sorting, the timestamps of the operations are prioritized; when timestamps are the same, the dependencies between devices in the topology graph are used. For example, a new node operation must be generated first before a new connection operation to that node can be generated. This causal ordering avoids potential logical conflicts in subsequent processing. This step transforms the original, unordered state changes into a structured, ordered differential packet D containing complete change information. _k It serves as the data foundation for all subsequent incremental update steps.

[0061] As an alternative, in scenarios with extremely stringent performance requirements but tolerable minor information delays, the generation frequency of differential packets does not need to be strictly synchronized with the refresh frequency of the data stream. Instead, a batch processing mode can be adopted, for example, generating a differential packet containing all changes within that time period every 100 milliseconds, thereby reducing the CPU overhead of the comparison operation.

[0062] Step S3.2: Using the differential package as the trigger source, perform dependency-aware dirty region propagation based on the layer dependency graph to generate a dirty region set.

[0063] The layer dependency graph (G) here _layer A Z-set is a directed graph generated during the baseline modeling phase to describe the relationships between different rendered primitives or layers. For example, the label text layer of a device node is geometrically dependent on the node's icon layer. _k () is the set of all graphic element identifiers that are directly or indirectly affected after propagation.

[0064] In this embodiment, dependency-aware dirty region propagation is performed based on the layer dependency graph. Specifically, the dependencies in the layer dependency graph are pre-marked as different granularities such as geometric references, semantic references, or interactive references. It is determined whether the change type of the atomic operation in the differential package triggers the granularity of the associated dependency annotation, and dirty region propagation is performed only when triggered.

[0065] Specifically, when the difference package D _k When an atomic operation (such as `set_attr(nodeA, color, 'red')`) occurs, the system locates the primitive `nodeA`; the system then checks all dependent edges originating from `nodeA`. Suppose `nodeA` has a dependent edge pointing to `nodeB`, and this edge is labeled as a semantic reference. If the `set_attr` operation changes the semantic information of the color, this change will trigger a semantic reference, and a dirty flag will propagate along this edge to `nodeB`. Conversely, if the dependent edge is labeled as a geometric reference, and the color change does not affect the geometric position, the dirty flag will not propagate along this edge.

[0066] This granular propagation mechanism improves the accuracy of propagation and avoids the spread of irrelevant updates. For example, `set_data` operations (such as updating power values) typically only trigger semantic references. `add_node` or node position movement triggers both geometric and semantic references. `set_attr` operations (such as enabling / disabling a button) may trigger interactive references. Furthermore, to ensure that the propagation process always terminates, this embodiment sets corresponding propagation stopping conditions. For example, a maximum propagation depth (such as no more than 5 layers of dependency) or a threshold for the scale of affected primitives (such as no more than 20% of the total number of primitives) can be set. Once either condition is met, the propagation terminates. This step replaces the crude, full-map or full-level refresh logic of traditional methods with an intelligent propagation approach, ensuring that only primitives truly affected by the change are included in the subsequent processing scope, thus controlling the scope of updates at the source.

[0067] Step S3.3: Perform neighborhood pruning on the dirty region set to determine the minimum influence region. The minimum influence region (Ω) _k A region is a logically or geometrically contiguous area that contains all primitives in the dirty region set, as well as a small number of neighboring primitives that are necessary to ensure rendering consistency.

[0068] Accordingly, the dirty region set Z _k The primitives in the seed primitives are used as seeds, and their neighborhoods are expanded on the rendering canvas. Preferably, the radius of the neighborhood is dynamically determined. For example, if the changes within the dirty region do not involve cross-level connection routing changes, a single-layer neighborhood (i.e., containing primitives directly connected to the seed primitives) can be used; if complex cross-level connection rerouting is involved, it may be necessary to expand to two layers of neighborhood to ensure that the drawing of the new routing path is complete and continuous. The neighborhood expansion results of all seed primitives are merged to form the final minimum influence domain Ω. _k .

[0069] Based on this, the system will also perform a priori estimation of the size of the influence domain, such as estimating its pixel area, the number of primitives it contains, and the number of edges. This estimate will serve as input for subsequent steps, such as stability gating and resource allocation.

[0070] This step transforms a potentially spatially discrete set of dirty regions into a continuous, bounded processing unit, simplifying subsequent layout calculations, trimming rendering, and resource management logic.

[0071] Step S3.4: Within a preset time window, aggregate differential packets directed to the same minimum influence domain; simplify the aggregated differential packets according to semantic merging rules to generate an execution sequence. The execution sequence (P) _k The final output of the differential orchestration stage is a highly optimized list of instructions that can be directly submitted to the rendering engine for execution.

[0072] Considering the high-frequency nature of data in energy monitoring scenarios (e.g., power data from the same device may be updated dozens of times per second), this embodiment introduces a time window (or throttling window, e.g., 50 milliseconds). The system will allocate data within this time window that operates on the same minimum influence domain Ω. _k All differential packages are aggregated.

[0073] Next, the aggregated difference package is simplified according to semantic merging rules. These rules include at least one strategy selected from the following groups: equivalent merging (overriding duplicate changes to the same object); mutual cancellation (mutual cancellation of removal operations that cancel each other out); and idempotency preservation (merging consecutive idempotent operations into a single execution). In other words, the semantic merging rules are selected from: equivalent merging, mutual cancellation, and idempotency preservation of a single execution; at least one of these is included. Equivalent merging refers to overriding duplicate changes to the same object into a single operation; mutual cancellation refers to the removal and addition operations of the same object canceling each other out, directly deleting both operations; and idempotency preservation of a single execution represents merging consecutive idempotent operations into a single execution.

[0074] For example, if two operations, `set_attr(nodeA, color, 'yellow')` and `set_attr(nodeA, color, 'red')`, occur consecutively within a window, they will be merged into a single operation, `set_attr(nodeA, color, 'red')`. If `add_node(nodeB)` occurs first, followed by `del_node(nodeB)`, both operations will be removed directly because their net effect is zero. If three `enable_alarm(nodeC)` operations occur within a window, they will be merged into a single `enable_alarm(nodeC)` operation. During the simplification process, the system also simultaneously generates intent records to audit the basis for each merge decision. The sequence of atomic operations, after semantic merging and re-causal ordering, constitutes the final execution sequence P. _k .

[0075] This step reduces the number of rendering instructions that need to be executed at the end by denoising and deduplicating changes over time, thus optimizing for high-performance rendering. In an optional implementation, the set of semantic merging rules can be expanded to include more domain-specific merging logic for even better simplification.

[0076] Another example, differential orchestration and minimum impact domain incremental rendering can also be implemented in the following way:

[0077] The system reads the device tree snapshot from the previous cycle and the current device tree snapshot, compares the device identifiers and connection sets, identifies newly added devices, deleted devices, and connection additions / removals, and obtains a list of structural changes, which is then written to the structural change section of the differential packet. It reads the device attributes and monitoring data from the previous cycle's rendering cache, combines them with the current device tree snapshot and the current real-time data stream, compares the units, precision, and threshold ranges field by field, and generates an attribute change list and a data change list, which are then merged into the data change section of the differential packet. It reads the port order baseline from the previous cycle's rendering cache, combines it with the port definitions from the current device tree snapshot, compares the order differences by port grouping and priority rules, forms a port order change list, and appends it to the order change section of the differential packet. It reads the edge routing history from the previous cycle's rendering cache, combines it with the port location from the current device tree snapshot and the template view binding table, detects changes in route identifiers or vertex sets, generates a route change list, and appends it to the route change section of the differential packet. The system compiles lists of structural changes, attribute changes, data changes, port order changes, and routing changes. These are then linearized causally by timestamp and topology dependencies to obtain differential packets arranged in execution order, which are used for subsequent propagation and merging.

[0078] Read the differential packet and layer dependency graph. Within each layer, locate the affected nodes, edges, and controls based on primitive identifiers to obtain the affected set within the layer, and write it to a temporary marker area. Read the geometric reference, semantic reference, and interaction reference annotations of the layer dependency graph, and check each one to see if the change type of the differential packet triggers the reference conditions of the upstream or downstream layer, to obtain a cross-layer propagation list, and merge it with the affected set within the layer. Read the cross-layer propagation list, perform pruning on dependency edges unrelated to the current change type, and perform deduplication and termination marking on duplicate and cyclical arrivals to obtain a converged candidate dirty region set. Based on the maximum propagation depth and maximum affected scale threshold in the system configuration, perform termination judgment on the candidate dirty region set to obtain a dirty region set for subsequent pruning.

[0079] Read the dirty region set and the current device tree snapshot. Extract intra-layer connected subgraphs using affected primitives as seeds. Merge multi-layer subgraphs according to cross-layer connection mapping to obtain cross-layer candidate subgraphs. Read the cross-layer candidate subgraphs and the route change list. Based on whether the route crosses layers, edge vertex density, and node anchoring attributes, select one or two neighboring layers to expand the candidate subgraphs to obtain extended neighborhood subgraphs. Read the extended neighborhood subgraphs and the layer dependency graph. Estimate the affected scale according to the longest dependency chain and the upper limit of out-degree to produce an impact domain size estimate, which serves as prior information for subsequent planning and gating. Write the extended neighborhood subgraph as the minimum impact domain to the rendering cache and synchronously archive the impact domain size estimate.

[0080] The process involves reading the differential package and the minimum impact domain, aggregating repeated changes to the same target object within a short throttling window, and applying an equivalent merge rule that overwrites the same field once to obtain an equivalent merge result. Reading the equivalent merge result, it performs offsetting operations on offset sequences such as adding and immediately deleting, or setting attributes and immediately rolling back, to obtain an offset merge result. Reading the offset merge result, it retains the last valid modification for consecutive attribute settings of the same object and merges idempotent operations into a single execution, resulting in an idempotent merge result. Reading the idempotent merge result and the layer dependency graph, it sorts the data according to a combination of causal time priority and topological priority to generate an unambiguous execution sequence. Reading the execution sequence, it writes the reason for each merge and sorting into the intent record for merging into the transaction log for auditing and replay.

[0081] The system reads the execution sequence and layer dependency graph to determine the redraw order of layers and generates a layer scheduling list. It reads the minimum influence domain, divides the view area into tile blocks, and generates an off-screen parallel rendering plan based on the layer scheduling list. It reads the influence domain size estimate, sets quotas and concurrency limits for the graphics pipeline and thread pool, and obtains a resource allocation scheme. Finally, it writes the off-screen parallel rendering plan and resource allocation scheme into the rendering cache as a pre-rendering plan.

[0082] Example 4: A multi-layered implementation of stability gating. The quality of the layout or user experience is quantified into calculable and measurable technical indicators. Based on these, an intelligent closed-loop mechanism for decision submission, correction, and rollback is established to suppress jitter and jumps in the monitoring screen.

[0083] In a specific embodiment, the decision-making method based on the stability objective is implemented as follows:

[0084] Step S4.1: Calculate the stability metric. Specifically, within the minimum influence domain, compare the layout state before and after applying the execution sequence, and parse at least one incremental metric selected from the following groups: displacement increment obtained by measuring node position; edge cross increment obtained by calculating the change in the number of edge crosses; edge length increment obtained by calculating the change in the total edge length; port order change obtained by evaluating the difference in port arrangement order; and routing history change obtained by analyzing the difference in the history of edge routing paths.

[0085] In this embodiment, the stability metric is not a single numerical value, but a multi-dimensional metric vector S. _metrics It characterizes the visual impact of layout updates from multiple orthogonal perspectives that influence user perception. Specifically, within the minimum impact domain Ω _k Inside, the system obtains the layout state L before the update. _k-1 Virtually apply execution sequence P _k A temporary layout candidate is obtained. The metric vector S is calculated by comparing the differences between the two. _metricsThe components of {Δpos, Δcross, Δlen, Δorder, Δroute}:

[0086] Calculate Ω based on the displacement increment Δpos. _k The sum of the Euclidean distances of the displacements of all nodes that have changed position is normalized according to the length of the viewport diagonal; this is used to quantify the magnitude of node movement, as large positional jumps can make visual tracking difficult for users.

[0087] The edge crossing increment Δcross is calculated using, for example, the Bentley-Ottmann algorithm, to calculate Ω before and after the update. _k The total number of intersections of all inner edges, the difference between the two is Δcross; used to control the neatness of the layout and avoid creating a messy spider web of connections.

[0088] Side length increment Δlen, statistical Ω _k The change in the total length of all internal connections before and after the update is normalized; this indirectly reflects the compactness of the layout and tends to avoid unnecessary routing detours.

[0089] The port order changes Δorder for Ω _k For nodes where port rearrangement occurs, extract the port sequences before and after the update; preferably, use Kendall's rank correlation coefficient or standardized Hamming distance to calculate the difference between the two sequences; this is used to maintain the muscle memory of user operations and avoid frequent changes in the port positions that users are familiar with.

[0090] Routing history changes Δroute, for Ω _k When a connection is rerouted, the system reads its historical path (i.e., a sequence of vertex coordinates) from the rendering cache. Preferably, the difference between the old and new paths is calculated using the dynamic time warping (DTW) distance or edit distance of the path. This is to maintain the inheritance of the connection path and avoid drastic changes to the entire path due to the movement of a small node.

[0091] Furthermore, the stability metric is calculated, including: acquiring real-time alarm events associated with the minimum impact domain; and for layout elements related to real-time alarm events due to execution sequence changes, increasing the calculation weight of their corresponding incremental indicators, and then summing the results to obtain the stability metric value. In other words, real-time alarm events associated with the minimum impact domain are acquired; for layout elements related to real-time alarm events due to execution sequence changes, the calculation weight of their corresponding incremental indicators is increased, and the adjusted incremental indicators are summarized to obtain the stability metric value.

[0092] Optionally, in the summary calculation of the final stability objective J _stab Previously, the system would check Ω _kDoes the element within the graph belong to a high-priority alarm? If a node is under a severe alarm, its displacement increment Δpos will be multiplied by an alarm weighting factor w greater than 1. _alarm (e.g., 1.5 or 2.0). When the system malfunctions, users have much higher requirements for the stability of critical equipment locations than in normal conditions. This weighted strategy makes the system's stability gating more stringent at critical moments.

[0093] Step S4.2: Make a submission decision based on preset gating conditions. Specifically, compare the stability metric with the preset gating threshold.

[0094] In this embodiment, the multi-dimensional vector is transformed into the final admission or rejection decision. Specifically, the metric vector S is transformed into... _metrics By using a weighted summation method, a single scalar value is aggregated, namely the stability objective J. _stab The formula is: J _stab =w _pos ·Δpos+w _cross ·Δcross+w _len ·Δlen+w _order ·Δorder+w _route ·Δroute. Where the weighting coefficient w _i Series (w _pos w _cross (etc.) reflects the importance of different metric dimensions. For example, edge crossings and port order changes are generally considered to have a greater impact on users, and their weights can be set higher. Based on this, the calculated J... _stab Compare with a dynamic gating threshold τ.

[0095] Accordingly, the weights used in calculating the stability metric, as well as the preset gating threshold, are adaptively calibrated based on statistical indicators from historical rendering cycles. These statistical indicators may include rendering latency percentiles, jitter metrics, or the number of submission failures. In other words, both the weights used to calculate the stability metric and the preset gating threshold are adaptively calibrated using statistical indicators from historical rendering cycles. These statistical indicators may include rendering latency percentiles, jitter metrics, and the number of submission failures. This adaptive calibration mechanism ensures that the gating conditions are not static but can learn and adapt to the system's operating state.

[0096] Accordingly, the system will continuously analyze J in historical rendering cycles (e.g., the most recent 1000 cycles). _stabThe numerical distribution of the data. The threshold τ can be dynamically set to a high quantile of this distribution, such as 1.2 times the 90th quantile (P90). The system allows the vast majority (90%) of regular updates to pass through, while only blocking extremely drastic updates (up to 20% exceeding P90). When a large-scale refactoring of the system topology occurs, the historical J... _stab The value will generally increase, and τ will also be adaptively increased accordingly, allowing the refactoring operation to be committed.

[0097] The weighting coefficients can also be dynamically adjusted. For example, the system can statistically analyze the historical distribution of each metric component Δi (Δpos, Δcross, etc.). If it is found that most recent submission failures are caused by excessively high Δcross, the system can appropriately reduce w. _cross The weights of the crossovers are tolerable to a certain extent, with the possibility of increasing crossovers and vice versa. This mechanism allows the stability objective itself to evolve continuously, aiming to achieve an optimal balance between stability and real-time information.

[0098] Step S4.3: If the stability metric meets the gating threshold, the layout update triggered by the execution sequence is accepted, forming a gated layout candidate. If the stability metric does not meet the gating threshold, a local perturbation search is performed within the minimum influence domain to generate a layout candidate that meets the gating threshold, or a state rollback is performed based on the rollback point of the previous cycle. In other words, when the stability metric reaches the gating threshold, a temporary layout candidate is accepted, and the layout candidate scheme is updated; if the stability metric does not reach the gating threshold, a correction is initiated to further generate layout candidates that meet the gating threshold requirements, or a state rollback operation is performed based on the rollback point of the previous cycle.

[0099] Accordingly, when J _stab When ≤τ, gating is successful, and the temporary layout candidate is formally accepted as the gated layout candidate L. _k This information is then passed on to subsequent steps.

[0100] When J _stab When the value is greater than τ, the system will not simply reject the update, but will initiate a correction strategy: performing a local perturbation search. Optionally, the system will attempt to find the minimum influence region Ω. _k Minimally invasive surgery is performed internally; Ω is locked before the search is performed. _k The boundary nodes and key connections to the outside are used as static boundary conditions; only for Ω _k For internal non-critical nodes and connecting paths, perform constrained optimization algorithms with few iterations (such as stochastic hill climbing or simulated annealing) to make small-scale (e.g., 1-5 pixel) fine-tuning of position or route vertices; after each round of fine-tuning, recalculate J. _stab If a time limit of a few milliseconds can be found to make J... _stab If the new layout is less than or equal to τ, then it is considered as the candidate layout L for the revised layout._k '.

[0101] Furthermore, the correction strategy also includes: when the local perturbation search fails to generate layout candidates that meet the gating threshold, the execution sequence is split into multiple batches according to the impact intensity, and each batch is submitted and verified one by one. Specifically, the system will split the execution sequence P _k The changes are decomposed into multiple subsequences. The decomposition can be based on the type of operation (e.g., updating all data in `set_data` as the first batch, and modifying the structure in `add_node` as the second batch) or the scope of impact. Further, the system attempts to apply the changes batch by batch, calculates stability, and submits them. This step is used to break down large, drastic changes into multiple smaller, more stable changes, increasing the probability of the update being accepted.

[0102] If all the above correction strategies fail, the system will trigger the final rollback mechanism; all changes in the current cycle will be discarded, and the system will proceed based on the rollback checkpoint saved at the end of the previous cycle. _k-1 This completely restores the rendering state to its state before the update, ensuring that the user always sees a stable and consistent image, regardless of how drastic the real-time data changes.

[0103] In summary, this embodiment transforms layout stability from a subjective concept into an engineerable and adaptively optimizable technical system through a closed loop of calculation-decision-correction / rollback, thereby improving the usability and user experience of the dynamic visualization monitoring system in complex scenarios.

[0104] In another embodiment, the stability objective and transaction consistency commit can also be implemented in the following ways:

[0105] Read the minimum influence domain and the layout results of the previous cycle, measure the Euclidean displacement of the node positions and normalize it according to the viewport parameters to obtain the displacement increment. Read the minimum influence domain and the layout results of the previous cycle, calculate the change in the number of edge pair intersections and normalize it according to the number of edges to obtain the edge intersection increment. Read the minimum influence domain and the layout results of the previous cycle, count the change in total edge length and normalize it according to the viewport diagonal to obtain the edge length increment. Read the port order baseline of the minimum influence domain and the rendering cache of the previous cycle, calculate the port sequence difference, and obtain the port order change. Read the routing history of the minimum influence domain and the rendering cache of the previous cycle, calculate the difference in vertices and corners, and obtain the routing history change. Summarize the displacement increment, edge intersection increment, edge length increment, port order change, and routing history change to obtain a stability metric vector for gating and fine-tuning review.

[0106] The system reads historical percentiles of statistical indicators and recent statistics of stability metric vectors, maps the weights of each metric to the runtime range, and obtains the stability weight configuration. It then reads the stability weight configuration and stability metric vectors, calculates the stability target, and sets a gating threshold based on historical percentiles, resulting in the submission threshold. Finally, it reads the submission threshold and stability target to determine whether submission is allowed, obtaining the gating decision. Finally, it reads the current alarm level and stability weight configuration, and, while maintaining consistency with the submission threshold, increases the weights of critical devices or high-alarm areas, obtaining the weighted alarm configuration, which is synchronously written back for subsequent cycles.

[0107] Read the minimum impact domain and the weighted configuration after alarm weighting, identify anchor nodes and key connections, lock boundary conditions, and obtain a set of disturbance boundaries. Read the set of disturbance boundaries and the minimum impact domain, and perform a small-amplitude coordinate search on the internal nodes within the confined space to obtain a position fine-tuning scheme. Read the position fine-tuning scheme and the minimum impact domain, and make small-range adjustments to edge turning points and corners while maintaining the port order to obtain a routing fine-tuning scheme. Read the position fine-tuning scheme, the routing fine-tuning scheme, and the submission threshold. If the review result still does not meet the submission threshold, the execution sequence is split into multiple batches according to the impact intensity to obtain a batch submission plan. Read the batch submission plan and the rollback point of the previous cycle, trigger rollback and retry in batches when necessary to obtain submitable layout candidates and new rollback points.

[0108] The system reads the template view binding table and committable layout candidates, verifies control capabilities, permissions, and interlocking relationships, and obtains the control consistency verification result. It reads the pre-rendering plan, commit threshold, and control consistency verification result, performs a joint check on layout renderability and control consistency, and obtains a pre-commit pass flag or a pre-commit failure flag. When the pre-commit pass flag is valid, it reads the off-screen parallel rendering plan and committable layout candidates, replaces the front screen in one go after off-screen compositing is completed, and simultaneously issues corresponding control commands to obtain the committed layout result. When a pre-commit failure flag is displayed or an atomic replacement failure occurs, it reads the rollback point and batch commit plan, executes rollback and idempotent retries, and obtains the failure handling result and the layout result after retry. It reads the intent record, failure handling result, committed layout result, or retry layout result, merges them to generate a transaction log, updates the rollback point, and synchronously refreshes the rendering cache for use in the next cycle.

[0109] Read the submitted layout result or the layout result after retry and the current real-time data stream, update the primitive state, and obtain the refreshed data surface. Read the refreshed data surface and the template view binding table, synchronize styles and layer states, and obtain the refreshed view surface. Read statistical indicators and rendering cache, scroll through the historical data window to obtain a new historical statistical baseline. Integrate the refreshed data surface, the refreshed view surface, and the new historical statistical baseline to generate the rendering cache for the next cycle.

[0110] Example 5 describes an optional implementation method for generating the final presentation frame, ensuring consistency between the visual layer and the control layer. In traditional monitoring systems, the separate execution of the interface display (visual layer) and the actual device state (control layer) can lead to inconsistencies between the two states, causing operator misjudgments and miscontrols. This example introduces a transaction mechanism based on two-phase commit to firmly bind the two, achieving a WYSIWYG (What You See Is What You Get) experience for the user.

[0111] Specifically, it includes the following steps:

[0112] Step S5.1: Derive the device control instructions associated with the gated layout candidate from the execution sequence. In this embodiment, the execution sequence P _k It not only contains rendering instructions for updating the view, but also implicitly includes the corresponding device control intent. The system will parse P _k From this, specific instructions that need to be issued to physical devices or the control backend are derived.

[0113] For example, if sequence P is executed _k The atomic operations included change the visual state of the valve element from closed to open. The system then derives the actual open control command sent to the corresponding PLC (Programmable Logic Controller) or SCADA (Supervisory Control and Data Acquisition) for that valve. Similarly, if P... _k The operation in the code is to adjust the target frequency value of the inverter element, which will generate a control command to set the new frequency of the inverter.

[0114] Step S4.2: Bind the generation of the final rendering frame and the issuance of device control commands into a single transaction using a two-phase commit mechanism to ensure consistency between the visual layer and the control layer. A single transaction refers to an indivisible logical unit of work, adhering to the atomicity principle of either all succeeding or all failing. The two-phase commit mechanism is the specific protocol for achieving this atomicity, dividing the commit process into a preparation phase and a commit phase. Specifically, the two-phase commit mechanism involves performing a joint check including layout rendering and control feasibility. After the check passes, the front-end screen is atomically updated and device control commands are issued synchronously.

[0115] Furthermore, it is confirmed that all parties involved in the transaction (i.e., the front-end renderer and the back-end controller) are ready to execute the commit. The system sends the derived control command to the back-end control service for pre-checking. The back-end service performs strict capability, permission, and interlock checks. For example, it checks whether the target device is currently in a controllable state (capability), whether the current operator has the permission to execute the command (permission), and whether executing the command would violate safety interlock conditions (e.g., the water pump cannot be started if the outlet valve is not open). After the checks pass, the back-end service does not immediately execute the command, but places the command in a pending commit state and returns a ready-to-commit response to this method.

[0116] At the same time, the front-end rendering module will process the gated layout candidate L _k Perform a final presentation check, such as confirming that all text can be displayed completely in the current viewport and that there are no unexpected element overlaps. The preparation phase is considered successful only if all the above checks pass. If any check fails, the entire transaction will be immediately aborted and rolled back, and the reason for the failure will be recorded in the transaction log.

[0117] Once the preparation phase is successful, the transaction coordinator will issue a formal commit command to all participants. The system will trigger near-simultaneous atomic operations. The front-end rendering engine will then base its rendering on the layout candidate L. _k The final rendering frame, synthesized in the off-screen buffer, is then displayed on the screen all at once. Almost simultaneously, the backend control service officially issues control commands that are in a pending state to the physical device for execution.

[0118] This atomic submission design shortens the time window between visual and physical states, resulting in a higher degree of synchronization between screen changes and device response from the user's perspective.

[0119] Step S5.3: Further, if either phase of the two-phase commit mechanism fails, a synchronous rollback for layout and control is triggered based on the transaction log and the preset rollback point, restoring the system to a consistent state before the transaction began.

[0120] As before, the rollback process is relatively simple when the preparation phase fails, since no permanent changes have been made to the system state; simply aborting the transaction is sufficient. Failure in the commit phase requires entering the fault-tolerance phase. For example, the front-end screen might update successfully, but the back-end, after issuing a command, fails to receive confirmation from the device due to a network interruption. In this case, the system is placed in a state of visual-control inconsistency. The rollback mechanism is triggered, and the system uses the transaction log... _tx The backtracking checkpoint of the previous stable state _kThen, a synchronous rollback is performed. Specifically, the front-end interface will automatically restore to the state before the transaction began; at the same time, the system can attempt to send compensation instructions to downstream devices according to preset strategies (for example, if it was enabled before, the compensation instruction will be disabled) to restore the state of the physical devices and push the entire system back to the consistency point before the transaction began.

[0121] As an alternative, for non-critical control operations that allow for eventual consistency, two-phase commit can be optimized into a single-phase commit with compensating transactions. That is, visual updates and command issuance are performed first; if command execution fails, a reverse compensating transaction is initiated to roll back the visual and physical states. This approach has lower latency, but its consistency guarantee is slightly less stringent than that of two-phase commit.

[0122] This embodiment solves the problem of visual and control consistency in dynamic monitoring systems through a two-phase commit transaction mechanism, providing technical support for highly reliable and secure industrial scenarios.

[0123] Example 6 provides a specific implementation method for cross-terminal adaptive rendering, which provides a consistent and optimized visual experience on terminals of different sizes and resolutions (such as the large screen in the control room, the engineer's PC, and the maintenance personnel's tablet), while ensuring that the adaptive adjustment itself does not introduce new visual jitter or disrupt layout stability. Specifically, it includes the following steps:

[0124] Step S6.1: Based on the viewport parameters of the current terminal, perform adaptive fine-tuning on the gated layout candidates; wherein, the adaptive fine-tuning process is subject to preset monotonicity or smoothness mathematical constraints, which are used to maintain the predictability and visual consistency of layout adjustment across different terminals.

[0125] Among them, the viewport parameter V _k It is a collection containing key physical and logical attributes of the current display terminal, such as screen resolution (width pixels × height pixels), device pixel ratio (DPR), physical size, etc. Adaptive fine-tuning refers to fine-tuning non-topology-related style parameters in the layout (such as node spacing, font size, edge thickness, etc.) to adapt to the current viewport. The specific implementation includes the following steps:

[0126] The system uses viewport parameters V _k The system calculates basic style parameters using preset human factors engineering rules or heuristic formulas. These rules ensure basic readability and information density.

[0127] For example, the basic node spacing s _0 It can be set to s _0 =c _1 ×sqrt(width×height / N _vis), where width and height are the viewport width and height, N _vis c is the number of visible nodes in the current viewport. _1 It is an adjustable coefficient; this rule makes the spacing more lenient as the screen becomes larger and the nodes become sparser.

[0128] Basic font size z _0 It can be set to z _0 =c _2 ×log(1+DPI). Where DPI is the pixel density of the screen, c _2 It is a coefficient. This rule ensures that the font does not appear too small on high-resolution screens.

[0129] Basic edge thickness b _0 It can be set to b _0 =c _3 ×(1+N _cross_norm ), where N _cross_norm It is the normalized edge cross density, c _3 It is a coefficient. This rule can automatically thicken lines in areas with crowded layouts and many intersections to improve recognizability.

[0130] After obtaining the basic style parameters, the system will fine-tune the function f. # Further optimization will be carried out; among them, # For the purpose of smoothing and predictability, the adaptive fine-tuning process is subject to predefined monotonicity or smoothness mathematical constraints.

[0131] In a preferred embodiment of this invention, the fine-tuning function f # Designed to satisfy Lipschitz continuity, with its Lipschitz constant L ≤ 1, this can be achieved by constraining its function structure (e.g., spectral norm normalization if it's a small neural network). If the user's screen size changes slightly (e.g., the browser window is slightly stretched), the changes in output style parameters (such as spacing and font size) will also be slight and proportional, avoiding abrupt layout changes caused by a small screen size adjustment. Monotonicity constraints ensure that, for example, as the screen size increases, node spacing and font size will not decrease.

[0132] Step S6.2: Recalculate the stability metric of the adaptively fine-tuned layout and review it based on the gating threshold; only when the review passes will the adaptively fine-tuned layout be used to generate the final rendering frame. This step is to ensure a closed loop for safe adaptation.

[0133] Specifically, fine-tuning improves visual adaptability, but may unintentionally cross stability red lines (e.g., increasing spacing causes the displacement of a critical node to exceed a threshold). Therefore, a safety review is necessary before applying the fine-tuned layout. The system will select the fine-tuned layout candidate L... _k The data is then sent back to the stability metric calculation module. Its stability objective J is recalculated. _stab ';J _stab 'Compare with the current gating threshold τ. Only if the review passes (J) _stab Only when the fine-tuned layout is less than or equal to τ is it finally adopted. In a specific implementation, the review condition can be set as follows: the fine-tuned J... _stab Compared to J before fine-tuning _stab The increase must not exceed a small tolerance, such as 5%. If the review fails, the system can choose to abandon the current fine-tuning or reduce the intensity of the fine-tuning (for example, multiply the fine-tuning effect by a decay factor of 0.5) and try again until the review passes.

[0134] Alternatively, for mobile terminals with limited computing power, simplified, pre-computed style sheets can be used instead of complex real-time calculations, matching the most suitable style sheet based on the screen size range. However, this approach does not provide a smoother transition than the aforementioned constrained calculation method.

[0135] By employing the strategy of first fine-tuning the mapping and then verifying it, this embodiment achieves a balance between cross-terminal adaptation and ensuring the stability of the core layout, enabling it to provide a high-quality and highly stable visualization experience on any device.

[0136] According to one aspect of this application,

[0137] Example 7 provides a numerical calculation case involving stability measurement and gating decision-making process.

[0138] Suppose that in a local view of a microgrid monitoring scenario, there exists a topology consisting of 5 device nodes (N1, N2, N3, N4, N5) and 4 connecting lines (E1, E2, E3, E4). At the end of rendering cycle k-1, its layout solution L... _k-1 The coordinates of each node are as follows (unit: pixels): N1(100, 100); N2(200, 100); N3(150, 200); N4(100, 300); N5(200, 300); the connection relationships are: E1(N1-N2), E2(N1-N3), E3(N2-N3), E4(N3-N4). At this point, the layout is stable, and all edges do not intersect.

[0139] In the new rendering cycle k, the system receives the execution sequence P. _kThis resulted in the following changes: Device N3, due to excessive load, needed to be moved to be highlighted, and its new target coordinates became (250, 250). Device N5 was added to the topology, establishing a connection E5 (N2-N5) with N2. The minimum impact region Ω of this change is... _k This includes all nodes and connections. The system will perform stability gating on this change.

[0140] Calculate the stability metric vector S _metrics The system will use virtual application P _k A temporary layout candidate is obtained, and various incremental indicators are calculated: only node N3 has moved. The displacement vector is (250-150, 250-200) = (100, 50). The Euclidean distance of the displacement is sqrt(100... 2 +50 2 )≈111.8. Assuming the viewport diagonal length is 1000 pixels, the normalized displacement increment Δpos=111.8 / 1000=0.1118.

[0141] Before the update, edges do not cross, and the cross count is 0. After the update, N3 moves to (250, 250), N5 is at (200, 300), and a new connection E5 (N2-N5) is added. Connection E2 (N1-N3) changes from (100, 100) to (250, 250), and connection E3 (N2-N3) changes from (200, 100) to (250, 250). Through geometric calculation or the scanline algorithm, it can be found that the new connection E2 (N1-N3) crosses with connection E5 (N2-N5). Therefore, the cross count changes from 0 to 1. Δcross = 1.

[0142] To simplify the calculation, in this example, we assume that the calculated results for the edge length increment Δlen, port order change Δorder, and route history change Δroute are Δlen=0.05, Δorder=0 (no port rearrangement), and Δroute=0 (no complex route changes), respectively. The final metric vector is S. _metrics ={Δpos: 0.1118, Δcross: 1, Δlen: 0.05, Δorder: 0, Δroute: 0}.

[0143] Furthermore, assume that the system adaptively calibrates the weight configuration based on historical operating data as follows: w _pos =0.2, w _cross =0.5, w _len =0.1, w _order =0.1, w _route =0.1. It can be seen that the system sets the highest level of attention to the edge intersection term. Stability objective J _stab=(0.2×0.1118)+(0.5×1)+(0.1×0.05)+(0.1×0)+(0.1×0)=0.02236+0.5+0.005=0.52736.

[0144] Assume the current gating threshold τ is adaptively set to 0.40. J _stab (0.52736)>τ(0.40). The gating condition is not met, and direct submission is rejected. Since direct submission is rejected, the system initiates a local perturbation search. The position of N3 is adjusted within a small range to eliminate edge crossings, making J... _stab The system searches within a circular region with a radius of 20 pixels, centered at the temporary target position (250, 250) of N3. After several iterations, the algorithm finds that when the position of N3 is finely adjusted to (230, 180), the line E2 (N1-N3) will no longer intersect with E5 (N2-N5). The system recalculates the stability metric using the new coordinates (230, 180) of N3.

[0145] The displacement relative to the original position (150, 200) is (80, -20), and the distance is sqrt(80). 2 +(-20) 2 The displacement increment Δpos' is approximately 82.46. After normalization, the new displacement increment Δpos' = 82.46 / 1000 = 0.08246. The number of intersections is 0, so the new edge intersection increment Δcross' = 0. The new stability objective J... _stab = (0.2 × 0.08246) + (0.5 × 0) + ... ≈ 0.01649 + ... (other terms change only slightly). Clearly, J _stab The value will be much less than 0.40. The gating condition is met, and the corrected layout is accepted. The system adopts the new position of N3 as (230, 180) to generate the final rendering frame. It should be understood that the gating mechanism of this invention will result in visually chaotic and drastic updates, which will be automatically corrected to smooth, clear layout updates.

[0146] Example 8 describes the construction of the layer dependency graph and the specific implementation of the data flow closed-loop mechanism (for ensuring long-term stable system operation). The layer dependency graph G... _layer It is the premise and foundation for realizing the spread of dirty areas based on perception.

[0147] On the one hand, the construction of the layer dependency graph can also be achieved through the following steps: In the baseline modeling stage, after the system parses the device tree snapshot and template library for the first time, it constructs the graph based on the reference relationships between templates in the template library and the layout constraints of each visual element (such as icons, labels, status indicators, etc.) within the template. Figure G _layerEach node in the graph represents an independent rendering unit, which can be a layer or a more granular primitive. For example, a water pump device might consist of three primitives in the view: a pump icon, a name label, and a running status indicator. _layer This is represented by three nodes.

[0148] If a certain attribute of rendering unit A (such as position, color, visibility) depends on an attribute of rendering unit B, then in G... _layer Create directed edges from B to A; accordingly, annotate each dependency edge with fine-grained detail. If the position or size of A depends on the position or size of B (e.g., the name label must always be below the icon), the dependency edge is annotated as a geometric reference. If the color or text content of A depends on a data attribute of B (e.g., the color of an indicator light depends on the pump's operating status data), the dependency edge is annotated as a semantic reference. If the interactive behavior of A (e.g., whether it is clickable) depends on the state of B (e.g., when the pump is in maintenance mode, its control buttons become unavailable), the dependency edge is annotated as an interactive reference.

[0149] Deconstruct the initial layout L _0 The port order and edge routing history (i.e., a set of vertex coordinates) are used as a baseline snapshot and stored in the rendering cache. _0 This is a specific historical region; this archive is the zero point for calculating the stability metrics Δorder and Δroute in all subsequent rendering cycles, and is the basis for the implementation of the stability gating mechanism.

[0150] On the other hand, the closed-loop mechanism for system data flow can also be implemented using the following methods:

[0151] When the rendering cycle k generates the final rendering frame Frame _k Afterwards, the system does not terminate but immediately starts the end-of-cycle refresh procedure to prepare for the next rendering cycle k+1. Accordingly, the latest real-time data stream R is updated. _k With the already accepted layout candidate L _k The states in the rendering cache are merged, and the real-time data values ​​of primitives in the rendering cache are updated. Based on changes in the data planes, the style attributes of the view planes (such as color and text) are updated synchronously to ensure that the data in the cache is consistent with the view state. Stability metrics, rendering latency, and other statistical indicators calculated in the current rendering cycle k are pushed into a fixed-length historical data window (e.g., retaining statistical data from the last 1000 cycles). This scrolling historical window serves as the data source for adaptive calibration of weights and thresholds.

[0152] After the above refresh, a brand new, consistent rendering cache is available. _k It was fixed and renamed Cache. _k+1Meanwhile, the current layout solution L _k Solidified into L _k+1 Generate a new rollback checkpoint _k+1 The cache contains the latest state. _k+1 and checkpoint _k+1 This will serve as the direct input baseline for differential alignment, stability calculation, and failure rollback in the next rendering cycle k+1. It should be understood that the cyclical data flow of rendering → refreshing → generating the baseline for the next cycle → re-rendering constitutes a complete, self-consistent, and long-term stable closed-loop system.

[0153] Example 9 provides a specific energy internet application scenario, namely rapid fault isolation and load transfer in the distribution network, to describe the collaborative workflow of the method of the present invention. Furthermore, this example also provides an optional machine learning-based technical solution for the stability gating mechanism.

[0154] Assume that in a city power distribution network monitoring interface, under normal operating conditions, the load in a certain area is powered by the main line L1 through switch K1. The rendering system is running stably, the interface is clear, and there are no obvious changes. Fault Occurrence and Differential Scheduling: At a certain moment t0, a short-circuit fault occurs on the main line L1. Within a very short time (e.g., within 100 milliseconds), the monitoring system receives a series of high-concurrency events and data streams: the protection device of line L1 activates, and switch K1 trips; in the device tree, the state attribute of K1 changes from closed to open, and its corresponding connection needs to be visually disconnected or grayed out. The system's automatic power transfer strategy is activated, switch K2 of the backup line L2 closes, switching the load to L2 for power supply; the topology changes, adding a valid connection from L2 to the load. Multiple devices related to L1 and K1 (such as transformers and sensors) generate a large amount of alarm data.

[0155] Accordingly, the differential orchestration mechanism begins to function. The system compares the aforementioned changes and quickly compiles them into differential packets containing atomic operations such as `set_attr(K1, state, 'open')`, `set_attr(K2, state, 'closed')`, `del_edge(L1, Load)`, `add_edge(L2, Load)`, and multiple `set_data(alarm_level, 'critical')`. After dependency-aware dirty region propagation and minimum impact domain pruning, the system precisely limits the update scope to a local region Ω centered on K1, K2, and related lines. _k Furthermore, semantic merging within the throttling window simplifies potentially duplicate alarm data, generating a concise and ordered execution sequence P. _k .

[0156] In some scenarios, sequence P will be executed._k Before rendering, a stability gate is required. This embodiment uses a pre-trained machine learning model for decision-making. The approach employs a lightweight regression prediction model (e.g., Gradient Boosting Decision Tree (GBDT) or Small Graph Neural Network (GNN)).

[0157] Specifically, the system starts from virtual application P _k In the layout changes before and after, high-dimensional feature vectors are extracted. These vectors can include not only indicators such as displacement, intersection, and edge length, but also richer graph structure features, such as changes in node degree, changes in local clustering coefficients, and changes in pixel area of ​​primitives. This feature vector is then input into a pre-trained model. The model's output is a continuous value between [0, 1], called the instability prediction score; it is a comprehensive prediction of the extent of visual interference caused by the update. The model's output score is compared with a fixed threshold (e.g., 0.8). If the score is below the threshold, the update is considered acceptable; if it is above the threshold, the update is considered too drastic, and a correction strategy needs to be initiated.

[0158] In a specific embodiment, the model is trained offline; the training dataset comes from a large number of historical rendering snapshots, and human factors engineering experts or senior operators annotate each layout change (e.g., labeled as stable, acceptable, disruptive, drastic, etc.). The annotation results are converted into numerical values ​​and used as training targets.

[0159] This scheme can capture more complex, non-linear feature combinations than manually designed weighted formulas, achieving more intelligent judgments; however, its decision-making process is a black box with poor interpretability, requires a large amount of labeled data for training, and is prone to misjudgment. Therefore, this scheme is more suitable for scenarios with extremely high user experience requirements and the ability to collect large amounts of user behavior data for model iteration. It is understandable that methods based on explicit rules and multi-dimensional weighting, due to their determinism, high interpretability, and lack of large-scale training requirements, can be considered a more preferred implementation method in the industrial monitoring field addressed by this invention.

[0160] Assuming the layout update passes stability gating (regardless of the mechanism), in this scenario, the rendering operation that updates the visual state of switch K2 to closed on the interface must be bound to the physical control command to close the actual switch K2 within the same two-phase commit transaction. The system performs a pre-commit check to confirm that the backend transfer logic allows closing (e.g., confirming that the L1 fault has been isolated) and that the frontend layout update will not cause rendering anomalies. Only when all conditions are met will the system atomically update the screen of K2 to a green closed state and simultaneously issue the closing command. This avoids the problem of the operator seeing K2 as closed when the transfer has not actually succeeded.

[0161] Based on this, let's assume an operations engineer is on-site viewing the fault handling process via a tablet. The constrained cross-device adaptive fine-tuning mechanism will automatically activate. The system will automatically adjust the node spacing and alarm text font size according to the tablet's viewport parameters. Even on a smaller screen, the topology of the fault area and key alarm information remain clearly visible. Furthermore, this fine-tuned layout has undergone stability verification before being presented to the engineer, ensuring that the adaptive process itself does not introduce additional visual interference.

[0162] The preferred embodiments of the present invention have been described in detail above. However, the present invention is not limited to the specific details of the above embodiments. Within the scope of the technical concept of the present invention, various equivalent transformations can be made to the technical solutions of the present invention, and these equivalent transformations all fall within the protection scope of the present invention.

Claims

1. A method for generating a rendering of a dynamic visual monitoring, characterized in that, The method comprises: acquiring initial data, performing baseline modeling, generating a rendering cache, a layer dependency graph, and an initial layout solution; in response to real-time data changes, using the rendering cache and the layer dependency graph to perform differential arrangement, define a minimum impact domain, and generate an execution sequence; based on the minimum impact domain and the execution sequence, referring to the initial layout solution, calculating a stability metric, making a submission decision based on a preset gating condition, and obtaining a gated layout candidate; generating a final presentation frame based on the gated layout candidate.

2. The method according to claim 1, characterized in that, The calculation of the stability metric comprises: within the minimum impact domain, comparing the layout state before and after the application of the execution sequence to analyze at least one incremental indicator selected from the following group: a displacement increment of a node position; an edge crossing increment calculated from the change in the number of edge pair crossings; an edge length increment calculated from the change in the total length of the edges; a port order change resulting from the evaluation of the difference in the order of the ports; a routing history change resulting from the analysis of the historical difference in the edge routing path.

3. The method according to claim 2, characterized in that, The submission decision based on the preset gating condition to obtain the gated layout candidate comprises: comparing the stability metric with the preset gating threshold; if the stability metric meets the gating threshold, accepting the layout update caused by the execution sequence to form the gated layout candidate; if the stability metric does not meet the gating threshold, performing a local perturbation search within the minimum impact domain to generate a layout candidate that meets the gating threshold, or performing state rollback based on the rollback point of the previous period.

4. The method according to claim 1, characterized by, The differential arrangement to define the minimum impact domain comprises: comparing the real-time data changes with the rendering cache to compile a differential package containing atomic operations; using the differential package as a trigger, performing dependency-aware dirty region propagation based on the layer dependency graph to generate a dirty region set; performing neighborhood clipping on the dirty region set to determine the minimum impact domain.

5. The method according to claim 4, characterized in that, The differential arrangement further comprises: within a preset time window, aggregating differential packages targeting the same minimum impact domain; simplifying the aggregated differential packages based on semantic merging rules to generate an execution sequence, the semantic merging rules including at least one strategy selected from the following group: equivalent merging by covering repeated changes to the same object; mutual cancellation of operation sequences with mutually cancelable operation effects; idempotent preservation by combining consecutive idempotent operations into a single execution.

6. The method of claim 1, characterized in that, Generating the final presentation frame based on the gated layout candidate comprises: deriving device control instructions associated with the gated layout candidate from the execution sequence; binding the generation of the final presentation frame and the issuance of the device control instructions as a single transaction using a two-phase commit mechanism; wherein the two-phase commit mechanism specifically includes joint verification of layout presentation and control feasibility, and after the verification passes, atomically synchronously updating the front-end picture and issuing the device control instructions.

7. The method according to claim 6, characterized in that, The method further comprises: in the event of a failure at either stage of the two-phase commit mechanism, triggering a synchronous rollback of the layout and control based on the transaction log and a preset rollback point to restore the system to a consistent state before the transaction began.

8. The method of claim 1, characterized in that, Before generating the final presentation frame, the method further comprises: performing adaptive fine-tuning of the gated layout candidate based on the viewport parameters of the current terminal; wherein the adaptive fine-tuning process is subject to preset monotonicity or smoothness mathematical constraints.

9. The method according to claim 8, characterized in that, After the adaptive fine-tuning, the method further comprises: recomputing the stability metric for the adaptively fine-tuned layout, and reviewing the adaptively fine-tuned layout against the gating threshold; only when the review passes, generating the final presentation frame using the adaptively fine-tuned layout.

10. The method of claim 2, wherein, The computing the stability metric further comprises: obtaining a real-time alert event associated with the minimal impact domain; for a layout element that is changed due to the execution sequence change and is related to the real-time alert event, aggregating the stability metric by increasing the computation weight of the corresponding delta indicator.

Images