Adaptive topology reconstruction method for substation secondary system communication network

Abstract

This invention provides a method for adaptive topology reconstruction of a substation secondary system communication network. The method includes: using multi-scale delay feature fusion modeling to accurately predict protocol conversion delay; designing a layered and integrated protocol conversion delay control framework, including two-stage delay control based on feedforward compensation and feedback adjustment based on a resource-delay sensitivity matrix; proposing a dynamic protocol semantics tailoring technique to achieve differentiated semantic processing based on delay requirements through a performance-semantics trade-off function; and constructing an end-to-end delay-aware topology reconstruction decision mechanism to comprehensively evaluate the impact of candidate topology solutions on the delay of critical service flows. This method reduces protocol conversion delay for critical services in a substation's multi-protocol environment, achieving millisecond-level delay assurance and adaptive optimization of network topology.

Description

Technical Field

[0001] The present invention relates to a transformer substation secondary system, in particular to a transformer substation secondary system communication network adaptive topology reconstruction method. Background Art

[0002] As the core infrastructure of smart grids, substation secondary system communication networks carry multiple service functions, including protection, control, and measurement. Their performance directly impacts the safe and stable operation of power systems. With the advancement of smart grid development, substation secondary system communication networks are characterized by the coexistence of multiple protocols, a rich variety of services, and diverse real-time requirements. In particular, in scenarios involving cross-protocol service flow transmission, ensuring end-to-end transmission latency for latency-sensitive services (such as protection trip signals and emergency control commands) has become a key challenge in substation communication network design and optimization.

[0003] Currently, research on substation secondary system communication network topology optimization focuses on several areas: communication network design based on the IEC 61850 standard, focusing on functional division and equipment layout; high-reliability network architectures based on redundancy technologies, such as HSR (High-Availability Seamless Redundancy Protocol) and PRP (Parallel Redundancy Protocol); and network traffic management based on QoS (Quality of Service), ensuring the transmission of critical business flows through priority scheduling and bandwidth allocation. In the area of protocol conversion, research focuses on semantic mapping and data model conversion between different protocols, such as functional mapping and interoperability between IEC 61850 and traditional protocols (Modbus, DNP3.0, etc.). Furthermore, research on the application of delay-sensitive networking (TSN) technology in power systems has also made progress, such as time-aware scheduling based on IEEE 802.1Qbv and frame duplication and elimination based on IEEE 802.1CB.

[0004] However, existing technologies have significant shortcomings in optimizing latency for cross-protocol services in multi-protocol substation environments. In substation secondary systems, when control commands and protection signals need to be transmitted across protocols (e.g., from IEC 61850 to DNP3.0), the standard protocol conversion process introduces uncertain latency ranging from 2 to 10 milliseconds. Especially for critical protection services (such as overcurrent protection trip commands), the additional latency introduced by protocol conversion can cause protection action delays, threatening equipment safety. First, at the protocol conversion level, existing technologies often use static mapping mechanisms that fail to understand the latency sensitivity differences between different service flows. This results in poorly differentiated processing of critical protection signals during protocol conversion, leading to wide fluctuations in conversion latency. Second, semantic processing during protocol conversion typically employs an "all-or-nothing" strategy: either fully converting all fields (preserving semantic integrity but with higher latency) or employing a minimalist conversion mode (sacrificing non-critical information in exchange for low latency). These technologies lack the ability to dynamically adjust the level of semantic preservation based on latency requirements. Currently, there is a lack of a protocol conversion mechanism that can accurately compensate for delays based on message delay sensitivity, making it impossible to guarantee the real-time requirements of millisecond-level critical services during cross-protocol transmission. Summary of the Invention

[0005] The purpose of the invention is to provide a method for adaptive topology reconstruction of a substation secondary system communication network, in order to solve at least one technical problem existing in the prior art.

[0006] A technical solution, a method for adaptive topology reconstruction of a substation secondary system communication network, comprising:

[0007] Collect communication data from multi-protocol networks in substation secondary systems, extract multi-scale delay sensitivity features, and build a multi-scale delay feature model;

[0008] Use a multi-scale delay feature model to predict protocol conversion delay and generate delay compensation strategies for delay-sensitive services;

[0009] According to the delay compensation strategy, protocol conversion optimization and delay control are performed to obtain the optimized conversion results and real-time processing delay. In addition, end-to-end delay perception analysis is performed in combination with the multi-scale delay feature model to generate and execute the optimal topology reconstruction plan.

[0010] According to one aspect of the present application, a multi-scale delay feature model is constructed, including:

[0011] Collect communication data from multi-protocol networks in the substation secondary system, including packet timestamps, payload sizes, priority tags, and network device status information for different protocols, to generate raw communication data sets.

[0012] Based on the original communication dataset, macro, meso and micro delay features are extracted in sequence to obtain macro and meso load feature vectors, as well as micro processing feature vectors, and a multi-scale delay feature model is constructed based on them.

[0013] According to one aspect of the present application, a multi-scale delay feature model is constructed, including:

[0014] Extracting baseline load trend and periodic fluctuation components from macro load feature vector;

[0015] Read the meso-level load characteristic vector, calculate its deviation from the baseline load trend, and obtain the load fluctuation intensity and load mutation frequency indicators. Based on this, a switching model for high and low load states is constructed to form a load state transfer matrix.

[0016] Based on the micro-processing eigenvectors, distribution fitting is performed to obtain the delay probability distribution model of each processing stage. This is combined with the load state transition matrix to construct a conditional delay distribution model considering state transition.

[0017] The baseline load trend, periodic fluctuation component and conditional delay distribution model are integrated into a multi-scale delay feature model.

[0018] According to one aspect of the present application, generating a delay compensation strategy for delay-sensitive services includes:

[0019] Receive communication data, extract multi-scale delay characteristics under the current network state and input them into the multi-scale delay feature model to obtain the expected protocol conversion delay of different types of messages under the current network conditions;

[0020] Calculate the delay margin based on the expected protocol conversion delay and the end-to-end delay requirement of the message;

[0021] According to the delay margin and network resource status, a feedforward compensation strategy is generated for high-priority messages whose delay margin is less than a threshold, thereby forming a delay compensation strategy.

[0022] According to one aspect of the present application, forming a delay compensation strategy includes:

[0023] Read the message's latency margin and priority tag and classify the message into high, medium, and low sensitivity;

[0024] For highly sensitive messages, calculate the minimum processing resource requirements to ensure that their conversion delay does not exceed the delay margin;

[0025] Based on current system resources and the weight of each resource's contribution to reducing conversion delay, a resource-delay sensitivity matrix is constructed and the optimal resource allocation scheme is calculated. Based on this, the most suitable conversion path is selected, taking into account the message protocol type, message complexity, and minimum processing resource requirements.

[0026] Comprehensive resource allocation scheme and switching path selection to generate a complete delay compensation strategy.

[0027] According to one aspect of the present application, obtaining an optimized conversion result includes:

[0028] According to the delay compensation strategy, the appropriate protocol conversion processing mode is determined for each message, a conversion mode decision is made, and the allowed processing time is calculated;

[0029] Acquire and analyze the protocol structure of the target message, and identify the key semantic sets and non-key semantic sets in the message based on the structure; calculate the processing time of the key semantic sets and the remaining time budget for processing the non-key semantic sets based on the allowed processing time;

[0030] Based on the remaining time budget, an important retained subset is extracted from the non-critical semantic set and combined with the critical semantic set to generate a semantic pruning scheme;

[0031] Protocol conversion is performed according to the semantic tailoring scheme, key semantic sets are prioritized, and optimized conversion results are generated.

[0032] According to one aspect of the present application, identifying a key semantic set and a non-key semantic set in a message includes:

[0033] Read the protocol type and message type of the target message and extract the complete semantic structure graph of the message type;

[0034] Identify necessary functional fields from the complete semantic structure diagram based on current business scenarios and control requirements;

[0035] Analyze the application context of the target message in the current business environment and identify the associated status fields required for interaction with other systems from the complete semantic structure diagram;

[0036] The necessary function fields and associated status fields are combined to form the key semantic set of the message and assign weights. The remaining fields in the complete semantic structure diagram are classified into the non-key semantic set.

[0037] According to one aspect of the present application, generating a semantic clipping solution includes:

[0038] Based on the semantic importance scores in the key semantic set and the estimated processing time of each field, a performance-semantics trade-off function is constructed to maximize the amount of semantic information retained under time constraints.

[0039] Call the performance-semantics trade-off function to select the most important subset from the non-critical semantic set so that its processing time does not exceed the remaining time budget, and generate the non-critical semantic retention subset;

[0040] The key semantic set and the non-key semantic retention subset are integrated to form a semantic pruning scheme, which includes all fields that need to be retained and their processing priorities.

[0041] According to one aspect of the present application, it also includes monitoring the real-time processing delay during the protocol conversion process and performing delay control adjustment:

[0042] Read the real-time processing delay data of the current protocol conversion process, calculate the deviation from the expected protocol conversion delay, and obtain the delay deviation value; when the delay deviation exceeds the delay deviation threshold, trigger the feedback adjustment process;

[0043] Analyze the positive and negative direction and magnitude of the delay deviation value to determine whether the current delay situation is exceeding expectations or due to resource redundancy.

[0044] If the latency exceeds expectations, adjust the semantic pruning plan, streamline the non-critical semantic retention subset, and apply for emergency processing resources;

[0045] In case of resource redundancy, the non-critical semantic reserved subset is expanded and the excess resources are released.

[0046] According to one aspect of the present application, generating an optimal topology reconstruction solution includes:

[0047] Based on a multi-scale delay feature model and real-time processing of delay data, we identify delay bottlenecks and congested areas in the current network topology. Furthermore, we build a network optimization objective function based on the end-to-end delay requirements of each substation service flow.

[0048] Based on the network optimization objective function, a set of candidate topology reconstruction schemes is generated, including link adjustment, traffic redistribution, and protocol conversion node deployment strategies;

[0049] Evaluate the impact of each candidate topology reconstruction scheme on the latency of key business flows, generate scheme evaluation results, and select the scheme with the highest comprehensive score as the optimal topology reconstruction scheme.

[0050] Beneficial effects: This embodiment achieves high-precision prediction of protocol conversion delay, effectively copes with network load fluctuations, controls the stability of key protection service protocol conversion delay, and reduces conversion delay fluctuations; it can dynamically adjust the semantic retention level according to the delay sensitivity of different messages, optimize the processing delay to the greatest extent while ensuring functional correctness, ensure the ultimate integrity of the data, and achieve millisecond-level delay guarantee and adaptive optimization of network topology. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] Figure 1 This is a flowchart of the steps of a method for adaptive topology reconstruction of a substation secondary system communication network provided in an embodiment of the present application.

[0052] Figure 2This is a flowchart of the steps for extracting multi-scale delay sensitivity features and constructing a multi-scale delay feature model provided by an embodiment of the present application.

[0053] Figure 3 This is a flowchart of the steps for constructing a multi-scale delay feature model provided in an embodiment of the present application.

[0054] Figure 4 This is a flowchart of the steps for generating a delay compensation strategy for delay-sensitive services provided in an embodiment of the present application.

[0055] Figure 5 This is a flowchart of the steps for forming a delay compensation strategy provided by an embodiment of the present application. DETAILED DESCRIPTION

[0056] In order to enable those skilled in the art to better understand the solutions of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the embodiments described are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of the present invention.

[0057] It should be noted that to clearly illustrate the steps of this application, serial numbers are assigned to each step in the specification. These serial numbers are for illustrative purposes only and do not limit the order in which the steps must be executed. In actual operation, depending on the technical requirements of the specific implementation scenario, the steps may be executed in a different order than shown in the specification, and in some cases, parallel processing between steps may be implemented.

[0058] like Figure 1 As shown, a method for adaptive topology reconstruction of a substation secondary system communication network includes:

[0059] Collect communication data from multi-protocol networks in substation secondary systems, extract multi-scale delay sensitivity features, and build a multi-scale delay feature model;

[0060] Specifically, communication data includes packet timestamps, payload sizes, priority tags, and network device status information for different protocols (IEC 61850, DNP3.0, and Modbus). Data latency characteristics vary at different scales (e.g., milliseconds, seconds, etc.). Extracting multi-scale latency sensitivity features provides a data foundation for subsequent transition delay prediction and topology reconfiguration decisions.

[0061] Use a multi-scale delay feature model to predict protocol conversion delay and generate delay compensation strategies for delay-sensitive services;

[0062] Specifically, conversions between different communication protocols may introduce additional latency, such as changes in data format or processing time. Using a latency model, we can predict in advance how long this conversion process will take. To mitigate this impact, we can generate compensation solutions. For example, we might pre-send data packets, optimize transmission paths, or adjust network resource allocation to ensure stable and fast operation of critical services.

[0063] Perform protocol conversion optimization and delay control according to the delay compensation strategy to obtain optimized conversion results and real-time processing delay;

[0064] Specifically, when transmitting data between different communication protocols, format changes or processing differences may occur. Based on delay compensation strategies, the protocol conversion process is optimized to reduce unnecessary delays. To ensure that critical services are not affected by long network delays, transmission strategies are proactively monitored and adjusted. For example, it may prioritize important data packets or dynamically adjust resource allocation to reduce the impact of delays on services. Protocol conversion delay control can be implemented using a combination of feedforward and feedback, while also dynamically tailoring protocol semantics to optimize conversion delay performance while ensuring critical semantics.

[0065] Based on the optimized conversion results, real-time processing delay, and multi-scale delay feature model, end-to-end delay perception analysis is performed to generate and execute the optimal topology reconstruction plan.

[0066] Specifically, based on the protocol conversion delay analysis results and end-to-end delay requirements, network bottlenecks are identified, and optimal network topology reconstruction decisions are generated and executed. The reconstruction execution results are obtained, enabling adaptive topology reconstruction of the substation secondary system communication network.

[0067] like Figure 2 As shown, according to one aspect of the present application, a multi-scale delay feature model is constructed, including:

[0068] Collect communication data of multi-protocol networks in substation secondary systems and generate raw communication data sets;

[0069] Based on the original communication dataset, macro, meso, and micro delay features are extracted sequentially to obtain macro and meso load feature vectors, as well as micro processing feature vectors.

[0070] Based on the macro- and meso-level load feature vectors, as well as the micro-level processing feature vectors, a multi-scale delay feature model is constructed.

[0071] According to one aspect of the present application, obtaining an optimized conversion result includes:

[0072] According to the delay compensation strategy, the appropriate protocol conversion processing mode is determined for each message, a conversion mode decision is made, and the allowed processing time is calculated;

[0073] Acquire and analyze the protocol structure of the target message, and identify the key semantic sets and non-key semantic sets in the message based on the structure; calculate the processing time of the key semantic sets and the remaining time budget for processing the non-key semantic sets based on the allowed processing time;

[0074] Based on the remaining time budget, an important retained subset is extracted from the non-critical semantic set and combined with the critical semantic set to generate a semantic pruning scheme;

[0075] Protocol conversion is performed according to the semantic tailoring scheme, key semantic sets are prioritized, and optimized conversion results are generated.

[0076] like Figures 3 to 5 As shown in Figure 2, in a certain scenario, the processing process of the adaptive topology reconstruction method of the substation secondary system communication network based on delay sensitivity analysis is as follows:

[0077] Multi-protocol network communication data is collected, including packet timestamps, payload sizes, priority tags, and network device status information for different protocols (IEC 61850, DNP3.0, and Modbus), to generate a raw communication dataset. Macro-delay features are extracted by analyzing network traffic fluctuation patterns within a 24-hour period, calculating the average load level and periodic load patterns for each time period, and outputting a macro-load feature vector. Meso-delay features are extracted by statistically analyzing network queue status and processing delay within a 100ms sliding window, calculating queue occupancy, processing delay variance, and burst traffic metrics, and generating a meso-load feature vector. Micro-delay features are extracted by analyzing the processing time distribution of each stage (parsing, mapping, and repackaging) during a single protocol conversion process, recording the processing delay and processing resource consumption at each stage, and outputting a micro-processing feature vector. By integrating macro-load feature vectors, meso-load feature vectors, and micro-processing feature vectors, a multi-scale delay feature model is constructed. This model captures the key factors affecting protocol conversion delay at different time scales and their interactions. Specifically, the macro-load feature vector is read, the periodic load pattern and peak load period characteristics are extracted, and the baseline load trend and periodic fluctuation component are separated through waveform decomposition method; the meso-load feature vector is read, its deviation from the macro-baseline load trend is calculated, and the load fluctuation intensity and load mutation frequency indicators are obtained; the processing delay of each stage in the micro-processing feature vector is distributed fitted to obtain the delay probability distribution model of each processing stage; based on the load fluctuation intensity and load mutation frequency, a switching model for high and low load states is constructed to form a load state transition matrix; the delay probability distribution model is combined with the load state transition matrix to construct a conditional delay distribution model considering state transition; through a hierarchical feature fusion algorithm, the baseline load trend, periodic fluctuation component, and conditional delay distribution model are integrated into a multi-scale delay feature model. This model can accurately capture the relationship between network load and protocol conversion delay at multiple time scales.

[0078] Receive real-time raw communication data sets, extract multi-scale delay features under the current network state, input pre-trained multi-scale delay feature models, and predict the expected protocol conversion delay of different types of messages under the current network conditions. Based on the expected protocol conversion delay and the end-to-end delay requirements of the message, calculate the delay margin and determine whether the delay compensation mechanism needs to be triggered. For high-priority messages with insufficient delay margin, generate a feedforward compensation strategy based on the expected protocol conversion delay and network resource status, including resource allocation scheme and conversion path selection, and output a delay compensation strategy, specifically: read the delay margin and priority tag of the message, and classify the message into three categories of high sensitivity, medium sensitivity and low sensitivity based on the preset threshold; for high-sensitivity messages, calculate the minimum processing resources required to ensure that its conversion delay does not exceed the delay margin; construct a delay compensation strategy based on the currently available processor resources, memory resources and network bandwidth resources, as well as the contribution weight of each resource to reducing the conversion delay. A resource-delay sensitivity matrix is constructed. Based on this matrix, a resource allocation algorithm is used to calculate the optimal resource allocation plan, which allocates an appropriate amount of resources to each high-sensitivity message to maximize the overall delay benefit. Based on the allocated resources, the most suitable conversion path is selected from a predefined conversion path library, taking into account the message protocol type and message complexity. This path provides the minimum conversion delay under resource constraints. Combining the resource allocation plan and conversion path selection, a complete delay compensation strategy is generated, which includes detailed resource allocation instructions and conversion processing flow configuration. A resource pooling mechanism is established to avoid resource competition when multiple high-priority messages arrive simultaneously. Processing resources are pre-allocated according to the delay compensation strategy, and a resource pooling configuration is generated to ensure resource availability for critical services.

[0079] Based on the conversion path selected in the delay compensation strategy, the appropriate protocol conversion processing mode is determined for each message, transitioning from a full protocol stack to lightweight key field conversion, forming a conversion mode decision. Two-stage delay control is implemented, and feedforward scheduling is implemented based on the resource allocation plan, prioritizing high-latency sensitive services and outputting resource scheduling instructions. Dynamic protocol semantic tailoring is performed for messages requiring rapid conversion: the protocol structure of the target message is analyzed to identify key and non-key semantic sets. Specifically, the protocol type and message type of the target message are read, and a pre-built protocol semantic knowledge base is consulted to extract the complete semantic structure diagram of this type of message. Based on the current business scenario and control requirements, the necessary functional fields in the semantic structure diagram are identified. These fields are directly related to the core functional implementation of the control command. The application context of the target message in the current business environment is analyzed to identify the associated state fields required for interaction with other systems. Although these fields are non-functional, they are critical for system state consistency. The necessary functional fields and associated state fields are combined to form the key semantic set of the message, and the remaining fields are classified as non-key semantic sets. Each field in the key semantic set is assigned a semantic importance score to reflect its contribution to the implementation of business functions. Based on the current delay margin and conversion mode decision, the semantic retention level is dynamically determined and a semantic trimming scheme is generated. Specifically, the delay margin and conversion mode decision of the message are read, and the maximum allowable protocol conversion processing time is calculated; a protocol field processing time model is established to estimate the critical semantic processing time required to process all fields in the critical semantic set; the maximum allowable processing time is compared with the critical semantic processing time. If the critical semantic processing time is less than the maximum allowable processing time, the remaining time budget that can be used to process non-critical semantics is calculated; based on the semantic importance score in the critical semantic set and the estimated processing time of each field, a performance-semantic trade-off function is constructed, which maximizes the amount of retained semantic information under time constraints; using the performance-semantic trade-off function, the most important subset is selected from the non-critical semantic set so that its processing time does not exceed the remaining time budget, and a non-critical semantic retention subset is generated; the critical semantic set and the non-critical semantic retention subset are integrated to form a final semantic trimming scheme, which includes all fields that need to be retained and their processing priority.

[0080] Execute protocol conversion according to the semantic tailoring scheme to ensure the semantic integrity of key control instructions and protection signals, optimize processing delay, and output optimized conversion results. Specifically, read the source protocol message and semantic tailoring scheme, prepare the protocol conversion environment and resources; give priority to processing the fields in the key semantic set, and convert them to the target protocol format according to the predefined mapping relationship to form the key semantic conversion result; if time permits, process the fields in the non-key semantic retention subset, convert them to the target protocol format, and merge them with the key semantic conversion result; mark the non-key fields that cannot be processed in the current conversion cycle with the to-be-supplemented identifier, record their original information and target mapping relationship, and output them to the to-be-supplemented data cache; assemble the final target protocol message structure, fill in the converted semantic content, and form an optimized conversion result that meets the target protocol specification. The real-time processing delay during the actual protocol conversion process is monitored. When a significant deviation from the expected protocol conversion delay is detected, the feedback adjustment mechanism is triggered to dynamically adjust resource allocation and semantic clipping levels to form a closed-loop control. Specifically, the real-time processing delay data of the current protocol conversion process is read, the deviation from the expected protocol conversion delay is calculated, and the delay deviation value is obtained; a delay deviation threshold is set, and when the delay deviation value exceeds this threshold, the feedback adjustment process is triggered; the positive and negative direction and amplitude of the delay deviation value are analyzed to determine whether the current delay condition is delay exceeding expectations or resource redundancy; in the case of delay exceeding expectations, the semantic clipping plan is quickly adjusted to further streamline the non-critical semantic retention subset to form an emergency clipping plan; at the same time, additional emergency processing resources are applied, and the resource allocation plan is updated to an emergency resource plan, giving priority to critical semantic processing; in the case of resource redundancy, the non-critical semantic retention subset is appropriately expanded to form an extended clipping plan, while releasing excess resources for use by other messages; based on the actual adjustment results, the parameters of the delay prediction model are updated to improve future prediction accuracy, and the model adjustment parameters are output. For messages that use semantic clipping, after completing the rapid conversion of key fields, the non-key field information is asynchronously supplemented and transmitted to ensure data integrity while not affecting the real-time performance of key services, and the complete converted data is output. Specifically, the non-key field information and related metadata in the data cache to be supplemented are read to evaluate the current network load status; based on the network load status and the semantic importance of the data to be supplemented, a hierarchical priority scheduling algorithm is used to calculate the optimal supplementary transmission time window; a dedicated supplementary data packet structure is constructed for the data to be supplemented, which contains metadata such as the original message identifier, timestamp, and supplementary content type to form a supplementary data packet; within the determined supplementary transmission time window, a low-priority channel is used to transmit the supplementary data packet to ensure that the current key business flow is not interfered with; at the target device end, the supplementary data packet is received and associated with the corresponding original converted message through the message identifier therein; the original converted message and the supplementary data content are merged to reconstruct the complete protocol message semantics, output the complete converted data, and update the relevant status in the target system.

[0081] Based on a multi-scale delay feature model and real-time processing of delay data, it identifies delay bottlenecks and congested areas in the current network topology and outputs a network bottleneck analysis report. Combining the network bottleneck analysis report and the end-to-end delay requirements of each business flow in the substation, a network optimization objective function is constructed. This function balances the delay performance of key businesses with network resource utilization. Specifically, the network bottleneck analysis report is read to extract the bottleneck degree index and congestion duration of each node and link in the network; the end-to-end delay requirements of various business flows in the substation are analyzed to determine the delay tolerance and business importance weight of each type of business; based on the bottleneck degree index and congestion duration, an initial performance evaluation function is constructed. This function considers the ratio of the delay improvement potential to the transformation cost of each bottleneck point and calculates the node improvement potential score; using existing business flow data to build a network traffic distribution model, simulate the impact of different topology changes on the delay of each business flow, and form a topology impact mapping matrix; integrating the node improvement potential score, topology impact mapping matrix, delay tolerance, and business importance weight to construct a comprehensive network optimization objective function. This function maximizes the delay performance gain under multiple constraints (resource limitations, reliability requirements, and business continuity). Based on the network optimization objective function, a set of candidate topology reconstruction schemes is generated. Each scheme includes specific link adjustment, traffic redistribution and protocol conversion node deployment strategies, and the candidate topology scheme set is output. Specifically, based on the existing network topology and network optimization objective function, a heuristic search algorithm is used to generate a series of potential topology adjustment schemes to form an initial candidate scheme pool; for each scheme in the candidate scheme pool, the specific implementation steps are refined, including link adjustment details, traffic routing rules and conversion node configuration, to form an executable topology adjustment scheme; each topology adjustment scheme is preliminarily screened, and obviously unreasonable or overly difficult to implement schemes are eliminated, while high-potential schemes are retained to generate a streamlined set of candidate topology schemes.

[0082] The impact of each candidate topology solution on the latency of key service flows is evaluated, considering three dimensions: latency performance, reliability, and implementation complexity. The solution that minimizes protocol conversion latency while meeting end-to-end latency requirements is selected, generating a solution evaluation result. The solution with the highest overall score from the evaluation results is selected as the optimal topology reconstruction solution for subsequent network reconfiguration. Specifically, a detailed network simulation model is constructed that accurately reflects the current substation network topology, equipment characteristics, and service flow characteristics. Each solution in the candidate topology solution set is evaluated in detail using the simulation model, simulating network performance under different load conditions and calculating the expected end-to-end latency for each service flow. Two additional metrics, reliability and implementation complexity, are introduced to form a multi-dimensional evaluation system, along with latency performance. The reliability of each solution is evaluated based on factors such as redundancy, single-point failure resilience, and security isolation, generating a reliability score. An implementation complexity score is generated by analyzing the implementation difficulty, resource requirements, and impact on existing services for each solution. A multi-objective optimization method is applied to comprehensively evaluate the three dimensions of latency performance, reliability, and implementation complexity, calculating a comprehensive optimization score for each solution. The candidate topology solutions are ranked according to their comprehensive optimization scores, generating a final evaluation result to provide a basis for selecting the optimal topology reconstruction solution. The solution with the highest comprehensive optimization score, which achieves the best balance across all evaluation dimensions, is selected as the optimal topology reconstruction solution. The optimal topology reconstruction solution is then executed, adjusting network connections, updating routing tables, and reallocating protocol conversion processing nodes to complete the adaptive reconstruction of the network topology, and the reconstruction execution results are output.

[0083] To address the uncertainty of protocol conversion delay, this embodiment establishes a multi-scale delay feature fusion model that integrates and analyzes delay features at three levels: macro-load trends, meso-level emergencies, and micro-level processing details. This model achieves highly accurate prediction of protocol conversion delay. Based on accurate delay prediction, a two-stage delay control strategy is implemented, combining feedforward resource allocation with real-time feedback adjustment to effectively address network load fluctuations and ensure that protocol conversion delay for critical protection services is stably controlled within 1 millisecond. To address the "all-or-nothing" problem of protocol conversion semantic processing, this embodiment proposes dynamic protocol semantic tailoring technology. By accurately identifying key and non-key semantic sets in messages and introducing a performance-semantics trade-off function, it achieves refined semantic processing based on latency budgets. This breaks the traditional "full conversion or simplified conversion" dichotomy and dynamically adjusts the semantic preservation level based on the latency sensitivity of different messages, maximizing processing latency while ensuring functional correctness. Furthermore, through an asynchronous supplementary transmission mechanism, "gradual conversion" is achieved, ensuring ultimate data integrity. Existing topology reconstruction methods usually focus on traffic distribution optimization at the network level, and rarely consider the impact of the deployment of protocol conversion nodes and protocol conversion delay on the overall network performance, resulting in limited end-to-end delay optimization effects in a multi-protocol mixed environment. In response to the problem that topology reconstruction does not consider the impact of protocol conversion delay, this embodiment designs an end-to-end delay-aware topology reconstruction decision-making mechanism, which organically combines the deployment of protocol conversion nodes with network traffic distribution optimization. By constructing a comprehensive network optimization objective function, not only traditional network congestion factors are considered, but also special attention is paid to the performance of conversion nodes through which cross-protocol business flows pass, thereby achieving coordinated optimization of resource allocation, protocol conversion and network topology. By evaluating the impact of candidate topology schemes on the delay of key business flows through simulation, the reconstruction scheme that can achieve the best balance in the three dimensions of delay performance, reliability and implementation complexity is selected, effectively solving the end-to-end delay optimization problem in a multi-protocol mixed environment.

[0084] In a specific embodiment of the present application, it is applied to a 220kV smart substation. The secondary system of the substation consists of 21 protection and control devices, including 6 protection devices, 4 merging units, 8 smart terminals and 3 gateway devices. These devices use three protocols: IEC 61850, Modbus and DNP3.0 for communication. The substation has the problem of uncertainty in protocol conversion delay. Especially in cross-protocol services, the delay of 2-10 milliseconds introduced by the standard protocol conversion process may cause delays in critical protection services and threaten equipment safety. The specific steps include:

[0085] Step 1: Delay-sensitive data collection and feature extraction.

[0086] 1.1. In this 220kV substation, network data acquisition equipment was deployed to collect network communication data within 24 hours. The collected results include the following: 12,463 IEC 61850 GOOSE messages with an average payload size of 385 bytes; 8,742 IEC 61850 MMS messages with an average payload size of 512 bytes; 4,215 DNP3.0 messages with an average payload size of 256 bytes; and 6,834 Modbus messages with an average payload size of 128 bytes. Data packet example (partial): Data packet ID: PKT-001254; Timestamp: 2024-05-09 09:15:23.456; Protocol type: IEC 61850 GOOSE; Payload size: 386 bytes; Priority tag: 7 (highest); Source device: Protection device 1; Target device: Smart terminal 3. These raw data form the raw communication dataset D. raw .

[0087] 1.2. Analysis of the original communication dataset D raw The network traffic fluctuation pattern within a 24-hour period is calculated as follows: The average load level per hour L h Calculation formula: L h = ∑(P i × S i ) / T h ; where P i is the i-th data packet, S i is the size of data packet i (bytes), T h The 24-hour data is statistically analyzed to obtain the macro load characteristic vector F macro =[L1, L2, ..., L 24 ]:F macro = [123.5, 142.8, 98.6, 76.4, 68.2, 72.5, 156.8, 254.3,312.5, 287.6, 265.4, 243.8, 256.9, 278.5, 254.3, 245.6, 267.8, 289.5, 276.4,232.1, 187.6, 156.4, 134.2, 128.7] KB / s; periodic load pattern P cycle Extraction by Fourier transform (FFT): P cycle = FFT(F macro ) = [0.0, 124.5∠0°, 78.3∠45°, 45.2∠90°, 32.1∠135°,...] KB / s.

[0088] 1.3. Statistics on network queue status and processing delay within a 100ms sliding window: queue occupancy rate Q i Calculation: Q i = B used / B total ; Among them B used is the occupied buffer size, B total is the total buffer size. Processing delay variance V i Calculation: V i = sqrt(∑(D j -D avg ) 2 / n); where D j is the jth packet processing delay, D avg is the average processing delay, and n is the number of packets in the window. Calculate the burst traffic index B i :B i = max(R j ) / R avg ; where R j is the data rate at the jth second in the window, R avg is the average data rate within the window. The statistical results for a representative 100ms window (09:15:23.400-09:15:23.500) are as follows: queue occupancy Q = 0.65 (65%); processing delay variance V = 0.82ms; burst traffic index B = 2.34; mesoscopic load characteristic vector F meso = [Q, V, B] = [0.65, 0.82, 2.34].

[0089] 1.4. Analyze the processing time distribution of the three stages of parsing, mapping, and repackaging during the protocol conversion process. Take the conversion from IEC61850 to DNP3.0 as an example: the processing delay T in the parsing stage parse = 1.25ms; Mapping phase processing delay T map =1.68ms; repackaging stage processing delay T pack = 0.92ms. Processing resource consumption statistics: CPU usage C cpu = 45%; memory usage M mem = 128MB; number of processing threads N thread = 4. Microscopic processing eigenvector F micro = [T parse , T map , T pack , C cpu , M mem , N thread ] = [1.25, 1.68, 0.92, 45, 128, 4].

[0090] 1.5. Extract macro-feature components. From the macro-load feature vector F macro Extract periodic load patterns and peak load periods from the baseline load trend BL trend = Mean(F macro ) = 203.6 KB / s; the periodic fluctuation component is extracted using wavelet decomposition: CW component = Wavelet decomposition(F macro -BL trend ) = [+52.3, +84.7, +43.2, -43.4, -72.1, ...]; Peak load period identification: PT peak = [8, 9, 10, 11, 17, 18, 19] (corresponding to 8-11 a.m. and 5-7 p.m.). Calculate the deviation of the mesoscopic load characteristic vector from the macroscopic baseline load trend: Load fluctuation intensity calculation: LS i ntensity = |F meso [0] - F macroavg / F macromax | = |0.65 - 0.45| = 0.20; Load mutation frequency calculation: LM frequency = Number of mutations / Observation time = 42 / 3600 = 0.0117 times / second. Distribution fitting of each stage processing delay in the micro-processing feature vector: Analytical stage delay distribution: DM parse = Lognormal distribution (mean μ = 0.223, standard deviation σ = 0.086); Mapping phase delay distribution: DM map = Normal distribution (μ = 1.68, σ = 0.123); Delay distribution during repackaging: DM pack = normal distribution (μ = 0.92, σ = 0.068). Based on the load fluctuation intensity and load mutation frequency, a high- and low-load state switching model is constructed: Load state definitions: Low-load state (L): load level <150 KB / s; Medium-load state (M): 150 KB / s ≤ load level <250 KB / s; High-load state (H): load level ≥ 250 KB / s. The state transition matrix SM = [ [0.75, 0.20, 0.05], [0.15, 0.70, 0.15], [0.10, 0.25, 0.65] ], where SM[i, j] represents the probability of transitioning from state i to state j. For example, the probability of transitioning from the low-load state to the medium-load state is 0.20. The delay probability distribution model is combined with the load state transition matrix: Conditional Delay Distribution Model: CDM(t|s) = α s × DMparse + β s × DM map + γ s × DM pack ; Where t is the delay value; s is the load state (L, M or H); α s , β s , γ s is the weight coefficient under state s; the weight coefficient matrix: WM = [ [0.30, 0.40, 0.30], low load state weight; [0.35, 0.40, 0.25], medium load state weight; [0.45, 0.35, 0.20], high load state weight]. For example, under high load, the weight of the parsing stage is 0.45, the mapping stage is 0.35, and the repackaging stage is 0.20. A hierarchical feature fusion algorithm is used to integrate all the above features: the multi-scale delay feature model MST. model Defined as a five-tuple: MST model ={BL trend , The CW component , SM, WM, CDM}. The model uses a hierarchical forecasting approach: using the baseline load trend BL trend and the periodic fluctuation component CW component Predict macro load levels; use the state transition matrix SM to predict load state transitions; use the weight coefficient matrix WM and the conditional delay distribution model CDM to predict specific delay values.

[0091] Step 2: Protocol conversion delay prediction and compensation strategy generation.

[0092] 2.1. Receive real-time raw communication dataset D raw_real , extract the multi-scale delay features of the current network state: the current macro load level L current = 268.5 KB / s; current mesoscopic load characteristic F meso_current = [0.72, 0.91, 2.65]; Current micro-processing feature F micro_current = [1.45, 1.83, 1.05, 58, 156, 4]. According to the multi-scale time delay feature model MST model Predicting protocol switching delay: Determine the current load state s = H (high load); obtain the corresponding weights WM[H] = [0.45, 0.35, 0.20]; calculate the expected processing delay E delay = WM[H][0]× F micro_current [0] +WM[H][1] × F micro_current [1] + WM[H][2] × F micro_current[2] = 0.45 × 1.45 + 0.35 × 1.83 + 0.20 × 1.05 = 1.51ms. Predict different types of messages: Expected protocol conversion delay table ET = { "IEC61850_GOOSE-to-DNP3.0": 2.45ms, "IEC61850_MMS-to-DNP3.0": 3.12ms, "IEC61850_GOOSE-to-Modbus": 1.98ms, "Modbus-to-IEC61850": 2.76ms, "DNP3.0-to-IEC61850": 2.83ms}.

[0093] 2.2. Calculate the delay margin based on the expected protocol conversion delay and the end-to-end delay requirements of the message: End-to-end delay requirement table TR = { "Protection trip command": 4ms, "Measurement data": 20ms, "Control command": 10ms, "Status information": 50ms, "Alarm information": 100ms}. Delay margin calculation formula: TM = TR[message type] - ET[protocol conversion type] - OT; where TM is the delay margin and OT is other processing delays (network transmission, etc.). Assume OT = 1ms. Calculate the delay margin for a "Protection trip command" (IEC61850_GOOSE-to-DNP3.0): TM = 4ms - 2.45ms - 1ms = 0.55ms; Calculate the delay margin for a "Measurement data" (Modbus-to-IEC61850): TM = 20ms - 2.76ms - 1ms = 16.24ms.

[0094] 2.3. Classify messages according to the delay margin and priority markings: Delay margin classification criteria: High sensitivity: TM ≤ 1ms; Medium sensitivity: 1ms < TM ≤ 10ms; Low sensitivity: TM > 10ms. Example message classification: "Protection trip command" (TM = 0.55ms, priority = 7) → High sensitivity; "Control command" (TM = 6.88ms, priority = 5) → Medium sensitivity; "Measurement data" (TM = 16.24ms, priority = 3) → Low sensitivity. For high-sensitivity messages (such as "Protection trip command"), calculate the minimum processing resources required: Minimum CPU resource requirement R cpu = C cpu_base × (ET base / TM target );where C cpu_base is the reference CPU usage rate (40%), ET baseThe benchmark processing delay is 2.45ms. target is the target processing delay (0.55ms). cpu = 40% × (2.45ms / 0.55ms) = 178.2%, requiring allocation to two processing cores. Minimum memory requirement R mem = 128MB (basic processing memory requirement); minimum bandwidth requirement R bw = 50Mbps (basic processing bandwidth requirement). Construct a weight matrix for each resource's contribution to reducing switching delay: Resource-Delay Sensitivity Matrix RTS = {"CPU": 0.65, for every 10% increase in CPU resources, latency is reduced by 6.5%; "Memory": 0.15, for every 10MB increase in memory resources, latency is reduced by 1.5%; "Bandwidth": 0.20, for every 10Mbps increase in bandwidth resources, latency is reduced by 2.0%}. Based on the resource-delay sensitivity matrix, a resource allocation algorithm is used to calculate the optimal allocation plan: For highly sensitive messages (such as "protection tripping instructions"), CPU resources A are allocated. cpu = 180% (allocated to 2 processing cores); memory resource A mem = 192MB; Bandwidth resource A bw = 80Mbps. Allocation of medium-sensitivity messages (such as "control instructions"): CPU resource A cpu = 90% (allocated to 1 processing core); memory resource A mem = 128MB; Bandwidth resource A bw= 50 Mbps. Resource allocation scheme RA = {"High Sensitivity": {CPU: 180%, Memory: 192 MB, Bandwidth: 80 Mbps}, "Medium Sensitivity": {CPU: 90%, Memory: 128 MB, Bandwidth: 50 Mbps}, "Low Sensitivity": {CPU: 50%, Memory: 96 MB, Bandwidth: 30 Mbps}}. Based on the allocated resources, combined with the message protocol type and complexity, the most appropriate translation path is selected: Translation path library CP = {"Full Stack Translation": {Latency: High, Resource Consumption: High, Integrity: Full}, "Critical Field Translation": {Latency: Medium, Resource Consumption: Medium, Integrity: Partial}, "Minimal Field Translation": {Latency: Low, Resource Consumption: Low, Integrity: Minimum}}. The "Minimal Field Translation" path is selected for high-sensitivity messages (such as "Protection Trip Command"). The "Critical Field Translation" path is selected for medium-sensitivity messages (such as "Control Command"). For low-sensitivity messages (such as "measurement data"), the "full stack conversion" path is selected. Conversion path selection = {"high sensitivity": "minimum field conversion", "medium sensitivity": "key field conversion", "low sensitivity": "full stack conversion"}. Combining the resource allocation scheme and conversion path selection, a complete delay compensation strategy is generated: Delay Compensation Strategy TC = {"resource allocation": RA, "conversion path": CP select , "Processing Priority": { "High Sensitivity": 1, "Medium Sensitivity": 2, "Low Sensitivity": 3}}.

[0095] 2.4. Establish a resource pooling mechanism to avoid resource competition when multiple high-priority messages arrive at the same time: the total amount of resource pool RP total = {"CPU": 400% (4 processing cores), "Memory": 512MB, "Bandwidth": 200Mbps}; Reserved resources (high-sensitivity messages) RP reserved = {"CPU": 180% (2 processing cores), "Memory": 192MB, "Bandwidth": 80Mbps}; Resource pool configuration RP config = { "Total amount": RP total , "reserved": RP reserved , "Available": { "CPU": 220% (2.2 processing cores), "Memory": 320MB, "Bandwidth": 120Mbps}}.

[0096] Step 3: Protocol conversion optimization and delay control execution.

[0097] 3.1. Determine the appropriate protocol conversion processing mode for each message based on the conversion path in the delay compensation strategy TC: Conversion Mode Decision TM decision = { "High Sensitivity": { "Mode": "Minimal Field Conversion", "Processing Depth": 1, # Process only key control fields "Priority": 1}, "Medium Sensitivity": { "Mode": "Key Field Conversion", "Processing Depth": 2, # Process control fields and main status fields "Priority": 2}, "Low Sensitivity": { "Mode": "Full Stack Conversion", "Processing Depth": 3, # Fully process all fields "Priority": 3}}.

[0098] 3.2. Implement feedforward scheduling based on the resource allocation plan, giving priority to high-latency sensitive services: Resource scheduling instruction RD = { "CPU affinity": { "High sensitivity": [0, 1], # Specify the use of CPU cores 0 and 1 "Medium sensitivity": [2], # Specify the use of CPU core 2 "Low sensitivity": [3] # Specify the use of CPU core 3}, "Memory allocation": { "High sensitivity": "192MB", "Medium sensitivity": "128MB", "Low sensitivity": "96MB"}, "Queue priority": { "High sensitivity": 1, # Highest priority queue "Medium sensitivity": 2, # Medium priority queue "Low sensitivity": 3 # Low priority queue}}.

[0099] 3.3, taking the IEC 61850 GOOSE protection trip message as an example, analyze its protocol structure: read the protocol type (IEC61850 GOOSE) and message type (protection trip), query the protocol semantic knowledge base, and extract the complete semantic structure graph SG full The complete semantic structure diagram includes the following field groups: message header field group (6 fields); APPID field (1 field); GOOSE control block field group (4 fields); data set reference field (1 field); timestamp field (1 field); status number field (SqNum, 1 field); test flag field (1 field); configuration version field (1 field); data set content field group (12 fields); check field (1 field). According to the current control requirements (protection tripping), identify the necessary function fields FF necessary : Necessary function field FF necessary= ["APPID", "GOOSE control block identifier", "timestamp", "status number", "trip command type", # data set content field 1 "trip phase information", # data set content field 2 "trip cause code" # data set content field 3]. Analyze the application context of the target message in the current business environment (protection trip) and identify the associated status field SF. related : Association status field SF related = ["Test Flag", "Configuration Version", "Device Identifier", # Data Set Content Field 8 "Protection Action Time" # Data Set Content Field 9]. Combine the necessary function fields and the associated status fields to form a key semantic set KS: Key semantic set KS = FF necessary + SF related =["APPID","GOOSE control block identifier","Timestamp","Status number","Trip command type","Trip phase information","Trip cause code","Test flag","Configuration version","Device identifier","Protection action time"]. The remaining fields in the complete semantic structure diagram are classified into the non-key semantic set NKS: Non-key semantic set NKS = ["Destination MAC address","Source MAC address","Ethernet type","Priority tag","GOOSE PDU length","GOOSE protocol version","Data set reference","Fault phase current value", # Data set content field 4 "Fault phase voltage value", # Data set content field 5 "Zero sequence current value", # Data set content field 6 "Zero sequence voltage value", # Data set content field 7 "Spare field 1", # Data set content field 10 "Spare field 2", # Data set content field 11 "Spare field 3", # Data set content field 12 "Checksum"]. Assign a semantic importance score SI to each field in the key semantic set: Semantic importance score matrix SI = { "APPID": 0.95, "GOOSE control block identifier": 0.90, "timestamp": 0.85, "status number": 0.90, "trip command type": 1.00, # highest importance "trip phase information": 0.98, "trip reason code": 0.95, "test flag": 0.85, "configuration version": 0.80, "device identifier": 0.75, "protection action time": 0.88}.

[0100] Read the message delay margin (TM = 0.55 ms) and conversion mode decision (minimum field conversion), and calculate the maximum allowable protocol conversion processing time MT = 0.50 ms. Establish a protocol field processing time model and estimate the time KT required to process all fields in the critical semantic set: Field processing time table FT = { "APPID": 0.05 ms, "GOOSE control block identifier": 0.08 ms, "Timestamp": 0.06 ms, "Status number": 0.04 ms, "Trip command type": 0.08 ms, "Trip phase information": 0.07 ms, "Trip reason code": 0.06 ms, "Test flag": 0.03 ms, "Configuration version": 0.04 ms, "Device identifier": 0.05 ms, "Protection action time": 0.06 ms}. Critical semantic processing time KT = ∑FT[field] for field in KS = 0.62 ms. Compare the maximum allowable processing time with the critical semantic processing time: MT (0.50 ms) < KT (0.62 ms), the critical semantic set cannot be fully processed and needs to be further trimmed. Construct a performance-semantic trade-off function PST, which maximizes the retained semantic information under time constraints: Performance-semantic trade-off function PST(F) = ∑(SI[f] × I(f in F)) / ∑FT[f]; where F is the field set, SI[f] is the semantic importance score of field f, I(f in F) is the indicator function (1 if f is in F, otherwise 0), and FT[f] is the processing time of field f. Use the performance-semantic trade-off function to select the optimal field subset F opt , such that ∑FT[f] for f in F opt ≤ MT; PST(F opt ) has the maximum value. Through the greedy algorithm, sort the fields by SI[f] / FT[f] and select a subset of the critical semantic set: Optimized critical semantic set KS opt= [ "Trip command type", # SI = 1.00, FT = 0.08ms; "Trip phase information", # SI = 0.98, FT = 0.07ms; "Trip cause code", # SI = 0.95, FT = 0.06ms; "APPID", # SI = 0.95, FT = 0.05ms; "GOOSE control block identifier", # SI = 0.90, FT = 0.08ms; "Status number", # SI = 0.90, FT = 0.04ms; "Timestamp" # SI = 0.85, FT = 0.06ms ]. Total processing time = 0.08 + 0.07 + 0.06 + 0.05 + 0.08 + 0.04 = 0.38ms < MT(0.50ms). Non-critical semantic retention subset NKS kept = [ "Test flag", # SI = 0.85, FT = 0.03ms "Protection operation time" # SI = 0.88, FT = 0.06ms ]. Total processing time = 0.38ms + 0.03ms + 0.06ms = 0.47ms < MT(0.50ms). Integrate and optimize the critical semantic set and non-critical semantic retention subset to form the final semantic pruning scheme SP: Semantic pruning scheme SP = { "Fields to be retained": KS opt , # Optimized critical semantic set; "Fields with secondary retention": NKS kept , # Non-critical semantic retention subset; "Fields to be supplemented": KS - KS opt + NKS - NKS kept , # Fields that cannot be processed currently; "Processing priority": { "Fields to be retained": 1, "Fields with secondary retention": 2}, "Estimated total processing time": 0.47ms}.

[0101] Read the source protocol message (IEC 61850 GOOSE protection trip message) and the semantic tailoring scheme (SP), prepare the protocol conversion environment and resources. Prioritize the "required fields" (optimized key semantic set) and convert them to the target protocol format (DNP3.0) according to predefined mapping relationships: IEC 61850 GOOSE to DNP3.0 key semantic mapping table KM = { "APPID": "Application Identifier", "GOOSE Control Block Identifier": "Source Point Code", "Status Number": "Sequence Number", "Time Stamp": "Time Stamp", "Trip Command Type": "BIN Output Point Command Code", "Trip Phase Information": "BIN Output Index Number", "Trip Cause Code": "Status Code"}. The generated key semantic conversion result KR = {"Application Identifier": "0x4001", "Source Point Code": "P5", "Serial Number": "1458", "Time Stamp": "2024-05-09 09:15:23.456", "BIN Output Point Command Code": "0x03", "BIN Output Index Number": "0x02", # Phase A tripped, "Status Code": "0x01" # Overcurrent protection}. The "Secondary Reserved Field" (non-key semantic reserved subset) is processed and converted to the target protocol format: the secondary semantic mapping table SM from IEC 61850 GOOSE to DNP3.0 = {"Test Flag": "Test Bit", "Protection Action Time": "Event Time"}; the generated secondary semantic conversion result SR = {"Test Bit": "0", "Event Time": "100ms"}. Fields that cannot be processed in the current conversion cycle are marked with "to be supplemented" identifiers, their original information and target mapping relationships are recorded, and the results are output to the "to be supplemented" data buffer PS: "to be supplemented" data buffer PS = { "Message ID": "PKT-001254", "Fields to be supplemented": [ {"Original field": "Configuration version", "Target field": "Configuration version", "Original value": "2", "Mapping relationship ID": "M17"}, {"Original field": "Device identifier", "Target field": "Device identifier", "Original value": "PROT1", "Mapping relationship ID": "M23"}, {"Original field": "Destination MAC address", "Target field": "None", "Original value": "01:0C:CD:01:00:01", "Mapping relationship ID": "None"}, # ... other unprocessed fields]}.Assemble the final target protocol message structure, fill in the converted semantic content, and form the optimized conversion result OR: DNP3.0 message structure = { "Message Header": { "Start Byte": "0x0564", "Length": "18", "Control Code": "0x44", "Destination Station Address": "3", "Source Station Address": "1"}, "Application Layer": { "Application Control": "0xC0", # Confirmation Request "Function Code": "0x03", # Direct Operation "Internal Indication": "0x00", "Application Identifier": KR["Application Identifier"], "Source Point Code": KR["Source Point Code"], "Sequence Number": KR["Sequence Number"], "Time Tag": KR["Time Tag"], "Object Header": { "Group Number": "0x0C", # BIN Output "Variation Point": "0x01", # Single Point "Qualifier": "0x17", # Number of Fields within Range 7 "BIN Output Point Command Code": KR["BIN Output Point Command Code"], "BIN Output Index Number": KR["BIN Output Index Number"], "Status Code": KR["Status Code"], "Test Bit": SR["Test Bit"], "Event Time": SR["Event Time"]}}, "Checksum": "0xA2B6"}.

[0102] Read the real-time processing delay RT = 0.52ms of the current protocol conversion process, calculate the deviation from the expected protocol conversion delay (ET = 0.47ms), and obtain the delay deviation value DV = RT - ET = 0.05ms. Set the delay deviation threshold DT = 0.1ms. When |DV| > DT, trigger the feedback adjustment process. In this example, |DV| (0.05ms) < DT (0.1ms), so there is no need to trigger the feedback adjustment. However, for the purpose of demonstrating the feedback adjustment process, assume that in a subsequent message processing, RT = 0.65ms and ET = 0.47ms are measured, and DV = 0.18ms > DT is calculated, which requires triggering the feedback adjustment. Analyze the delay deviation value DV = 0.18ms > 0, and determine that the current delay situation is "delay exceeds expectation". Quickly adjust the semantic pruning scheme, further streamline the non-critical semantic retention subset, and form the emergency pruning scheme ESP: Remove "protection action time" from the non-critical semantic retention subset NKS kept to save 0.06ms of processing time: Emergency Pruning Scheme ESP = { "Fields to be Retained": KS opt , # unchanged "Sub-Fields to be Retained": ["test flag"], # Only retain the test flag "Fields to be Supplemented": KS - KS opt+ NKS - ["Test Flag"], # More fields are added to the "Processing Priority" field: {"Required Fields": 1, "Secondary Fields": 2}, "Total Estimated Processing Time": 0.41ms}. Request additional emergency processing resources and update the resource allocation plan to the Emergency Resource Plan (ERP): Emergency Resource Plan (ERP) = {"CPU": 220%, # Increase to 2.2 cores; "Memory": 192MB, # Unchanged; "Bandwidth": 100Mbps, # Increase by 20%}. For resource redundancy, expand the reserved subset of non-critical semantics and release excess resources. In this case, latency exceeded expectations, so this is not executed. Based on the actual adjustment results, update the parameters of the delay prediction model to improve future prediction accuracy: Model adjustment parameter MAP = { "Processing delay coefficient adjustment": 1.15, # The actual processing delay is about 15% higher than the prediction "State transition probability adjustment": [0, 0, 0.05], # Increase the probability of a high load state by 5% "Weight coefficient matrix adjustment": [[0, 0, 0], [0, 0, 0], [0.05, -0.03, -0.02]] # Increase the weight of the parsing phase under high load by 5%}. The updated weight coefficient matrix is: WM updated = [ [0.30, 0.40, 0.30], # the weight of the low load state remains unchanged; [0.35, 0.40, 0.25], # the weight of the medium load state remains unchanged; [0.50, 0.32, 0.18] # the weight of the high load state is adjusted].

[0103] The system reads non-critical fields and related metadata from the pending data cache (PS) and assesses the current network load: CL = 196.4 KB / s (medium load). Based on the network load and the semantic importance of the pending data, it calculates the optimal supplement transmission window (ST). The priority order of the pending data is: "Configuration Version" (SI = 0.80); "Device Identifier" (SI = 0.75); and "Other Non-critical Fields" (SI < 0.50). The network load forecast indicates a low load period in 12 seconds, lasting approximately 30 seconds. The supplement transmission window (ST) is [09:15:35.500, 09:16:05.500]. Build a dedicated supplementary data packet structure SD, which contains metadata such as the original message identifier, timestamp, and supplementary content type: Supplementary data packet SD = { "Package Type": "0xF2", # Supplementary data type "Original Message ID": "PKT-001254", "Original Message Timestamp": "2024-05-09 09:15:23.456", "Supplementary Timestamp": "2024-05-09 09:15:35.500", "Supplementary Content Type": "0x01", # Non-critical semantic supplement "Number of Supplementary Fields": 15, "Supplementary Content": [ {"Field ID": "0x17", "Field Name": "Configuration Version", "Field Value": "2"}, {"Field ID": "0x23", "Field Name": "Device Identifier", "Field Value": "PROT1"}, # ... other supplementary fields], "Checksum": "0xB7C9"}. Within the specified supplementary transmission time window, a low-priority channel is used to transmit the supplementary data packet to ensure that it does not interfere with the current critical service flow: Supplementary Data Transmission Configuration STC = { "Transmission Channel": "Channel 4", # Low-priority channel "QoS Level": "Best Effort", "Transmission Time": "2024-05-09 09:15:40.000", # Specific time selected within the time window "Timeout Setting": "5 seconds", "Number of Retries": 2}. On the target device side, the supplementary data packet is received and associated with the corresponding original converted message using the message identifier in it: Message Association Result MA = { "Original Message ID": "PKT-001254", "Original Message Storage Location": "0x12A8F4", "Original Message Processing Status": "Processed", "Original Message Execution Result": "Successful Trip"}.Merge the original conversion message and supplementary data content, reconstruct the complete protocol message semantics, and output the complete conversion data CD: complete conversion data CD = optimized conversion result OR + { "application layer": { "extended field": { "configuration version": "2", "device identification": "PROT1", # ... other supplementary fields}}}.

[0104] Step 4: End-to-end delay perception and topology reconstruction decision-making.

[0105] 4.1. Multi-scale delay feature model MST model The network topology has 16 nodes and 24 links. By analyzing the processing delay data of nearly 1 hour, the bottleneck index of each node and link is calculated: the node bottleneck index NBI calculation formula is: NBI = (P avg / P max ) × (Q avg / Q max ) × (D avg / D threshold ); where P avg is the average processing load, P max is the maximum processing capacity, Q avg is the average queue length, Q max is the maximum queue length, D avg is the average processing delay, D threshold is the delay threshold. The calculation formula of link congestion index LCI is: LCI = (B avg / B max ) × (D var / D varmax ); where B avg is the average bandwidth occupancy, B max is the maximum bandwidth, D var is the delay change rate, D varmax is the maximum acceptable delay variation rate.

[0106] Node bottleneck analysis results: Node 6 (Protocol Conversion Gateway 1): NBI = 0.85, congestion duration = 42 minutes / hour; Node 9 (Protocol Conversion Gateway 2): NBI = 0.72, congestion duration = 28 minutes / hour; Node 12 (Network Switch 3): NBI = 0.68, congestion duration = 25 minutes / hour; Other nodes: NBI < 0.50. Link congestion analysis results: Link 8-6 (Protection Device 2 to Gateway 1): LCI = 0.78, congestion duration = 35 minutes / hour; Link 5-12 (Protection Device 4 to Switch 3): LCI = 0.65, congestion duration = 23 minutes / hour; Other links: LCI < 0.60. Network Bottleneck Analysis Report NBR = { "Node Bottlenecks": [ { "Node ID": 6, "Node Type": "Protocol Conversion Gateway 1", "NBI": 0.85, "Congestion Duration": 42}, { "Node ID": 9, "Node Type": "Protocol Conversion Gateway 2", "NBI": 0.72, "Congestion Duration": 28}, { "Node ID": 12, "Node Type": "Network Switch 3", "NBI": 0.68, "Congestion Duration": 25} ], "Link Congestion": [ { "Link ID": "8-6", "Link Type": "Protection Device 2 to Gateway 1", "LCI": 0.78, "Congestion Duration": 35}, { "Link ID": "5-12", "Link Type": "Protection Device 4 to Switch 3", "LCI": 0.65, "Congestion Duration": 23} ],"Bottleneck Cause Analysis":{"Node 6":"Processing multiple protocol conversion tasks, severe resource competition","Link 8-6":"Protection tripping instructions and measurement data share the same channel, resulting in bandwidth contention"}}.

[0107] 4.2. Extract the bottleneck index and congestion duration of each node and link from the network bottleneck analysis report NBR: bottleneck index matrix BIM = [ [6, 0.85, 42], # [node ID, NBI, congestion duration][9, 0.72, 28], [12, 0.68, 25], ["8-6", 0.78, 35], # [link ID, LCI, congestion duration]["5-12", 0.65, 23]]. Analyze the end-to-end delay requirements of various service flows in the substation and determine the delay tolerance and service importance weight of each service type: service delay requirement matrix BDM = [ ["Protection trip command", 4, 1.0], # [Service type, Delay tolerance (ms), Importance weight] ["Measurement data", 20, 0.6], ["Control command", 10, 0.8], ["Status information", 50, 0.5], ["Alarm information", 100, 0.7] ]. Construct an initial performance evaluation function and calculate the delay improvement potential score of each bottleneck point: The delay improvement potential score IPS calculation formula is: IPS = (BIM[i][1]×BIM[i][2]) / C[i]; where BIM[i][1] is the bottleneck degree index, BIM[i][2] is the congestion duration, and C[i] is the transformation cost coefficient (assuming the node transformation cost is 2.0 and the link transformation cost is 1.0). Node improvement potential score calculation: Node 6: IPS = (0.85 × 42) / 2.0 = 17.85; Node 9: IPS = (0.72 × 28) / 2.0 = 10.08; Node 12: IPS = (0.68 × 25) / 2.0 = 8.50. Link improvement potential score calculation: Link 8-6: IPS = (0.78 × 35) / 1.0 = 27.30; Link 5-12: IPS = (0.65 × 23) / 1.0 = 14.95. Node improvement potential score matrix IPSM = [ [6, 17.85], [9, 10.08], [12, 8.50], ["8-6", 27.30], ["5-12", 14.95] ]. Construct a network traffic distribution model to simulate the impact of different topology changes on the latency of each business flow: Topology change types: adding nodes (adding new protocol conversion gateways); modifying links (adding dedicated links); load splitting (business separation); relocating protocol conversion points.For each topology change, calculate the service flow delay impact factor (TIF): Topology impact mapping matrix (TIM) = [topology change type, protection tripping delay impact, measurement data delay impact, control command delay impact, status information delay impact, alarm information delay impact] = [1, -0.65, -0.30, -0.45, -0.25, -0.20], # adding a node [2, -0.75, -0.50, -0.55, -0.35, -0.25], # modifying a link [3, -0.60, -0.70, -0.50, -0.60, -0.65], # load splitting [4, -0.80, -0.40, -0.60, -0.30, -0.25] # protocol conversion point relocation]. Negative values indicate delay reduction. For example, the impact factor of adding a node on the delay of the protection tripping command is -0.65, indicating that the delay can be reduced by 65%. By integrating the node improvement potential score matrix IPSM and the topology impact mapping matrix TIM, a comprehensive network optimization objective function NOF is constructed: Network optimization objective function NOF(T, N) =∑(BDM[j][2]× min(TIM[T][j+1]× (-1) × 100, BDM[j][1])) × ∑IPSM[i][1]; where T is the topology change type, N is the set of changed nodes / links, BDM[j][2] is the importance weight of service j, TIM[T][j+1] is the delay impact factor of topology change T on service j, BDM[j][1] is the delay tolerance of service j, and IPSM[i][1] is the improvement potential score of node / link i. This function maximizes the delay performance gain under the constraints of resource constraints (a maximum of 3 points can be modified), reliability requirements (redundancy is not less than 2), and service continuity (service is not interrupted during the modification process).

[0108] 4.3. Based on the existing network topology and the network optimization objective function NOF, a series of potential topology adjustment schemes are generated: candidate scheme pool CP = { "Scheme 1": { "Type": 1, # Adding node "Change Point": [{"New": "Protocol Conversion Gateway 3", "Location": "Near Protection Device 2", "Function": "Dedicated Protection Service Protocol Conversion"}], "NOF Initial Estimate": 245.6}, "Scheme 2": { "Type": 2, # Modifying link "Change Point": [{"Add": "High-speed Dedicated Link", "Starting Point": "Protection Device 2", "Ending Point": "Gateway 1", "Bandwidth": "1 Gbps"}], "NOF Initial Estimate": 273.8}, "Scheme 3": { "Type": 3, # Load splitting "Change Point": [{"Adjustment": "Service Separation", "Protection Service": "Gateway 1", "Non-protection Service": "Gateway 2"}], "NOF Initial Estimate": 216.3}, "Scheme 4": { "Type": 4, # Relocate the protocol conversion point "Change Point": [{"Move": "Gateway 1", "New Location": "Close to Switch 1", "Optimization Goal": "Reduce Transmission Distance"}], "NOF Initial Estimate": 198.7}, "Scheme 5": { "Type": [1, 2], # Hybrid Scheme: Add Nodes + Modify Links "Change Point": [{"Added": "Protocol Conversion Gateway 3", "Location": "Close to Protection Device 2", "Function": "Dedicated Protection Service Protocol Conversion"}, {"Added": "High-speed Dedicated Link", "Starting Point": "Protection Device 4", "End Point": "Switch 3", "Bandwidth": "1 Gbps"}], "NOF Initial Estimate": 312.5}}. For each solution in the candidate solution pool, detail the specific implementation steps. Taking "Scheme 5" as an example, detail its implementation steps: Link Adjustment Details LD = {"Step 1": "Install a new protocol conversion gateway 3 in cabinet 3", "Step 2": "Configure the IP address of gateway 3 to 10.1.1.15", "Step 3": "Configure gateway 3 to support the dedicated conversion function from IEC61850 to DNP3.0", "Step 4": "Deploy the semantic dynamic tailoring module on gateway 3", "Step 5": "Lay a direct optical fiber from protection device 2 to gateway 3", "Step 6": "Lay a gigabit optical fiber from protection device 4 to switch 3", "Step 7": "Update the routing table to forward the tripping command of protection device 2 to gateway 3", "Step 8": "Update the routing table to forward high-priority messages from protection device 4 through the new link"}.

[0109] Traffic routing rule FR = { "Rule 1": "Protection tripping instructions are sent from protection device 2 after conversion via gateway 3", "Rule 2": "Measurement data are transmitted along the original path", "Rule 3": "Control instructions are divided into paths based on priority", "Rule 4": "All messages from protection device 4 are transmitted via the newly added high-speed link"}. Conversion node configuration CC = { "Gateway 1 configuration": { "Mainly responsible": "Control instruction and measurement data conversion", "CPU allocation": "70%", "Protocol support": ["IEC61850-MMS to DNP3.0", "Modbus to IEC61850"]}, "Gateway 2 configuration": { "Mainly responsible": "Status information and alarm information conversion", "CPU allocation": "60%", "Protocol support": ["IEC61850 to Modbus", "DNP3.0 to IEC61850"]}, "Gateway 3 configuration": { "Mainly responsible": "Dedicated conversion of protection tripping instructions", "CPU allocation": "90% dedicated to protection services", "Protocol support": ["IEC61850-GOOSE to DNP3.0"]}}. Topology adjustment plan TA = {"Scheme ID": 5,"Link Adjustment Details": LD,"Traffic Routing Rules": FR,"Conversion Node Configuration": CC,"Expected Effect":"Protection trip command delay reduced by 80%, and other service delays reduced by an average of 40%"}.

[0110] Perform a preliminary screening of each topology adjustment plan to eliminate unreasonable or overly difficult plans: Plan screening criteria SS = {"Feasibility threshold": 0.7, # between 0 and 1, the higher the threshold, the stricter the requirements; "Cost ceiling": 50,000, # in RMB; "Implementation difficulty ceiling": 0.8, # between 0 and 1, the higher the threshold, the more difficult it is; "Service interruption risk ceiling": 0.2, # between 0 and 1, the higher the threshold, the greater the risk}. All options are evaluated: Option 1: Feasibility = 0.85, Cost = 30,000, Implementation Difficulty = 0.6, Business Interruption Risk = 0.15; Option 2: Feasibility = 0.90, Cost = 15,000, Implementation Difficulty = 0.5, Business Interruption Risk = 0.20; Option 3: Feasibility = 0.75, Cost = 5,000, Implementation Difficulty = 0.4, Business Interruption Risk = 0.10; Option 4: Feasibility = 0.65, Cost = 25,000, Implementation Difficulty = 0.9, Business Interruption Risk = 0.30; Option 5: Feasibility = 0.80, Cost = 45,000, Implementation Difficulty = 0.7, Business Interruption Risk = 0.18. Option 4 is eliminated (its feasibility is below the threshold, its implementation difficulty is above the upper limit, and its business interruption risk is above the upper limit). The candidate topology solution set CTS = {Option 1, Option 2, Option 3, Option 5}.

[0111] 4.4. Construct a detailed network simulation model to accurately reflect the current substation network topology, device characteristics, and traffic flow characteristics. The network simulation model includes the following components: Topology model: The connection relationships of 16 nodes and 24 links; Device characteristic model: Parameters such as the processing capability, queue length, and buffer size of each device; Protocol characteristic model: The message structure and processing characteristics of IEC61850, DNP3.0, and Modbus; Traffic flow model: The frequency, data volume, and priority of five types of traffic flows; Delay calculation model: The calculation methods for transmission delay, queuing delay, and processing delay. Each candidate topology solution set (CTS) was evaluated in detail using the simulation model: Simulation conditions: Simulation duration: 3600 seconds (1 hour); Load pattern: [low load (20 minutes) → medium load (20 minutes) → high load (20 minutes)]; Traffic generation pattern: Generated based on the actual substation traffic statistical distribution; Key event: Triggering two protection trip commands during the high load period.

[0112] Simulation results (partial): Simulation results of Scheme 1: Average delay of protection tripping instructions: 1.25ms (original: 3.85ms), a reduction of 67.5%; average delay of measurement data: 12.6ms (original: 15.8ms), a reduction of 20.3%; average delay of control instructions: 5.8ms (original: 8.5ms), a reduction of 31.8%; average delay of status information: 38.5ms (original: 45.2ms), a reduction of 14.8%; average delay of alarm information: 85.2ms (original: 96.3ms), a reduction of 11.5%; network congestion probability under high load conditions: 0.35 (original: 0.72), a reduction of 51.4%. Simulation results for Scheme 2: Average delay of protection tripping commands: 0.95ms (original: 3.85ms), a reduction of 75.3%; average delay of measurement data: 10.2ms (original: 15.8ms), a reduction of 35.4%; average delay of control commands: 6.1ms (original: 8.5ms), a reduction of 28.2%; average delay of status information: 40.1ms (original: 45.2ms), a reduction of 11.3%; average delay of alarm information: 88.5ms (original: 96.3ms), a reduction of 8.1%; network congestion probability under high load conditions: 0.40 (original: 0.72), a reduction of 44.4%. Simulation results for Scheme 3: Average delay of protection tripping commands: 1.85ms (original: 3.85ms), a reduction of 51.9%; average delay of measurement data: 8.5ms (original: 15.8ms), a reduction of 46.2%; average delay of control commands: 6.8ms (original: 8.5ms), a reduction of 20.0%; average delay of status information: 30.2ms (original: 45.2ms), a reduction of 33.2%; average delay of alarm information: 65.4ms (original: 96.3ms), a reduction of 32.1%; network congestion probability under high load conditions: 0.28 (original: 0.72), a reduction of 61.1%. Simulation results for Scheme 5: Average delay of protection tripping commands: 0.75ms (original: 3.85ms), a reduction of 80.5%; average delay of measurement data: 9.2ms (original: 15.8ms), a reduction of 41.8%; average delay of control commands: 5.2ms (original: 8.5ms), a reduction of 38.8%; average delay of status information: 35.1ms (original: 45.2ms), a reduction of 22.3%; average delay of alarm information: 70.5ms (original: 96.3ms), a reduction of 26.8%; network congestion probability under high load conditions: 0.22 (original: 0.72), a reduction of 69.4%.Expected end-to-end delay ET = { "Scheme 1": [1.25, 12.6, 5.8, 38.5, 85.2], "Scheme 2": [0.95, 10.2, 6.1, 40.1, 88.5], "Scheme 3": [1.85, 8.5, 6.8, 30.2, 65.4], "Scheme 5": [0.75, 9.2, 5.2, 35.1, 70.5]}.

[0113] Two additional metrics, reliability and implementation complexity, have been introduced. The reliability score is calculated based on: System redundancy (higher, better): The degree of redundancy provided for key links; Single point failure recovery (higher, better): The system's ability to recover from a single node or link failure; Security isolation (higher, better): The degree of isolation between critical and non-critical services. The implementation complexity score is calculated based on: Hardware changes (lower, better): The number of devices that need to be added or replaced; Software configuration complexity (lower, better): The amount of software and configuration updates required; Service interruption time (shorter, better): The duration of service interruption during implementation; Professional skills requirements (lower, better): The level of professional skills required for implementation. Scoring results (out of 10 points): Reliability score RS = { "Scheme 1": 8.2, "Scheme 2": 7.5, "Scheme 3": 6.8, "Scheme 5": 8.8}; Implementation complexity score CS (the lower the better) = { "Scheme 1": 6.5, "Scheme 2": 4.2, "Scheme 3": 3.0, "Scheme 5": 7.8}.

[0114] A multi-objective optimization method was applied to conduct a comprehensive evaluation: the multi-objective optimization weights were set as follows: delay performance weight WT = 0.6; reliability weight WR = 0.3; implementation complexity weight WC = 0.1 (complexity is a negative indicator, so the inverse value is taken). The delay performance score TS is calculated as follows: TS = ∑(BDM[j][2]× (ET orig [j] - ET[i][j]) / ET orig [j]); where BDM[j][2] is the importance weight of business j, ET orig[j] is the original delay, and ET[i][j] is the expected delay of solution i. Latency performance score calculation (normalized to 10 points): TS["Scheme 1"] = (1.0×67.5% + 0.6×20.3% + 0.8×31.8% + 0.5×14.8% + 0.7×11.5%) / (1.0+0.6+0.8+0.5+0.7) × 10 = 7.2 TS["Scheme 2"] = (1.0×75.3% + 0.6×35.4% + 0.8×28.2% + 0.5×11.3% + 0.7×8.1%) / (1.0+0.6+0.8+0.5+0.7) × 10 = 7.8 TS["Scheme 3"] = (1.0×51.9% + 0.6×46.2% + 0.8×20.0%) +0.5×33.2% + 0.7×32.1%) / (1.0+0.6+0.8+0.5+0.7) × 10 = 6.9 TS["Scheme 5"]=(1.0×80.5% + 0.6×41.8% + 0.8×38.8% + 0.5×22.3% + 0.7×26.8%) / (1.0+0.6+0.8+0.5+0.7) × 10 = 9.2. The comprehensive optimization score (COS) is calculated as follows: COS = WT × TS + WR × RS + WC × (10 - CS); Comprehensive optimization score calculation: COS["Scheme 1"] = 0.6 × 7.2 + 0.3 × 8.2 + 0.1 × (10 - 6.5) = 7.07 COS["Scheme 2"] = 0.6 × 7.8 + 0.3 × 7.5 + 0.1 × (10 -4.2) = 7.49 COS["Scheme 3"] = 0.6 × 6.9 + 0.3 × 6.8 + 0.1 × (10 - 3.0) = 6.92 COS["Scheme 5"] = 0.6 × 9.2 + 0.3 × 8.8 + 0.1 × (10 - 7.8) = 8.68. The solution with the highest overall optimization score is selected as the optimal topology reconstruction solution: The ranking of overall optimization scores is: Solution 5: 8.68; Solution 2: 7.49; Solution 1: 7.07; Solution 3: 6.92. The optimal topology reconstruction solution (ORP) is Solution 5, which is the hybrid solution (adding a protocol conversion gateway and modifying links).Solution evaluation result ER = {"Best solution": "Scheme 5", "Overall score": 8.68, "Delay improvement": "Protection tripping delay reduced by 80.5%, average delay reduced by 42.0%", "Reliability score": 8.8, "Implementation complexity": 7.8, "Expected return on investment": 3.5 # Return on investment = performance improvement percentage / cost}.

[0115] 4.5. Based on the optimal topology reconstruction plan ORP (Scheme 5), perform adaptive reconstruction of the network topology: Reconstruction execution steps: install a new protocol conversion gateway 3 in cabinet 3, and configure the IP address to 10.1.1.15; deploy the protocol semantic dynamic tailoring module of the present invention on gateway 3; lay a direct optical fiber from protection device 2 to gateway 3; lay a gigabit optical fiber from protection device 4 to switch 3; configure gateway 3 to support the dedicated conversion function from IEC61850-GOOSE to DNP3.0; update the routing table to forward the tripping instruction of protection device 2 to gateway 3; update the routing table to forward the high-priority message of protection device 4 through the new link; reallocate the responsibilities of the protocol conversion processing nodes, gateway 1 is responsible for control instruction and measurement data conversion, gateway 2 is responsible for status information and alarm information conversion, and gateway 3 focuses on protection tripping instruction conversion. Reconstruction execution result RE = { "Execution status": "Completed", "Actual execution time": "2024-05-10 02:00:00 to 04:30:00", "Service interruption time": "15 minutes", "Verification test result": { "Actual delay of protection tripping command": 0.78ms, "Delay before reconstruction": 3.85ms, "Improvement ratio": "79.7%", "Safety margin": 3.22ms, "Verification conclusion": "Meets design expectations"}}.

[0116] To verify the effectiveness of this embodiment, actual tests were conducted on key business scenarios in the substation secondary system. The tests were conducted in an actual 220kV substation environment to compare the performance differences between this embodiment and the traditional protocol conversion method. Tests were conducted in the protection trip instruction scenario: by simulating the overcurrent protection action, the protection trip instruction conversion from IEC 61850 GOOSE to DNP3.0 was triggered, and the delay data of 100 operations was counted: the average conversion delay of the traditional method was 3.85ms, the maximum conversion delay was 9.65ms, the minimum conversion delay was 2.12ms, the delay standard deviation was 1.85ms, and the proportion of exceeding the delay requirement (4ms) was 38%; the average conversion delay of this embodiment was 0.78ms, the maximum conversion delay was 1.25ms, the minimum conversion delay was 0.65ms, the delay standard deviation was 0.15ms, and the proportion of exceeding the delay requirement (4ms) was 0%. Average latency was reduced by 79.7%, latency fluctuation was reduced by 91.9%, and the safety margin was increased by 3.22ms, improving reliability. All instructions were completed within the required latency. In a multi-service concurrent scenario test, simulating a high-load substation with multiple concurrent services, the overall performance before and after network topology reconstruction was tested. Before topology reconstruction, the network's average load rate was 78.5%, the peak load rate was 92.3%, the CPU utilization of key nodes was 85.6%, the bandwidth utilization of key links was 87.2%, and the network congestion probability was 0.72. After topology reconstruction, the network's average load rate was 52.3%, the peak load rate was 68.5%, the CPU utilization of key nodes was 60.2%, the bandwidth utilization of key links was 55.4%, and the network congestion probability was 0.22. Network load balancing improved by 33.4%, key resource utilization decreased by 29.7%, the congestion probability was reduced by 69.4%, and overall network performance improved by 42.8%.

[0117] Testing under different load conditions demonstrated the effectiveness of dynamic protocol semantic tailoring on conversion latency. Under low load conditions (network load <30%), the latency of the traditional method (full conversion) was 2.25ms, while the latency of this embodiment (dynamic tailoring) was 1.35ms, resulting in a 40.0% improvement and a 92.5% semantic retention rate. Under medium load conditions (network load 30%-70%), the latency of the traditional method (full conversion) was 3.45ms, while the latency of this embodiment (dynamic tailoring) was 1.65ms, resulting in a 52.2% improvement and a 85.3% semantic retention rate. Under high load conditions (network load > 70%), the traditional method (full conversion) has a latency of 5.85ms; the traditional method (simplified conversion) has a latency of 1.95ms, and a semantic retention rate of 45.0%; the latency of this embodiment (dynamic clipping) is 0.78ms; the improvement compared to full conversion is 86.7%; the improvement compared to simplified conversion is 60.0%; the key semantic retention rate is 100%; and the overall semantic retention rate is 76.2%.

[0118] A 30-day stability test of the system in this embodiment showed that the conventional method (30-day statistics) had 12 protocol conversion failures, 105 protocol conversion timeouts, 42 network congestion events, and 3 automatic system restarts. The system in this embodiment (30-day statistics) had 0 protocol conversion failures, 2 protocol conversion timeouts, 5 network congestion events, and 0 automatic system restarts. In comparison, conversion reliability increased by 100%, timeouts decreased by 98.1%, congestion events decreased by 88.1%, and system stability increased by 100%.

[0119] This embodiment describes in detail the specific implementation of a method for adaptive topology reconfiguration of a substation secondary system communication network based on delay sensitivity analysis. Through testing and verification in an actual 220 kV substation environment, this embodiment demonstrates the following significant advantages: A multi-scale delay feature fusion model achieves high-precision prediction of protocol conversion delay, reducing prediction error. Dynamic protocol semantic tailoring technology breaks the traditional "all-or-nothing" processing model by dynamically adjusting the semantic retention level based on delay sensitivity, ensuring that protocol conversion delay for critical protection services is consistently controlled within 1 millisecond. End-to-end delay-aware topology reconfiguration decisions consider protocol conversion node deployment and network traffic distribution optimization, achieving coordinated optimization of protocol conversion, resource allocation, and network topology. A performance-semantics trade-off method maximizes processing delay while ensuring functional correctness, while ensuring ultimate data integrity through an asynchronous supplementary transmission mechanism. A feedback adjustment mechanism establishes a complete closed-loop control system that can respond to network load fluctuations in real time, ensuring the real-time performance of critical services. Through this embodiment, the substation secondary system communication network shows significant performance improvement when facing the problem of protocol conversion delay uncertainty in a multi-protocol environment, which not only improves the system reliability and stability, but also provides important guarantees for the safe and efficient operation of the smart grid.

[0120] By integrating latency characteristics at three levels: macro-load trends, meso-level emergencies, and micro-level processing details, this paper establishes a predictive model that accurately captures delay fluctuations in substation multi-protocol networks. By separating periodic loads from baseline loads through waveform decomposition and combining this with conditional delay distribution modeling, delay prediction errors are reduced. In the substation secondary system, millisecond-level latency guarantees are provided for critical services such as protection tripping, fundamentally addressing the high uncertainty of protocol conversion delays in existing technologies. By precisely quantifying the contribution of different resources (processors, memory, and bandwidth) to latency improvement, optimal resource allocation is achieved. By classifying messages into three levels of sensitivity (high, medium, and low) and pre-allocating resources for high-sensitivity messages, important protection signals and control instructions receive priority processing. In substation emergency event handling scenarios, this strategy stabilizes the protocol conversion delay for critical instructions such as overcurrent protection tripping to within 0.8 milliseconds, a significant improvement over traditional methods. The resource pooling mechanism effectively avoids resource contention when multiple high-priority messages arrive simultaneously, ensuring the stability and reliability of the substation protection system under fluctuating network loads and preventing protection delays caused by communication delays. Dynamic protocol semantic tailoring technology breaks away from the "all-or-nothing" processing model of traditional protocol conversion. It identifies key and non-key semantic sets in messages and dynamically adjusts the semantic retention level using a performance-semantics trade-off function. By distinguishing between essential functional fields and associated status fields, it prioritizes the correct execution of core control commands even when latency budgets are tight. Especially under network congestion, the system intelligently tailors non-critical information to ensure the timely delivery of emergency protection commands, effectively preventing protection failures or malfunctions caused by protocol conversion delays and enhancing the safety and stability of the substation's secondary system. By monitoring the processing delay during protocol conversion in real time, resource allocation and semantic tailoring levels can be dynamically adjusted when significant deviations from expected delays are detected. By establishing a delay deviation threshold and a bidirectional adjustment strategy, the system can address both emergency situations involving exceeding expected delays and opportunities to optimize resource redundancy. Controlling delay recovery within a safe range enables the system to adaptively learn and optimize. The accuracy of delay prediction increases with operating time, forming a true adaptive control closed loop that effectively overcomes the uncertainty brought about by the complex and changing environment of the substation. Network optimization for end-to-end delay is achieved. A network bottleneck analysis and topology impact mapping matrix has been established, which can accurately assess the impact of different topology adjustments on various business flows. In particular, for data flows that span multiple protocol areas, the system can intelligently optimize the deployment location and number of protocol conversion nodes, reducing the additional delay introduced by protocol conversion. This ensures that even in a multi-protocol mixed environment, the end-to-end delay of the substation secondary system meets the strict requirements of the IEC 61850 standard for time-critical messages, thereby improving the reliability and security of the power system.

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

Claims

1. A method for adaptive topology reconstruction of a substation secondary system communication network, characterized in that: include: Collect communication data from multi-protocol networks in substation secondary systems, extract multi-scale delay sensitivity features, and build a multi-scale delay feature model; Use a multi-scale delay feature model to predict protocol conversion delay and generate delay compensation strategies for delay-sensitive services; Execute protocol conversion optimization and delay control based on the delay compensation strategy, obtain optimized conversion results and real-time processing delay, and perform end-to-end delay perception analysis based on the multi-scale delay feature model to generate and execute the optimal topology reconstruction plan; Generates delay compensation policies for delay-sensitive services, including: Receive communication data, extract multi-scale delay characteristics under the current network state and input them into the multi-scale delay feature model to obtain the expected protocol conversion delay of different types of messages under the current network conditions; Calculate the delay margin based on the expected protocol conversion delay and the end-to-end delay requirement of the message; Based on the delay margin and network resource status, a feedforward compensation strategy is generated for high-priority messages whose delay margin is less than a threshold, thus forming a delay compensation strategy. Form a delay compensation strategy, including: Read the message's latency margin and priority tag and classify the message into high, medium, and low sensitivity; For highly sensitive messages, calculate the minimum processing resource requirements to ensure that their conversion delay does not exceed the delay margin; Based on current system resources and the weight of each resource's contribution to reducing conversion delay, a resource-delay sensitivity matrix is constructed and the optimal resource allocation scheme is calculated. Based on this, the most suitable conversion path is selected, taking into account the message protocol type, message complexity, and minimum processing resource requirements. Comprehensive resource allocation scheme and switching path selection to generate a complete delay compensation strategy.

2. The method according to claim 1, characterized in that Construct a multi-scale delay feature model, including: Collect communication data from multi-protocol networks in the substation secondary system, including packet timestamps, payload sizes, priority tags, and network device status information for different protocols, to generate raw communication data sets. Based on the original communication dataset, macro, meso and micro delay features are extracted in sequence to obtain macro and meso load feature vectors, as well as micro processing feature vectors, and a multi-scale delay feature model is constructed based on them.

3. The method according to claim 2, characterized in that Construct a multi-scale delay feature model, including: Extracting baseline load trend and periodic fluctuation components from macro load feature vector; Read the meso-level load characteristic vector, calculate its deviation from the baseline load trend, and obtain the load fluctuation intensity and load mutation frequency indicators. Based on this, a switching model for high and low load states is constructed to form a load state transfer matrix. Based on the micro-processing eigenvectors, distribution fitting is performed to obtain the delay probability distribution model of each processing stage. This is combined with the load state transition matrix to construct a conditional delay distribution model considering state transition. The baseline load trend, periodic fluctuation component and conditional delay distribution model are integrated into a multi-scale delay feature model.

4. The method according to claim 1, wherein Get optimized conversion results, including: According to the delay compensation strategy, the appropriate protocol conversion processing mode is determined for each message, a conversion mode decision is made, and the allowed processing time is calculated; Acquire and analyze the protocol structure of the target message, and identify the key semantic sets and non-key semantic sets in the message based on the structure; calculate the processing time of the key semantic sets and the remaining time budget for processing the non-key semantic sets based on the allowed processing time; Based on the remaining time budget, an important retained subset is extracted from the non-critical semantic set and combined with the critical semantic set to generate a semantic pruning scheme; Protocol conversion is performed according to the semantic tailoring scheme, key semantic sets are prioritized, and optimized conversion results are generated.

5. The method according to claim 4, characterized in that Identify key and non-key semantic sets in the message, including: Read the protocol type and message type of the target message, and extract the complete semantic structure graph of the protocol type message and the message type message; Identify necessary functional fields from the complete semantic structure diagram based on current business scenarios and control requirements; Analyze the application context of the target message in the current business environment and identify the associated status fields required for interaction with other systems from the complete semantic structure diagram; The necessary function fields and associated status fields are combined to form the key semantic set of the message and assign weights. The remaining fields in the complete semantic structure diagram are classified into the non-key semantic set.

6. The method according to claim 4, characterized in that Generate semantic pruning solutions, including: Based on the semantic importance scores in the key semantic set and the estimated processing time of each field, a performance-semantics trade-off function is constructed to maximize the amount of semantic information retained under time constraints. Call the performance-semantics trade-off function to select the most important subset from the non-critical semantic set so that its processing time does not exceed the remaining time budget, and generate the non-critical semantic retention subset; The key semantic set and the non-key semantic retention subset are integrated to form a semantic pruning scheme, which includes all fields that need to be retained and their processing priorities.

7. The method according to claim 6, characterized in that It also includes monitoring the real-time processing delay during protocol conversion and making delay control adjustments: Read the real-time processing delay data of the current protocol conversion process, calculate the deviation from the expected protocol conversion delay, and obtain the delay deviation value; When it exceeds the delay deviation threshold, the feedback adjustment process is triggered; Analyze the positive and negative direction and magnitude of the delay deviation value to determine whether the current delay situation is exceeding expectations or due to resource redundancy. If the latency exceeds expectations, adjust the semantic pruning plan, streamline the non-critical semantic retention subset, and apply for emergency processing resources; In case of resource redundancy, the non-critical semantic reserved subset is expanded and the excess resources are released.

8. The method according to claim 1, characterized in that Generate an optimal topology reconstruction plan, including: Based on a multi-scale delay feature model and real-time processing of delay data, we identify delay bottlenecks and congested areas in the current network topology. Furthermore, we build a network optimization objective function based on the end-to-end delay requirements of each substation service flow. Based on the network optimization objective function, a set of candidate topology reconstruction schemes is generated, including link adjustment, traffic redistribution, and protocol conversion node deployment strategies; Evaluate the impact of each candidate topology reconstruction scheme on the latency of key business flows, generate scheme evaluation results, and select the scheme with the highest comprehensive score as the optimal topology reconstruction scheme.

Images