Real-time monitoring system and method for operation state of power communication SDH network

Abstract

This application provides a real-time monitoring system and method for the operating status of a power communication SDH network. The system includes: a multi-protocol adaptive acquisition module, which collects network element information, performance information, alarm information, and equipment information of the power communication SDH network according to a preset strategy; a protocol parsing engine module, which standardizes the acquired multi-source heterogeneous data to obtain structured data; an intelligent data filtering and deconstruction module, which parses, correlates, and identifies the structured data to obtain key business entities; a lightweight encapsulation module, which performs serialization and compression optimization on the key business entities to obtain lightweight encapsulated data; and a rendering module, which performs real-time rendering based on the lightweight encapsulated data to obtain a real-time visualized operating status of the power communication SDH network. This application optimizes acquisition efficiency, supports real-time monitoring, reduces bandwidth costs, reduces invalid data transmission by 80%, and compresses fault location time from hours to minutes.

Description

Technical Field

[0001] This application belongs to the field of real-time monitoring technology of power communication networks, and relates to a real-time monitoring system and method for the operation status of power communication SDH networks. Background Technology

[0002] The SDH (Synchronous Digital Hierarchy) network for power communication serves as the transmission foundation for critical services such as power grid dispatching, protection, and stability control. Real-time assessment of its operational status is a rigid requirement determined by the high risk, real-time nature, and uninterruptibility of the power system.

[0003] SDH networks carry primary load communication in power systems, providing lifeline services for the power grid with zero fault tolerance. These services require "second-level detection and minute-level handling," which can only be met through real-time assessment. Unlike the "best-effort" approach of IP networks, SDH employs rigid time slot allocation. The rigid pipeline characteristics of SDH networks necessitate proactive monitoring, and real-time assessment (such as monitoring B1 / B2 / B3 bit errors, MS-AIS, R-LOS alarms, etc.) is the only means of detecting "gradual faults." Power system faults follow an evolutionary pattern of "millisecond-level faults - second-level stability - minute-level collapse." The "avalanche effect" of grid faults requires predictive defense; therefore, real-time assessment is not only about "seeing faults," but also the foundation of predictive maintenance. Summary of the Invention

[0004] This application provides a real-time monitoring system and method for the operation status of a power communication SDH network. It solves the dual challenges of the complexity of multi-source data acquisition and the difficulty of deconstructing and filtering raw data into lightweight data in the real-time monitoring of the operation status of a power communication SDH network. It realizes real-time monitoring of the operation status of the power communication SDH network and provides a demonstration of the effect.

[0005] In a first aspect, this application provides a real-time monitoring system for the operating status of a power communication SDH network, comprising:

[0006] The multi-protocol adaptive acquisition module collects network element information, performance information, alarm information and equipment information of the power communication SDH network according to the preset strategy. The protocol parsing engine module performs standardization processing on the acquired multi-source heterogeneous data to obtain structured data.

[0007] The intelligent data filtering and deconstruction module parses, associates, and identifies the structured data to obtain key business entities;

[0008] The lightweight packaging module performs serialization and compression optimization on the key business entities to obtain lightweight packaged data.

[0009] The rendering module performs real-time rendering based on the lightweight encapsulated data to obtain a real-time visualized operating status of the SDH power communication network.

[0010] In one implementation of the first aspect, the multi-protocol adaptive acquisition module includes: an acquisition scheduler, a network data acquisition module, a performance data acquisition module, an alarm data acquisition module, a device data acquisition module, and a protocol parsing engine module;

[0011] The data acquisition scheduler controls the network element information acquisition module to acquire network element information of the power communication SDH network, parses the equipment list and basic information in the network element information, and generates a network element information view;

[0012] The acquisition scheduler controls the performance data acquisition module to acquire the performance information of the power communication SDH network, parses the acquired optical power and / or bit error rate in the performance information, and generates performance trend data.

[0013] The data acquisition scheduler controls the alarm data acquisition module to collect alarm information from the power communication SDH network, extracts real-time alarms and historical alarms from the alarm information, and generates alarm statistics information.

[0014] The data acquisition scheduler controls the equipment data acquisition module to collect and obtain the equipment configuration and status information of the power communication SDH network, and generates the equipment health status;

[0015] The protocol parsing engine module standardizes the multi-source heterogeneous data, eliminating the differences in the underlying communication protocols of the multi-source heterogeneous data, and obtaining structured data; the multi-source heterogeneous data includes network data view, performance trend data, alarm statistics information and / or device health status.

[0016] In one implementation of the first aspect, the protocol parsing engine module includes:

[0017] The raw response receiving unit captures multi-source heterogeneous data returned by the server, i.e., heterogeneous protocol data, through UnityWebRequest;

[0018] The preprocessing and verification unit checks the integrity of the heterogeneous protocol data, filters invalid characters, and outputs standardized XML data.

[0019] The namespace resolution unit registers XML namespaces and resolves tag conflicts.

[0020] The XPath extraction unit uses predefined XPath expressions to locate target nodes in standardized XML data, queries the target nodes through the XPath engine, and extracts key information from the target nodes; the key information of the target nodes includes text content or attribute values.

[0021] The standardized output unit maps the extracted key information into a unified output format for use by downstream modules; the unified output format is a structured key-value pair format, and the field names contained in the unified output format all follow a predefined data dictionary.

[0022] In one implementation of the first aspect, the intelligent data filtering and deconstruction module includes: a data aggregation module, a data association engine module, and a field recognition engine module;

[0023] The data aggregation module merges and aligns the structured data output by the multi-protocol adaptive acquisition module at the data aggregation point to form a unified business data context.

[0024] The data association engine module integrates relevant scattered data from the business data context into a panoramic view of the device through primary key matching, time sequence alignment, and multi-source fusion.

[0025] The field recognition engine module, based on predefined business rules and a data dictionary, uses intelligent filtering strategies to filter redundant data in the device panoramic view, extract key fields, perform key field recognition, redundant information removal, and semantic mapping of heterogeneous names to obtain standard core data.

[0026] In one implementation of the first aspect, the data association engine module includes:

[0027] The primary key matching unit uses the device ID or IP address as a unique identifier to associate configuration, alarm, and performance data, and obtains a set of key-value pairs after primary key matching.

[0028] The time-series alignment unit sorts events by timestamp to form time-series data, and the time-series aligned data format is an ordered list.

[0029] The multi-source fusion unit integrates scattered data to form a panoramic view of the equipment, retaining only the core fields. The format is a flat structure, and the output example is simplified (compressed from 218 fields to 32 fields in the initial draft).

[0030] The data association engine module transforms isolated fragments of data from individual devices into complete business entities containing configuration, status, and history.

[0031] In one implementation of the first aspect, the field recognition engine module includes:

[0032] The input unit receives structured data containing 218 fields output by the protocol parsing engine module;

[0033] The rule application unit loads the business rule dictionary, performs field-by-field priority filtering on the structured data, applies threshold checks and redundancy merging, and obtains the core data after rule processing.

[0034] The output unit generates a simplified core dataset containing only 32 fields based on the core data processed by the rules.

[0035] In one implementation of the first aspect, the lightweight packaging module includes:

[0036] The user-space network protocol stack unit uses a user-space RDMA protocol stack to bypass the kernel protocol stack and directly process the network data packets of the lightweight encapsulated data in user space.

[0037] A binary serialization protocol unit, which replaces XML parsing with the binary protocol SDH-BNP, extracts fields from the network data packets of the lightweight encapsulated data.

[0038] The hardware clock synchronization unit synchronizes the system clocks of the sending and receiving ends of the network data packets based on PTP.

[0039] In one implementation of the first aspect, the rendering module includes:

[0040] The multi-threaded rendering pipeline unit uses a dedicated parsing thread to handle data deserialization, a computation thread to perform physical calculations and state updates, and a rendering thread to trigger drawing commands when the main thread is idle.

[0041] The GPU asynchronous computing unit uses computing shaders to process data update logic, avoiding the transmission latency from the CPU to the GPU;

[0042] The dynamic vertical synchronization unit dynamically switches vertical synchronization based on frame rate prediction, coordinating the GPU rendering rate with the display refresh rate.

[0043] In one implementation of the first aspect, the rendering module further includes:

[0044] The data snapshot storage unit saves the hash value or version number of the current structured data after each rendering.

[0045] The difference detection unit compares the hash value of the new structured data with the hash value saved in the previous snapshot when new structured data arrives. If the hash values ​​are different, it is determined that there is a difference; otherwise, it is determined that there is no difference.

[0046] The real-time rendering condition triggering unit determines whether to trigger rendering based on the differences and business rules; the business rules include field change thresholds.

[0047] In one implementation of the first aspect, it further includes: a network health metric evaluation model; the network health metric evaluation model includes: a network element health calculation module, a network link health calculation module, and a network operation status trend evaluation module;

[0048] The network element health calculation module calculates the network element health of the i-th network element as follows:

[0049] HealthScore_i = max(0, 100 - ∑(Penalty_severity × e^(-λ·Δt)));

[0050] Wherein, Penalty_severity represents the basic deduction value for alarm severity (e.g., CRITICAL alarm deducts 20 points, WARNING deducts 5 points); λ represents the attenuation coefficient, usually taken as 0.1~0.3, which controls the rate at which the deduction decreases over time; Δt represents the time difference between the current time and the time the alarm occurred, with 100 points being the initial full score, and the result after deduction is limited to between 0 and 100.

[0051] The network link health calculation module calculates the network link health as follows:

[0052] SlotScore=∑metric(SubScore_metric×W_metric);

[0053] Where SubScore_metric represents the score of each sub-item, W_metric represents the weight coefficient of the corresponding sub-item, ∑W=1, W_metric is dynamically adjusted according to the device type; ∑metric represents the sum of all indicator functions;

[0054] The network operation status trend evaluation module calculates the network operation status trend as: H(t) = BasePenalty;

[0055] Where t is the time point when the alarm occurs; BasePenalty represents a fixed deduction value determined by the alarm level; CRITICAL indicates the use of the BaseCriticalPenalty value; MAJOR indicates the use of the BaseMajorPenalty value; MINOR indicates the use of the BaseMinorPenalty value; and WARNING indicates the use of the BaseWarningPenalty value (subject to the cumulative upper limit).

[0056] The network health metric evaluation model is: OverallHealthScore = w1 × Avg(HealthScore_i) + w2 × SlotScore + w3 × H(t); where w1, w2, and w3 are the weight coefficients of network element health, network link health, and network operation status trend, respectively, and the sum of w1, w2, and w3 is 1; w1, w2, and w3 can be dynamically adjusted according to the network type.

[0057] Secondly, this application provides a method for real-time monitoring of the operating status of a power communication SDH network, including:

[0058] According to the preset strategy, network element information, performance information, alarm information and equipment information of the power communication SDH network are collected. The multi-source heterogeneous data collected is standardized by the protocol parsing engine module to obtain structured data.

[0059] The structured data is parsed, correlated, and identified to obtain key business entities;

[0060] The key business entities are serialized and compressed to obtain lightweight packaged data;

[0061] Real-time rendering is performed based on the lightweight encapsulated data to obtain a real-time visualized operating status of the power communication SDH network.

[0062] As described above, the real-time monitoring system and method for the operation status of the power communication SDH network described in this application has the following beneficial effects:

[0063] This application proposes a multi-protocol adaptive acquisition module, which performs lifecycle management and fault-tolerant scheduling for specialized acquisition tasks such as network element, performance, alarm, and device acquisition based on preset strategies, ensuring the orderliness and reliability of data acquisition. The protocol parsing engine module converts heterogeneous protocols (such as XML / SOAP) into structured data, solving the format compatibility problem of multi-source heterogeneous data. The multi-protocol adaptive acquisition module effectively solves the data silo problem and endows the system with excellent scalability, allowing the addition of new data sources without disrupting the core processes.

[0064] The intelligent data filtering and deconstruction module (intelligent filtering processor) described in this application processes the original data (i.e. structured data) of 218 fields into core data (i.e. standard core data) of 32 fields, enabling real-time data stream processing capability to reach 1000 records / second, and optimizing memory usage to 30% of the original data.

[0065] This application identifies three core issues through root cause analysis: format heterogeneity, chaotic field mapping, and time base differences. Subsequently, it achieves basic optimizations through architecture reconstruction, including a unified data access layer (i.e., a multi-protocol adaptive acquisition module) that reduces parsing time by 82.5%, an intelligent field mapping engine (i.e., an intelligent data filtering and deconstruction module) that improves accuracy by 28.9%, and a lightweight transmission mechanism (i.e., a lightweight encapsulation module) that reduces bandwidth usage by 66.7%.

[0066] This application bypasses the kernel protocol stack by using a user-space RDMA protocol stack in the user-space network protocol stack unit (transport layer), and combines hardware clock synchronization (PTP) to compress the transmission latency to 0.8ms and reduce the timestamp error from ±8.7ms to ±0.05ms. The user-space network protocol stack unit bypasses the operating system kernel and processes network packets directly in user space, thereby solving the bottleneck problem of traditional kernel protocol stacks in high-performance scenarios.

[0067] This application reduces unnecessary rendering overhead by using a multi-threaded rendering pipeline unit and a GPU asynchronous computation unit. The multi-threaded rendering pipeline unit (rendering layer) separates parsing / computation / rendering tasks through multi-threading, and, in conjunction with GPU asynchronous computation (Compute Shader), reduces pipeline latency from 26.7ms to 3.1ms.

[0068] The real-time monitoring system for the operation status of the SDH power communication network described in this application achieves millisecond-level rendering optimization. The core of this system lies in its adoption of key technologies such as user-space network driver, simplified binary protocol, multi-threaded parallel processing, and dynamic vertical synchronization. This approach breaks through bottlenecks in various aspects, significantly compressing end-to-end latency to 4.25 milliseconds, an improvement of 95%, thus providing a solid architectural foundation for real-time interaction. Attached Figure Description

[0069] Figure 1 The diagram shown is a schematic representation of an implementation architecture of the real-time monitoring system for the operation status of the SDH power communication network described in this application embodiment.

[0070] Figure 2 The diagram shown is a schematic representation of an implementation structure of the real-time monitoring system for the operation status of the SDH power communication network described in this application embodiment.

[0071] Figure 3 The diagram shown is a schematic representation of an implementation structure of the multi-protocol adaptive acquisition module described in an embodiment of this application.

[0072] Figure 4 The diagram shown is a schematic representation of an implementation structure of the protocol parsing engine module described in an embodiment of this application.

[0073] Figure 5The diagram shown is a schematic representation of an implementation structure of the intelligent data filtering and deconstruction module described in an embodiment of this application.

[0074] Figure 6 The diagram shown is a schematic representation of an implementation structure of the data association engine module described in this application embodiment.

[0075] Figure 7 The diagram shown is a schematic representation of an implementation structure of the field recognition engine module described in this application embodiment.

[0076] Figure 8 The diagram shown is a schematic representation of an implementation structure of the lightweight packaging module described in this application embodiment.

[0077] Figure 9 The diagram shown is a schematic representation of an implementation structure of the rendering module described in an embodiment of this application.

[0078] Figure 10 The diagram shown is a schematic representation of an implementation structure of the network health quantification evaluation model described in this application embodiment.

[0079] Figure 11 This diagram illustrates an implementation flow of the real-time monitoring method for the operating status of a power communication SDH network as described in an embodiment of this application.

[0080] Figure 12A This is a schematic diagram showing one way of displaying the data flow in the real-time monitoring system for the operation status of the SDH power communication network described in this application embodiment.

[0081] Figure 12B This is a schematic diagram illustrating another display method of the data flow in the real-time monitoring system for the operation status of the SDH power communication network described in this application embodiment.

[0082] Figure 12C This is a schematic diagram illustrating the third display method of the data flow in the real-time monitoring system for the operation status of the SDH power communication network described in this application embodiment.

[0083] Figure 12D The diagram shown is a schematic diagram of the optimized system architecture of the real-time monitoring system for the operation status of the SDH power communication network described in this application embodiment.

[0084] Figure 12E The diagram shows a comparison of the system architecture before and after optimization of the real-time monitoring system for the operation status of the SDH power communication network described in this application embodiment.

[0085] Figure 12F The diagram shows the optimization of the effects at each stage of the real-time monitoring system for the operation status of the SDH power communication network described in this application embodiment.

[0086] Figure 12G This diagram illustrates an implementation architecture of a network health quantification evaluation model for a real-time monitoring system for the operation status of an SDH power communication network as described in this application embodiment.

[0087] Figure 13 The diagram shown is a flowchart of the network operation trend evaluation process of the real-time monitoring system for the operation status of the SDH power communication network described in this application embodiment. Detailed Implementation

[0088] The following specific examples illustrate the implementation of this application. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be noted that, unless otherwise specified, the following embodiments and features in the embodiments can be combined with each other.

[0089] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this application. Therefore, the drawings only show the components related to this application and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0090] The technical solutions in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0091] like Figure 1 As shown, this application provides a real-time monitoring system for the operation status of a power communication SDH network. The hardware architecture of this system follows a layered design. Network element-level data starts from the underlying SDH physical network (including network elements, optical cables, and ports) and is collected by the northbound interface of the network management system to the data processing server. After completing the normalization (i.e., protocol parsing), correlation analysis (i.e., data correlation), and health score calculation of key heterogeneous data (such as alarm data and performance data), the data is finally pushed to the PC workstation for 3D panoramic monitoring and HoloLens 2 device for mixed reality immersive viewing, forming a closed-loop monitoring system from the physical world to the digital space. Figure 1In the SDH entity network, network element-level data such as SNMP / TL1 are output. SNMP (Simple Network Management Protocol) is a standard protocol defined by the Internet Engineering Task Force (IETF) for network device management and belongs to the application layer of the TCP / IP protocol suite. TL1 (Transaction Language 1) is a telecommunications network management protocol, similar to SNMP. The northbound interface of the network management system outputs full alarm and performance data via HTTP+XML / JSON. HTTP (Hypertext Transfer Protocol) is the cornerstone of the Web, defining the communication rules between clients (browsers / apps) and servers. XML (eXtensible Markup Language) is a markup language for storing and transmitting structured data. JSON (JavaScript Object Notation) is a lightweight data exchange format. The optimized data stream output from the data acquisition and processing server is transmitted to the monitoring and presentation terminal via the SDH-BNP (Binary Network Protocol).

[0092] The real-time monitoring system for the operation status of the SDH power communication network described in this application is a core data processing overview architecture that constructs an end-to-end normalized pipeline. First, this pipeline takes multi-source heterogeneous data as input, which undergoes preliminary standardization via a protocol adaptation layer, eliminating differences in underlying communication protocols. Then, the data enters the core processing unit, the filtering and deconstruction layer, where a parsing, identification, and association engine extracts key business entities from the complex multi-source raw information, completing the first refinement of the data model. Finally, a lightweight encapsulation layer performs serialization and compression optimization on the data, significantly reducing transmission overhead, thereby providing efficient and clean structured data support for the upper-layer rendering engine, laying the foundation for the entire system to achieve low-latency, high-fidelity visualization.

[0093] The following is combined Figures 2 to 11 The technical solutions in the embodiments of this application will be described in detail.

[0094] like Figure 2 As shown, this embodiment provides a real-time monitoring system 200 for the operation status of a power communication SDH network, including: a multi-protocol adaptive acquisition module 210, an intelligent data filtering and deconstruction module 220, a lightweight encapsulation module 230, and a rendering module 240.

[0095] The multi-protocol adaptive acquisition module 210 collects network element information, performance information, alarm information, and equipment information of the power communication SDH network according to a preset strategy. The acquired multi-source heterogeneous data is then standardized by the protocol parsing engine module to obtain structured data. Specifically, the multi-source heterogeneous data (including network element information, performance information, alarm information, and equipment information) serves as input and undergoes preliminary standardization via the protocol adaptation layer (i.e., the protocol parsing engine module), eliminating differences in the underlying communication protocols.

[0096] The intelligent data filtering and deconstruction module 220 parses, identifies, and associates the structured data to obtain key business entities. Specifically, the structured data enters the core processing unit—the filtering and deconstruction layer (i.e., the intelligent data filtering and deconstruction module)—where a parsing, identification, and association engine extracts key business entities from the complex multi-source raw information.

[0097] The lightweight packaging module 230 performs serialization and compression optimization on the key business entities to obtain lightweight packaged data.

[0098] The rendering module 240 performs real-time rendering based on the lightweight encapsulated data to obtain a real-time visualized operating status of the power communication SDH network.

[0099] This application faces the dual challenges of the complexity of multi-source data acquisition and the difficulty of deconstructing and filtering raw data into lightweight data.

[0100] The complexities and challenges of multi-source data acquisition include:

[0101] 1) Diverse acquisition protocols: The system needs to process 5 different communication interfaces in the northbound XML protocol API interface at the same time, and the conversion overhead causes the data acquisition delay to accumulate to ≥38ms.

[0102] 2) Significant differences in data volume: On average, a single full-port data collection generates 2.4MB of raw data, of which only 38% is valid data, and invalid data transmission results in bandwidth waste of ≥1.5MB / time.

[0103] 3) Data acquisition timing is out of sync: There is a maximum deviation of 380ms in the acquisition completion time of the 32 ports, and the timing misalignment causes a status judgment distortion rate of ≥23%.

[0104] The challenges of deconstructing and filtering raw data into lightweight data include:

[0105] 1) Difficulty in identifying redundant fields: The original XML data contains 218 fields, but only 32 core fields are actually rendered. Traditional parsing methods cannot intelligently identify key fields, resulting in low parsing efficiency.

[0106] 2) Lack of data correlation: Device alarm data, performance data, and configuration data are scattered across different interfaces, lacking a unified correlation mechanism, resulting in a data integration error rate of ≥15%.

[0107] 3) Stringent real-time requirements: The end-to-end latency from data acquisition to rendering and display must be ≤2 seconds, and the traditional layer-by-layer parsing method cannot meet the real-time requirements.

[0108] This application proposes a collaborative scheduling mechanism at the data acquisition level, the core of which lies in a unified acquisition orchestration engine (i.e., a multi-protocol adaptive acquisition module). This multi-protocol adaptive acquisition module performs lifecycle management and fault-tolerant scheduling for specific acquisition tasks such as network elements, performance, alarms, and devices according to preset strategies, ensuring the orderliness and reliability of data acquisition.

[0109] like Figure 3 As shown, in one embodiment of this application, the multi-protocol adaptive acquisition module 210 includes: an acquisition scheduler 211, a network data acquisition module 212, a performance data acquisition module 213, an alarm data acquisition module 214, a device data acquisition module 215, and a protocol parsing engine module 216.

[0110] The data acquisition scheduler 211 controls the network data acquisition module 212 to acquire network element information of the power communication SDH network, parse the equipment list and basic information in the network element information, and generate a network data data view.

[0111] Specifically, a network element refers to an SDH device, namely a digital twin model device; network element information includes data reflecting the overall operating status of the network element device, such as: device communication status data, device basic information and resource status data, power supply and environment status data, clock synchronization status data, protection switching status data, etc.

[0112] The data item in the device communication status data is "Network Element Connection Status (e.g., ConnectivityStatus)". It indicates whether the network management system can establish a communication connection with this network element device. The status it reflects is either Online (normal) or Offline (disconnected). Device power failure, interruption of the device's control link, etc., will result in disconnection.

[0113] The data items for basic device information and resource status are "Device Model, Software Version, and SystemUpTime". The device model and version are used to identify device capabilities and compatibility. A long and stable uptime generally indicates good device status. This reflects the device's identity and software stability.

[0114] The power supply and environmental status data items are "Power Module Status (Primary / Backup), Fan Status, and Internal Equipment Temperature." These represent the basic operating environment of the monitored equipment. Power module failure, fan stoppage, and excessively high temperatures can all jeopardize equipment safety. The reflected statuses are: Normal, Fail, and Degrade.

[0115] The data items in the clock synchronization status data are "current clock source priority and clock state (locked, held, free oscillation)". This means that SDH network elements require high-precision clock synchronization. If the clock source frequently switches or enters free oscillation mode, it indicates a problem on the clock synchronization link. This status reflects the quality of clock synchronization, which is the cornerstone of network performance.

[0116] The data items for protection switching status data are "Multiplex section protection ring status, subnet connection protection status, and switching event record (reason, time, type)". Their meaning reflects whether the network-level self-healing capability has been activated, and the reason for activation. The reflected status indicates whether a major network failure has occurred (such as fiber optic cable interruption), and whether the protection mechanism is functioning correctly.

[0117] The acquisition scheduler 211 controls the performance data acquisition module 213 to acquire the performance information of the power communication SDH network, parse the acquired optical power and / or bit error rate in the performance information, and generate performance trend data.

[0118] The data acquisition scheduler 211 controls the alarm data acquisition module 214 to acquire alarm information from the power communication SDH network, extract real-time alarms and historical alarms from the alarm information, and generate alarm statistics.

[0119] The data acquisition scheduler 211 controls the equipment data acquisition module 215 to acquire the equipment configuration and status information of the power communication SDH network and generate the equipment health status.

[0120] This application selects three of the most important data categories based on the northbound interface of the network management system: alarms, performance, and configuration. These three categories together constitute a complete information map reflecting the operating status of network elements and boards. Specifically, single-site equipment (network element) operating data includes: equipment indicator light status, equipment temperature data, board slot configuration, and photoelectric port occupancy status; link operating data between two interconnected sites includes: real-time "receive / emit power" data on the line side of each network element, real-time "bit error" data for uplink and downlink of each network element (including: bit error rate, ES, SES, UES, EC), and "switchover" protection information; alarm information for each network element includes various alarm levels. For example, Table 1 shows an exemplary data type for data collection.

[0121] Table 1: Network Operation Status Data Set (Northbound) for Network Management

[0122]

[0123] The protocol parsing engine module 216 standardizes the multi-source heterogeneous data, eliminating the differences in the underlying communication protocols of the multi-source heterogeneous data and obtaining structured data. The multi-source heterogeneous data includes network data views, performance trend data, alarm statistics, and / or device health status. Specifically, the protocol parsing engine module is responsible for converting multi-source heterogeneous data with heterogeneous protocols into structured data, solving the format compatibility problem of multi-source heterogeneous data. For example, the protocol parsing engine module converts heterogeneous protocols (such as XML / SOAP) into structured data, solving the format compatibility problem of multi-source heterogeneous data.

[0124] The multi-protocol adaptive acquisition module described in this application is a multi-interface acquisition engine that supports adaptive switching of 5 interfaces, an automatic retry mechanism for acquisition failure (3 retries), and a protocol anomaly detection accuracy of 99.5%.

[0125] Each acquisition module specializes in a specific data domain, adhering to the principle of high cohesion. The data aggregation module combines and aligns the data output from the network data acquisition module, performance data acquisition module, alarm data acquisition module, and device data acquisition module at the data aggregation point, forming a unified business data context. The multi-protocol adaptive acquisition module effectively solves the data silo problem and gives the system excellent scalability, allowing the addition of new data sources without disrupting the core processes.

[0126] like Figure 4 As shown, in one embodiment of this application, the protocol parsing engine module 216 includes: a raw response receiving unit 2161, a preprocessing and verification unit 2162, a namespace parsing unit 2163, an XPath extraction unit 2164, and a normalized output unit 2165.

[0127] The raw response receiving unit 2161 captures multi-source heterogeneous data returned by the server through UnityWebRequest, namely heterogeneous protocol (SOAP / XML) data (such as device list, alarm information).

[0128] The preprocessing and verification unit 2162 checks the integrity of the heterogeneous protocol data (e.g., whether it is empty or conforms to the XML specification), filters invalid characters, and outputs standardized XML data. Specifically, the preprocessing and verification unit 2162 checks whether the heterogeneous protocol data is empty; if so, it considers the data invalid. Otherwise, it checks whether the heterogeneous protocol data conforms to the XML specification; if it does not conform, it considers the data invalid; otherwise, it considers the data valid.

[0129] Namespace resolution unit 2163 registers XML namespaces (such as soapenv, v11) and resolves tag conflicts (document 6, document 11).

[0130] The XPath extraction unit 2164 uses predefined XPath expressions to locate target nodes (such as / / v11:me / v12:name) in standardized XML data, queries the target nodes through the XPath engine, and extracts key information (device name, IP, etc.) of the target nodes; the key information of the target nodes includes text content or attribute values.

[0131] The standardized output unit 2165 maps the extracted key information into a unified output format (such as JSON) for use by downstream modules; the unified output format is a structured key-value pair format, and the field names contained in the unified output format all follow a predefined data dictionary.

[0132] For example: The original XML response contains the device name. <name>and IP address <ipaddress>After the tags are parsed by the engine, the following structured data is output:

[0133] {

[0134] "deviceName": "Router_A",

[0135] IP address: 192.168.1.1

[0136] "status": "online"

[0137] }

[0138] In the protocol parsing engine module, the XPath extraction unit is responsible for locating and extracting key information from preprocessed heterogeneous protocol data (such as XML / SOAP).

[0139] In one embodiment of this application, the extraction process of the XPath extraction unit is implemented based on XPath expression query, and the specific steps are as follows:

[0140] Input: Receives standardized XML data from the preprocessing and validation unit (invalid characters have been filtered and integrity has been verified).

[0141] Namespace resolution: First, register an XML namespace (such as soapenv, v11) to resolve tag conflicts.

[0142] XPath Expression Application: Use predefined XPath expressions to locate target nodes. For example, the expression / / v11:me / v12:name is used to extract the device name node, and / / v11:ipaddress is used to extract the IP address node.

[0143] Node extraction: Query nodes using the XPath engine to obtain the node's text content or attribute values ​​(i.e., key information).

[0144] Output: The extracted raw information (such as device name, IP address, and other text content, which are the key information) is passed to the standardized output unit.

[0145] For example: Suppose the original XML response contains the following fragment:

[0146] <v11:me>

[0147] <v12:name> Router_A< / v12:name>

[0148] <v11:ipaddress> 192.168.1.1< / v11:ipaddress>

[0149] < / v11:me> .

[0150] The XPath extraction unit uses the expressions / / v11:me / v12:name and / / v11:ipaddress to extract Router_A and 192.168.1.1, respectively. This process demonstrates the transformation from the raw response to the location of key information.

[0151] The standardized output unit maps the key information output by the XPath extraction unit into a unified format, ensuring consistency in downstream module processing.

[0152] In one embodiment of this application, the output format of the standardized output unit is a structured key-value pair format, typically using JSON or a similar lightweight data format. The output format of the standardized output unit is described as follows: the output is a JSON object containing fields such as deviceName, ip, status, etc., and all field names follow a predefined data dictionary. The design principle of the output format is to eliminate differences in heterogeneous protocols, retain only core fields, and reduce redundancy.

[0153] For example: The input is the extracted raw data (Device Name = Router_A, IP = 192.168.1.1, Status = online). The standardized output unit generates JSON in the following uniform format:

[0154] {

[0155] "deviceName": "Router_A",

[0156] IP address: 192.168.1.1

[0157] "status": "online"

[0158] }

[0159] like Figure 5 As shown, in one embodiment of this application, the intelligent data filtering and deconstruction module 220 includes: a data aggregation module 221, a data association engine module 222, and a field recognition engine module 223.

[0160] The data aggregation module 221 merges and spatiotemporally aligns the structured data output by the multi-protocol adaptive acquisition module at the data aggregation point to form a unified business data context. Here, the data aggregation point typically refers to a physical or logical node configured to receive identification data / sensor data from multiple terminal devices, perform deduplication, compression, or protocol conversion, and then transmit it to the central server.

[0161] The data association engine module 222 integrates relevant scattered data from the business data context into a device panoramic view through primary key matching, time-series alignment, and multi-source fusion; it integrates scattered data into a device panoramic view. Distributed / Fragmented Data refers to a collection of data that is physically or logically distributed across multiple locations, systems, or formats, and a complete view cannot be obtained through a single access point.

[0162] The field recognition engine module 223, based on predefined business rules and data dictionaries, filters redundant data in the device panoramic view through intelligent filtering strategies, performs key field recognition, redundant information removal, and semantic mapping of heterogeneous names to obtain standard core data.

[0163] The intelligent data filtering and deconstruction module filters redundant data and extracts key fields through intelligent filtering strategies. This application effectively solves the data silo problem through a data aggregation module and endows the system with excellent scalability, allowing new data sources to be added without disrupting core processes. The data association engine module integrates structured data (device configuration, alarms, performance) to form a unified context. This data association engine module transforms isolated fragments of individual device data into complete business entities containing configuration, status, and history. The field recognition engine module, based on predefined business rules and a data dictionary, performs key field identification, redundant information removal, and semantic mapping of heterogeneous naming. For example, it unifies device manufacturer-specific identifiers into a standard data model within the system, realizing the transformation from raw chaotic data (i.e., raw chaotic structured data) to an extremely concise and highly standardized core dataset, greatly reducing the processing complexity and load of downstream systems.

[0164] The intelligent data filtering and deconstruction module (intelligent filtering processor) described in this application processes the original data (i.e. structured data) of 218 fields into core data (i.e. standard core data) of 32 fields, enabling real-time data stream processing capability to reach 1000 records / second, and optimizing memory usage to 30% of the original data.

[0165] like Figure 6 As shown, in one embodiment of this application, the data association engine module 222 includes: a primary key matching unit 2221, a time sequence alignment unit 2222, and a multi-source fusion unit 2223.

[0166] The primary key matching unit 2221 uses the device ID or IP address as a unique identifier to associate configuration data, alarm data, and performance data, and obtains a set of key-value pairs as the data format after primary key matching.

[0167] Furthermore, the primary key matching unit 2221 creates association keys, linking data from different sources through a common "primary key". The most typical key is [network element ID, slot ID, port ID, timestamp].

[0168] The timing alignment unit 2222 sorts events by timestamp (such as matching alarm occurrence time with performance fluctuation time) to form time series data, and obtains the time-aligned data format as an ordered list.

[0169] The multi-source fusion unit 2223 integrates scattered data (such as key-value pair sets, ordered lists, etc.) to form a panoramic view of the device, transforming individual device data from isolated fragments into complete entities containing configuration, status, and history, and obtaining a flat structure with 32 fields in the simplified data class format after multi-source fusion.

[0170] Furthermore, the multi-source fusion unit 2223 performs data fusion. For example, it can associate a "LOS" alarm with the "received optical power" performance data of the same port at the same time to verify the authenticity of the alarm (the optical power is indeed too low).

[0171] In this application, alarm data, performance data, and configuration data from the network management northbound interface come from different data streams or database tables, and the data is isolated and unrelated. The data association engine integrates the scattered data into a panoramic view of the device through primary key matching, time-series alignment, and multi-source fusion. Examples of data formats at each stage are illustrated below.

[0172] For example: The data generated after primary key matching is in JSON format:

[0173] {

[0174] "deviceID": "D001",

[0175] "config": {"type": "Router", "version": "v2.1"},

[0176] "alarms": [

[0177] {"id": "A1", "severity": "CRITICAL", "time": "2023-10-12T15:30:00Z"}

[0178] ],

[0179] "performance": {

[0180] "txPower": -10.5,

[0181] "rxPower": -22.3

[0182] }

[0183] }

[0184] The time-aligned data format is as follows: [

[0186] {

[0187] "timestamp": "2023-10-12T15:30:00Z",

[0188] "event": "Alarm triggered",

[0189] "deviceID": "D001"

[0190] },

[0191] {

[0192] "timestamp": "2023-10-12T15:31:00Z",

[0193] "event": "performance fluctuation",

[0194] "deviceID": "D001"

[0195] } ]

[0197] After multi-source fusion, a panoramic view of the device is generated, retaining only the core fields in a flat structure, reflecting the transformation from isolated data to a complete entity.

[0198] For example, the simplified data format output after multi-source fusion (compressed from 218 fields to 32 fields) is as follows:

[0199] {

[0200] "deviceID": "D001",

[0201] IP address: 192.168.1.1

[0202] "healthScore": 85.5,

[0203] "keyMetrics": {

[0204] "txPower": -10.5,

[0205] "rxPower": -22.3,

[0206] "errorRate": 1.2e-12

[0207] }

[0208] }

[0209] like Figure 7 As shown, in one embodiment of this application, the field recognition engine module 223 includes: an input unit 2231, a rule application unit 2232, and an output unit 2233.

[0210] Input unit 2231 receives structured data containing 218 fields output by the protocol parsing engine module. Specifically, it receives a device panorama view output by the data association engine module.

[0211] The rule application unit 2232 loads the business rule dictionary (i.e., the field mapping table), performs field-by-field priority filtering (e.g., extracting alarm-related fields first, then processing performance data), applies threshold checks and redundancy merging, and obtains structured data after rule processing. The rule application unit filters redundant data in the device panoramic view through intelligent filtering strategies, extracts key fields, and obtains standard core data (32 fields).

[0212] The output unit 2233 generates a simplified core dataset (i.e. a set of standard core data) containing only 32 fields based on the structured data processed by the rules.

[0213] This application utilizes a field recognition engine to transform chaotic raw data into an extremely concise and highly standardized core dataset, significantly reducing the processing complexity and load of downstream systems.

[0214] For example, the system converts manufacturer-specific identifiers into a standardized internal data model. The raw data has 218 fields, including device name, IP address, transmit optical power, receive optical power, temperature, and / or other information. After filtering the raw data using a field recognition engine, core data is output; this core data includes device identifier, communication IP address, transmit value, receive value, and temperature. Rendered data is then obtained based on this core data mapping. This rendered data includes device identifier, IP address, transmit optical power, receive optical power, and temperature value.

[0215] In this application, the field recognition engine module performs key field identification, redundancy removal, and semantic mapping based on predefined business rules and a data dictionary. Deconstruction process: Taking the original XML as an example, after filtering and deconstructing 218 fields, only 32 core fields are retained.

[0216] The recognition schemes of the field recognition engine module mainly include three categories:

[0217] 1) Business priority filtering: Dynamically adjust the collection strategy according to business value, and prioritize the retention of high-priority fields (such as alarm information CRITICAL / WARNING over log INFO / DEBUG).

[0218] 2) Dynamic threshold filtering: Only retain abnormal data that exceeds the preset range (such as temperature > 55℃), which is achieved based on threshold comparison.

[0219] 3) Redundancy elimination: Merge duplicate fields (such as similar alarms from multiple interfaces) and identify duplicates through hashing or pattern matching.

[0220] The software execution flow of the field recognition engine module is a chained process, including the following steps S1~S3.

[0221] S1, Input: Receive structured data (such as a JSON object with 218 fields) from the protocol parsing engine.

[0222] S2, Rule Application:

[0223] Load the business rule dictionary (such as the field mapping table defined in the initial draft).

[0224] Apply priority filtering to each field: For example, extract alarm-related fields first, and then process performance data.

[0225] Apply threshold checks: For example, if the optical power value is within the normal range (-10dBm to -25dBm), it is marked as redundant.

[0226] Redundancy merging: Duplicate entries are merged using a unique identifier (such as a device ID).

[0227] S3, Output: Generates a streamlined core dataset (only 32 fields), retaining only key fields such as device identifier, IP address, and optical power.

[0228] In one embodiment of this application, taking a device fault diagnosis scenario as an example, the following steps can be achieved through this application:

[0229] Protocol parsing: The multi-protocol adaptive acquisition module extracts device alarm information (such as CPU overheating) from SOAP responses.

[0230] Data association: The data aggregation module and the data association engine module associate the device's real-time temperature data (35°C) and historical alarm records.

[0231] Filtering optimization: The field recognition engine module filters out non-critical fields (such as vendor private logs) and retains only core data such as temperature and alarm type.

[0232] Final output: Generate actionable and clickable fault data, combine with algorithms to achieve health monitoring, and guide maintenance personnel to quickly locate problems.

[0233] In one embodiment of this application, Figure 12A This is a schematic diagram showing one way of displaying the data flow in the real-time monitoring system for the operation status of the SDH power communication network described in this application embodiment. Figure 12B This is a schematic diagram illustrating another display method of the data flow in the real-time monitoring system for the operation status of the SDH power communication network described in this application embodiment. Figure 12C This is a schematic diagram illustrating the third display method of the data flow in the real-time monitoring system for the operation status of the SDH power communication network described in this application embodiment. Figure 12D The diagram shown is a schematic representation of the optimized system architecture of the real-time monitoring system for the operation status of the SDH power communication network described in this application embodiment. In this diagram, GPU stands for Graphics Processing Unit, and PTP stands for Precision Time Protocol. Figure 12E The diagram shows a comparison of the system architecture before and after optimization of the real-time monitoring system for the operation status of the SDH power communication network described in this application embodiment. TCP / IP is short for Transmission Control Protocol / Internet Protocol, also known as a network communication protocol; XML (eXtensible Markup Language) is a markup language used for storing and transmitting structured data; Unity refers to the Unity engine; GPU stands for Graphics Processing Unit; RDMA stands for Remote Direct Memory Access; SDH-BNP stands for Binary Network Protocol; PTP stands for Precision Time Protocol; and GPU stands for Graphics Processing Unit. Figure 12F The diagram shows the optimization of the effects at each stage of the real-time monitoring system for the operation status of the SDH power communication network described in this application embodiment. Figure 12G This diagram illustrates an implementation architecture of a network health quantification evaluation model for a real-time monitoring system for the operation status of an SDH power communication network as described in this application embodiment.

[0234] like Figures 12A-12G As shown, this application significantly improves acquisition efficiency through a multi-protocol adaptive acquisition module, with the improvement effect detailed in Table 2. The intelligent data filtering and deconstruction module improves filtering accuracy, with key field identification accuracy increasing from 72% to 98.5%, data association accuracy from 85% to 99.2%, and real-time performance compliance from 65% to 99.8%.

[0235] Under extreme scenario testing, this application maintains a data acquisition success rate of 98% with network bandwidth limitations (1Mbps); in high-concurrency scenarios (1000+ devices), data processing latency fluctuation is ≤±1.2ms; and in the case of abnormal data injection (20% dirty data), the system fault tolerance rate is 95.3%.

[0236] Table 2: Effect of Improved Data Acquisition Efficiency

[0237]

[0238] This application achieves a significant improvement in delay compression performance through a lightweight packaging module, and the improvement effect is detailed in Table 3.

[0239] Table 3: Comparison of Delay Compression Performance

[0240]

[0241] Table 4: Performance Parameter Description of Delay Compression and Comparison with the Old Solution

[0242]

[0243] As shown in Table 4, the total delay of the old solution is 38ms + 12ms + 26.7ms = 76.7ms;

[0244] The total latency of the new solution is 0.8ms + 0.3ms + 5ms = 6.1ms;

[0245] Delayed compression ratio = (1 - 6.1 / 76.7) × 100% ≈ 92.0%;

[0246] This formula guided the end-to-end reconstruction from the transport protocol to the rendering pipeline, ultimately successfully compressing the total system latency from the theoretical 76.7ms to 6.1ms, far exceeding the target of 0.1 seconds (100ms), laying the foundation for achieving millisecond-level interaction.

[0247] This application adheres to the value-oriented data collection principle, dynamically adjusting the collection strategy based on business value, with key data collection priority at 100%. This application follows intelligent filtering criteria, employing intelligent filtering strategies to identify core fields, achieving a filtering accuracy rate of ≥95%. This application adheres to the lightweight transmission principle, with a data compression rate of ≥70% and end-to-end latency of ≤15ms.

[0248] This application optimizes data acquisition efficiency, reducing data processing time from 85ms to 12ms within a 15-minute acquisition cycle, supporting real-time monitoring; it reduces bandwidth costs, decreasing invalid data transmission by 80% and annual bandwidth costs by 60%; it accelerates fault location, with intelligent data correlation reducing fault location time from hours to minutes. This application significantly enhances system reliability, improves fault tolerance mechanisms, enabling stable system operation even with 20% abnormal data injection, reducing business impact to less than 5%; and it optimizes resource utilization, reducing CPU utilization from 85% to 45% and memory usage by 60%.

[0249] This application identifies three core issues through root cause analysis: format heterogeneity, chaotic field mapping, and time base discrepancies. Subsequently, fundamental optimizations are achieved through architectural restructuring, including an 82.5% reduction in parsing time with a unified data access layer (i.e., a multi-protocol adaptive acquisition module), a 28.9% improvement in accuracy with an intelligent field mapping engine (i.e., an intelligent data filtering and deconstruction module), and a 66.7% reduction in bandwidth usage with a lightweight transmission mechanism (i.e., a lightweight encapsulation module). Finally, industrial deployment verification demonstrates 100% stability compliance in high-concurrency scenarios, a 92% automatic abnormal data repair rate, and cross-platform consistency differences ≤0.1%.

[0250] In terms of industrial value realization, operational efficiency has been significantly improved, with data preprocessing time reduced from 85ms to 12ms, supporting real-time status updates; system stability has been enhanced, with automatic fault tolerance for abnormal data reducing system downtime by 95%; breakthroughs have been achieved in development standardization, with unified data processing specifications shortening the development cycle for new equipment integration by 70%. Through a three-tiered technical architecture, heterogeneous data normalization has been upgraded from simple format conversion to an intelligent processing system, providing a reliable data foundation for real-time data rendering.

[0251] like Figure 8 As shown, in one embodiment of this application, the lightweight packaging module 230 includes: a user-space network protocol stack unit 231, a binary serialization protocol unit 232, and a hardware clock synchronization unit 233.

[0252] User-space network protocol stack unit 231 uses a user-space RDMA protocol stack to bypass the kernel protocol stack and directly process the network data packets of the lightweight encapsulated data in user space.

[0253] The binary serialization protocol unit 232 uses the binary protocol SDH-BNP to replace XML parsing and extracts fields from the network data packets of the lightweight encapsulated data.

[0254] The hardware clock synchronization unit 233 synchronizes the system clocks of the sending and receiving ends of the network data packets based on PTP (Precision Time Protocol).

[0255] In this application, the user-space network protocol stack unit (transport layer) bypasses the kernel protocol stack by using a user-space RDMA protocol stack. Combined with hardware clock synchronization (PTP), the transmission latency is compressed to 0.8ms, and the timestamp error is reduced from ±8.7ms to ±0.05ms. The user-space network protocol stack unit bypasses the operating system kernel and processes network data packets directly in user space, thereby solving the bottleneck problem of traditional kernel protocol stacks in high-performance scenarios.

[0256] Specifically, the user-space network protocol stack unit is used to implement transmission optimization, including the RDMA driver subunit. The RDMA (Direct Memory Access) driver subunit disables the TCP / IP protocol stack in the Linux kernel and transfers data via RDMA network card direct memory access (DMA), reducing the number of CPU interrupts. DMA (Direct Memory Access) is a technology that allows peripherals to exchange data directly with memory without CPU intervention, thereby significantly improving data transfer efficiency.

[0257] Traditional TCP / IP transmission process: application memory → socket buffer → kernel TCP stack → network card buffer → network → peer network card → kernel TCP stack → socket buffer → application memory. This transmission process involves 6 copies and 4 context switches, resulting in high latency.

[0258] RDMA transfer process: application memory → network card → network → peer network card → peer application memory. This transfer process involves 2 copies and 0 context switches, with zero CPU intervention.

[0259] The PTP hardware clock synchronization unit (i.e., hardware clock synchronization unit) is deployed with a network card that supports IEEE 1588, and achieves microsecond-level clock synchronization through a GPS timing module, while the software layer compensates for network jitter errors.

[0260] In this application, the binary serialization protocol unit (protocol layer) replaces XML parsing with the binary protocol SDH-BNP (Binary Network Protocol), reducing the field extraction time from 12ms to 0.3ms (a reduction of 97.5%), and the pre-compiled XPath caching improves query efficiency by 90%.

[0261] Specifically, the binary serialization protocol unit is used to implement protocol optimization, including the Protocol Buffers encoding subunit and the XPath buffer pool.

[0262] Protocol Buffers encoding subunits define fixed-length protocols for fields such as temperature (2 bytes) and optical power (4 bytes) to compress redundant data (such as timestamp difference encoding).

[0263] In C#, the XPath cache pool maintains a compiled cache of frequently accessed XPath paths, allowing repeated queries to directly access pre-compiled node pointers. C# is a modern, general-purpose object-oriented programming language developed by Microsoft.

[0264] like Figure 9 As shown, in one embodiment of this application, the rendering module 250 includes: a data snapshot storage unit 251, a difference detection unit 252, a real-time rendering condition triggering unit 253, a multi-threaded rendering pipeline unit 254, a GPU asynchronous computing unit 255, and a dynamic vertical synchronization unit 256.

[0265] After each rendering, the data snapshot storage unit 251 saves the hash value or version number of the current structured data.

[0266] When new structured data arrives, the difference detection unit 252 compares the hash value of the new structured data with the hash value saved in the previous snapshot. If the hash values ​​are different, it is determined that there is a difference; otherwise, it is determined that there is no difference.

[0267] The real-time rendering condition triggering unit 253 determines whether to trigger rendering based on the differences and business rules; the business rules include field change thresholds.

[0268] The multi-threaded rendering pipeline unit 254 uses a dedicated parsing thread to handle data deserialization, a computation thread to perform physics calculations and state updates, and a rendering thread to trigger drawing commands when the main thread is idle.

[0269] The GPU asynchronous compute unit 255 uses compute shaders to process data update logic, avoiding transmission latency from the CPU to the GPU.

[0270] The Dynamic Vertical Synchronization Unit 256 dynamically switches vertical synchronization based on frame rate prediction to coordinate the GPU rendering rate with the display refresh rate.

[0271] In this application, the rendering module determines whether to trigger a re-render by comparing the current data with the data from the previous rendering. Its core mechanism is based on data version number or hash value comparison, ensuring that the UI is updated only when there is a valid change. The core mechanisms of the rendering module for determining whether to render include: data snapshot storage, difference detection, and rendering condition triggering.

[0272] Data snapshot storage: After each rendering, save the hash value or version number of the current data (e.g., using MD5 hash);

[0273] Difference detection: When new data arrives, its hash value is calculated and compared with the previous snapshot. If the hash values ​​are different, a difference is determined.

[0274] Rendering condition triggering: Combine the differences with business rules (such as field change thresholds), for example, rendering is only triggered when the light power change exceeds ±0.1dBm.

[0275] For example: Suppose the hash of the data rendered in the last time was a1b2c3, and the hash of the current new data is d4e5f6. The hashes are different after comparison, triggering a re-render.

[0276] Specific scenario: When port performance data (such as bit error rate) is updated, changes are monitored via the coroutine MonitorPowerLevels. If txPower changes from -10.5dBm to -10.6dBm (a change exceeding 0.1dBm), the UI text and charts are updated.

[0277] This application reduces unnecessary rendering overhead by using a multi-threaded rendering pipeline unit and a GPU asynchronous computing unit.

[0278] In this application, the multi-threaded rendering pipeline unit (rendering layer) separates the parsing / computation / rendering tasks through multi-threading and, in conjunction with GPU asynchronous computation (Compute Shader), reduces pipeline latency from 26.7ms to 3.1ms.

[0279] Specifically, the multi-threaded rendering pipeline unit is used to implement rendering optimization, including the Job System scheduling subunit and the GPU Compute Shader.

[0280] The Job System scheduling subunit allocates independent threads within the Unity engine to handle XML deserialization (1000 data streams per second), while the computation threads update the physical state through the ECS architecture.

[0281] GPU Compute Shader: Ports matrix transformation and lighting calculations to the GPU, and uses ShaderLab to write parallel code, reducing memory bandwidth usage by 50%.

[0282] ShaderLab is a descriptive language provided by Unity specifically for writing and managing shaders. It describes the various parts of a Unity shader in a structured way, making the creation and management of shaders easier.

[0283] ShaderLab consists of four main parts:

[0284] Shader name: Defines the name of the shader.

[0285] Shader properties: Adjustable properties displayed in the material panel.

[0286] Subshader: Contains the actual rendering code.

[0287] Alternate Shader: The lowest-level shader used when all child shaders fail to run.

[0288] In this application, the GPU asynchronous computing unit (computing layer) adopts fixed-point (Q15 format) unified floating-point operation, combined with cloud environment-aware weight synchronization, reducing the score difference between the two ends from ±5.7 points to ±0.01 points.

[0289] Specifically, the GPU asynchronous computing unit is used to achieve computational consistency, including a fixed-point arithmetic subunit and a dynamic weight synchronization subunit.

[0290] The fixed-point arithmetic subunit uses the Neon instruction set of ARM processors (such as the ARM Cortex-A72) to accelerate Q15 format calculations, reducing the time for a single temperature score from 50μs to 5μs. NEON is a SIMD (Single Instruction Multiple Data) instruction set on the ARM platform, which allows multiple data points to be processed simultaneously with a single instruction, thereby improving program execution speed. The Q15 format is a 16-bit fixed-point number representation used to represent fixed-point numbers with 15 decimal places.

[0291] The dynamic weight synchronization subunit sends environment identifiers (such as "high-temperature computer room") in real time via WebSocket, with a weight parameter version number verification error rate of ≤0.02%. WebSocket is a full-duplex communication protocol based on TCP, allowing real-time bidirectional data transmission between clients and servers.

[0292] The real-time monitoring system for the operation status of the SDH power communication network described in this application achieves millisecond-level rendering optimization. The core of this optimization lies in the fundamental transformation of data flow from "serial blocking" to "parallel pipeline" through a complete architectural restructuring and technological upgrade. In the old solution (before optimization), data had to sequentially pass through a high-latency kernel protocol stack, inefficient XML parsing, and single-threaded blocking processing, ultimately resulting in a fixed wait at the vertical synchronization stage, leading to a total latency of up to 85.4 milliseconds. The new solution (this application), by employing key technologies such as user-space network drivers, a simplified binary protocol, multi-threaded parallel processing, and dynamic vertical synchronization, breaks through the bottlenecks in each stage, significantly compressing the end-to-end latency to 4.25 milliseconds, an improvement of 95%, thus providing a solid architectural foundation for real-time interaction.

[0293] This application achieves millisecond-level rendering of large-scale data, breaking through the following two technical barriers:

[0294] 1) Accumulated data pipeline transmission delay

[0295] Protocol stack latency bottleneck: The traditional TCP / IP protocol stack has a cumulative latency of ≥38ms in data packet encapsulation, routing selection, verification and retransmission, etc. The protocol processing overhead alone accounts for 0.1 seconds, which is 38% of the target.

[0296] Serialization / deserialization bottleneck: XML data parsing requires processes such as character encoding conversion, DOM tree construction, and XPath query, and a single parsing takes ≥12ms (0.1 seconds, which is 12% of the target).

[0297] Dual-end data synchronization conflict: Due to system clock differences (±8.7ms) and network jitter (±15ms) between the PC and HoloLens ends, the timestamp alignment error is ≥23.7ms.

[0298] 2) Rendering pipeline congestion chain

[0299] Unity main thread blocking: XML parsing, physics calculation, and rendering command submission all compete for main thread resources, and the success rate of processing data update requests within a single frame (16.7ms) is only 41%.

[0300] GPU rendering latency: Holographic model texture updates require CPU→GPU data transfer (3.2ms), shader compilation (4.8ms), and rasterization (2.3ms), with a cumulative latency of ≥10.3ms.

[0301] Vertical Sync Wait: VSync Lock is enabled to avoid screen tearing, introducing an additional 16.7ms wait delay (at 60Hz refresh rate).

[0302] This application proposes an ultra-low latency synchronous architecture, including: reconstruction of the high-speed transmission protocol stack and parallelization of the rendering pipeline.

[0303] The result of the reconstruction of the high-speed transmission protocol stack is the proposal of a high-speed transmission protocol stack module, which includes: a user-space network protocol stack unit, a binary serialization protocol unit, and a hardware clock synchronization unit.

[0304] User-space network protocol stack unit: By bypassing the kernel TCP / IP protocol stack, it adopts direct data access technology to compress the transmission latency from 38ms to 0.8ms, a reduction of 97.9%.

[0305] Binary serialization protocol unit: Design a dedicated binary protocol SDH-BNP (Binary Network Protocol) to replace XML parsing, reducing field extraction time from 12ms to 0.3ms, a reduction of 97.5%.

[0306] Hardware clock synchronization unit: Introducing PTP (Precise Time Protocol) to synchronize the dual-end system clock (PC and HoloLens), compressing the timestamp error from ±8.7ms to ±0.05ms.

[0307] The result of the parallelization of the rendering pipeline is the proposed multi-threaded rendering architecture (i.e., multi-threaded rendering pipeline unit), GPU asynchronous computing unit, and dynamic vertical synchronization unit.

[0308] The multithreaded rendering pipeline unit includes:

[0309] Parsing thread: A dedicated thread handles data deserialization (occupies 1 CPU core).

[0310] Computation thread: Physical calculation and state update (occupies 2 CPU cores);

[0311] Rendering thread: Only submits drawing commands (triggered when the main thread is idle).

[0312] GPU asynchronous computing unit: It uses Compute Shader to directly handle data update logic, avoiding CPU→GPU transmission latency and saving 3.2ms.

[0313] Dynamic Vertical Sync Unit: Based on frame rate prediction, dynamically switches Vsync (vertical synchronization) to coordinate the synchronization between the GPU rendering rate and the display refresh rate, preventing screen tearing. Average latency has been reduced from 16.7ms to 2.1ms.

[0314] like Figure 10 As shown in one embodiment of this application, the real-time monitoring system for the operation status of the SDH power communication network further includes a network health quantification evaluation model 260; the network health quantification evaluation model 260 includes: a network element health calculation module 261, a network link health calculation module 262, and a network operation status trend evaluation module 263.

[0315] The network element health calculation module 261 calculates the network element health as follows:

[0316] HealthScore_i = max(0, 100 - ∑(Penalty_severity × e^(-λ·Δt)));

[0317] Wherein, Penalty_severity represents the basic deduction value for alarm severity (e.g., CRITICAL alarm deducts 20 points, WARNING deducts 5 points); λ represents the attenuation coefficient, usually taken as 0.1~0.3, which controls the rate at which the deduction decreases over time; Δt represents the time difference between the current time and the time the alarm occurred, with 100 points being the initial full score, and the result after deduction is limited to between 0 and 100.

[0318] The network link health calculation module 262 calculates the network link health as follows:

[0319] SlotScore=∑metric(SubScore_metric×W_metric);

[0320] Wherein, SubScore_metric represents the score of each sub-item (temperature, light power, etc.), W_metric represents the weight coefficient (∑W=1), which is dynamically adjusted according to the equipment type; ∑metric represents the sum of all indicator functions.

[0321] The network operation status trend evaluation module 263 calculates the network operation status trend as: H(t) = BasePenalty;

[0322] Where t is the time point when the alarm occurs; BasePenalty represents a fixed deduction value determined by the alarm level; CRITICAL indicates the use of the BaseCriticalPenalty value; MAJOR indicates the use of the BaseMajorPenalty value; MINOR indicates the use of the BaseMinorPenalty value; and WARNING indicates the use of the BaseWarningPenalty value (subject to the cumulative upper limit).

[0323] The network health metric evaluation model is: OverallHealthScore = w1 × Avg(HealthScore_i) + w2 × SlotScore + w3 × H(t); where w1, w2, and w3 are the weight coefficients of network element health, network link health, and network operation status trend, respectively, and the sum of w1, w2, and w3 is 1; w1, w2, and w3 can be dynamically adjusted according to the network type.

[0324] In this application, the average health score of all network elements is calculated based on HealthScore_i. Network link health score SlotScore = ∑metric(SubScore_metric × Wmetric). The network operating status trend is taken from the BasePenalty value of the most recent alarm; for example, a CRITICAL alarm deducts 20 points. w1, w2, and w3 are weighting coefficients (which can be defaulted or preset to w1=0.5, w2=0.3, w3=0.2, and ∑w=1), or can be dynamically adjusted according to the network type.

[0325] For example: Suppose a network has 3 network elements with health scores of 90, 80, and 70 respectively, then Avg(HealthScore_i) = 80. The network link health score SlotScore = 85. The network operating status trend is H(t) = BasePenalty = −20 (a recent CRITICAL alarm occurred). Then the total score of the network health quantification evaluation model is:

[0326] OverallHealthScore=0.5×80+0.3×85+0.2×(−20)=40+25.5−4=61.5.

[0327] This application utilizes key technologies for integrating multi-source data acquisition protocols of various in-use devices of the same type to create a quantitative evaluation model for network health of power communication systems based on physical-data driven methods. It enables integrated interaction of multi-source heterogeneous data, such as performance data, configuration data, and channel data, from the digital twin model of the optical transmission system and similar heterogeneous devices, thereby achieving online response and operation and maintenance support for the digital link status of the twin based on business-driven principles.

[0328] Furthermore, the set of parameters for calculating network element health is shown in Table 5 below:

[0329] variable type illustrate HealthScore_i Output value Health score of network element i (0-100 points) Penalty_severity constant Alarm severity base deduction: - CRITICAL = 20 points - MAJOR = 10 points - MINOR = 5 points - WARNING = 2 points (maximum deduction of 5 points for this item) λ(DecayRate) constant Time decay factor: 0.01 (decays by 10% per hour) Δt Calculated value Elapsed time (in hours) since the alarm occurred e^{-λ·Δt} Attenuation factor The penalty value decays exponentially over time.

[0330] The formula for Element-Level Health Score is:

[0331] HealthScore_i = max(0,100-∑(Penalty_severity × e^(-λ·Δt)))

[0332] in:

[0333] Penalty_severity: Basic deduction value for alarm severity (e.g., CRITICAL alarm deducts 20 points, WARNING deducts 5 points);

[0334] λ (lambda): Attenuation coefficient (usually taken as 0.1~0.3), which controls the rate at which the deduction decreases over time;

[0335] Δt: The time difference between the current time and the time the alarm occurred (unit: days);

[0336] 100 points is the initial maximum score, and the result after deductions is limited to between 0 and 100.

[0337] Specifically, the network element health calculation process includes the following steps:

[0338] a) Initial value: Health of all network elements = 100 points;

[0339] b) Traverse the alarm data:

[0340] Analyze the alarm time and calculate Δt (time difference);

[0341] Select the basic penalty point based on severity;

[0342] If the alarm level is WARNING, check if the current accumulated original deduction points for WARNING alarms have exceeded the upper limit (5 points); if they have, ignore the deduction points for this alarm; otherwise, add its original deduction points to the accumulation.

[0343] Applying the attenuation formula: Actual deduction = Penalty × e^(-λ·Δt);

[0344] For CRITICAL level alarms, if they occur within the last 24 hours (Δt < 1 day), an immediate critical alarm is triggered.

[0345] c) The cumulative deductions are limited to a range of 0-100 points.

[0346] Calculation example:

[0347] Suppose a device generated a CRITICAL alarm (Penalty=20) 24 hours ago (Δt=1), λ=0.2:

[0348] Actual deduction points ≈ 20 × 0.819 ≈ 16.38 points;

[0349] Current health score = max(0, 100 - 16.38) = 83.62 points;

[0350] Special handling: The cumulative deduction for WARNING level alarms is capped at 5 points to prevent minor alarms from excessively affecting the score.

[0351] Furthermore, the weight allocation of the network link health calculation parameters is shown in Table 6 below:

[0352] index Weight W_metric Calculation module temperature 50% (Temperature Weight) CalculateTemperatureScore Received optical power 10% (Receive Power Weight) CalculateReceivePowerScore Unusable seconds 40% (UnavailableSecondsWeight) CalculateUnavailableSecondsScore

[0353] The formula for calculating network link health is: SlotScore = ∑metric(SubScore_metric × W_metric).

[0354] in:

[0355] SubScore_metric: Score for each sub-item (temperature, optical power, etc.);

[0356] W_metric: Weighting coefficient (∑W=1), dynamically adjusted according to device type;

[0357] It supports dynamically adding monitoring dimensions and has strong scalability.

[0358] Calculation of scores for each sub-item:

[0359] a) Temperature Score Calculation

[0360] Temperature threshold:

[0361] const float NormalTempMin = 0; / / Low temperature safety threshold (°C);

[0362] const float NormalTempMax = 45; / / High temperature safety threshold (°C);

[0363] const float WarningTempMin = 55; / / Warning threshold for low temperature;

[0364] const float CriticalTemp = 70; / / Critical temperature;

[0365] Temperature calculation is performed using a piecewise function:

[0366] .

[0367] Calculation example:

[0368] When the temperature is 50℃, the temperature score is 100 - 5 × (50 - 45) = 75 points.

[0369] Scoring logic explanation:

[0370] If T <= 45℃, the score is 100.

[0371] 45°C < T <= 55°C, curvature deduction (more points are deducted the closer it is to 55°C), score drops from 100 points to 50 points;

[0372] 55°C < T <= 70°C, curvature deduction (more points are deducted the closer it is to 70°C), score drops from 50 points to 0 points;

[0373] T > 70°C, score = 0.

[0374] b) Received optical power score (RxPowerScore)

[0375] Optical power threshold:

[0376] const float NormalRxPowerMin = -31; / / Minimum normal value (dBm);

[0377] const float NormalRxPowerMax = 0; / / Maximum normal value (dBm);

[0378] const float IdealRxPowerMin = -18; / / Lower limit of the ideal range;

[0379] const float IdealRxPowerMax = -8; / / Upper limit of the ideal range;

[0380] The optical power is calculated as a piecewise function:

[0381]

[0382] Calculation example:

[0383] When the optical power = -20 dBm:

[0384] Score = 100 + (100 / 13) × (-20 + 31) ≈ 100 + 7.69 × 11 ≈ 184.6 → Limited to 100 points.

[0385] Explanation of the optical power scoring logic:

[0386] Power value < -31 dBm or > 0 dBm, score = 0;

[0387] Power value is between [-18 dBm, -8 dBm], score = 100;

[0388] Power value is between [-31 dBm, -18 dBm], linearly increasing from 0 points to 100 points;

[0389] The power value is between [-8dBm, 0dBm], and decreases linearly from 100 points to 0 points.

[0390] c) Unavailable second score (UAScore)

[0391] Unavailable second threshold parameter:

[0392] const float WarningSec = 10; / / Warning threshold (seconds);

[0393] const float CriticalSec = 30; / / Critical threshold (seconds);

[0394] It is not possible to calculate using seconds as a piecewise function:

[0395]

[0396] Calculation example:

[0397] When the unavailable seconds are 25 seconds, the score is 100 - 5 × (25 - 10) = 25 points;

[0398] Explanation of the unavailable second scoring logic:

[0399] If UAS < 10 seconds, score = 100;

[0400] If 10 seconds <= UAS < 30 seconds, points are deducted linearly, and the score drops from 100 to 0.

[0401] If UAS >= 30 seconds, score = 0.

[0402] Furthermore, the set of network operation trend evaluation parameters is shown in Table 7 below:

[0403]

[0404] The formula for evaluating network operation trends is: H(t) = BasePenalty, where t is the time point when the alarm occurs.

[0405] The flowchart for evaluating network operation trends is as follows: Figure 13 As shown.

[0406] The network operation trend evaluation steps include: First, the evaluation system traverses the network management alarm data of the network and network element areas of interest. Then, filtering conditions are applied to determine the nature of the alarm data. If it is an accompanying alarm, it is skipped; if it is a valid alarm, the existence of the corresponding network element is determined. The evaluation scoring algorithm is then activated based on the alarm level. After itemized calculation, the comprehensive evaluation score is stored, and the network operation trend evaluation results are output in a standardized graphic and textual display format. Among them, BasePenalty represents a fixed deduction value determined by the alarm level; CRITICAL (critical alarm level), MAJOR (important alarm level), MINOR (general alarm level), and WARNING (warning alarm level) represent four alarm levels. CRITICAL indicates the use of the BaseCriticalPenalty value, which is the deduction value for critical alarms; MAJOR indicates the use of the BaseMajorPenalty value, which is the deduction value for important alarms; MINOR indicates the use of the BaseMinorPenalty value, which is the deduction value for general alarms; and WARNING indicates the use of the BaseWarningPenalty value, which is the deduction value for warning alarms.

[0407] Furthermore, the formula for the Element Health Score is:

[0408] SlotScore=metric∑(SubScoremetric×Wmetric)

[0409] In this application, device health is also the method for calculating network link health.

[0410] Parameter description:

[0411] SubScore_metric: Score for each sub-item (temperature, optical power, etc.);

[0412] W_metric: Weight coefficient (∑W=1), dynamically adjusted according to device type, supports dynamic addition of monitoring dimensions, and has strong scalability.

[0413] 1) Temperature Score

[0414] Piecewise function:

[0415] Calculation example: When the temperature is 50℃, the score is 100 - 5 × (50 - 45) = 75 points.

[0416] 2) Received optical power score (RxPowerScore)

[0417] Piecewise function:

[0418]

[0419] Calculation example: When optical power = -20dBm,

[0420] Score = 100 + (100 / 13)×(-20 + 31)≈100 + 7.69×11≈184.6 → Limited to 100 points.

[0421] 3) Unavailable score by second (UAScore)

[0422] Piecewise function:

[0423]

[0424] Calculation example: When the unavailable seconds = 25 seconds, the score = 100 - 5 × (25 - 10) = 25 points.

[0425] To ensure consistency in dual-end computation, this application addresses the precision difference caused by the PC using 64-bit floating-point calculations and the HoloLens using 32-bit floating-point calculations. Floating-point operations are converted to Q15 format fixed-point numbers (16-bit integers representing decimals), ensuring a precision error of ≤0.01%. A cross-validation mechanism is established, comparing the PC and HoloLens results every 5 calculations; a high-precision compensation algorithm is activated when the difference exceeds ±2 points. Furthermore, environment type identifiers are uniformly distributed from the cloud to ensure that both ends use the same weight allocation scheme.

[0426] The verification system shows that in extreme scenario stress tests, the scoring deviation in high temperature and high load scenarios (temperature 68℃ + optical power -65dBm) was reduced from ±15.3 points to ±2.1 points; in dual-end network interruption tests, the weight configuration difference was ≤0.3% after 24 hours of network outage; and in rapid environment switching tests, the weight adjustment response time after switching between indoor and outdoor scenarios was ≤1.5 seconds.

[0427] The technological achievements include three principles for multi-parameter weighting: the first principle (uniformity of dimensions criterion) requires all parameters to be normalized to the [0,100] interval with an error ≤0.5%; the second principle (environmental perception criterion) requires the weight allocation to be dynamically adjusted according to the environmental type and the environmental recognition accuracy ≥92%; the third principle (consistency between both ends criterion) requires the PC and HoloLens to use the same fixed-point number calculation standard and the tolerance threshold for scoring differences is ±2 points.

[0428] The research and development process went through three stages: Stage 1: root cause identification, identifying three core issues: dimensional differences, neglect of nonlinear relationships, and differences in accuracy between the two ends; Stage 2: core technology development, including multi-parameter normalization algorithm (38% reduction in deviation), piecewise function modeling (229.6% improvement in critical identification accuracy), and fixed-point number calculation standard (99.7% improvement in consistency between the two ends); Stage 3: industrial application verification, achieving a scoring deviation of ≤2.1 points in high-temperature scenarios, a dynamic weight adjustment response of ≤1.5 seconds, and support for adaptation to 7 environmental types.

[0429] In terms of industrial value realization, the operation and maintenance decision support capability has been significantly improved, with the health score matching the actual equipment status increasing to 95%, and the accuracy of guiding maintenance decisions increasing by 60%; cross-platform consistency has achieved a breakthrough, with the score difference between the two ends ≤0.3 points, realizing true multi-terminal collaborative monitoring; environmental adaptability has been greatly enhanced, and the dynamic weight mechanism enables the system to adapt to different deployment scenarios, reducing the workload of manual configuration by 80%.

[0430] Through a three-tiered technical architecture of multi-parameter normalization processing, piecewise function modeling, and fixed-point number calculation, the multi-parameter weighted calculation is upgraded from simple linear superposition to an intelligent dynamic weighted system, providing accurate and reliable assessment basis for equipment health monitoring.

[0431] This application quantitatively verifies the technical advantages and performance benefits of the aforementioned architecture. The figure clearly shows that after the raw data passes through key stages such as protocol parsing, data association, field filtering, lightweight encapsulation, and transmission optimization, its data volume and processing latency exhibit a step-like decrease. The final quantitative indicators show that this architecture successfully reduces end-to-end processing latency by 85.9% while reducing the effective data volume by 66.7%, powerfully demonstrating its ability to effectively resolve the core contradiction between massive heterogeneous data and real-time requirements, providing a fundamental guarantee for a smooth experience in digital twin applications.

[0432] This application also provides a method for real-time monitoring of the operating status of a power communication SDH network. The real-time monitoring system for the operating status of the power communication SDH network can implement the method described in this application. However, the implementation device for the method described in this application includes, but is not limited to, the structure of the real-time monitoring system for the operating status of the power communication SDH network listed in this embodiment. Any structural modifications and substitutions of the prior art made based on the principles of this application are included within the protection scope of this application.

[0433] like Figure 11 As shown in the figure, this application embodiment also provides a method for real-time monitoring of the operating status of a power communication SDH network, including steps S101 to S104.

[0434] S101 collects network element information, performance information, alarm information and equipment information of the power communication SDH network according to the preset strategy, and performs standardization processing on the collected multi-source heterogeneous data through the protocol parsing engine module to obtain structured data.

[0435] S102, the structured data is parsed, associated and identified to obtain key business entities.

[0436] S103, perform serialization and compression optimization on the key business entities to obtain lightweight packaged data.

[0437] S104, perform real-time rendering based on the lightweight encapsulation data to obtain a real-time visualized operating status of the power communication SDH network.

[0438] The implementation process of the real-time monitoring method for the operating status of the SDH power communication network described in this application is consistent with the description of the real-time monitoring system for the operating status of the SDH power communication network, and will not be repeated here.

[0439] This application quantitatively verifies the technical advantages and performance benefits of the real-time monitoring system architecture for the operational status of SDH power communication networks. It clearly demonstrates that after the raw data passes through key stages such as protocol parsing, field filtering, data association, lightweight encapsulation, and transmission optimization, its data volume and processing latency exhibit a step-wise decrease. The final quantitative indicators show that this architecture successfully reduces end-to-end processing latency by 85.9% while reducing the effective data volume by 66.7%, powerfully proving its ability to effectively resolve the core contradiction between massive heterogeneous data and real-time requirements, providing a fundamental guarantee for a smooth experience in digital twin applications.

[0440] This application optimizes acquisition efficiency, reducing data processing time from 85ms to 12ms within a 15-minute acquisition cycle, and supports real-time monitoring; it reduces bandwidth costs, decreasing invalid data transmission by 80% and annual bandwidth costs by 60%; and it accelerates fault location, with intelligent data association reducing fault location time from hours to minutes.

[0441] This application significantly improves acquisition efficiency through a multi-protocol adaptive acquisition module and enhances screening accuracy through an intelligent data filtering and deconstruction module. Specifically, the accuracy of key field identification has increased from 72% to 98.5%, the data association accuracy has increased from 85% to 99.2%, and the real-time compliance rate has increased from 65% to 99.8%.

[0442] The scope of protection for the real-time monitoring method for the operation status of the SDH power communication network described in this application is not limited to the execution order of the steps listed in this embodiment. Any solution implemented by adding, subtracting, or replacing steps in the prior art based on the principles of this application is included within the scope of protection of this application.

[0443] The descriptions of the processes or structures corresponding to the above figures each have their own emphasis. For parts of a process or structure that are not described in detail, please refer to the relevant descriptions of other processes or structures.

[0444] The above embodiments are merely illustrative of the principles and effects of this application and are not intended to limit this application. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of this application. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in this application should still be covered by the claims of this application.< / ipaddress> < / name>

Claims

1. A real-time monitoring system for the operating status of a power communication SDH network, characterized in that, include: The multi-protocol adaptive acquisition module collects network element information, performance information, alarm information and equipment information of the power communication SDH network according to the preset strategy. The protocol parsing engine module performs standardization processing on the acquired multi-source heterogeneous data to obtain structured data. The intelligent data filtering and deconstruction module parses, associates, and identifies the structured data to obtain key business entities. This module includes a data aggregation module, a data association engine module, and a field recognition engine module. The data aggregation module merges and aligns the structured data output by the multi-protocol adaptive acquisition module at a data aggregation point, forming a unified business data context. The data association engine module integrates relevant scattered data from the business data context into a device panoramic view through primary key matching, temporal alignment, and multi-source fusion. The field recognition engine module, based on predefined business rules and a data dictionary, filters redundant data in the device panoramic view using intelligent filtering strategies, extracts key fields, and obtains standard core data. A lightweight encapsulation module performs serialization and compression optimization on the key business entities to obtain lightweight encapsulated data. The lightweight encapsulation module includes: a user-space network protocol stack unit, which uses a user-space RDMA protocol stack to bypass the kernel protocol stack and directly process the network data packets of the lightweight encapsulated data in user space; a binary serialization protocol unit, which uses the binary protocol SDH-BNP instead of XML parsing to extract fields from the network data packets of the lightweight encapsulated data; and a hardware clock synchronization unit, which synchronizes the system clocks of the sending and receiving ends of the network data packets based on PTP. The rendering module performs real-time rendering based on the lightweight encapsulated data to obtain a real-time visualized operating status of the SDH power communication network. The rendering module includes: a multi-threaded rendering pipeline unit, which uses a dedicated parsing thread to handle data deserialization, a computing thread to perform physical calculations and status updates, and a rendering thread to trigger drawing submission commands when the main thread is idle; a GPU asynchronous computing unit, which uses a computing shader to handle data update logic, avoiding transmission latency from the CPU to the GPU; and a dynamic vertical synchronization unit, which dynamically switches vertical synchronization based on frame rate prediction to coordinate the GPU rendering rate with the display refresh rate.

2. The real-time monitoring system for the operation status of a power communication SDH network according to claim 1, characterized in that, The multi-protocol adaptive acquisition module includes: an acquisition scheduler, a network data acquisition module, a performance data acquisition module, an alarm data acquisition module, a device data acquisition module, and a protocol parsing engine module; The data acquisition scheduler controls the network element information acquisition module to acquire network element information of the power communication SDH network, parses the equipment list and basic information in the network element information, and generates a network element information view; The acquisition scheduler controls the performance data acquisition module to acquire the performance information of the power communication SDH network, parses the acquired optical power and / or bit error rate in the performance information, and generates performance trend data. The data acquisition scheduler controls the alarm data acquisition module to collect alarm information from the power communication SDH network, extracts real-time alarms and historical alarms from the alarm information, and generates alarm statistics information. The data acquisition scheduler controls the equipment data acquisition module to collect and obtain the equipment configuration and status information of the power communication SDH network, and generates the equipment health status; The protocol parsing engine module standardizes the multi-source heterogeneous data, eliminating the differences in the underlying communication protocols of the multi-source heterogeneous data, and obtaining structured data; the multi-source heterogeneous data includes network data view, performance trend data, alarm statistics information and / or device health status.

3. The real-time monitoring system for the operation status of the SDH power communication network according to claim 2, characterized in that, The protocol parsing engine module includes: The raw response receiving unit captures multi-source heterogeneous data returned by the server, i.e., heterogeneous protocol data, through UnityWebRequest; The preprocessing and verification unit checks the integrity of the heterogeneous protocol data, filters invalid characters, and outputs standardized XML data. The namespace resolution unit registers XML namespaces and resolves tag conflicts. The XPath extraction unit uses predefined XPath expressions to locate target nodes in standardized XML data, queries the target nodes through the XPath engine, and extracts key information from the target nodes; the key information of the target nodes includes text content or attribute values. The standardized output unit maps the extracted key information into a unified output format for use by downstream modules; the unified output format is a structured key-value pair format, and the field names contained in the unified output format all follow a predefined data dictionary.

4. The real-time monitoring system for the operation status of the SDH power communication network according to claim 1, characterized in that, The data association engine module includes: The primary key matching unit uses the device ID or IP address as a unique identifier to associate configuration, alarm, and performance data, and obtains a set of key-value pairs after primary key matching. The time-series alignment unit sorts events by timestamp to form time-series data, and the time-series aligned data format is an ordered list. The multi-source fusion unit integrates scattered data to form a panoramic view of the equipment.

5. The real-time monitoring system for the operation status of a power communication SDH network according to claim 1, characterized in that, The field recognition engine module includes: The input unit receives structured data containing 218 fields output by the protocol parsing engine module; The rule application unit loads the business rule dictionary, performs field-by-field priority filtering on the structured data, applies threshold checks and redundancy merging, and obtains the core data after rule processing. The output unit generates a simplified core dataset containing only 32 fields based on the core data processed by the rules.

6. The real-time monitoring system for the operation status of a power communication SDH network according to claim 1, characterized in that, The rendering module also includes: The data snapshot storage unit saves the hash value or version number of the current structured data after each rendering. The difference detection unit compares the hash value of the new structured data with the hash value saved in the previous snapshot when new structured data arrives. If the hash values ​​are different, it is determined that there is a difference; otherwise, it is determined that there is no difference. The real-time rendering condition triggering unit determines whether to trigger rendering based on the differences and business rules; the business rules include field change thresholds.

7. The real-time monitoring system for the operation status of a power communication SDH network according to claim 1, characterized in that, Also includes: A quantitative evaluation model for network health; The network health quantification and evaluation model includes: a network element health calculation module, a network link health calculation module, and a network operation status trend evaluation module; The network element health calculation module calculates the network element health of the i-th network element as follows: HealthScore_i = max(0, 100 - ∑(Penalty_severity × e^(-λ·Δt))); Wherein, Penalty_severity represents the basic deduction value for alarm severity; λ represents the attenuation coefficient, which is usually taken as 0.1~0.3, controlling the rate at which the deduction decreases over time; Δt represents the time difference between the current time and the time the alarm occurred, with 100 points being the initial full score, and the result after deduction is limited to between 0 and 100. The network link health calculation module calculates the network link health as follows: SlotScore=∑metric(SubScore_metric×W_metric); Where SubScore_metric represents the score of each sub-item, W_metric represents the weight coefficient of the corresponding sub-item, ∑W=1, W_metric is dynamically adjusted according to the device type; ∑metric represents the sum of all indicator functions; The network operation status trend evaluation module calculates the network operation status trend as: H(t) = BasePenalty; Where t is the time point when the alarm occurs; BasePenalty represents the fixed deduction value determined by the alarm level; The network health metric evaluation model is: OverallHealthScore = w1 × Avg(HealthScore_i) + w2 × SlotScore + w3 × H(t); where w1, w2, and w3 are the weight coefficients of network element health, network link health, and network operation status trend, respectively, and the sum of w1, w2, and w3 is 1; w1, w2, and w3 can be dynamically adjusted according to the network type.

8. A method for real-time monitoring of the operating status of a power communication SDH network, characterized in that, include: According to the preset strategy, network element information, performance information, alarm information and equipment information of the power communication SDH network are collected. The multi-source heterogeneous data collected is standardized by the protocol parsing engine module to obtain structured data. The structured data is parsed, correlated, and identified to obtain key business entities. This includes: aggregating and aligning the structured data output by the multi-protocol adaptive acquisition module at a data aggregation point to form a unified business data context; integrating relevant scattered data in the business data context into a device panoramic view through primary key matching, time-series alignment, and multi-source fusion; and filtering redundant data in the device panoramic view based on predefined business rules and a data dictionary using an intelligent filtering strategy to extract key fields and obtain standard core data. The key business entities are serialized and compressed to obtain lightweight encapsulated data; this includes: using a user-space RDMA protocol stack to bypass the kernel protocol stack and directly processing the network data packets of the lightweight encapsulated data in user space; using the binary protocol SDH-BNP to replace XML parsing and extracting fields from the network data packets of the lightweight encapsulated data; and synchronizing the system clocks of the sending and receiving ends of the network data packets based on PTP. Real-time rendering is performed based on the lightweight encapsulated data to obtain a real-time visualized operating status of the SDH power communication network; including: processing data deserialization based on a dedicated parsing thread, performing physical calculations and status updates based on a computing thread, and triggering the submission of drawing instructions when the main thread is idle based on a rendering thread; using a computational shader to process data update logic to avoid transmission latency from the CPU to the GPU; and dynamically switching vertical synchronization based on frame rate prediction to coordinate the GPU rendering rate and the display refresh rate.

Images