Train communication detection method and system

Abstract

The application provides a train communication detection method and system. The method comprises: an Ethernet switch periodically collecting physical layer state parameters, data link layer state parameters, network layer state parameters and switch self-running parameters; a train central control unit analyzing the state parameters to obtain state variables, performing logical operation according to a preset fault diagnosis model to obtain a fault diagnosis result and / or early warning information; a train human-computer interaction unit receiving and analyzing the state parameters and the fault diagnosis result to perform visual display; and a train data recording unit recording and storing the state parameters and the fault diagnosis result. The application can identify hidden faults such as physical layer cable degradation, network layer traffic congestion and switch health attenuation and actively warn by collecting full-dimension bottom layer state parameters of a train Ethernet from a physical layer to a network layer and combining single variable and multi-variable fusion diagnosis models to perform comprehensive logical judgment.

Description

Technical Field

[0001] This application relates to the field of train communication technology, and in particular to a train communication detection method and system. Background Technology

[0002] With the development of rail transit towards high speed and intelligence, onboard Ethernet technology, with its advantages of high bandwidth, standardized architecture, and flexible topology, has become the mainstream solution for the backbone communication network of next-generation rail vehicles. In Ethernet train control and monitoring systems, each network device relies on its application to periodically send life signals to the central control unit to indicate that the device is working properly. Current network monitoring and diagnostic technologies for onboard Ethernet communication are mostly based on the above principle, focusing on the verification and detection of the application itself, mainly involving the transport layer and application layer in the five-layer network model.

[0003] However, existing monitoring technologies have significant limitations: First, they mainly focus on the transport and application layers of Ethernet communication, neglecting systematic monitoring of the physical, data link, and network layers. Key dimensions such as physical layer signal quality (CRC errors caused by loose connector connections), data link layer protocol interaction (MAC address drift), and network layer transmission dynamics (bandwidth utilization fluctuations) are not effectively covered. Second, this monitoring blind spot means that when vehicle Ethernet communication fails, analysis can only be performed based on application layer data, making it impossible to further explore the underlying behavior of Ethernet at that time. Fault location is difficult, and maintenance can only be performed passively after the fault occurs, without the ability to provide early warning of risks. Summary of the Invention

[0004] This application addresses at least some of the aforementioned technical problems by providing a train communication detection method and system. It collects low-level status parameters in all dimensions via an Ethernet switch, performs integrated diagnosis and provides early warnings by the central control unit, displays the data through an interactive unit, and stores it in a recording unit, thus filling monitoring gaps and improving diagnostic accuracy and efficiency.

[0005] Embodiments of this disclosure provide a train communication detection method, including: Ethernet switches periodically collect status parameters, which include physical layer status parameters, data link layer status parameters, network layer status parameters, and the Ethernet switch's own operating parameters. The train's central control unit parses the state parameters to obtain state variables, and performs logical operations on the state variables according to a preset fault diagnosis model to obtain fault diagnosis results and / or early warning information. The train human-machine interaction unit receives the status parameters and the fault diagnosis results, analyzes them, and displays them visually based on the analysis results. The train data recording unit records and stores the status parameters and the fault diagnosis results.

[0006] The technical solution provided in this application brings at least the following benefits: it enables full-dimensional monitoring of the underlying state from the physical layer to the network layer, filling the blind spots of existing technologies; and it enables automatic fault identification, early warning, and complete data closure through a diagnostic model.

[0007] In other embodiments of this application, the fault diagnosis model includes a univariate fault diagnosis model and a multivariate fault diagnosis model. The univariate fault diagnosis model is configured to compare a single state variable with a corresponding preset normal range threshold. When the state variable exceeds the normal range threshold, it is determined that the fault type corresponding to the state variable is valid. The multivariate fault diagnosis model is configured to perform a comprehensive logical judgment on at least two state variables and compare them with the corresponding preset fault judgment threshold, and determine whether the fault type is valid based on the comparison result.

[0008] The technical solution provided in this application brings at least the following beneficial effects: through the hierarchical diagnostic architecture of univariate and multivariate, it can identify abnormalities in a single indicator and capture complex faults associated with multiple factors, thereby improving the comprehensiveness and accuracy of diagnosis.

[0009] In other embodiments of this application, the multivariate fault diagnosis model includes a physical layer fault diagnosis sub-model, which is configured as follows: The status parameters are parsed to obtain status variables, which include the number of brief interruptions, port operating mode, and number of CRC errors. Based on the state variables, fault judgment is performed. When the number of interruptions exceeds the preset frequency, the port working mode is abnormal, or the number of CRC errors continues to increase, it is determined that a physical layer fault has occurred and physical layer maintenance warning information is output.

[0010] The technical solution provided in this application brings at least the following benefits: by using the multi-dimensional correlation between the frequency of interruptions, working mode and CRC error, the physical layer hidden faults can be accurately located, the scope of maintenance can be narrowed and the false alarm rate can be reduced.

[0011] In other embodiments of this application, the multivariate fault diagnosis model includes a network layer fault diagnosis sub-model, which is configured as follows: The state parameters are parsed to obtain state variables, which include the port traffic bandwidth, port packet transmission and reception rate, port multicast packet rate, and port broadcast packet rate of the Ethernet switch. Based on the state variables, fault judgment is performed. When the port traffic bandwidth of the Ethernet switch exceeds a preset bandwidth threshold, the port message transmission and reception rate of the Ethernet switch exceeds a first preset rate, the port multicast message rate of the Ethernet switch exceeds a second preset rate, or the port broadcast message rate of the Ethernet switch exceeds a third preset rate, it is determined that an overload fault has occurred in the network layer and traffic overload warning information is output.

[0012] The technical solution provided in this application brings at least the following benefits: by comprehensively monitoring port bandwidth utilization and various message rates, the risk of network congestion can be predicted, and packet loss and communication interruption caused by traffic overload can be avoided.

[0013] In other embodiments of this application, the multivariate fault diagnosis model includes an Ethernet switch fault diagnosis sub-model, which is configured as follows: The state parameters are parsed to obtain state variables, which include the load rate of the Ethernet switch, the memory usage rate of the Ethernet switch, and the working flag of the Ethernet switch. Based on the state variables, fault judgment is performed. When the load rate of the Ethernet switch exceeds the first threshold and continues for a preset time, the memory usage rate of the Ethernet switch continues to increase, or the working flag bit of the Ethernet switch indicates an abnormal working state, it is determined that the Ethernet switch has a health fault and outputs a hardware warning message to replace the Ethernet switch.

[0014] The technical solution provided in this application brings at least the following benefits: by comprehensively monitoring CPU load, memory usage and working flag bits, the hardware health degradation trend of Ethernet switches can be predicted, thereby realizing equipment lifespan management and proactive protection.

[0015] In other embodiments of this application, the Ethernet switch periodically collects status parameters, including: The status parameters are encapsulated to obtain physical status messages and transmit / receive data statistics messages. The physical status messages include the load rate of the Ethernet switch, the memory utilization rate of the Ethernet switch, the number of brief outages of the Ethernet switch, and the port operating mode of the Ethernet switch. The transmit / receive data statistics messages include the number of CRC errors of the Ethernet switch, the port traffic bandwidth of the Ethernet switch, the port message transmit / receive rate of the Ethernet switch, the port multicast message rate of the Ethernet switch, and the port broadcast message rate of the Ethernet switch. The physical status message and the transmitted / received data statistics message are sent to the train communication backbone network; The train's central control unit parses the state parameters to obtain state variables, including: The physical status message and the transmitted and received data statistics message are obtained and parsed through the train communication backbone network; The train data recording unit records and stores the status parameters, including: The physical status messages and the transmitted and received data statistics messages are obtained through the train communication backbone network and recorded and stored.

[0016] The technical solution provided in this application brings at least the following benefits: by classifying and encapsulating two types of messages, the length of a single message is avoided, thus improving transmission efficiency; data distribution is achieved based on the existing backbone network without the need for additional cabling.

[0017] In other embodiments of this application, the Ethernet switch sends the physical status message to the train communication backbone network via a first multicast address; The Ethernet switch sends the transmitted and received data statistics message to the train communication backbone network through the second multicast address; The train human-machine interaction unit obtains the physical status message from the train communication backbone network through the first multicast address and receives and parses the transmit and receive data statistics message from the train communication backbone network through the second multicast address; The train data recording unit obtains the physical status message from the train communication backbone network through the first multicast address and the transmitted and received data statistics message from the train communication backbone network through the second multicast address, and records and stores them.

[0018] The technical solution provided in this application brings at least the following benefits: multi-device synchronous reception is achieved through multicast addresses, ensuring data consistency; the train central control unit, train human-machine interaction unit, and train data recording unit can subscribe on demand, improving data transmission efficiency.

[0019] In other embodiments of this application, the method further includes: the train central control unit encapsulating the fault diagnosis results and / or early warning information into a diagnosis result message according to a communication protocol; and the train central control unit sending the diagnosis result message to the train communication backbone network. The train human-machine interaction unit obtains and parses the diagnostic result message through the train communication backbone network, and displays the result visually. The train data recording unit obtains, records, and stores the diagnostic result messages through the train communication backbone network.

[0020] The technical solution provided in this application brings at least the following benefits: establishing a complete data closed loop from diagnosis to visualization and storage, ensuring that the diagnostic results can be viewed in real time and traced historically, and supporting operation and maintenance decisions.

[0021] In other embodiments of this application, the train central control unit sends the diagnostic result message to the train communication backbone network via a third multicast address; The train human-machine interaction unit obtains the diagnostic result message from the train communication backbone network through the third multicast address and parses it, and then displays the result visually. The train data recording unit obtains the diagnostic result message from the train communication backbone network through the third multicast address and records and stores it.

[0022] The technical solution provided in this application brings at least the following benefits: the train human-machine interaction unit and the train data recording unit can synchronously obtain diagnostic results through the third multicast address, ensuring the consistency of displayed and stored data and improving distribution efficiency.

[0023] A second aspect of this disclosure discloses a train communication detection system for implementing a train communication detection method disclosed in the first aspect of this disclosure, the method comprising: Ethernet switches are configured to periodically collect status parameters, including physical layer status parameters, data link layer status parameters, network layer status parameters, and the Ethernet switch's own operating parameters. The train central control unit, connected to the Ethernet switch, is configured to parse the status parameters to obtain status variables, and perform logical operations on the status variables according to a preset fault diagnosis model to obtain fault diagnosis results and / or early warning information. The train human-machine interaction unit, connected to the Ethernet switch and the train central control unit, is configured to receive the status parameters and the fault diagnosis results and parse them, and then perform a visual display based on the parsing results. The train data recording unit, connected to the Ethernet switch and the train central control unit, is configured to record and store the status parameters and the fault diagnosis results.

[0024] Compared with the prior art, the present invention has the following beneficial effects: (1) By periodically collecting the physical layer, data link layer, network layer and the Ethernet switch itself of the train Ethernet switch, the bottom-level status parameters of the physical layer, data link layer, network layer and the Ethernet switch itself are collected, which fills the bottom-level monitoring blind spot caused by the existing technology that only focuses on the application layer and the transmission layer, and provides a new data dimension for vehicle Ethernet communication status monitoring.

[0025] (2) By using the single-variable and multi-variable fusion diagnostic model built into the train central control unit to perform logical operations on the full-dimensional state parameters, the limitations of single index threshold judgment are overcome, and the early identification and proactive warning of hidden faults such as physical layer cable degradation, network layer traffic congestion and switch health decay are realized.

[0026] The above description is merely an overview of the technical solution disclosed herein. In order to better understand the technical means of this disclosure and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this disclosure more apparent and understandable, specific embodiments of this disclosure are described below. Attached Figure Description

[0027] To more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0028] Figure 1 This is a flowchart of the train communication detection method according to an embodiment of this application; Figure 2 This is a schematic diagram of the physical layer fault diagnosis process provided in the embodiments of this application; Figure 3 This is a schematic diagram of the network layer fault diagnosis process provided in the embodiments of this application; Figure 4 This is a schematic diagram of the switch fault diagnosis process provided in the embodiments of this application; Figure 5 This is a schematic diagram of the train communication detection system according to an embodiment of this application. Detailed Implementation

[0029] To make the technical problems, technical solutions, and beneficial effects to be solved by this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and are not intended to limit the scope of this application.

[0030] The prefixes such as "first" and "second" used in this application embodiment are merely for distinguishing different descriptive objects and do not limit the position, order, priority, quantity, or content of the described objects. The use of ordinal numbers and other prefixes used to distinguish descriptive objects in this application embodiment does not constitute a limitation on the described objects. The description of the described objects is given in the claims or the context of the embodiments, and should not constitute unnecessary restrictions due to the use of such prefixes. Furthermore, in the description of this embodiment, unless otherwise stated, "multiple" means two or more.

[0031] The technical solutions of the embodiments of this application will be described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B; the term "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone.

[0032] In the embodiments provided in this application, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0033] In this application, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to a specific feature, structure, material, or characteristic described in connection with that embodiment or example, which is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0034] As a new generation of backbone communication network for rail vehicles, the operational reliability of train Ethernet directly affects train safety. However, current monitoring methods for onboard Ethernet mainly focus on the application layer, judging the communication status by parsing life signals in the application layer protocol. While this method works normally under normal conditions, when communication anomalies occur, due to the lack of underlying communication behavior data support, the fault often presents only as a single symptom of "communication interruption," making it difficult for maintenance personnel to distinguish whether it is caused by a physical link break, network congestion, or equipment malfunction. This predicament of knowing the "what" but not the "why" forces on-site troubleshooting to be broken down and verified at each level, which is not only time-consuming and labor-intensive but also fails to provide early warning of faults. In view of this, this application provides the following implementation method to reconstruct the monitoring and diagnostic system of train Ethernet from the underlying data.

[0035] The first aspect of this disclosure discloses a train communication detection method, such as... Figure 1 As shown, the method includes: S01: The Ethernet switch periodically collects status parameters, including physical layer status parameters, data link layer status parameters, network layer status parameters, and the Ethernet switch's own operating parameters.

[0036] Specifically, the Ethernet switch, as the foundation and core equipment for train Ethernet communication, undertakes the function of data path scheduling for the entire train. The Ethernet switch has an internal monitoring module that periodically collects four types of status parameters.

[0037] Physical layer status parameters reflect the signal quality and connection status of the Ethernet physical transmission medium, including but not limited to port link status (indicating whether the physical link is connected), rate / duplex negotiation mode (indicating whether the port's current operating rate and duplex mode match the peer), and direct / cross-connect status. Data link layer status parameters reflect the transmission quality of Ethernet frames at the data link layer, including the number of unicast / multicast / broadcast messages sent and received, and error frame statistics (such as FCS checksum errors, frame length errors, etc.). Network layer status parameters reflect the configuration and operating status of the IP network layer, including IP addresses, VLAN division, and port rate limiting. Ethernet switch operating parameters reflect the workload and health status of the Ethernet switch itself, including CPU load rate, memory usage, and firmware version.

[0038] All of the above status parameters are read through the standard monitoring counters inside the Ethernet switch, requiring no additional hardware. After collecting these parameters, the Ethernet switch sends them to the train's central control unit.

[0039] S02: The train's central control unit parses the status parameters to obtain status variables, and performs logical operations on the status variables according to the preset fault diagnosis model to obtain fault diagnosis results and / or early warning information. The train central control unit, as the decision-making hub for train control, analyzes the received state parameters and extracts various state variables. The train central control unit has a pre-set fault diagnosis model, which performs logical operations based on the state variables to determine whether there are communication faults or potential risks, and outputs corresponding fault diagnosis results and / or warning information.

[0040] S03: The train's human-machine interaction unit receives status parameters and fault diagnosis results, analyzes them, and displays them visually based on the analysis results; The train data recording unit records and stores status parameters and fault diagnosis results.

[0041] The train's human-machine interface unit receives raw status parameters collected by the Ethernet switch and diagnostic results output by the train's central control unit. After parsing the data according to the communication protocol, it provides users with real-time visualized information on the display interface, including port physical status, port data transmission and reception statistics, equipment status, fault alarm / early warning information, and maintenance suggestions. The train data recording unit simultaneously receives and records all the above data, storing it in time series for subsequent historical tracing and maintenance analysis.

[0042] In this technical solution, the Ethernet switch, the train central control unit, the train human-machine interaction unit, and the train data recording unit are all existing onboard equipment of the train, requiring no additional hardware. This enables full-dimensional low-level status monitoring from the physical layer to the network layer, filling the monitoring blind spots of existing technologies and achieving automatic fault identification and early warning through diagnostic models.

[0043] In other embodiments of this application, the fault diagnosis model includes a univariate fault diagnosis model and a multivariate fault diagnosis model. The univariate fault diagnosis model is configured to compare a single state variable with a corresponding preset normal range threshold. When the state variable exceeds the normal range threshold, it is determined that the fault type corresponding to the state variable is valid. The multivariate fault diagnosis model is configured to perform a comprehensive logical judgment on at least two state variables and compare them with the corresponding preset fault judgment thresholds, and determine whether the fault type is valid based on the comparison result.

[0044] Specifically, the fault diagnosis model adopts a hierarchical architecture, including two types: univariate fault diagnosis model and multivariate fault diagnosis model, which respectively address different types of fault scenarios.

[0045] Univariate fault diagnosis models are used to handle faults related to only a single state variable. Specifically, after the train's central control unit parses the state parameters reported by the Ethernet switch to obtain each state variable, it compares each state variable with its corresponding preset normal range threshold. For example, for the state variable of Ethernet switch CPU load rate, its normal range threshold is preset to 0%~85%. When the CPU load rate collected by the train's central control unit is 90%, this value exceeds the normal range threshold (85%), and the univariate fault diagnosis model determines that the fault type "CPU overload" is valid. The advantages of univariate diagnosis are its simple calculation and fast response, making it suitable for fault types with a clear single indicator.

[0046] Multivariate fault diagnosis models are used to handle complex faults related to multiple state variables. These faults are characterized by the fact that while a single state variable may be within the normal range, a comprehensive judgment is needed to identify the fault when multiple variables simultaneously exhibit abnormal trends. Specifically, the train's central control unit performs a comprehensive logical judgment on at least two state variables and then compares them with their respective preset fault judgment thresholds. It's important to note that the "comprehensive logical judgment" in multivariate fault diagnosis differs from the independent threshold comparison in univariate diagnosis: in multivariate diagnosis, the train's central control unit not only determines whether each variable exceeds the threshold but also considers the correlation between variables (e.g., triggering a specific fault judgment when both variable A and variable B are abnormal). For example, the port outage frequency may not exceed the univariate diagnostic threshold individually, but if it is accompanied by an increase in the number of CRC errors and an abnormal port operating mode, the multivariate model will comprehensively judge it as a physical layer fault. The advantage of multivariate diagnosis is its ability to capture hidden complex faults and avoid missed detections by univariate threshold judgments.

[0047] It should be noted that the univariate fault diagnosis model and the multivariate fault diagnosis model can run independently or in conjunction. In a preferred embodiment, the train central control unit first runs the univariate diagnosis for rapid screening, and then runs the multivariate diagnosis on the data that has not triggered a univariate alarm to discover potential complex fault hazards.

[0048] The technical solution of this application adopts a hierarchical diagnostic architecture of univariate and multivariate methods, which can identify abnormalities in a single indicator and capture complex faults associated with multiple factors, thereby improving the comprehensiveness and accuracy of diagnosis.

[0049] In other embodiments of this application, the multivariate fault diagnosis model includes a physical layer fault diagnosis sub-model, which is configured as follows: Parse the status parameters to obtain status variables, which include the number of brief interruptions, port operating mode, and number of CRC errors. Fault judgment is performed based on status variables. When the number of interruptions exceeds the preset frequency, the port working mode is in abnormal mode, and the number of CRC errors continues to increase, it is determined that a physical layer fault has occurred and physical layer maintenance warning information is output.

[0050] The physical layer fault diagnosis sub-model is a specific implementation of the multivariate fault diagnosis model, used to diagnose latent faults in the train Ethernet physical layer. Physical layer faults typically manifest as a degradation in signal quality without completely interrupting communication, such as cable damage, loose or aging connectors, or physical damage to ports. If these faults are not detected early, they may develop into communication outages.

[0051] Specifically, the train's central control unit parses the status parameters reported by the Ethernet switch and extracts the status variables related to the physical layer, including the number of interruptions, port operating mode, and the number of CRC errors (i.e., the number of cyclic redundancy check errors).

[0052] "Flashover count" refers to the number of times the link state of an Ethernet switch port repeatedly switches between connected and disconnected within a unit of time, reflecting the stability of the physical link. Ethernet switch ports have a built-in link state monitoring mechanism; each time a physical layer signal loss or recovery is detected, a state change is recorded. The train's central control unit obtains the flashover count by reading the relevant counters on the Ethernet switch.

[0053] "Port operating mode" refers to the current operating parameter configuration of the Ethernet switch port, including the speed mode (such as 100Mbps, 1000Mbps) and duplex mode (full-duplex or half-duplex). When the port's operating mode does not match that of the peer device, it may lead to decreased communication efficiency or even connection abnormalities.

[0054] "CRC error count" refers to the number of times a data frame received by an Ethernet switch port has been detected as corrupted during transmission through cyclic redundancy check. CRC check is a data link layer error detection mechanism. The receiving end performs a CRC calculation on each data frame. If the calculated result does not match the check value carried in the frame, the frame is determined to have been corrupted during transmission, and the corresponding counter is incremented by 1. CRC errors are usually caused by poor network cable quality, excessive cable length, or electromagnetic interference.

[0055] like Figure 2 As shown, the judgment logic of the physical layer fault diagnosis sub-model is as follows: The train central control unit simultaneously monitors the above three state variables. When the number of interruptions exceeds a preset frequency (for example, more than 3 times per minute), the port operating mode is in an abnormal mode (e.g., falling back to the default mode after failing to negotiate with the peer device), and the number of CRC errors continues to increase (for example, showing an increasing trend in multiple consecutive sampling periods), all three conditions are met simultaneously, and a hidden fault in the physical layer is judged to have occurred. At this time, the train central control unit outputs physical layer maintenance warning information, suggesting that maintenance personnel check the network cable connection, connector status, and port hardware.

[0056] It should be noted that a single condition trigger may not constitute a physical layer fault (e.g., an occasional CRC error may be caused by transient interference), while the simultaneous abnormality of three conditions has a higher fault orientation and can effectively reduce the false alarm rate.

[0057] The technical solution of this application accurately locates hidden physical layer faults by using a multi-dimensional correlation between port interruption frequency, working mode and CRC error, thus narrowing the scope of maintenance.

[0058] In other embodiments of this application, the multivariate fault diagnosis model includes a network layer fault diagnosis sub-model, which is configured as follows: The state parameters are parsed to obtain the state variables, which include the port traffic bandwidth, port packet transmission and reception rate, port multicast packet rate, and port broadcast packet rate of the Ethernet switch. Fault judgment is performed based on state variables. When the port traffic bandwidth of the Ethernet switch exceeds the preset bandwidth threshold, the port message transmission and reception rate of the Ethernet switch exceeds the first preset rate, the port multicast message rate of the Ethernet switch exceeds the second preset rate, or the port broadcast message rate of the Ethernet switch exceeds the third preset rate, it is determined that an overload fault has occurred in the network layer and an overload warning message is output.

[0059] Specifically, the network layer fault diagnosis sub-model is used to diagnose overload faults in the train's Ethernet network layer. Network layer overload refers to network traffic exceeding the processing capacity of a port or backbone network, which may lead to packet loss, increased transmission delay, or even communication interruption.

[0060] The train's central control unit parses the status parameters reported by the Ethernet switch and extracts status variables related to network layer traffic, including the Ethernet switch's port traffic bandwidth, port message transmission and reception rate, port multicast message rate, and port broadcast message rate.

[0061] "Port bandwidth" refers to the data throughput of an Ethernet switch port per unit time, measured in bps, reflecting the overall load of the port. Port packet transmission / reception rate refers to the number of data packets sent and received by an Ethernet switch port per unit time, measured in pps (packets per second). Port multicast packet rate and port broadcast packet rate respectively count the number of multicast and broadcast packets sent and received by the port, also measured in pps.

[0062] It should be noted that normal multicast and broadcast traffic may exist in the train Ethernet (for example, the multicast address used by the TRDP protocol), but when the multicast or broadcast message rate increases abnormally, it may cause a broadcast storm or network congestion.

[0063] like Figure 3As shown, the judgment logic of the network layer fault diagnosis sub-model is as follows: When the port traffic bandwidth of the Ethernet switch exceeds a preset bandwidth threshold (for example, 80% of the port's rated bandwidth), the port packet transmission and reception rate exceeds a first preset rate (for example, 100,000pps for a 100Mbps port), the port multicast packet rate exceeds a second preset rate (for example, 50,000pps), and the port broadcast packet rate exceeds a third preset rate (for example, 30,000pps), if all four conditions are met simultaneously, it is determined that an overload fault has occurred in the network layer. At this time, the train's central control unit outputs a traffic overload warning message, prompting maintenance personnel to check whether there are abnormal traffic sources in the network or whether network configuration needs to be optimized.

[0064] Similar to physical layer fault diagnosis, network layer overload diagnosis employs a multi-condition comprehensive judgment to avoid false alarms caused by instantaneous fluctuations in single traffic flows. Each preset threshold can be flexibly adjusted according to the actual network configuration and operating conditions of the train.

[0065] In other embodiments of this application, the multivariate fault diagnosis model includes an Ethernet switch fault diagnosis sub-model, which is configured as follows: The state parameters are parsed to obtain the state variables, which include the load rate of the Ethernet switch, the memory utilization rate of the Ethernet switch, and the working flags of the Ethernet switch. Fault diagnosis is performed based on status variables. When the load rate of the Ethernet switch exceeds the first threshold and continues for a preset time, the memory usage of the Ethernet switch continues to rise, or the working flag of the Ethernet switch indicates an abnormal working status, it is determined that the Ethernet switch has a health fault and outputs a warning message to replace the Ethernet switch hardware.

[0066] Specifically, the Ethernet switch fault diagnosis sub-model is used to diagnose whether there are health faults in the Ethernet switch itself. Ethernet switches are the basic core infrastructure of the train network, and Ethernet switch failures will directly affect the communication status of the entire network.

[0067] The train's central control unit parses the status parameters reported by the Ethernet switch and extracts variables related to the health status of the Ethernet switch, including the Ethernet switch's load rate (CPU load rate), Ethernet switch's memory usage rate, and Ethernet switch's operating flags.

[0068] "Ethernet switch load rate" refers to the average utilization rate of the Ethernet switch's CPU per unit time, reflecting the computational load of the Ethernet switch's processor. When the Ethernet switch load rate is consistently too high, it may lead to increased packet processing latency and decreased forwarding capacity. "Ethernet switch memory utilization rate" refers to the proportion of memory used by the Ethernet switch to the total memory. When the memory utilization rate continuously increases and approaches its limit, it may cause the Ethernet switch to restart or crash due to memory exhaustion. "Ethernet switch operating flags" are flags in the Ethernet switch's internal status register, used to indicate whether the various functional modules of the device are working properly. The train's central control unit can obtain the value of this flag by reading the Ethernet switch's status register.

[0069] like Figure 4 As shown, the judgment logic of the Ethernet switch fault diagnosis sub-model is as follows: When the load rate of the Ethernet switch exceeds the first threshold (exemplary, 85%) and continues for a preset time (exemplary, 30 minutes), the memory usage rate of the Ethernet switch continuously increases in multiple consecutive sampling periods (exemplary, the memory usage rate shows an increasing trend for 5 consecutive sampling periods), and the working flag bit of the Ethernet switch indicates an abnormal working state (exemplary, the flag bit of a core functional module is in an abnormal state), if all three conditions are met simultaneously, it is determined that the Ethernet switch has a health fault. At this time, the train central control unit outputs a hardware warning message to replace the Ethernet switch, suggesting that maintenance personnel prepare spare parts in advance and replace the Ethernet switch at an appropriate time to avoid network paralysis due to Ethernet switch failure.

[0070] The purpose of diagnosing Ethernet switch health faults is to shift the operation and maintenance mode from reactive emergency repairs to proactive protection, reducing the impact of equipment failures on safe train operation through predictive maintenance. In practical applications, maintenance personnel can arrange maintenance plans based on early warning information output by the train's central control unit, avoiding operational interruptions caused by sudden Ethernet switch failures.

[0071] The technical solution of this application predicts the hardware health degradation trend of Ethernet switches by comprehensively monitoring the CPU load, memory usage and working flag bits of Ethernet switches, thereby realizing equipment life management.

[0072] In other embodiments of this application, the Ethernet switch periodically collects status parameters, including: The status parameters are encapsulated to obtain physical status messages and transmit / receive data statistics messages. The physical status messages include the load rate of the Ethernet switch, the memory utilization rate of the Ethernet switch, the number of brief outages of the Ethernet switch, and the port operating mode of the Ethernet switch. The transmit / receive data statistics messages include the number of CRC errors of the Ethernet switch, the port traffic bandwidth of the Ethernet switch, the port message transmit / receive rate of the Ethernet switch, the port multicast message rate of the Ethernet switch, and the port broadcast message rate of the Ethernet switch. Send physical status messages and transmitted / received data statistics messages to the train communication backbone network; The train's central control unit parses the state parameters to obtain state variables, including: Physical status messages and transmitted / received data statistics messages are obtained and parsed through the train communication backbone network; The train data recording unit records and stores status parameters, including: Physical status messages and data transmission and reception statistics messages are acquired, recorded, and stored through the train communication backbone network.

[0073] Specifically, after collecting various status parameters, Ethernet switches classify and encapsulate the collected parameters into two types of messages to avoid the network transmission efficiency from being reduced due to excessively long individual messages.

[0074] Ethernet switches encapsulate parameters reflecting their own operating status and physical layer connection status into "physical status messages." These messages include the Ethernet switch's load rate, memory usage, number of brief outages, and port operating mode. Ethernet switches also encapsulate parameters reflecting data link layer transmission quality and network layer traffic statistics into "transmit / receive data statistics messages." These messages include the number of CRC errors, port traffic bandwidth, port message transmission / reception rate, port multicast message rate, and port broadcast message rate.

[0075] Both types of messages are encapsulated according to the standard train communication protocol format. In this embodiment, the Train Real-Time Data Protocol (TRDP) is preferably used. This protocol supports multicast communication mode and is suitable for real-time data distribution among multiple devices in a train Ethernet environment. After encapsulation, the Ethernet switch sends the physical status message and the transmitted / received data statistics message to the train communication backbone network.

[0076] The train's central control unit acquires the two types of messages mentioned above through the train communication backbone network and parses them according to the TRDP protocol specification, extracting various state variables for subsequent fault diagnosis. The train data recording unit also acquires these two types of messages through the train communication backbone network, records and stores them in chronological order for subsequent historical tracing and maintenance analysis.

[0077] The train communication backbone network is a data transmission network built on Ethernet technology within the train. Onboard equipment such as Ethernet switches, the train's central control unit, the train's human-machine interface unit, and the train's data recording unit are all interconnected and exchange data through this backbone network. By utilizing the existing backbone network for data transmission, no new independent cabling is required, reducing system deployment costs.

[0078] The technical solution of this application classifies and encapsulates status parameters into two types of messages, avoiding excessively long individual messages and improving transmission efficiency; it also achieves data distribution based on the existing backbone network of the train, eliminating the need for additional cabling.

[0079] In other embodiments of this application, the Ethernet switch sends physical status messages to the train communication backbone network via the first multicast address; The Ethernet switch sends the data transmission and reception statistics messages to the train communication backbone network via the second multicast address; The train human-machine interaction unit obtains physical status messages from the train communication backbone network through the first multicast address and receives and parses data transmission and reception statistics messages from the train communication backbone network through the second multicast address; The train data recording unit obtains physical status messages from the train communication backbone network through the first multicast address and obtains and records the transmitted and received data statistics messages from the train communication backbone network through the second multicast address.

[0080] Specifically, the Ethernet switch sends physical status messages to the train communication backbone network via a first multicast address and transmits and receives data statistics messages via a second multicast address. In this embodiment, the first multicast address is preferably 239.194.1.8, and the second multicast address is preferably 239.194.1.9. The train central control unit subscribes to the first and second multicast addresses to receive physical status messages and transmit and receive data statistics messages.

[0081] The train's human-machine interface unit also subscribes to both the first and second multicast addresses. It obtains physical status messages from the train communication backbone network via the first multicast address and receives data transmission and reception statistics messages from the same network via the second multicast address. It then parses both types of messages and displays the contained status information on the interface in real time. The train data recording unit similarly subscribes to both the first and second multicast addresses to obtain and store these two types of messages.

[0082] Through the data distribution mechanism of multicast addresses, Ethernet switches only need to send a message to the multicast address once, which can be simultaneously obtained by multiple devices such as the train central control unit, the train human-machine interaction unit, and the train data recording unit. This avoids the bandwidth waste of repeatedly sending the same data to multiple destinations in point-to-point communication, while ensuring the consistency of the data received by each device in time.

[0083] In this application's technical solution, the Ethernet switch sends two types of encapsulated packets to the train communication backbone network via a specific multicast address. Multicast communication allows the sender to send data to a specific multicast address, and any device subscribed to that multicast address can receive the data, achieving efficient one-to-many data transmission.

[0084] In other embodiments of this application, the train central control unit encapsulates the fault diagnosis results and / or early warning information into a diagnosis result message according to the communication protocol; the train central control unit sends the diagnosis result message to the train communication backbone network; The train human-machine interaction unit obtains and parses diagnostic result messages through the train communication backbone network, and then displays the results visually. The train data recording unit obtains, records, and stores diagnostic result messages through the train communication backbone network.

[0085] Specifically, the train's central control unit encapsulates the fault diagnosis results and / or warning information into a diagnostic result message according to the train communication protocol (preferably TRDP protocol, i.e., train real-time data protocol). This message contains information such as fault type identifier, fault level, relevant status variable values ​​that triggered the fault, and timestamp, so that the receiver can fully understand the diagnostic situation.

[0086] After encapsulation, the train's central control unit sends the diagnostic result message to the train's communication backbone network. The train's human-machine interface unit (HMI) obtains the diagnostic result message through the train's communication backbone network, parses it according to the protocol specifications, extracts the fault diagnosis results and early warning information, and displays them visually on the HMI's interface. Maintenance personnel can view the current network communication status, fault alarm information, and recommended maintenance suggestions in real time through the HMI's screen.

[0087] The train data recording unit also obtains diagnostic result messages through the train communication backbone network and records and stores them together with the status parameters originally collected by the Ethernet switch. The train data recording unit builds a database according to time series, with all data organized chronologically to ensure that the network status and diagnostic results at any historical point in time can be traced and queried later. This complete data closed-loop mechanism allows maintenance personnel not only to grasp the current network status in real time, but also to review complete data before and after a fault occurs, assisting in root cause analysis.

[0088] In the technical solution of this application, after the train central control unit completes the fault diagnosis calculation, it distributes and processes the diagnosis results to form a complete closed loop of diagnostic data.

[0089] In other embodiments of this application, the train central control unit sends the diagnostic result message to the train communication backbone network via a third multicast address; The train human-machine interaction unit obtains and parses diagnostic result messages from the train communication backbone network through a third multicast address, and then displays the parsing results visually. The train data recording unit obtains diagnostic result messages from the train communication backbone network via a third multicast address and records and stores them.

[0090] Specifically, the train distributes diagnostic result messages to the train communication backbone network via a specific multicast address. Specifically, the train's central control unit sends the diagnostic result messages to the train communication backbone network via a third multicast address. In this embodiment, the third multicast address is preferably 239.194.1.66, which is distinguishable from the first multicast address (239.194.1.8) used by the aforementioned Ethernet switch to send physical status messages and the second multicast address (239.194.1.9) used to send and receive data statistics messages, thus avoiding confusion between different types of messages at the receiving end.

[0091] The train's human-machine interface unit obtains diagnostic result messages from the train's communication backbone network by subscribing to a third-party multicast address, parses them, and displays them visually on the interface. The train data recording unit also obtains and stores diagnostic result messages by subscribing to a third-party multicast address.

[0092] By introducing a third multicast address, the train's central control unit only needs to send a diagnostic result message once to the third multicast address, which can then be simultaneously received by both the train's human-machine interface unit and the train's data recording unit, instead of sending separate messages to each unit. Compared to point-to-point transmission, this multicast distribution mechanism saves bandwidth resources in the train communication backbone network and ensures that the data displayed by the train's human-machine interface unit and the data stored by the train's data recording unit are completely consistent in timing.

[0093] It is worth noting that, in addition to subscribing to the third multicast address to obtain diagnostic result messages, the train human-machine interface unit and the train data recording unit also obtain the original physical status messages and transmitted / received data statistics messages collected by the Ethernet switch through the first and second multicast addresses, respectively. Therefore, the train human-machine interface unit can simultaneously display raw status data and diagnostic result data, and the train data recording unit can simultaneously record raw data and diagnostic result data, providing maintenance personnel with a complete network status view and historical traceability capabilities.

[0094] The technical solution of this application enables the train human-machine interaction unit and the train data recording unit to synchronously obtain diagnostic results through a third multicast address, ensuring the consistency of displayed and stored data and improving the efficiency of diagnostic information distribution.

[0095] The second aspect of the embodiments of this disclosure discloses a train communication detection system, such as... Figure 5 As shown, the system includes an Ethernet switch, a train central control unit, a train human-machine interaction unit, and a train data recording unit.

[0096] Ethernet switches periodically collect status parameters, including physical layer status parameters, data link layer status parameters, network layer status parameters, and the Ethernet switch's own operating parameters.

[0097] Specifically, the Ethernet switch, as the foundation and core equipment for train Ethernet communication, undertakes the data path scheduling function for the entire train. The Ethernet switch is equipped with a status monitoring module, which periodically collects physical layer status parameters (such as port link status, rate / duplex negotiation mode), data link layer status parameters (such as the number of unicast / multicast / broadcast messages sent and received, error frame statistics), network layer status parameters (such as IP address, VLAN division, port rate limiting), and the Ethernet switch's own operating parameters (such as CPU load rate, memory usage rate, firmware version).

[0098] The train's central control unit is connected to an Ethernet switch to parse status parameters to obtain status variables, and performs logical operations on the status variables according to a preset fault diagnosis model to obtain fault diagnosis results and / or early warning information. Specifically, the train's central control unit parses messages according to the communication protocol to obtain various state variables. The central control unit has a pre-set fault diagnosis model, which includes univariate fault diagnosis sub-models and multivariate fault diagnosis sub-models (physical layer fault diagnosis sub-model, network layer fault diagnosis sub-model, and Ethernet switch fault diagnosis sub-model). Based on the fault diagnosis model, the central control unit performs logical operations on each state variable to obtain fault diagnosis results and / or early warning information.

[0099] The train human-machine interface unit connects to the Ethernet switch and the train central control unit. It is used to receive status parameters and fault diagnosis results, analyze them, and then display them visually based on the analysis results.

[0100] The train data recording unit is connected to the Ethernet switch and the train central control unit to record and store status parameters and fault diagnosis results.

[0101] Those skilled in the art will recognize that the modules, units, and method steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0102] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. A train communication detection method, characterized in that, include: Ethernet switches periodically collect status parameters, which include physical layer status parameters, data link layer status parameters, network layer status parameters, and the Ethernet switch's own operating parameters. The train's central control unit parses the state parameters to obtain state variables, and performs logical operations on the state variables according to a preset fault diagnosis model to obtain fault diagnosis results and / or early warning information. The train human-machine interaction unit receives the status parameters and the fault diagnosis results, analyzes them, and displays them visually based on the analysis results. The train data recording unit records and stores the status parameters and the fault diagnosis results.

2. The train communication detection method according to claim 1, characterized in that, The fault diagnosis model includes a univariate fault diagnosis model and a multivariate fault diagnosis model. The univariate fault diagnosis model is configured to compare a single state variable with a corresponding preset normal range threshold. When the state variable exceeds the normal range threshold, it is determined that the fault type corresponding to the state variable is valid. The multivariate fault diagnosis model is configured to perform a comprehensive logical judgment on at least two state variables and compare them with the corresponding preset fault judgment threshold, and determine whether the fault type is valid based on the comparison result.

3. The train communication detection method according to claim 2, characterized in that, The multivariate fault diagnosis model includes a physical layer fault diagnosis sub-model, which is configured as follows: The status parameters are parsed to obtain status variables, which include the number of brief interruptions, port operating mode, and number of CRC errors. Based on the state variables, fault judgment is performed. When the number of interruptions exceeds the preset frequency, the port working mode is abnormal, or the number of CRC errors continues to increase, it is determined that a physical layer fault has occurred and physical layer maintenance warning information is output.

4. The train communication detection method according to claim 2, characterized in that, The multivariate fault diagnosis model includes a network layer fault diagnosis sub-model, which is configured as follows: The state parameters are parsed to obtain state variables, which include the port traffic bandwidth, port packet transmission and reception rate, port multicast packet rate, and port broadcast packet rate of the Ethernet switch. Based on the state variables, fault judgment is performed. When the port traffic bandwidth of the Ethernet switch exceeds a preset bandwidth threshold, the port message transmission and reception rate of the Ethernet switch exceeds a first preset rate, the port multicast message rate of the Ethernet switch exceeds a second preset rate, or the port broadcast message rate of the Ethernet switch exceeds a third preset rate, it is determined that an overload fault has occurred in the network layer and traffic overload warning information is output.

5. The train communication detection method according to claim 2, characterized in that, The multivariate fault diagnosis model includes an Ethernet switch fault diagnosis sub-model, which is configured as follows: The state parameters are parsed to obtain state variables, which include the load rate of the Ethernet switch, the memory usage rate of the Ethernet switch, and the working flag of the Ethernet switch. Based on the state variables, fault judgment is performed. When the load rate of the Ethernet switch exceeds the first threshold and continues for a preset time, the memory usage rate of the Ethernet switch continues to increase, or the working flag bit of the Ethernet switch indicates an abnormal working state, it is determined that the Ethernet switch has a health fault and outputs a hardware warning message to replace the Ethernet switch.

6. The train communication detection method according to claim 1, characterized in that, Ethernet switches also periodically collect status parameters including: The status parameters are encapsulated to obtain physical status messages and transmit / receive data statistics messages. The physical status messages include the load rate of the Ethernet switch, the memory utilization rate of the Ethernet switch, the number of brief outages of the Ethernet switch, and the port operating mode of the Ethernet switch. The transmit / receive data statistics messages include the number of CRC errors of the Ethernet switch, the port traffic bandwidth of the Ethernet switch, the port message transmit / receive rate of the Ethernet switch, the port multicast message rate of the Ethernet switch, and the port broadcast message rate of the Ethernet switch. The physical status message and the transmitted / received data statistics message are sent to the train communication backbone network; The train's central control unit parses the state parameters to obtain state variables, including: The physical status message and the transmitted and received data statistics message are obtained and parsed through the train communication backbone network; The train data recording unit records and stores the status parameters, including: The physical status messages and the transmitted and received data statistics messages are obtained through the train communication backbone network and recorded and stored.

7. The train communication detection method according to claim 6, characterized in that, The Ethernet switch sends the physical status message to the train communication backbone network via the first multicast address; The Ethernet switch sends the transmitted and received data statistics message to the train communication backbone network through the second multicast address; The train human-machine interaction unit obtains the physical status message from the train communication backbone network through the first multicast address and receives and parses the transmit and receive data statistics message from the train communication backbone network through the second multicast address; The train data recording unit obtains the physical status message from the train communication backbone network through the first multicast address and the transmitted and received data statistics message from the train communication backbone network through the second multicast address, and records and stores them.

8. The train communication detection method according to claim 1, characterized in that, Also includes: The train central control unit encapsulates the fault diagnosis results and / or early warning information into a diagnosis result message according to the communication protocol; the train central control unit sends the diagnosis result message to the train communication backbone network; The train human-machine interaction unit obtains and parses the diagnostic result message through the train communication backbone network, and displays the result visually. The train data recording unit obtains, records, and stores the diagnostic result message through the train communication backbone network.

9. The train communication detection method according to claim 8, characterized in that, The train central control unit sends the diagnostic result message to the train communication backbone network via a third multicast address. The train human-machine interaction unit obtains the diagnostic result message from the train communication backbone network through the third multicast address and parses it, and then displays the result visually. The train data recording unit obtains the diagnostic result message from the train communication backbone network through the third multicast address and records and stores it.

10. A train communication detection system, characterized in that, The system for implementing the train communication detection method according to any one of claims 1-9 comprises: Ethernet switches are configured to periodically collect status parameters, including physical layer status parameters, data link layer status parameters, network layer status parameters, and the Ethernet switch's own operating parameters. The train central control unit, connected to the Ethernet switch, is configured to parse the status parameters to obtain status variables, and perform logical operations on the status variables according to a preset fault diagnosis model to obtain fault diagnosis results and / or early warning information. The train human-machine interaction unit, connected to the Ethernet switch and the train central control unit, is configured to receive the status parameters and the fault diagnosis results and parse them, and then perform a visual display based on the parsing results. The train data recording unit, connected to the Ethernet switch and the train central control unit, is configured to record and store the status parameters and the fault diagnosis results.

Images