A method and system for processing mixed CAN communication analog data based on TCP protocol

Abstract

The application relates to the technical field of data processing, and provides a mixed CAN communication analog data processing method and system based on a TCP protocol, which comprises the following steps: generating fault snapshot data when an operation exception occurs; establishing a virtual TCP communication link and a virtual CAN communication link according to the fault snapshot data and configuring a virtual DCDC module; injecting a TCP communication data stream into the virtual TCP communication link and reconstructing the TCP communication data stream into a CAN message sequence; capturing a response message and converting the response message into a TCP data packet; injecting a diagnosis instruction, monitoring behaviors and communication data streams, and obtaining post-injection behavior information; comparing the post-injection behavior information with expected behaviors; recording changes of all communication data and system states in a digital mirror test environment, analyzing the recorded communication data and system states, and locating a fault root; and deploying a verified diagnosis instruction to an actual production system based on the fault root. The application has the effect of improving the real-time recovery capability of a production system.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and specifically to a method and system for simulating data processing based on TCP protocol and hybrid CAN communication. Background Technology

[0002] In modern industrial production and system testing, especially in applications involving complex power management modules such as modularized DC-DC power supplies, ensuring that the system is fully validated before actual operation and can quickly respond to sudden failures after being put into use is crucial to ensuring production continuity and system stability.

[0003] Existing testing methods often fail to fully cover the complexity of real-world deployment environments and the unpredictability of multi-device collaboration. This can lead to insufficient testing and difficulty in detecting potential anomalies before the system goes live. Furthermore, if a production-ready system experiences a failure caused by software / hardware incompatibility or communication protocol processing issues, extremely high demands are placed on real-time recovery capabilities.

[0004] Existing methods typically cannot achieve bidirectional protocol conversion and data encapsulation from TCP to CAN communication, making it difficult to simulate data flow and abnormal scenarios under real-world operating conditions during system integration testing. Furthermore, due to the lack of support for historical operational data, test cases are often limited to manual construction, making it difficult to recreate complex data interaction processes and edge cases in the field. This results in some well-hidden logical errors or performance bottlenecks not being detected in a timely manner during testing. This not only increases the risks and costs of on-site maintenance but also poses a potential threat to the long-term reliability and stability of the system.

[0005] To address the aforementioned issues, existing technologies urgently need improvement. Summary of the Invention

[0006] This application discloses a method and system for simulating data processing based on TCP protocol and hybrid CAN communication. It aims to solve the problems in existing industrial production and system testing, especially in applications involving complex power management modules such as the DC-DC converter module with a component capacity, where traditional testing methods are difficult to fully cover the complexity of the actual deployment environment and the unpredictability of multi-device linkage, as well as the lack of a complete, flexibly configurable simulation test platform that supports real data back-injection.

[0007] The technical solution of this application is as follows:

[0008] In a first aspect, this application discloses a method for simulating data processing based on TCP protocol and hybrid CAN communication, specifically including:

[0009] While ensuring the normal operation of the DC-DC converter module, when the DC-DC converter module malfunctions, the system captures TCP communication data stream, CAN communication data stream, operating parameters of the DC-DC converter module, system configuration information, and external environment data, and integrates them to generate fault snapshot data.

[0010] Based on the fault snapshot data, a virtual TCP communication link and a virtual CAN communication link are established on the simulation test platform, and the virtual DC-DC module and the corresponding virtual associated device corresponding to the capacity-determining power supply DC-DC module are configured to provide a digital mirror test environment.

[0011] In a digital mirror testing environment, TCP communication data streams from fault snapshot data are injected into a virtual TCP communication link. The first protocol conversion unit parses and reconstructs the TCP communication data stream into a CAN message sequence, which is then sent to the virtual DC-DC module. CAN response messages generated by the virtual DC-DC module are captured and converted into TCP data packets by a second protocol conversion unit, then transmitted back via the virtual TCP communication link. During the response and transmission process of the virtual DC-DC module, diagnostic commands are injected into the virtual DC-DC module, and the behavior and communication data stream of the virtual DC-DC module after the injection operation are monitored to obtain post-injection behavior information. The post-injection behavior information is compared with the expected behavior in the fault snapshot data to obtain behavior comparison results, thereby verifying the effectiveness of the diagnostic commands.

[0012] Based on the behavior comparison results, determine whether the diagnostic command has passed the verification.

[0013] Record all communication data and system status changes in the digital mirror test environment, and analyze the recorded communication data and system status to locate the root cause of the fault; based on the root cause of the fault, deploy the verified diagnostic instructions to the actual production system corresponding to the batch capacity power supply DC-DC module.

[0014] Through this technical solution, this application can achieve accurate simulation, diagnosis and repair of faults in the DC-DC module of the power supply with a capacity-determining structure. It effectively solves the problem that traditional testing methods are difficult to fully cover the complexity of the actual deployment environment, and provides a complete, flexibly configurable simulation testing platform that supports real data injection.

[0015] Furthermore, in the digital mirror testing environment, the TCP communication data stream from the fault snapshot data is injected into the virtual TCP communication link. The first protocol conversion unit parses and reconstructs the TCP communication data stream into a CAN message sequence, which is then sent to the virtual DC-DC module. The steps of capturing the CAN response message generated by the virtual DC-DC module, converting it into TCP data packets through the second protocol conversion unit, and transmitting it back via the virtual TCP communication link include:

[0016] When the DC-DC module of the power supply receives a CAN message and begins processing it, the start time is recorded, and the start time is associated with the unique identifier of the CAN message and the key data content.

[0017] The start time of processing is timestamped and correlated with the externally captured communication data of the divided capacity power supply DC-DC module, and integrated into the fault snapshot data;

[0018] When reproducing a fault in a digital mirror test environment, for CAN messages that contain both the timestamp of externally captured communication data and the timestamp of internal processing in the fault snapshot data, the start processing time is used as the time base for the CAN message to begin being processed in the virtual DC-DC module, in order to adjust the injection timing of the CAN message.

[0019] Through this technical solution, this application can ensure that the virtual DC-DC module can highly reproduce the CAN message processing timing of the real DC-DC module in the digital mirror test environment by accurately aligning the timestamps and adjusting the injection timing, thereby simulating fault scenarios more accurately.

[0020] Based on the above, this application further proposes the following steps to verify the effectiveness of the diagnostic commands: During the response and feedback process of the virtual DC-DC module, inject diagnostic commands into the virtual DC-DC module, monitor the behavior and communication data flow of the virtual DC-DC module after the injection operation to obtain post-injection behavior information, and compare the post-injection behavior information with the expected behavior in the fault snapshot data to obtain the behavior comparison result.

[0021] When the virtual DC-DC module receives a CAN message or diagnostic command, the real-time operating system simulation layer built into the simulation program that controls the virtual DC-DC module simulates the queuing, execution, and interrupt response of the CAN message processing task according to the preset scheduling strategy and resource contention rules, and records the actual start time and completion time of the task.

[0022] By simulating internal bus access conflicts and shared memory access latency through a real-time operating system simulation layer, microsecond-level processing timing deviations are introduced in specific critical state switching scenarios.

[0023] Based on the queuing, execution, and interrupt response of simulated CAN message processing tasks, the actual start and completion times of processing, and the introduced processing timing deviations, the output behavior of the virtual DC-DC module is obtained.

[0024] The output behavior of the virtual DC-DC module is compared with the expected behavior in the fault snapshot data to obtain the behavior comparison results. Based on the behavior comparison results, the scheduling parameters and delay parameters in the real-time operating system simulation layer are adjusted until the virtual DC-DC module reproduces the intermittent fault caused by the internal concurrency problem of the real-world fractional-capacity power supply DC-DC module.

[0025] Through this technical solution, this application can accurately reproduce the occasional failures caused by internal concurrency problems in real DC-DC modules by simulating concurrency and timing deviations at the real-time operating system level, thereby effectively verifying the effectiveness of diagnostic instructions for such complex failures.

[0026] In some preferred embodiments, in a digital mirror testing environment, the TCP communication data stream from the fault snapshot data is injected into a virtual TCP communication link. A first protocol conversion unit parses and reconstructs the TCP communication data stream into a CAN message sequence, which is then sent to the virtual DC-DC module. The steps of capturing the CAN response message generated by the virtual DC-DC module, converting the CAN response message into a TCP data packet through a second protocol conversion unit, and transmitting it back through the virtual TCP communication link include:

[0027] In the digital mirror test environment, the dynamic queue management module pre-configured by the first and second protocol conversion units is activated.

[0028] The dynamic queue management module is driven to adjust the length and priority of its internal message processing queues based on the real-time communication load and the response speed of the virtual DC-DC module.

[0029] When high concurrency or bursty data streams are detected, the dynamic queue management module is driven to simulate the queuing delay and dropping behavior of CAN messages in the protocol stack of the transformer capacity power supply DC-DC module according to the preset congestion control strategy, and record the actual processing delay of each CAN message.

[0030] The dynamic queue management module is driven to simulate changes in the CAN message processing order caused by resource contention, based on the internal state and current processing capacity of the virtual DC-DC module.

[0031] Based on the adjusted length and priority of the internal message processing queue, the simulated queuing delay and dropping behavior, the actual processing delay of each CAN message recorded, and the changes in the CAN message processing order, the output behavior of the virtual DC-DC module is obtained.

[0032] By comparing the output behavior of the virtual DC-DC module with the expected behavior in the fault snapshot data, the behavior comparison results are obtained.

[0033] Based on the behavior comparison results, the congestion control strategy and resource scheduling parameters in the dynamic queue management module are adjusted until the virtual DC-DC module reproduces the intermittent failure caused by the internal processing bottleneck of the protocol conversion unit in the real-world DC-DC module that is converted into a capacity power supply.

[0034] Through this technical solution, this application can simulate the internal processing bottleneck of the protocol conversion unit through the dynamic queue management module, accurately reproduce the intermittent failures of the real DC-DC module caused by the internal processing bottleneck of the protocol conversion unit, and thus effectively verify the effectiveness of diagnostic instructions for such complex failures.

[0035] More specifically, in some implementation schemes, in a digital mirror testing environment, the TCP communication data stream from the fault snapshot data is injected into a virtual TCP communication link. A first protocol conversion unit parses and reconstructs the TCP communication data stream into a CAN message sequence, which is then sent to the virtual DC-DC module. The steps of capturing the CAN response message generated by the virtual DC-DC module, converting it into TCP data packets through a second protocol conversion unit, and transmitting it back via the virtual TCP communication link include:

[0036] In the digital mirror testing environment, start the preset external system behavior simulator;

[0037] The external system behavior simulator receives TCP data packets returned by the virtual DC-DC module through the second protocol conversion unit;

[0038] The external system behavior simulator generates and injects subsequent TCP control command sequences into the virtual TCP communication link based on the content of TCP packets and the current state of the virtual DC-DC module.

[0039] Based on the preset interaction logic and state machine rules, the decision-making behavior of the real external system after receiving the response from the virtual DC-DC module is simulated.

[0040] Monitor the response of the virtual DC-DC module in real time, and adjust the generation strategy of subsequent instructions of the external system behavior simulator according to the response results.

[0041] Through this technical solution, this application can simulate the interaction logic between a real external system and a DCDC module using an external system behavior simulator, thereby more comprehensively verifying the effectiveness of diagnostic commands in complex system environments.

[0042] Based on the above, this application further proposes the following steps in a digital mirror testing environment: Injecting TCP communication data streams from fault snapshot data into a virtual TCP communication link; using a first protocol conversion unit to parse and reconstruct the TCP communication data streams into a CAN message sequence, which is then sent to the virtual DC-DC module; capturing CAN response messages generated by the virtual DC-DC module and converting them into TCP data packets using a second protocol conversion unit, which are then transmitted back via the virtual TCP communication link; injecting diagnostic commands into the virtual DC-DC module during its response and transmission process, and monitoring the behavior and communication data streams of the virtual DC-DC module after the injection operation to obtain post-injection behavior information; and comparing the post-injection behavior information with the expected behavior in the fault snapshot data to obtain a behavior comparison result, thereby verifying the effectiveness of the diagnostic commands.

[0043] In the digital mirror test environment, start the preset dynamic injection strategy controller;

[0044] The dynamic injection strategy controller is driven to receive TCP data packets returned by the virtual DC-DC module through the second protocol conversion unit and obtain the current internal state of the virtual DC-DC module.

[0045] Based on the content of the TCP packets, the current internal state of the virtual DC-DC module, and the historical communication data and system state recorded in the fault snapshot data, the response of the virtual DC-DC module to the injected diagnostic commands is evaluated, and the response evaluation results are obtained.

[0046] Based on the response assessment results, the timing, content, and frequency of subsequent diagnostic commands are adjusted to simulate the behavior of engineers in a real production environment who gradually adjust diagnostic commands based on real-time feedback from the virtual DC-DC module.

[0047] Through this technical solution, this application can simulate the behavior of engineers gradually adjusting diagnostic instructions in a real production environment by dynamically injecting a policy controller, thereby improving the verification efficiency and accuracy of diagnostic instructions.

[0048] Preferably, the steps of adjusting the timing, content, and frequency of subsequent diagnostic commands based on the response evaluation results to simulate the behavior of engineers gradually adjusting diagnostic commands based on real-time feedback from the virtual DC-DC module in a real production environment include:

[0049] Based on the real-time internal status of the virtual DC-DC module, external environment data, and historical response data of injected diagnostic commands, the future status change trend of the virtual DC-DC module under different adjustment schemes is analyzed.

[0050] Based on future trends in the state, assess the risk of deviation from the diagnostic path introduced by different adjustment plans;

[0051] Based on the risk of deviation from the diagnostic path corresponding to different adjustment schemes, the adjustment scheme with the lowest risk is selected, and the timing, content and frequency of subsequent diagnostic instructions are adjusted.

[0052] Through this technical solution, this application can optimize the injection strategy of diagnostic commands and improve the efficiency and safety of fault diagnosis by analyzing future state change trends and assessing the risk of deviation from the diagnostic path.

[0053] Based on the above, this application further proposes that, based on the diagnostic path deviation risk corresponding to different adjustment schemes, the step of selecting the adjustment scheme with the lowest risk and adjusting the injection timing, content, and frequency of subsequent diagnostic instructions includes:

[0054] Based on the real-time internal state, historical operating data, and component aging model of the virtual DC-DC module, the long-term operating behavior of the virtual DC-DC module under different adjustment schemes is simulated, and the drift trend of component parameters is analyzed.

[0055] Based on long-term operational behavior and drift trends, the impact of different adjustment schemes on the long-term stability and reliability of the virtual DC-DC module is evaluated, and long-term impact risk information is obtained.

[0056] Based on the long-term impact risk information corresponding to different adjustment schemes, the adjustment scheme with the lowest risk is selected, and the timing, content and frequency of subsequent diagnostic instructions are adjusted accordingly.

[0057] Through this technical solution, this application can evaluate the impact of different adjustment schemes on the long-term stability and reliability of the virtual DC-DC module by simulating long-term operating behavior and analyzing component parameter drift trends, thereby selecting the adjustment scheme with the lowest risk and further improving the reliability of diagnostic commands.

[0058] More specifically, in some implementation schemes, based on the long-term impact risk information corresponding to different adjustment schemes, the step of selecting the adjustment scheme with the lowest risk and adjusting the timing, content, and frequency of subsequent diagnostic instructions includes:

[0059] Based on the batch information, production serial number, or factory test report of the batch-conducting DC-DC power supply module, obtain the component parameter tolerance range and performance deviation data of the batch-conducting DC-DC power supply module.

[0060] Introduce error disturbances corresponding to the component parameter tolerance range and performance deviation data into the simulation parameters of the virtual DC-DC module;

[0061] In a digital mirror test environment, several virtual DC-DC modules with introduced error disturbances were simulated in parallel, and the response behavior and fault recovery of each virtual DC-DC module under different adjustment schemes were recorded.

[0062] Based on the simulation test results of the virtual DC-DC module, the adaptability of different adjustment schemes to the DC-DC module with a split-capacity power supply on different virtual DC-DC modules is evaluated. The adjustment scheme that can effectively recover faults on different virtual DC-DC modules without introducing new compatibility issues is selected, and the timing, content and frequency of subsequent diagnostic command injection are adjusted.

[0063] Through this technical solution, this application can evaluate the adaptability of different adjustment schemes to the DC-DC module of the divided capacity power supply on different virtual DC-DC modules by introducing error disturbances and parallel simulation tests, thereby selecting the adjustment scheme that can effectively recover faults on different virtual DC-DC modules without introducing new compatibility issues, and further improving the universality and compatibility of diagnostic commands.

[0064] Secondly, this application also discloses a TCP-based hybrid CAN communication simulation data processing system for performing TCP-based hybrid CAN communication simulation data processing, specifically including:

[0065] The fault snapshot integration module is used to capture TCP communication data stream, CAN communication data stream, operating parameters of the DC-DC converter, system configuration information and external environment data when the DC-DC converter malfunctions, while maintaining the normal operation of the DC-DC converter. The module then integrates these data to generate fault snapshot data.

[0066] The test environment configuration module is used to establish virtual TCP communication links and virtual CAN communication links on the simulation test platform based on fault snapshot data, and configure the virtual DC-DC modules and corresponding virtual associated devices corresponding to the capacity-determining power supply DC-DC modules to provide a digital mirror test environment.

[0067] The virtual simulation application module is used to inject TCP communication data streams from fault snapshot data into a virtual TCP communication link in a digital mirror testing environment. The first protocol conversion unit parses and reconstructs the TCP communication data stream into a CAN message sequence, which is then sent to the virtual DC-DC module. It captures the CAN response messages generated by the virtual DC-DC module and converts them into TCP data packets via a second protocol conversion unit, which are then transmitted back through the virtual TCP communication link. During the response and transmission process of the virtual DC-DC module, diagnostic commands are injected into the virtual DC-DC module, and the behavior and communication data stream of the virtual DC-DC module after the injection operation are monitored to obtain post-injection behavior information. The post-injection behavior information is compared with the expected behavior in the fault snapshot data to obtain the behavior comparison results, thereby verifying the effectiveness of the diagnostic commands.

[0068] The comparison result judgment module is used to determine whether the diagnostic command has passed the verification based on the behavior comparison result;

[0069] The diagnostic instruction deployment module is used to record all communication data and system status changes in the digital mirror test environment, and analyze the recorded communication data and system status to locate the root cause of the fault; based on the root cause of the fault, the verified diagnostic instructions are deployed to the actual production system corresponding to the batch capacity power supply DC-DC module.

[0070] This technical solution provides a complete system for capturing, simulating, diagnosing, and deploying faults in the DC-DC module of the batch-capacitance power supply, effectively solving the problem that traditional testing methods and existing technologies lack a complete, flexibly configurable simulation testing platform that supports real data injection.

[0071] Beneficial Effects: This application provides a TCP-based hybrid CAN communication simulation data processing method. When a fault occurs in a DC-DC converter module of a capacity-controlled power supply, multi-source data is captured and integrated to generate a fault snapshot. This snapshot is then used to establish a virtual communication link and a virtual DC-DC module in a digital mirror test environment, achieving accurate reproduction of the fault scenario. The method injects TCP communication data streams from the fault snapshot data into a virtual TCP communication link, which is then reconstructed into a CAN message sequence by a protocol conversion unit and sent to the virtual DC-DC module. The module's response is captured and transmitted back, thus simulating the real communication process. More importantly, during the simulation, this application can inject diagnostic commands into the virtual DC-DC module and monitor its behavior and communication data streams. The injected behavior information is compared with the expected behavior to verify the effectiveness of the diagnostic commands. Finally, based on the comparison results, the validity of the diagnostic commands is determined. All communication data and system state changes in the digital mirror test environment are recorded to analyze and locate the root cause of the fault. The validated diagnostic commands are then deployed to the real production system.

[0072] Compared with existing technologies, the solution of this application has significantly superior technical effects:

[0073] First, by capturing multi-source data and integrating it to generate a fault snapshot, this application can comprehensively and accurately restore the system state and communication environment at the time of the fault, overcoming the problem that traditional testing methods are difficult to fully cover the complexity of the actual deployment environment.

[0074] Secondly, a virtual TCP and CAN communication link was established in the digital mirror test environment, and a virtual DC-DC module and associated devices were configured, which achieved a high degree of simulation of the real production environment and solved the problem of the lack of a complete, flexibly configurable simulation test platform that supports real data back injection in the existing technology.

[0075] Furthermore, by using a bidirectional protocol conversion unit to achieve TCP-to-CAN data stream parsing and reconstruction, as well as CAN-to-TCP data packet conversion and back transmission, the problem of existing methods being unable to achieve bidirectional protocol conversion and data encapsulation from TCP to CAN communication is effectively solved, enabling the simulation of data flow and abnormal scenarios under real working conditions during the system integration testing phase.

[0076] Furthermore, injecting diagnostic commands into the virtual DC-DC module's response process and monitoring its behavior enables real-time and dynamic verification of the effectiveness of the diagnostic commands, avoiding the limitations of traditional manual test case construction and improving the accuracy and efficiency of fault diagnosis.

[0077] Finally, based on the root cause of the fault, the verified diagnostic instructions are deployed to the actual production system, realizing closed-loop management from fault simulation, diagnosis to repair, which significantly improves the real-time recovery capability of the production system and the reliability and stability of long-term operation, and effectively reduces the risks and costs of on-site operation and maintenance. Attached Figure Description

[0078] Figure 1 This is a flowchart of a method for simulating data processing based on TCP protocol and hybrid CAN communication in one embodiment of the present invention;

[0079] Figure 2 This is one of the flowcharts of a method for simulating data processing based on TCP protocol and hybrid CAN communication in another embodiment of the present invention;

[0080] Figure 3 This is a second flowchart of a method for simulating data processing based on TCP protocol and hybrid CAN communication in another embodiment of the present invention;

[0081] Figure 4 This is a system block diagram of a hybrid CAN communication analog data processing system based on the TCP protocol, according to another embodiment of the present invention.

[0082] Explanation of reference numerals in the attached figures:

[0083] 1. TCP-based hybrid CAN communication simulation data processing system; 11. Fault snapshot integration module; 12. Test environment configuration module; 13. Virtual simulation application module; 14. Comparison result judgment module; 15. Diagnostic instruction deployment module. Detailed Implementation

[0084] The technical solutions of this application will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this application, and not all embodiments. The components of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0085] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0086] This application proposes a method for simulating data processing based on TCP protocol and hybrid CAN communication, combined with... Figure 1 As shown, it includes:

[0087] S1, while ensuring the normal operation of the DC-DC converter module, when the DC-DC converter module malfunctions, captures TCP communication data stream, CAN communication data stream, operating parameters of the DC-DC converter module, system configuration information and external environment data, and integrates them to generate fault snapshot data.

[0088] S2, based on the fault snapshot data, establish virtual TCP communication links and virtual CAN communication links on the simulation test platform, and configure the virtual DC-DC modules and corresponding virtual associated devices corresponding to the capacity-determining power supply DC-DC modules to provide a digital mirror test environment;

[0089] S3, in the digital mirror test environment, the TCP communication data stream from the fault snapshot data is injected into the virtual TCP communication link. The first protocol conversion unit parses and reconstructs the TCP communication data stream into a CAN message sequence, which is then sent to the virtual DC-DC module. The CAN response message generated by the virtual DC-DC module is captured and converted into a TCP data packet by the second protocol conversion unit, then transmitted back through the virtual TCP communication link. During the response and transmission process of the virtual DC-DC module, diagnostic commands are injected into the virtual DC-DC module, and the behavior and communication data stream of the virtual DC-DC module after the injection operation are monitored to obtain post-injection behavior information. The post-injection behavior information is compared with the expected behavior in the fault snapshot data to obtain the behavior comparison result, thereby verifying the effectiveness of the diagnostic commands.

[0090] S4. Based on the behavior comparison results, determine whether the diagnostic command has passed the verification.

[0091] S5 records all communication data and system status changes in the digital mirror test environment, and analyzes the recorded communication data and system status to locate the root cause of the fault; based on the root cause of the fault, the verified diagnostic instructions are deployed to the actual production system corresponding to the batch capacity power supply DCDC module.

[0092] To better understand the technical solutions proposed in this application, some key terms are explained first. A formation and capacity-matching power supply DC-DC module refers to a power module used to achieve efficient DC power conversion and management during battery formation and capacity matching; its operating state directly affects battery performance and lifespan. TCP communication data stream refers to data transmitted based on the Transmission Control Protocol (TCP), typically used for high-reliability network communication. CAN communication data stream refers to data transmitted based on the Controller Area Network (CAN) protocol, widely used in automotive electronics and industrial control, renowned for its high real-time performance and reliability. Fault snapshot data is a one-time capture and integration of key operating parameters, communication data, system configuration, and external environmental data when an anomaly occurs, aiming to comprehensively record the system state at the time of the fault. Virtual DC-DC module and virtual associated device are software or hardware-in-the-loop simulations of real DC-DC modules and their peripheral devices on a simulation test platform to simulate their real behavior and response. A digital mirror test environment is a highly simulated test platform capable of accurately reproducing the operating state and fault scenarios of a real system.

[0093] The core of the simulated data processing method based on TCP protocol and hybrid CAN communication proposed in this application lies in the use of digital mirroring technology to achieve accurate reproduction, diagnosis and verification of faults in the DC-DC module of the power supply with a capacity-displacement system.

[0094] Specifically, while ensuring the normal operation of the DC-DC converter module, when an malfunction occurs, it is necessary to capture TCP communication data streams, CAN communication data streams, the module's operating parameters, system configuration information, and external environmental data, and integrate them to generate fault snapshot data. This data capture can be achieved by deploying data acquisition devices at the DC-DC module's communication interface; for example, network sniffing tools can be used to capture TCP packets, and CAN bus analyzers can be used to capture CAN messages. Simultaneously, the DC-DC module's internal sensors and controllers can record operating parameters (such as voltage, current, and temperature), system logs can provide configuration information, and external environmental sensors can provide environmental data (such as ambient temperature and humidity). This captured data is then integrated into a unified fault snapshot dataset for subsequent analysis and reproduction. For example, all captured data can be timestamped and stored in a structured database.

[0095] Based on fault snapshot data, virtual TCP and virtual CAN communication links are established on the simulation test platform. Virtual DC-DC modules and corresponding virtual associated devices are configured to correspond to the sectionalizing power supply DC-DC modules, providing a digital mirror test environment. Virtual communication links can be implemented using software simulation of the network protocol stack, for example, by using virtual network cards and virtual CAN interfaces. Virtual DC-DC modules and virtual associated devices can be implemented using hardware-in-the-loop (HIL) simulation or pure software simulation. In HIL simulation, real DC-DC module hardware can be used, but its inputs and outputs are controlled by the simulator; in pure software simulation, the behavior of the DC-DC module is entirely simulated through a software model. For example, a mathematical model of the DC-DC module can be built using tools such as MATLAB or Simulink and deployed to the simulation test platform.

[0096] In a digital mirror testing environment, TCP communication data streams from fault snapshot data are injected into a virtual TCP communication link. A first protocol conversion unit parses and reconstructs the TCP communication data stream into a CAN message sequence, which is then sent to the virtual DC-DC module. The CAN response message generated by the virtual DC-DC module is captured and converted into TCP data packets by a second protocol conversion unit, then transmitted back via the virtual TCP communication link. The first and second protocol conversion units can be independent hardware modules or integrated into software as protocol conversion services. For example, the first protocol conversion unit can receive TCP data packets, extract the payload, and encapsulate them into CAN messages according to a preset CAN message format. The second protocol conversion unit performs the reverse operation. During the virtual DC-DC module's response and transmission process, diagnostic commands are injected into the virtual DC-DC module, and the behavior and communication data stream of the virtual DC-DC module after the injection operation are monitored to obtain post-injection behavior information. The post-injection behavior information is compared with the expected behavior in the fault snapshot data to obtain the behavior comparison result, thus verifying the effectiveness of the diagnostic commands. The injection of diagnostic commands can be implemented through the control interface of the simulation test platform, for example, by sending specific diagnostic messages via a virtual CAN bus. Monitoring the behavior of a virtual DC-DC module can include recording its internal state changes, output signals, and communication data streams. Expected behavior refers to the DC-DC module's response under normal or specific fault conditions, as recorded in fault snapshot data.

[0097] Based on the behavior comparison results, it is determined whether the diagnostic command has passed verification. If, after injecting the diagnostic command, the behavior of the virtual DC-DC module is consistent with the expected behavior, or the fault is eliminated, the diagnostic command is considered to have passed verification. For example, if the diagnostic command aims to reset a subsystem of the DC-DC module, and the comparison results show that the subsystem was successfully reset, the diagnostic command is considered to be valid.

[0098] Record all communication data and system state changes in the digital mirror test environment, and analyze the recorded communication data and system state to locate the root cause of the fault. Based on the root cause, the verified diagnostic commands are deployed to the actual production system corresponding to the batch capacity power supply DC-DC module. Recording all communication data and system state changes can be achieved through a log system; for example, recording all data packets on all virtual communication links and the internal state changes of the virtual DC-DC module. The root cause of the fault can be located through analysis methods such as pattern recognition and anomaly detection on these recorded data. For example, by analyzing the sequence and timestamps of CAN messages, it is possible to discover whether there are message losses or delays, thereby locating the problem in the communication protocol stack.

[0099] Optional, combined Figure 2As shown, in S3, within the digital mirror test environment, the TCP communication data stream from the fault snapshot data is injected into the virtual TCP communication link. The first protocol conversion unit parses and reconstructs the TCP communication data stream into a CAN message sequence, which is then sent to the virtual DC-DC module. The CAN response message generated by the virtual DC-DC module is captured, and the second protocol conversion unit converts the CAN response message into a TCP data packet, which is then transmitted back through the virtual TCP communication link. The specific steps include:

[0100] S31, When the DC-DC module of the power supply receives the CAN message and starts processing, record the start time and associate the start time with the unique identifier of the CAN message and the key data content.

[0101] S32, timestamp-align and correlate the start processing time point with the externally captured communication data of the DC-DC power supply module, and integrate it into the fault snapshot data;

[0102] S33, when reproducing a fault in a digital mirror test environment, for CAN messages that contain both the timestamp of externally captured communication data and the timestamp of internal processing in the fault snapshot data, the start processing time point is used as the time base for the CAN message to start being processed in the virtual DC-DC module, so as to adjust the injection timing of the CAN message.

[0103] Specifically, when the DC-DC converter module of the power supply receives a CAN message, its internal real-time operating system or firmware records the precise time when the processor actually begins processing the message, i.e., the start processing time. This start processing time is considered a key timing marker in the internal processing flow of the CAN message within the DC-DC converter module. To ensure data integrity and traceability, this start processing time is associated with the unique identifier of the CAN message (e.g., CAN ID) and its key data content, so that it can be accurately identified and matched in subsequent analysis.

[0104] The start-processing time point is then timestamped and correlated with the externally captured communication data of the load cell DC-DC converter module. This externally captured communication data typically includes timestamps of CAN message transmission or reception on the bus. By aligning the internal start-processing time point with the external timestamps, a complete view of the timing information for the entire process from external message reception to internal start-processing can be constructed. This aligned and correlated data is ultimately integrated into the fault snapshot data, ensuring that the fault snapshot data includes not only external communication events but also the internal response timing of these events within the load cell DC-DC converter module.

[0105] In practical applications, when reproducing faults in a digital mirror testing environment, for CAN messages whose fault snapshot data simultaneously contains timestamps of externally captured communication data and internal processing timestamps, the start processing time point is used as the time reference for the CAN message to begin processing in the virtual DC-DC module. This means that after receiving a simulated CAN message, the virtual DC-DC module will not start processing immediately, but will simulate waiting until the start processing time point recorded in the fault snapshot data before starting to process the message. This injection timing adjustment based on the internal processing time reference ensures that the virtual DC-DC module can more realistically simulate the internal timing behavior of a capacitive power supply DC-DC module when processing CAN messages, including any potential processing delays.

[0106] Optional, combined Figure 3 As shown, during the response and feedback process of the virtual DC-DC module, diagnostic commands are injected into the virtual DC-DC module, and the behavior and communication data flow of the virtual DC-DC module after the injection operation are monitored to obtain post-injection behavior information. The steps to verify the effectiveness of the diagnostic commands by comparing the post-injection behavior information with the expected behavior in the fault snapshot data to obtain the behavior comparison results include:

[0107] A1. When the virtual DC-DC module receives a CAN message or diagnostic command, the simulation program that controls the virtual DC-DC module uses a built-in real-time operating system simulation layer to simulate the queuing, execution, and interrupt response of the CAN message processing task according to the preset scheduling strategy and resource contention rules, and records the actual start time and completion time of the task.

[0108] A2, through the real-time operating system simulation layer, simulates internal bus access conflicts and shared memory access latency, so as to introduce microsecond-level processing timing deviations in specific critical state switching scenarios.

[0109] A3, based on the queuing, execution and interrupt response of simulated CAN message processing tasks, the actual start time and completion time of processing, and the introduced processing timing deviation, obtains the output behavior of the virtual DC-DC module;

[0110] A4 compares the output behavior of the virtual DC-DC module with the expected behavior in the fault snapshot data to obtain the behavior comparison results. Based on the behavior comparison results, the scheduling parameters and delay parameters in the real-time operating system simulation layer are adjusted until the virtual DC-DC module reproduces the intermittent fault caused by the internal concurrency problem of the real-world fractional-capacity power supply DC-DC module.

[0111] Specifically, the real-time operating system simulation layer is a software module integrated into the simulation program of the virtual DC-DC module. Its purpose is to simulate the behavior of the real-time operating system inside the capacity power supply DC-DC module, including task scheduling, interrupt handling, and resource management. This simulation layer can accurately simulate the queuing, execution, and interrupt response processes of CAN message processing tasks within the virtual DC-DC module according to preset scheduling strategies, such as priority scheduling and time-slice round-robin, and resource contention rules, such as mutexes and semaphores. During this process, the actual start and completion times of the tasks are recorded in detail for subsequent analysis.

[0112] Furthermore, the real-time operating system simulation layer can also simulate internal bus access conflicts and shared memory access latency. These latency and conflicts are common phenomena in real hardware systems, especially when multiple tasks or processor cores attempt to access shared resources simultaneously. By introducing microsecond-level processing timing deviations in specific critical state switching scenarios, this application can more realistically reflect the internal behavior of the fractional-capacity DC-DC power supply module under complex operating conditions, thereby capturing sporadic faults caused by these minute deviations.

[0113] In practical applications, the output behavior of the virtual DC-DC module is derived from the queuing, execution, and interrupt responses of the simulated CAN message processing tasks, the actual start and completion times of the tasks, and the introduced processing timing deviations. This output behavior is then compared with the expected behavior in the fault snapshot data to generate a behavior comparison result. Based on this comparison result, the scheduling and latency parameters in the real-time operating system simulation layer are iteratively adjusted. This adjustment process continues until the virtual DC-DC module can accurately reproduce the intermittent faults caused by internal concurrency issues in the real-world fractional-capacity power supply DC-DC module, such as deadlock, race conditions, or task timeouts.

[0114] Optionally, in a digital mirror testing environment, the TCP communication data stream from the fault snapshot data is injected into a virtual TCP communication link. The first protocol conversion unit parses and reconstructs the TCP communication data stream into a CAN message sequence, which is then sent to the virtual DC-DC module. The steps of capturing the CAN response message generated by the virtual DC-DC module, converting it into TCP data packets through a second protocol conversion unit, and transmitting it back via the virtual TCP communication link include:

[0115] In the digital mirror test environment, start the preset dynamic queue management module;

[0116] The dynamic queue management module is driven to adjust the length and priority of its internal message processing queues based on the real-time communication load and the response speed of the virtual DC-DC module.

[0117] When high concurrency or bursty data streams are detected, the dynamic queue management module is driven to simulate the queuing delay and dropping behavior of CAN messages in the protocol stack of the transformer capacity power supply DC-DC module according to the preset congestion control strategy, and record the actual processing delay of each CAN message.

[0118] The dynamic queue management module is driven to simulate changes in the CAN message processing order caused by resource contention, based on the internal state and current processing capacity of the virtual DC-DC module.

[0119] Based on the adjusted length and priority of the internal message processing queue, the simulated queuing delay and dropping behavior, the actual processing delay of each CAN message recorded, and the changes in the CAN message processing order, the output behavior of the virtual DC-DC module is obtained.

[0120] By comparing the output behavior of the virtual DC-DC module with the expected behavior in the fault snapshot data, the behavior comparison results are obtained.

[0121] Based on the behavior comparison results, the congestion control strategy and resource scheduling parameters in the dynamic queue management module are adjusted until the virtual DC-DC module reproduces the intermittent failure caused by the internal processing bottleneck of the protocol conversion unit in the real-world DC-DC module that is converted into a capacity power supply.

[0122] Specifically, in the digital mirror test environment, the preset dynamic queue management module is first activated. This module is designed to simulate the dynamic behavior of the protocol conversion unit inside the form factor power supply DC-DC module when processing TCP and CAN messages. The dynamic queue management module can be understood as a software or hardware component whose core function is to manage the queuing, scheduling, and processing of data packets during protocol conversion. This module can dynamically adjust the length and priority of its internal message processing queue based on the real-time communication load and the response speed of the virtual DC-DC module. For example, when high concurrency or bursty data flows are detected, the dynamic queue management module will simulate the queuing delay and dropping behavior of CAN messages in the protocol stack of the form factor power supply DC-DC module according to a preset congestion control strategy, and record the actual processing delay of each CAN message. The congestion control strategy may include, but is not limited to, tail drop, random early detection (RED), and other mechanisms to simulate the situation where messages are delayed or dropped during network congestion in a real system. Furthermore, the dynamic queue management module simulates changes in the CAN message processing order caused by resource contention, based on the internal state and current processing capacity of the virtual DC-DC module. For example, when multiple tasks simultaneously request access to the CAN bus or shared memory, their processing order may change unexpectedly. Based on the adjusted length and priority of the internal message processing queue, the simulated queuing delay and drop behavior, the recorded actual processing delay of each CAN message, and the changes in the CAN message processing order, the output behavior of the virtual DC-DC module can be obtained. Subsequently, this output behavior is compared with the expected behavior in the fault snapshot data to obtain the behavior comparison result. Based on the behavior comparison result, the congestion control strategy and resource scheduling parameters in the dynamic queue management module can be adjusted until the virtual DC-DC module can reproduce the intermittent faults caused by the internal processing bottleneck of the protocol conversion unit in the real-world fractional-capacity power supply DC-DC module.

[0123] Optionally, in a digital mirror testing environment, the TCP communication data stream from the fault snapshot data is injected into a virtual TCP communication link. The first protocol conversion unit parses and reconstructs the TCP communication data stream into a CAN message sequence, which is then sent to the virtual DC-DC module. The steps of capturing the CAN response message generated by the virtual DC-DC module, converting it into TCP data packets through a second protocol conversion unit, and transmitting it back via the virtual TCP communication link include:

[0124] In the digital mirror testing environment, start the preset external system behavior simulator;

[0125] The external system behavior simulator receives TCP data packets returned by the virtual DC-DC module through the second protocol conversion unit;

[0126] The external system behavior simulator generates and injects subsequent TCP control command sequences into the virtual TCP communication link based on the content of TCP packets and the current state of the virtual DC-DC module.

[0127] Based on the preset interaction logic and state machine rules, the decision-making behavior of the real external system after receiving the response from the virtual DC-DC module is simulated.

[0128] Monitor the response of the virtual DC-DC module in real time, and adjust the generation strategy of subsequent instructions of the external system behavior simulator according to the response results.

[0129] Specifically, an external system behavior simulator can be understood as a software module or simulation component designed to mimic the behavior of an external control system or host computer interacting with a virtual DC-DC power supply module in a real production environment. This simulator can receive TCP packets transmitted back from the virtual DC-DC module through a second protocol conversion unit. These packets typically contain the virtual DC-DC module's operating status, response results, or error information. Its purpose is to provide a more realistic external interaction context for the digital mirror testing environment.

[0130] The external system behavior simulator dynamically generates and injects subsequent TCP control command sequences into the virtual TCP communication link based on the content of the received TCP packets and the current state of the virtual DC-DC module. For example, if the data packets returned by the virtual DC-DC module indicate that it is in an abnormal state, the external system behavior simulator will generate corresponding diagnostic or reset commands according to preset fault handling logic. This process aims to simulate the behavior of a real-world external system making decisions and issuing corresponding commands based on feedback information from the DC-DC module.

[0131] In practical applications, the external system behavior simulator simulates the decision-making behavior of a real external system after receiving a response from a virtual DC-DC module, based on preset interaction logic and state machine rules. These interaction logics and state machine rules can be modeled based on the operation manuals, protocol specifications, or historical operating data of the actual production system, ensuring a high degree of consistency between the simulated decision-making behavior and the real system. Furthermore, the external system behavior simulator is configured to monitor the virtual DC-DC module's response in real time and adjust its subsequent instruction generation strategy based on the response results. This means that the simulator does not simply execute according to a preset script, but can adaptively adjust based on the real-time feedback from the virtual DC-DC module, thereby more accurately reproducing complex interaction scenarios.

[0132] Optionally, in a digital mirror testing environment, the TCP communication data stream from the fault snapshot data is injected into a virtual TCP communication link. The first protocol conversion unit parses and reconstructs the TCP communication data stream into a CAN message sequence, which is then sent to the virtual DC-DC module. The CAN response message generated by the virtual DC-DC module is captured and converted into a TCP data packet by a second protocol conversion unit, then transmitted back via the virtual TCP communication link. During the response and transmission process of the virtual DC-DC module, diagnostic commands are injected into the virtual DC-DC module, and the behavior and communication data stream of the virtual DC-DC module after the injection operation are monitored to obtain post-injection behavior information. The steps of comparing the post-injection behavior information with the expected behavior in the fault snapshot data to obtain the behavior comparison result, and verifying the effectiveness of the diagnostic commands, include:

[0133] In the digital mirror test environment, start the preset dynamic injection strategy controller;

[0134] The dynamic injection strategy controller is driven to receive TCP data packets returned by the virtual DC-DC module through the second protocol conversion unit and obtain the current internal state of the virtual DC-DC module.

[0135] Based on the content of the TCP packets, the current internal state of the virtual DC-DC module, and the historical communication data and system state recorded in the fault snapshot data, the response of the virtual DC-DC module to the injected diagnostic commands is evaluated, and the response evaluation results are obtained.

[0136] Based on the response assessment results, the timing, content, and frequency of subsequent diagnostic commands are adjusted to simulate the behavior of engineers in a real production environment who gradually adjust diagnostic commands based on real-time feedback from the virtual DC-DC module.

[0137] Specifically, the dynamic injection strategy controller is a software module or hardware unit designed to analyze the feedback from the virtual DC-DC module in real time and adjust the diagnostic process accordingly. This controller is activated when the digital mirror test environment starts and runs continuously to monitor the diagnostic process. Specifically, the dynamic injection strategy controller is driven to receive TCP packets returned by the virtual DC-DC module through the second protocol conversion unit. These packets contain the virtual DC-DC module's response information, such as its operating status, error codes, and measurements. Simultaneously, the controller also acquires the current internal state of the virtual DC-DC module, which may include its internal register values, task scheduling status, and memory usage. This information is crucial for understanding the real-time behavior of the virtual DC-DC module. In practical applications, the controller comprehensively evaluates the virtual DC-DC module's response to previously injected diagnostic commands based on the content of the received TCP packets, the current internal state of the virtual DC-DC module, and historical communication data and system status extracted from fault snapshot data. This evaluation aims to determine whether the diagnostic commands produced the expected effect or whether they revealed new fault clues. The evaluation results, i.e., the response evaluation results, will serve as the basis for subsequent decisions. Furthermore, based on the response evaluation results, the controller is configured to dynamically adjust the timing, content, and frequency of subsequent diagnostic commands. For example, if the initial diagnostic command fails to trigger a fault or provide sufficient information, the controller may adjust the injection frequency to increase the trigger probability or modify the command content to probe different functional areas. This adjustment mechanism aims to simulate the behavior of experienced engineers who, when faced with complex faults, progressively refine and adjust diagnostic strategies based on real-time feedback from the device, thereby achieving more efficient and accurate fault location.

[0138] Optionally, based on the response evaluation results, the steps to adjust the timing, content, and frequency of subsequent diagnostic commands include:

[0139] Based on the real-time internal status of the virtual DC-DC module, external environment data, and historical response data of injected diagnostic commands, the future status change trend of the virtual DC-DC module under different adjustment schemes is analyzed.

[0140] Based on future trends in the state, assess the risk of deviation from the diagnostic path introduced by different adjustment plans;

[0141] Based on the risk of deviation from the diagnostic path corresponding to different adjustment schemes, the adjustment scheme with the lowest risk is selected, and the timing, content and frequency of subsequent diagnostic instructions are adjusted.

[0142] Specifically, the real-time internal state of the virtual DC-DC module can include its current voltage, current, temperature, internal register values, error flags, and other key operating parameters. External environmental data can refer to ambient temperature, load changes, power supply fluctuations, etc., within the simulated test platform. Historical response data of injected diagnostic commands records past injections of diagnostic commands and their corresponding behavioral feedback from the virtual DC-DC module. By comprehensively analyzing this data, predictive models or machine learning algorithms can be used to predict the long-term or short-term behavior of the virtual DC-DC module under different diagnostic command adjustment schemes (e.g., changing the timing, content, or frequency of command injection), thereby analyzing the future trend of its state.

[0143] The risk of diagnostic path deviation refers to the situation where, during the diagnostic process, inappropriate adjustments to diagnostic instructions cause the diagnostic process to deviate from an effective and efficient fault location path, potentially introducing new system instability factors or masking the true fault. For example, a diagnostic instruction might temporarily alleviate surface symptoms but accelerate the aging of other components or make the fault phenomenon more complex and difficult to trace. Assessing this risk involves comparing the predicted future state with the ideal fault diagnosis path to identify potential negative impacts or the degree of deviation.

[0144] In practical applications, after obtaining the diagnostic path deviation risks corresponding to different adjustment schemes, the system will employ a risk assessment algorithm, such as weighted scoring or multi-objective optimization, to select the adjustment scheme with the lowest risk. This scheme will be used to guide the adjustment of the timing, content, and frequency of subsequent diagnostic command injections to ensure the robustness and effectiveness of the diagnostic process.

[0145] Optionally, based on the diagnostic path deviation risk corresponding to different adjustment schemes, the adjustment scheme with the lowest risk is selected, and the steps to adjust the timing, content, and frequency of subsequent diagnostic instruction injection include:

[0146] Based on the real-time internal state, historical operating data, and component aging model of the virtual DC-DC module, the long-term operating behavior of the virtual DC-DC module under different adjustment schemes is simulated, and the drift trend of component parameters is analyzed.

[0147] Based on long-term operational behavior and drift trends, the impact of different adjustment schemes on the long-term stability and reliability of the virtual DC-DC module is evaluated, and long-term impact risk information is obtained.

[0148] Based on the long-term impact risk information corresponding to different adjustment schemes, the adjustment scheme with the lowest risk is selected, and the timing, content and frequency of subsequent diagnostic instructions are adjusted accordingly.

[0149] Specifically, the real-time internal state of a virtual DC-DC module refers to the instantaneous values ​​of key parameters such as internal registers, memory, processor load, temperature, voltage, and current during simulated operation in a digital mirror testing environment. This state data is acquired in real-time by the simulation program to reflect the current operating status of the virtual DC-DC module. Historical operating data can be understood as records of various parameters generated by the virtual DC-DC module during simulated operation in a digital mirror testing environment over a past period, including but not limited to communication logs, error codes, and performance indicators. Its purpose is to provide a data foundation for long-term behavioral analysis. A component aging model is a mathematical or empirical model used to describe the performance degradation patterns of key electronic components (such as capacitors, inductors, and semiconductor devices) within the virtual DC-DC module under long-term operation, different workloads, and environmental conditions. This model can be established based on actual component lifetime test data, accelerated aging test results, or industry standards, and its purpose is to predict changes in component performance over time.

[0150] Simulating the long-term operational behavior of a virtual DC-DC module under different adjustment schemes refers to simulating the continuous operation of the virtual DC-DC module over several months or even years in a digital mirror testing environment by applying different diagnostic instruction adjustment schemes to the virtual DC-DC module and combining it with a component aging model, either by accelerating the time or extending the simulation cycle. During this process, various operating parameters and state changes of the virtual DC-DC module are continuously recorded. Analyzing the drift trend of component parameters refers to identifying the direction and magnitude of changes in key component parameters (such as capacitance, resistance, and transistor characteristics) within the virtual DC-DC module over time using statistical analysis and trend prediction algorithms based on the simulated long-term operational behavior data. For example, the rate of decrease in capacitance and the rate of increase in resistance can be analyzed.

[0151] Furthermore, assessing the impact of different adjustment schemes on the long-term stability and reliability of the virtual DC-DC module refers to determining, based on simulated long-term operating behavior and component parameter drift trends, whether each diagnostic instruction adjustment scheme will lead to performance degradation, functional failure, or increased failure rate of the virtual DC-DC module during long-term operation. Long-term stability focuses on the system's ability to maintain consistent performance during continuous operation, while reliability focuses on the probability of the system operating without failure within a specified time. Obtaining long-term impact risk information involves quantifying the above assessment results, for example, by expressing them in the form of risk scores, failure probabilities, and changes in mean time between failures (MTBF). The purpose is to provide a decision-making basis for subsequent scheme selection.

[0152] Optionally, based on the long-term impact risk information corresponding to different adjustment schemes, the adjustment scheme with the lowest risk is selected, and the steps to adjust the timing, content, and frequency of subsequent diagnostic instructions include:

[0153] Based on the batch information, production serial number, or factory test report of the batch-conducting DC-DC power supply module, obtain the component parameter tolerance range and performance deviation data of the batch-conducting DC-DC power supply module.

[0154] Introduce error disturbances corresponding to the component parameter tolerance range and performance deviation data into the simulation parameters of the virtual DC-DC module;

[0155] In a digital mirror test environment, several virtual DC-DC modules with introduced error disturbances were simulated in parallel, and the response behavior and fault recovery of each virtual DC-DC module under different adjustment schemes were recorded.

[0156] Based on the simulation test results of the virtual DC-DC module, the adaptability of different adjustment schemes to the DC-DC module with a split-capacity power supply on different virtual DC-DC modules is evaluated. The adjustment scheme that can effectively recover faults on different virtual DC-DC modules without introducing new compatibility issues is selected, and the timing, content and frequency of subsequent diagnostic command injection are adjusted.

[0157] Specifically, batch information, production serial numbers, or factory test reports for the breakdown and capacity power supply DC-DC modules are crucial for understanding the manufacturing differences in real-world devices. Batch information indicates common characteristics or defects that may exist within the same batch of products; production serial numbers can be used to trace detailed production records of individual devices; and factory test reports directly provide the performance indicators and deviation data of the device at the time of manufacture. Through this information, the parameter tolerance ranges and actual performance deviation data of key components (such as capacitors, inductors, and MOSFETs) within the breakdown and capacity power supply DC-DC module can be obtained. These data reflect the differences between individual devices in the real world.

[0158] Introducing error disturbances corresponding to component parameter tolerance ranges and performance deviations into the simulation parameters of the virtual DC-DC module refers to randomly or systematically adjusting the corresponding component parameters in the simulation model of the virtual DC-DC module based on the aforementioned real device data. For example, if a capacitor has a nominal value of 100uF and a tolerance range of ±5%, multiple virtual DC-DC modules can be generated during simulation, with each module's capacitor parameter randomly selected between 95uF and 105uF. The purpose is to enable the virtual DC-DC module to more realistically simulate the physical characteristics and behavior of different individualized capacitive DC-DC power supply modules in reality.

[0159] In practical applications, several virtual DC-DC modules with introduced error disturbances are simulated and tested in parallel within a digital mirror testing environment. The response behavior and fault recovery of each virtual DC-DC module under different adjustment schemes are recorded. This means that multiple instances of virtual DC-DC modules with different parameter disturbances can be run simultaneously, and the same diagnostic instruction adjustment scheme can be applied to each instance. During this process, it is necessary to record in detail the behavioral changes of each virtual DC-DC module after receiving diagnostic instructions, the communication data stream, and whether the fault is effectively recovered. For example, key indicators such as fault indicator status, output voltage stability, and CAN message response time can be recorded.

[0160] Furthermore, based on the simulation test results of the virtual DC-DC module, the adaptability of different adjustment schemes to the componentized power supply DC-DC module on different virtual DC-DC modules was evaluated. The adjustment scheme that effectively recovers faults on all virtual DC-DC modules without introducing new compatibility issues was selected, and the timing, content, and frequency of subsequent diagnostic command injection were adjusted accordingly. This evaluation process aims to identify diagnostic schemes that not only work effectively under ideal conditions but also exhibit good robustness in the face of manufacturing differences in real equipment. Evaluation criteria include fault recovery success rate, recovery time, and whether it induces new abnormal behavior or performance degradation. The final selected scheme should demonstrate the best overall performance on all virtual DC-DC modules that introduce error disturbances.

[0161] This application also discloses a TCP-based hybrid CAN communication analog data processing system, used to perform TCP-based hybrid CAN communication analog data processing, combined with... Figure 4 As shown, the TCP protocol-based hybrid CAN communication analog data processing system 1 includes:

[0162] The fault snapshot integration module 11 is used to capture TCP communication data stream, CAN communication data stream, operating parameters of the formed-out capacity power supply DC-DC module, system configuration information and external environment data when the formed-out capacity power supply DC-DC module malfunctions, while maintaining the normal operation of the formed-out capacity power supply DC-DC module, and integrate them to generate fault snapshot data.

[0163] The test environment configuration module 12 is used to establish virtual TCP communication links and virtual CAN communication links on the simulation test platform based on fault snapshot data, and configure the virtual DC-DC modules and corresponding virtual associated devices corresponding to the capacity-compressing power supply DC-DC modules to provide a digital mirror test environment.

[0164] The virtual simulation application module 13 is used to inject TCP communication data streams from fault snapshot data into a virtual TCP communication link in a digital mirror test environment. Through a first protocol conversion unit, the TCP communication data stream is parsed and reconstructed into a CAN message sequence, which is then sent to the virtual DC-DC module. The module also captures CAN response messages generated by the virtual DC-DC module and converts them into TCP data packets through a second protocol conversion unit, which are then transmitted back through the virtual TCP communication link. During the response and transmission process of the virtual DC-DC module, diagnostic commands are injected into the virtual DC-DC module, and the behavior and communication data stream of the virtual DC-DC module after the injection operation are monitored to obtain post-injection behavior information. The post-injection behavior information is compared with the expected behavior in the fault snapshot data to obtain the behavior comparison result, thereby verifying the effectiveness of the diagnostic commands.

[0165] The comparison result judgment module 14 is used to determine whether the diagnostic command has passed the verification based on the behavior comparison result;

[0166] The diagnostic instruction deployment module 15 is used to record all communication data and system status changes in the digital mirror test environment, and analyze the recorded communication data and system status to locate the root cause of the fault; based on the root cause of the fault, the verified diagnostic instructions are deployed to the actual production system corresponding to the batch capacity power supply DCDC module.

[0167] To better understand the technical solutions proposed in this application, some key terms are explained first. A formation and capacity-matching power supply DC-DC module refers to a power module used to achieve efficient DC power conversion and management during battery formation and capacity matching; its operating state directly affects battery performance and lifespan. TCP communication data stream refers to data transmitted based on the Transmission Control Protocol (TCP), typically used for high-reliability network communication. CAN communication data stream refers to data transmitted based on the Controller Area Network (CAN) protocol, widely used in automotive electronics and industrial control, renowned for its high real-time performance and reliability. Fault snapshot data is a one-time capture and integration of key operating parameters, communication data, system configuration, and external environmental data when an anomaly occurs, aiming to comprehensively record the system state at the time of the fault. Virtual DC-DC module and virtual associated device are software or hardware-in-the-loop simulations of real DC-DC modules and their peripheral devices on a simulation test platform to simulate their real behavior and response. A digital mirror test environment is a highly simulated test platform capable of accurately reproducing the operating state and fault scenarios of a real system.

[0168] Specifically, the TCP protocol-based hybrid CAN communication analog data processing system of this application includes the following modules:

[0169] The fault snapshot integration module is used to capture TCP communication data streams, CAN communication data streams, operating parameters of the DC-DC converter, system configuration information, and external environmental data when the DC-DC converter malfunctions, while maintaining its normal operation. This data is then integrated to generate fault snapshot data. This module can be implemented as a standalone software service deployed on a data acquisition server, responsible for real-time monitoring of the DC-DC converter's communication ports and sensor interfaces. For example, data stream capture can be performed by configuring the API interfaces of a network sniffer and a CAN bus analyzer. Furthermore, this module can integrate data preprocessing functions, performing timestamp alignment, format conversion, and data cleaning on the captured raw data to ensure the integrity and consistency of the fault snapshot data. In some implementations, this module can adopt a distributed architecture, with multiple sub-modules working collaboratively, each responsible for capturing and initially integrating different types of data, ultimately aggregated by a central unit.

[0170] The test environment configuration module is used to establish virtual TCP and virtual CAN communication links on the simulation test platform based on fault snapshot data, and configure the virtual DC-DC modules and corresponding virtual associated devices corresponding to the capacity-controlled power supply DC-DC modules to provide a digital mirror test environment. This module can be implemented as a configuration management tool, receiving fault snapshot data as input through a graphical user interface (GUI) or command-line interface (CLI) and automatically generating configuration scripts for the simulation test environment. For example, this module can call the APIs of virtualization platforms (such as VMware or Docker) to create virtual network interfaces and virtual CAN interfaces, and load predefined simulation models of virtual DC-DC modules and virtual associated devices. In some implementations, this module can also support dynamic configuration, allowing users to adjust the parameters of the virtual DC-DC modules or the characteristics of the virtual communication links during testing to simulate different operating conditions.

[0171] The virtual simulation application module is used in a digital mirror testing environment to inject TCP communication data streams from fault snapshot data into a virtual TCP communication link. A first protocol conversion unit parses and reconstructs the TCP communication data stream into a CAN message sequence, which is then sent to the virtual DC-DC module. The module captures CAN response messages generated by the virtual DC-DC module and converts them into TCP data packets via a second protocol conversion unit, which are then transmitted back through the virtual TCP communication link. During the response and transmission process of the virtual DC-DC module, diagnostic commands are injected into the virtual DC-DC module, and the behavior and communication data stream of the virtual DC-DC module after the injection operation are monitored to obtain post-injection behavior information. The post-injection behavior information is compared with the expected behavior in the fault snapshot data to obtain the behavior comparison results, thus verifying the effectiveness of the diagnostic commands. This module is the core execution unit of the entire system and can be implemented as a complex simulation engine. For example, this module can include a data injector responsible for accurately injecting TCP communication data streams into the virtual TCP communication link according to the timing and content recorded in the fault snapshot data. The first and second protocol conversion units can serve as sub-components of this module, implementing TCP-to-CAN and CAN-to-TCP protocol conversion functions through software libraries or hardware accelerators. Diagnostic command injection can be achieved through the module's built-in diagnostic interface, for example, by sending specific diagnostic messages via a simulated CAN bus. The module also integrates a behavior monitor to record the internal state, output signals, and communication data streams of the virtual DC-DC module in real time, and integrates this information into post-injection behavior information.

[0172] The comparison result judgment module is used to determine whether diagnostic commands have passed verification based on the behavior comparison results. This module can be implemented as an intelligent analyzer, receiving the behavior comparison results output by the virtual simulation application module as input. For example, this module can have a built-in rule engine or machine learning model to evaluate the behavior comparison results according to preset verification criteria (such as whether the fault has been eliminated, whether the system has returned to normal operation, and whether key parameters are within allowable ranges). In some implementations, this module can also provide a visualization interface, displaying the comparison results to the user in chart form and providing detailed judgment criteria.

[0173] The diagnostic instruction deployment module records all communication data and system status changes in the digital mirror test environment, and analyzes the recorded data to pinpoint the root cause of the fault. Based on the root cause, it deploys verified diagnostic instructions to the actual production system corresponding to the batch capacity power supply DC-DC module. This module can be implemented as a log management and deployment tool. For example, it can continuously collect all log data generated by the virtual simulation application module and the comparison result judgment module, and store it in a traceable database. The location of the root cause can be achieved through the module's built-in log analyzer, for example, by identifying fault modes through pattern matching and anomaly detection algorithms. Once the diagnostic instruction is verified by the comparison result judgment module, this module is responsible for its safe and reliable deployment to the actual production system, for example, through remote firmware updates or configuration distribution. In some implementations, this module can also support pre-deployment risk assessment to ensure that the deployment operation does not introduce new problems.

[0174] The above are merely embodiments of this application and are not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for simulating data processing based on TCP protocol and hybrid CAN communication, characterized in that, include: While ensuring the normal operation of the DC-DC converter module, when the DC-DC converter module malfunctions, the system captures TCP communication data stream, CAN communication data stream, operating parameters of the DC-DC converter module, system configuration information, and external environment data, and integrates them to generate fault snapshot data. Based on the fault snapshot data, a virtual TCP communication link and a virtual CAN communication link are established on the simulation test platform, and a virtual DC-DC module and a corresponding virtual associated device are configured to be generated for the capacity-determining power supply DC-DC module, so as to provide a digital mirror test environment. In the digital mirror test environment, the TCP communication data stream in the fault snapshot data is injected into the virtual TCP communication link. The TCP communication data stream is parsed and reconstructed into a CAN message sequence through the first protocol conversion unit and sent to the virtual DC-DC module. The CAN response message generated by the virtual DC-DC module is captured and converted into a TCP data packet through the second protocol conversion unit and transmitted back through the virtual TCP communication link. During the response and feedback process of the virtual DC-DC module, diagnostic commands are injected into the virtual DC-DC module, and the behavior and communication data flow of the virtual DC-DC module after the injection operation are monitored to obtain post-injection behavior information; the post-injection behavior information is compared with the expected behavior in the fault snapshot data to obtain the behavior comparison result, so as to verify the effectiveness of the diagnostic commands. Based on the behavior comparison results, determine whether the diagnostic command has passed the verification. Record all communication data and system status changes in the digital mirror test environment, and analyze the recorded communication data and system status to locate the root cause of the fault; based on the root cause of the fault, deploy the verified diagnostic instructions to the actual production system corresponding to the batch capacity power supply DC-DC module.

2. The method for simulating data processing based on TCP protocol and hybrid CAN communication according to claim 1, characterized in that, The steps of injecting TCP communication data streams from the fault snapshot data into the virtual TCP communication link in the digital mirror test environment, parsing and reconstructing the TCP communication data streams into CAN message sequences through a first protocol conversion unit, and sending them to the virtual DC-DC module; capturing the CAN response messages generated by the virtual DC-DC module, converting the CAN response messages into TCP data packets through a second protocol conversion unit, and transmitting them back through the virtual TCP communication link include: When the DC-DC module of the power supply receives a CAN message and begins processing it, the start time of processing is recorded, and the start time of processing is associated with the unique identifier of the CAN message and the key data content. The start processing time point is timestamped and correlated with the externally captured communication data of the fractional-capacitance power supply DC-DC module, and then integrated into the fault snapshot data. When reproducing a fault in a digital mirror test environment, for CAN messages in the fault snapshot data that simultaneously contain the timestamps of externally captured communication data and internal processing timestamps, the start processing time point is used as the time reference for the CAN message to begin being processed in the virtual DC-DC module, in order to adjust the injection timing of the CAN message.

3. The method for simulating data processing based on TCP protocol and hybrid CAN communication according to claim 1, characterized in that, During the process of responding and transmitting data back to the virtual DC-DC module, diagnostic commands are injected into the virtual DC-DC module, and the behavior and communication data stream of the virtual DC-DC module after the injection operation are monitored to obtain post-injection behavior information. The steps of comparing the injected behavioral information with the expected behavior in the fault snapshot data to obtain the behavioral comparison results and verify the effectiveness of the diagnostic instructions include: When the virtual DC-DC module receives a CAN message or diagnostic command, the simulation program built into the virtual DC-DC module uses a real-time operating system simulation layer to simulate the queuing, execution, and interruption response of the CAN message processing task according to a preset scheduling strategy and resource contention rules, and records the actual start and end times of the task. The real-time operating system simulation layer simulates internal bus access conflicts and shared memory access latency to introduce microsecond-level processing timing deviations in specific critical state switching scenarios. The output behavior of the virtual DC-DC module is obtained based on the queuing, execution and interrupt response of the simulated CAN message processing task, the actual start time and completion time of the processing, and the introduced processing timing deviation. The output behavior of the virtual DC-DC module is compared with the expected behavior in the fault snapshot data to obtain the behavior comparison result. The scheduling parameters and delay parameters in the real-time operating system simulation layer are adjusted according to the behavior comparison result until the virtual DC-DC module reproduces the intermittent fault caused by the internal concurrency problem of the real-world fractional-capacity power supply DC-DC module.

4. The method for simulating data processing based on TCP protocol and hybrid CAN communication according to claim 1, characterized in that, The steps of injecting TCP communication data streams from the fault snapshot data into the virtual TCP communication link in the digital mirror test environment, parsing and reconstructing the TCP communication data streams into CAN message sequences through a first protocol conversion unit, and sending them to the virtual DC-DC module; capturing the CAN response messages generated by the virtual DC-DC module, converting the CAN response messages into TCP data packets through a second protocol conversion unit, and transmitting them back through the virtual TCP communication link include: In the digital mirror test environment, the dynamic queue management module pre-configured by the first protocol conversion unit and the second protocol conversion unit is activated; The dynamic queue management module is driven to adjust the length and priority of its internal message processing queue based on the real-time communication load and the response speed of the virtual DC-DC module. When high concurrency or bursty data streams are detected, the dynamic queue management module is driven to simulate the queuing delay and dropping behavior of CAN messages in the protocol stack of the transformer capacity power supply DC-DC module according to the preset congestion control strategy, and record the actual processing delay of each CAN message. The dynamic queue management module is driven to simulate changes in the CAN message processing order caused by resource contention, based on the internal state and current processing capacity of the virtual DC-DC module. The output behavior of the virtual DC-DC module is obtained based on the adjusted length and priority of the internal message processing queue, the simulated queuing delay and dropping behavior, the actual processing delay of each CAN message recorded, and the changes in the CAN message processing order. By comparing the output behavior of the virtual DC-DC module with the expected behavior in the fault snapshot data, a behavior comparison result is obtained. Based on the behavior comparison results, the congestion control strategy and resource scheduling parameters in the dynamic queue management module are adjusted until the virtual DC-DC module reproduces the intermittent failure caused by the internal processing bottleneck of the protocol conversion unit in the real-world form-capacity power supply DC-DC module.

5. The method for simulating data processing based on TCP protocol and hybrid CAN communication according to claim 1, characterized in that, The steps of injecting TCP communication data streams from the fault snapshot data into the virtual TCP communication link in the digital mirror test environment, parsing and reconstructing the TCP communication data streams into CAN message sequences through a first protocol conversion unit, and sending them to the virtual DC-DC module; capturing the CAN response messages generated by the virtual DC-DC module, converting the CAN response messages into TCP data packets through a second protocol conversion unit, and transmitting them back through the virtual TCP communication link include: In the digital mirror testing environment, start the preset external system behavior simulator; The external system behavior simulator receives TCP data packets transmitted back by the virtual DC-DC module through the second protocol conversion unit; The external system behavior simulator is driven to generate and inject subsequent TCP control command sequences into the virtual TCP communication link based on the content of the TCP data packets and the current state of the virtual DC-DC module. Based on preset interaction logic and state machine rules, the decision-making behavior of a real external system after receiving a response from the virtual DC-DC module is simulated. The response of the virtual DC-DC module is monitored in real time, and the generation strategy of subsequent instructions of the external system behavior simulator is adjusted according to the response results.

6. The method for simulating data processing based on TCP protocol and hybrid CAN communication according to claim 1, characterized in that, In the digital mirror test environment, the TCP communication data stream in the fault snapshot data is injected into the virtual TCP communication link. The TCP communication data stream is parsed and reconstructed into a CAN message sequence through the first protocol conversion unit and sent to the virtual DC-DC module. The CAN response message generated by the virtual DC-DC module is captured and converted into a TCP data packet through the second protocol conversion unit and transmitted back through the virtual TCP communication link. During the response and feedback process of the virtual DC-DC module, diagnostic commands are injected into the virtual DC-DC module, and the behavior and communication data flow of the virtual DC-DC module after the injection operation are monitored to obtain post-injection behavior information; The steps of comparing the injected behavioral information with the expected behavior in the fault snapshot data to obtain the behavioral comparison results and verify the effectiveness of the diagnostic instructions include: In the digital mirror test environment, start the preset dynamic injection strategy controller; The dynamic injection strategy controller is driven to receive the TCP data packets returned by the virtual DC-DC module through the second protocol conversion unit, and to obtain the current internal state of the virtual DC-DC module. Based on the content of the TCP data packet, the current internal state of the virtual DC-DC module, and the historical communication data and system state recorded in the fault snapshot data, the response of the virtual DC-DC module to the injected diagnostic instructions is evaluated to obtain the response evaluation result. Based on the response evaluation results, the timing, content, and frequency of subsequent diagnostic commands are adjusted to simulate the behavior of engineers in a real production environment who gradually adjust diagnostic commands based on real-time feedback from the virtual DC-DC module.

7. The method for simulating data processing based on TCP protocol and hybrid CAN communication according to claim 6, characterized in that, The step of adjusting the timing, content, and frequency of subsequent diagnostic commands based on the response evaluation results to simulate the behavior of engineers gradually adjusting diagnostic commands based on real-time feedback from the virtual DC-DC module in a real production environment includes: Based on the real-time internal state of the virtual DC-DC module, external environment data, and historical response data of the injected diagnostic commands, the future state change trend of the virtual DC-DC module under different adjustment schemes is analyzed. Based on the described future state change trends, assess the risk of diagnostic path deviation introduced by different adjustment schemes; Based on the risk of deviation from the diagnostic path corresponding to different adjustment schemes, the adjustment scheme with the lowest risk is selected, and the timing, content and frequency of subsequent diagnostic instructions are adjusted.

8. The method for simulating data processing based on TCP protocol and hybrid CAN communication according to claim 7, characterized in that, The steps of selecting the adjustment scheme with the lowest risk based on the diagnostic path deviation risk corresponding to different adjustment schemes, and adjusting the timing, content, and frequency of subsequent diagnostic instruction injections, include: Based on the real-time internal state, historical operating data, and component aging model of the virtual DC-DC module, the long-term operating behavior of the virtual DC-DC module under different adjustment schemes is simulated, and the drift trend of component parameters is analyzed. Based on the long-term operating behavior and the drift trend, the impact of different adjustment schemes on the long-term stability and reliability of the virtual DC-DC module is evaluated to obtain long-term impact risk information; Based on the long-term impact risk information corresponding to different adjustment schemes, the adjustment scheme with the lowest risk is selected, and the timing, content and frequency of subsequent diagnostic instructions are adjusted accordingly.

9. The method for simulating data processing based on TCP protocol and hybrid CAN communication according to claim 8, characterized in that, The steps of selecting the adjustment scheme with the lowest risk based on the long-term impact risk information corresponding to different adjustment schemes, and adjusting the timing, content, and frequency of subsequent diagnostic instructions include: Based on the batch information, production serial number, or factory test report of the batch-conducting DC-DC power supply module, obtain the component parameter tolerance range and performance deviation data of the batch-conducting DC-DC power supply module. An error disturbance corresponding to the component parameter tolerance range and performance deviation data is introduced into the simulation parameters of the virtual DC-DC module; In a digital mirror test environment, several virtual DC-DC modules with the introduced error disturbance are subjected to parallel simulation tests, and the response behavior and fault recovery of each virtual DC-DC module under different adjustment schemes are recorded. Based on the simulation test results of the virtual DC-DC module, the adaptability of different adjustment schemes to the DC-DC module of the componentized power supply on different virtual DC-DC modules is evaluated, and the adjustment scheme that can effectively recover faults on different virtual DC-DC modules without introducing new compatibility issues is selected. The timing, content and frequency of subsequent diagnostic command injection are then adjusted.

10. A TCP-based hybrid CAN communication simulation data processing system, used to perform TCP-based hybrid CAN communication simulation data processing, characterized in that, include: The fault snapshot integration module is used to capture TCP communication data stream, CAN communication data stream, operating parameters of the DC-DC converter, system configuration information and external environment data when the DC-DC converter malfunctions, while maintaining the normal operation of the DC-DC converter. The module then integrates these data to generate fault snapshot data. The test environment configuration module is used to establish virtual TCP communication links and virtual CAN communication links on the simulation test platform based on the fault snapshot data, and configure the virtual DC-DC modules and corresponding virtual associated devices corresponding to the capacity-compensating power supply DC-DC modules to provide a digital mirror test environment. The virtual simulation application module is used to inject the TCP communication data stream from the fault snapshot data into the virtual TCP communication link in a digital mirror test environment. A first protocol conversion unit parses and reconstructs the TCP communication data stream into a CAN message sequence, which is then sent to the virtual DC-DC module. The module also captures the CAN response message generated by the virtual DC-DC module and converts it into a TCP data packet through a second protocol conversion unit, which is then transmitted back through the virtual TCP communication link. During the response and feedback process of the virtual DC-DC module, diagnostic commands are injected into the virtual DC-DC module, and the behavior and communication data flow of the virtual DC-DC module after the injection operation are monitored to obtain post-injection behavior information; the post-injection behavior information is compared with the expected behavior in the fault snapshot data to obtain the behavior comparison result, so as to verify the effectiveness of the diagnostic commands. The comparison result judgment module is used to determine whether the diagnostic command has passed the verification based on the behavior comparison result; The diagnostic command deployment module is used to record all communication data and system status changes in the digital mirror test environment, and analyze the recorded communication data and system status to locate the root cause of the fault. Based on the root cause of the fault, the verified diagnostic instructions are deployed to the actual production system corresponding to the batch capacity power supply DC-DC module.

Images