Vehicle-mounted Ethernet packet capturing device and packet capturing method

Abstract

The invention provides a vehicle-mounted Ethernet packet capture device and a packet capture method, a physical layer of a vehicle-mounted Ethernet is connected with a switch through an RGMII / GMI / RMI / MII data line, the vehicle-mounted Ethernet packet capture device is connected to a bypass of the RGMII / GMI / RMI / MII data line, a data receiving module and a data output module are both connected with a data interface, and the data interface is connected with a data storage module. The data receiving module is used for being connected with an RGMII / GMI / RMI / MII data line and receiving data streams from the vehicle-mounted Ethernet, the high-speed logic circuit module is used for capturing the data streams and executing packet capturing operation, and the data processing and analyzing module is used for analyzing attribute data of the vehicle-mounted Ethernet according to the data streams after packet capturing. And the data output module is used for sending the attribute data of the vehicle-mounted Ethernet to the upper computer. The data information in the vehicle-mounted Ethernet can be conveniently obtained in real time, the packet capturing device is accessed to the vehicle-mounted Ethernet system in a bypass monitoring mode, and transparent data processing is achieved.

Description

Technical Field

[0001] The present invention relates to the field of Ethernet, and particularly to an in-vehicle Ethernet packet sniffer and a packet sniffing method. Background Art

[0002] With the development of automotive intelligence and networking, a large amount of data needs to be transmitted inside the vehicle. The traditional CAN (Controller Area Network) bus, due to its relatively low transmission rate, has become difficult to carry high-speed and large-volume data transmission tasks and cannot meet the requirements of autonomous driving for rapid interaction of massive data. In this context, in-vehicle Ethernet communication, with its advantages of high speed and high bandwidth, has gradually become the core data transmission architecture for future intelligent vehicles.

[0003] Although in-vehicle Ethernet provides strong support for the development of autonomous driving, in the actual application process, how to effectively monitor its data transmission status has become a problem to be solved urgently. Related technologies perform data transmission and conversion between multiple ECUs through a switch and directly capture the data transmitted by the switch as the packet sniffing data. In the face of network anomalies, packet loss, transmission delays, etc., it is difficult to monitor the data of the switch in a timely and accurate manner. Moreover, these devices often have a greater negative impact on the performance of the original in-vehicle network system, introducing a large delay during the packet sniffing process, seriously interfering with the normal operation of the in-vehicle network, and unable to guarantee the strict requirements of the autonomous driving system for data real-time performance. Summary of the Invention

[0004] In view of this, the purpose of the present invention is to provide an in-vehicle Ethernet packet sniffer and a packet sniffing method, which solve the problem that the in-vehicle Ethernet has a large delay during the packet sniffing process in the prior art and cannot achieve timely and accurate monitoring.

[0005] In a first aspect, the present application provides an in-vehicle Ethernet packet sniffer. The physical layer of the in-vehicle Ethernet is connected to the switch through RGMII / GMII / RMII / MII data lines. The in-vehicle Ethernet packet sniffer is connected to the bypass of the RGMII / GMII / RMII / MII data lines. The in-vehicle Ethernet packet sniffer includes a data processing unit and a data interface. The data processing unit includes a high-speed logic circuit module, a data receiving module, a data processing and analysis module, and a data output module. Both the data receiving module and the data output module are connected to the data interface. The data receiving module is used to be connected to the RGMII / GMII / RMII / MII data lines and receive data streams from the in-vehicle Ethernet. The high-speed logic circuit module is used to capture the data streams and perform packet sniffing operations. The data processing and analysis module is used to analyze the attribute data of the in-vehicle Ethernet based on the data streams after packet sniffing. The data output module is used to send the attribute data of the in-vehicle Ethernet to the host computer.

[0006] In one embodiment, the data interface includes an RGMII / GMII / RMII / MII interface. The RGMII / GMII / RMII / MII interface is connected to the RGMII / GMII / RMII / MII data lines. The RGMII / GMII / RMII / MII data lines perform data transmission based on BASE-T1 twisted pairs.

[0007] In one embodiment, the data interface includes an MDC / MDIO interface. The MDC / MDIO interface is connected to the physical layer of the in-vehicle Ethernet. The data processing unit can configure the attribute data of the in-vehicle Ethernet based on the MDC / MDIO interface.

[0008] In one embodiment, the data interface includes an SD interface. The SD interface is used to connect a storage device. The storage device is used to store the attribute data.

[0009] In one embodiment, the data interface includes an RJ45 interface and a USB interface. Both the RJ45 interface and the USB interface are used to connect to the host computer.

[0010] In a second aspect, the present application provides an in-vehicle Ethernet packet sniffing system, including the in-vehicle Ethernet packet sniffer according to any one of claims 1-5, and further including the physical layer of the in-vehicle Ethernet and the switch. The physical layer of the in-vehicle Ethernet is connected to the switch through RGMII / GMII / RMII / MII data lines. The in-vehicle Ethernet packet sniffer is connected to the bypass of the RGMII / GMII / RMII / MII data lines.

[0011] In a third aspect, the present application provides a method for capturing packets in in - vehicle Ethernet, which is executed by the in - vehicle Ethernet packet capture device described in any one of the first aspects or the in - vehicle Ethernet packet capture system described in the second aspect. The method includes:

[0012] Capture the data stream from the in - vehicle Ethernet and perform packet capture operations;

[0013] Analyze the attribute data of the data stream after packet capture according to the Ethernet communication protocol;

[0014] Send the attribute data to the host computer in a direct mapping manner.

[0015] In an embodiment, the analyzing the attribute data of the data stream after packet capture according to the Ethernet communication protocol specifically includes:

[0016] Parse the data stream frame - by - frame and byte - by - byte according to the RGMII\RMII\GMII\RGMII interface timing, extract the key information fields in the data stream, and determine the attribute data according to the key information fields.

[0017] In an embodiment, after analyzing the attribute data of the data stream after packet capture, it further includes:

[0018] Store the attribute data in a storage device according to the reception order corresponding to the attribute data in the data stream.

[0019] In an embodiment, after sending the attribute data to the host computer in a direct mapping manner, it further includes:

[0020] When obtaining the data stream of the in - vehicle Ethernet through the RGMII interface: perform fault detection on the transmission between the physical layer of the in - vehicle Ethernet and the switch according to the enable signals of the falling edge and the rising edge, and CRC cross - check;

[0021] When obtaining the data stream of the in - vehicle Ethernet through the GMII interface: perform fault detection on the transmission between the physical layer of the in - vehicle Ethernet and the switch according to the preset error level signal and clock synchronization anomaly signal;

[0022] When obtaining the data stream of the in - vehicle Ethernet through the RMII interface: perform fault detection on the transmission between the physical layer of the in - vehicle Ethernet and the switch according to the preset level signal and carrier signal;

[0023] When obtaining the data stream of the in - vehicle Ethernet through the MII interface: perform fault detection on the transmission between the physical layer of the in - vehicle Ethernet and the switch according to the preset level signal and collision detection signal.

[0024] In the on-vehicle Ethernet packet sniffer and packet sniffing method according to the embodiments of the present application, different types of data such as RGMII, GMII, RMII, and MII output by the on-vehicle Ethernet physical layer are directly mapped to the host computer through the data interface, enabling convenient and real-time acquisition of data information in the on-vehicle Ethernet, which greatly facilitates engineers to perform real-time monitoring and preliminary analysis of the data. In addition, the packet sniffer is connected to the on-vehicle Ethernet system in the form of bypass monitoring, and only passively receives and analyzes the communication data carried by the level changes between the on-vehicle Ethernet physical layers, without participating in the processes of data generation, forwarding, or modification. Whether it is the format, content of the data frame, or the timing of data transmission, etc., the packet sniffer maintains its original state without any active intervention. In this way, the data transmission of the on-vehicle Ethernet system proceeds normally according to the original communication protocol and process as if the packet sniffer does not exist, thus ensuring that the stability and performance of the entire vehicle network are not affected and realizing transparent data processing. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings required to be used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as limiting the scope. For those of ordinary skill in the art, other related drawings can be obtained based on these drawings without creative efforts.

[0026] Figure 1 It is a schematic diagram of the overall architecture of the on-vehicle Ethernet packet sniffer in the embodiments of the present application.

[0027] Figure 2 It is a schematic diagram of the structure of the on-vehicle Ethernet packet sniffing system in the embodiments of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0028] The specific embodiments of the present invention will be described in detail below with reference to the drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the description of the present invention without creative efforts belong to the scope of protection of the present invention.

[0029] In the description of the present invention, unless otherwise clearly defined and limited, terms such as "set", "installed", "connected", etc. should be understood in a broad sense. For example, it can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be directly connected or indirectly connected through an intermediate medium. For those of ordinary skill in the art, the specific meanings of the above terms can be understood according to specific situations.

[0030] The orientation or positional relationship indicated by terms such as "upper", "lower", "left", "right", "front", "rear", "top", "bottom", "inner", "outer", etc. is based on the orientation or positional relationship shown in the drawings, or the orientation or positional relationship in which the inventive product is customarily placed during use. It is only for the convenience of description and to simplify the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore should not be construed as a limitation on the present invention.

[0031] Terms such as "first", "second", "third", etc. are merely used to distinguish components with similar attributes, rather than indicating or implying relative importance or a specific order.

[0032] The term "comprising", "including" or any other variant thereof is intended to cover non-exclusive inclusion. In addition to the elements listed, it may also include other elements not specifically listed.

[0033] As Figure 1 and Figure 2 shown, the present application provides a vehicle-mounted Ethernet packet sniffer. The physical layer of the vehicle-mounted Ethernet is connected to the switch through RGMII / GMII / RMII / MII data lines. The vehicle-mounted Ethernet packet sniffer is connected to the bypass of the RGMII / GMII / RMII / MII data lines. The vehicle-mounted Ethernet packet sniffer includes a data processing unit and a data interface. The data processing unit includes a high-speed logic circuit module, a data receiving module, a data processing and analysis module, and a data output module. The data receiving module and the data output module are both connected to the data interface. The data receiving module is used to be connected to the RGMII / GMII / RMII / MII data lines and receive the data stream from the vehicle-mounted Ethernet. The high-speed logic circuit module is used to capture the data stream and perform a packet sniffing operation. The data processing and analysis module is used to analyze the attribute data of the vehicle-mounted Ethernet according to the data stream after packet sniffing. The data output module is used to send the attribute data of the vehicle-mounted Ethernet to the host computer.

[0034] In the in-vehicle Ethernet packet sniffer provided by this application, different types of data such as RGMII, GMII, RMII, and MII output by the in-vehicle Ethernet physical layer are directly mapped to the host computer through the data interface, enabling convenient and real-time acquisition of data information in the in-vehicle Ethernet, which greatly facilitates engineers to perform real-time monitoring and preliminary analysis of the data. In addition, the packet sniffer is connected to the in-vehicle Ethernet system in the form of bypass monitoring, only passively receiving and analyzing the communication data carried by the level changes between the in-vehicle Ethernet physical layers, and does not participate in the data generation, forwarding, or modification process. Whether it is the format and content of the data frame or the timing of data transmission, etc., the packet sniffer maintains its original state without any active intervention. In this way, the data transmission of the in-vehicle Ethernet system proceeds normally according to the original communication protocol and process as if the packet sniffer does not exist, thus ensuring that the stability and performance of the entire vehicle network are not affected and realizing transparent data processing.

[0035] In one embodiment, the data interface includes RGMII / GMII / RMII / MII interfaces, and the RGMII / GMII / RMII / MII interfaces are connected to the RGMII / GMII / RMII / MII data lines, and the RGMII / GMII / RMII / MII data lines perform data transmission based on twisted pairs of BASE-T1.

[0036] In this embodiment, RGMII, GMII, RMII, and MII are all interface standards between the Ethernet physical layer and the data link layer. Among them, MII (Media Independent Interface) is an Ethernet interface standard defined by IEEE 802.3. It separates the MAC layer and the physical layer, enabling different physical layer devices (such as twisted pairs, optical fibers, etc.) to communicate with the same MAC layer device. MII provides the ability to transmit Ethernet data at 10 Mbps and 100 Mbps. RMII (Reduced Media Independent Interface) is a simplified version of the MII interface. Its main purpose is to reduce the number of interface pins, lower costs and the complexity of PCB wiring, while still supporting the transmission of Ethernet data at 10 Mbps and 100 Mbps. GMII (Gigabit Media Independent Interface) is used to achieve the transmission of 1000 Mbps Ethernet data. It is an extension of MII, increasing the data bit width and clock frequency, etc., to meet the requirements of high-speed data transmission. RGMII (Reduced Gigabit Media Independent Interface) is a simplified version of GMII. Just as RMII simplifies MII, RGMII reduces the number of pins while maintaining the data transmission capacity of 1000 Mbps.

[0037] Among them, when MII sends data, the MAC layer sends parallel data to the physical layer through the TXD [3:0] pins, and at the same time provides a clock signal through TX_CLK. The physical layer encodes the data according to the clock signal and then sends it to the physical medium. When MII receives data, the physical layer receives data from the physical medium, decodes it, and then sends the parallel data to the MAC layer through the RXD [3:0] pins, and at the same time provides a clock signal through RX_CLK.

[0038] When RMII sends data, the MAC layer sends the data through the TXD [1:0] pins, and TX_EN is used to indicate the validity of the data. The physical layer samples and sends the data at the rising and falling edges of TX_CLK. When RMII receives data, the physical layer sends the data through RXD [1:0], and RX_DV indicates the validity of the data. The MAC layer samples the data at the rising and falling edges of RX_CLK.

[0039] When GMII sends data, the MAC layer sends data and control information to the physical layer through the 8-bit data bus TXD [7:0] and control signals such as TX_EN and TX_ER. Driven by a 125MHz clock, the physical layer encodes the data and sends it to the network medium. When GMII receives data, the physical layer receives data from the network medium, decodes it, and sends the data and status information to the MAC layer through signals such as RXD[7:0].

[0040] When RGMII sends data, the MAC layer sends the upper 4 bits of data on the rising edge of the clock and the lower 4 bits of data on the falling edge, and indicates the data status through the TX_CTL control signal; when RGMII receives data, the physical layer also sends the upper 4 bits and lower 4 bits of data on the rising and falling edges of the clock respectively, and RX_CTL is used to indicate the status of received data.

[0041] The transmission standard of the in-vehicle Ethernet in this embodiment is mainly based on the BASE-T1 twisted pair cable for data transmission, providing more powerful data transmission capabilities for autonomous driving.

[0042] This embodiment uses an FPGA (Field Programmable Gate Array) device and connects it directly to the RGMII (Reduced Gigabit Media Independent Interface) data line of the vehicle Ethernet. With its powerful hardware parallel processing capabilities, FPGA can accurately and quickly acquire data in high-speed data streams, and simultaneously perform real-time processing and packet capture operations. This technology has the remarkable characteristics of fast response, low latency, and high precision, providing a solid technical foundation for achieving efficient packet capture.

[0043] When capturing data, the data stream enters the packet grabber from the vehicle Ethernet interface and flows through the FPGA in an orderly manner. In the FPGA, the data is accurately decoded and deeply analyzed according to the preset protocol. The packet grabber can not only completely obtain all data packets in transmission, but also has the ability to perform preliminary analysis on the content of the data packets, and can keenly capture abnormal data packets and potential network failures, providing strong support for timely discovery and resolution of network problems.

[0044] In addition, this embodiment carefully optimizes the design of the FPGA core to fully guarantee efficient data capture and rapid processing. In the entire data processing process, the FPGA focuses on data capture and simple processing, effectively avoiding the introduction of a large number of complex computing tasks, thereby minimizing the adverse effects of delay on system performance and ensuring that the packet capturer can run stably and efficiently.

[0045] In one embodiment, the data interface includes an MDC / MDIO interface, and the MDC / MDIO interface is connected to the physical layer of the in-vehicle Ethernet. The data processing unit can configure the attribute data of the in-vehicle Ethernet based on the MDC / MDIO interface.

[0046] The MDC / MDIO interface (Management Data Clock / Management Data Input Output) is an interface for the exchange of management and configuration information between an Ethernet physical layer device (PHY) and a data processing unit. The MDC / MDIO interface is defined by the IEEE 802.3 standard, and its main function is to allow a MAC layer device to manage and configure a PHY layer device. MDC is a clock signal that provides a timing reference for data transmission; MDIO is a bidirectional data signal used to transmit data such as configuration commands and status information between the MAC and the PHY.

[0047] During operation, the clock signal (MDC) is a clock signal generated by the master device (FPGA) to provide synchronization for data transmission. Its frequency generally does not exceed 2.5 MHz, and the specific frequency can be set according to system requirements.

[0048] Data transmission (MDIO) is a bidirectional data line used to transmit data between the master device and the slave device. Data transmission uses a frame structure, and a complete transmission frame includes fields such as a preamble, an opcode, a physical device address (PHY address), a register address, and data.

[0049] The master device sends a request to the slave device to configure a command or read status information as needed. The request frame contains information such as the operation type (read or write), the address of the in-vehicle Ethernet, and the register address to be accessed.

[0050] After receiving the request from the master device, the slave device performs corresponding processing according to the operation type. If it is a write operation, the slave device writes the received data into the specified register; if it is a read operation, the slave device returns the data in the specified register to the master device via the MDIO line.

[0051] The FPGA, as the master device, provides a clock through the MDC, sends configuration commands on the MDIO, and receives the status information of the PHY, thereby realizing the configuration of attribute data such as the master-slave mode and rate of the PHY.

[0052] In one embodiment, the data interface includes an SD interface, and the SD interface is used to connect a storage device, and the storage device is used to store the attribute data.

[0053] The SD (Secure Digital) interface is a standard interface commonly used in mobile devices and embedded systems, mainly for connecting SD cards for data storage and transmission. After parsing, the attribute data will be stored orderly in the SD card or other storage devices such as eMMC and NAND Flash. These storage devices have the characteristics of large capacity and high reliability, and can store a large amount of historical data stably for a long time. When it is necessary to trace and analyze the abnormal situations occurring in the in-vehicle Ethernet communication process, technicians can directly read the data from the storage device for offline analysis without relying on the real-time network connection, which greatly improves the efficiency of problem location and solution.

[0054] When transmitting commands, the FPGA sends various commands to the storage device through the SD interface. The command format includes a command index, parameters, and a CRC check code. After receiving the command, the storage device will perform corresponding processing according to the command type and return response information through the SD interface. The FPGA and the storage device can perform data transmission in a single-block or multi-block transmission manner.

[0055] In one embodiment, the data interface includes an RJ45 interface and a USB interface, and both the RJ45 interface and the USB interface are used to connect to the host computer.

[0056] The switch is responsible for data forwarding and switching. Each in-vehicle device (such as a camera, a sensor, a controller, etc.) is connected to the switch through Ethernet. The switch usually supports the port mirroring function, which can copy the traffic of other ports to the port connected to the packet sniffer. After the RJ45 interface of the packet sniffer is connected to a certain port of the host computer, the packet sniffer can obtain the data traffic passing through this port.

[0057] The USB interface is a universal serial bus interface with a high data transmission rate and good compatibility. The packet sniffer transmits the captured data packets to the host computer through the USB interface, and the packet sniffer software running on the host computer can parse, store, and analyze these data packets.

[0058] As Figure 2 shown, based on the above in-vehicle Ethernet packet sniffer, the present application further provides an in-vehicle Ethernet packet sniffing system, including the above in-vehicle Ethernet packet sniffer, and further including the physical layer of the in-vehicle Ethernet and the switch. The physical layer of the in-vehicle Ethernet is connected to the switch through RGMII / GMII / RMII / MII data lines, and the in-vehicle Ethernet packet sniffer is connected to the bypass of the RGMII / GMII / RMII / MII data lines.

[0059] Based on the above vehicle-mounted Ethernet packet sniffer and vehicle-mounted Ethernet packet sniffing system, the present application also provides a vehicle-mounted Ethernet packet sniffing method, which is executed by the above vehicle-mounted Ethernet packet sniffer or vehicle-mounted Ethernet packet sniffing system. The method includes:

[0060] Step S100: Capture the data stream from the vehicle-mounted Ethernet and perform a packet sniffing operation;

[0061] Step S200: Analyze the attribute data of the data stream after packet sniffing according to the Ethernet communication protocol;

[0062] Step S300: Send the attribute data to the host computer in a direct mapping manner.

[0063] In step S100, the data receiving module of the packet sniffer receives the Ethernet data from the PHY chip through the interface protocol, decodes and verifies the data, and identifies the start and end flags of the Ethernet frame, extracts the frame header information (such as MAC address, frame type) and the data part to complete the packet sniffing operation.

[0064] In step S200, the analyzing the attribute data of the data stream after packet sniffing according to the Ethernet communication protocol specifically includes: parsing the data stream frame by frame and byte by byte according to the RGMII\RMII\GMII\RGMII interface timing, extracting the key information fields in the data stream, and determining the attribute data according to the key information fields.

[0065] In this embodiment, before parsing the data stream, frame synchronization is first performed to determine the start position of each frame. An Ethernet frame usually starts with a specific preamble and start frame delimiter (SFD). The preamble is 7 bytes of 8h55, and the frame start delimiter is 8hD5.

[0066] After determining the start position of the frame, the data stream is parsed byte by byte according to the data bit width and clock frequency of the interface. Different interfaces have differences in data transmission, but the basic principle is the same.

[0067] The structure of an Ethernet frame includes the destination MAC address, source MAC address, Ethernet type, data, and frame check sequence (FCS), etc. The key information fields usually include: the destination MAC address (6 bytes, used to indicate the target device of the data frame), the source MAC address (6 bytes, used to indicate the sending device of the data frame), the Ethernet type (2 bytes, used to identify the upper-layer protocol, such as IPv4 (0x0800), ARP (0x0806), etc.), the IP datagram (for example, when the Ethernet type is IPv4, it includes fields such as version, header length, service type, total length, identification, flags, fragment offset, time to live, protocol, header checksum, source IP address, destination IP address, etc.), and the TCP / UDP data segment (for example, when the IP protocol is TCP or UDP, it includes fields such as source port number, destination port number, sequence number, acknowledgment number, etc.).

[0068] Based on the extracted key information fields, various attribute data of the data stream can be determined, such as: device information of both communication parties (determining the sending and receiving devices through the MAC address and IP address), upper-layer protocol type (determining the upper-layer protocol used by the data based on the Ethernet type and IP protocol fields), data transmission status (such as the establishment, disconnection, data transmission, etc. status of the TCP connection), and other attribute data.

[0069] In step S300, the attribute data is sent to the host computer in a direct mapping manner.

[0070] In this embodiment, the FPGA can directly map different types of data such as RGMII, GMII, RMII, and MII output by the PHY (physical layer chip) of in-vehicle Ethernet to the RJ45 port. Through this direct connection mapping method, the host computer port only needs to access this RJ45 port to conveniently and real-time obtain the data information in the in-vehicle Ethernet, which greatly facilitates engineers to perform real-time monitoring and preliminary analysis of the data.

[0071] In one embodiment, after analyzing the attribute data of the data stream after packet capture, it further includes: storing the attribute data in a storage device according to the receiving order of the attribute data in the data stream.

[0072] Taking an SD card as a storage device as an example, before writing data to the SD card, a buffer is required to temporarily store the parsed data. To balance the difference between the data parsing speed and the SD card writing speed, the FIFO (First In First Out) buffer inside the FPGA or the memory buffer in the embedded system can be used. Before data storage, the SD card needs to be initialized, including sending initialization commands, setting the working mode (such as SPI mode or SD mode), etc. According to the order of receiving the attribute data, the data in the buffer is written into the SD card block by block according to the size of the data block and the read / write timing of the SD card.

[0073] When it is necessary to trace and analyze the abnormal situations that occur during in-vehicle Ethernet communication, technicians can directly read the data from the storage device for offline analysis without relying on the real-time network connection, which greatly improves the efficiency of problem location and solution.

[0074] In one embodiment, after sending the attribute data to the host computer in a direct mapping manner, it further includes: when obtaining the data stream of in-vehicle Ethernet through the RGMII interface: performing fault detection on the transmission between the physical layer of the in-vehicle Ethernet and the switch according to the enable signals of the falling edge and the rising edge, and CRC cross-check; when obtaining the data stream of in-vehicle Ethernet through the GMII interface: performing fault detection on the transmission between the physical layer of the in-vehicle Ethernet and the switch according to the preset error level signal and the clock synchronization anomaly signal; when obtaining the data stream of in-vehicle Ethernet through the RMII interface: performing fault detection on the transmission between the physical layer of the in-vehicle Ethernet and the switch according to the preset level signal and the carrier signal; when obtaining the data stream of in-vehicle Ethernet through the MII interface: performing fault detection on the transmission between the physical layer of the in-vehicle Ethernet and the switch according to the preset level signal and the collision detection signal.

[0075] Specifically, during fault diagnosis, the status and fault information of the current PHY can be obtained through the MDIO interface on the in-vehicle Ethernet PHY.

[0076] The ways of representing the transmission fault information by RGMII, GMII, RMII, and MII are as follows:

[0077] When obtaining the data stream of in-vehicle Ethernet through the RGMII interface, fault diagnosis can be performed through the control signal 2 and data cross-check:

[0078] If through control signal 2: In the RGMII interface, the ETH_TXCTL and ETH_RXCTL control signals are transmitted in DDR mode. The data enable signals for transmission / reception (TX_EN / RX_DV) are sent on the rising edge, and the exclusive OR values of the transmission / reception enable signal and the error signal (TX_ERR xor TX_EN, RX_ERR xor RX_DV) are sent on the falling edge. When the exclusive OR value received on the falling edge is abnormal, or the enable signal on the rising edge is continuously invalid, etc., it may indicate a possible transmission failure.

[0079] If through data verification: During data transmission, if the CRC verification fails, or the received data does not conform to the normal data format and encoding rules, it also means that a transmission failure has occurred.

[0080] When obtaining the data stream of in-vehicle Ethernet through the GMII interface, fault diagnosis can be carried out through dedicated error signal 1 and clock synchronization problems:

[0081] If through dedicated error signal 1: The GMII interface has TX_ER (transmitter error) and RX_ER (receiver error) signals. When TX_ER is at a high level, it indicates that an error has occurred in the transmitter, and there may be a problem with the data packet being transmitted; when RX_ER is at a high level, it means that there is an error in the received data and the received data is invalid.

[0082] If through clock synchronization problems: If GTXCLK (gigabit transmit clock) or RXCLK (receive clock) is unstable, has an abnormal frequency, or the synchronization relationship between the data and the clock signal is disordered, it may cause data transmission errors and can also be regarded as a transmission failure.

[0083] When obtaining the data stream of in-vehicle Ethernet through the RMII interface, fault diagnosis can be carried out through the RX_ER signal and the CRS_DV signal:

[0084] If through the RX_ER signal: When the RX_ER signal in the RMII interface is at a high level, it indicates a data reception error, that is, a failure has occurred in the physical layer chip reception, and the receiving end should not accept the data.

[0085] If through the CRS_DV signal: Under normal circumstances, the CRS_DV signal will change correspondingly during data transmission. If its change does not meet the expectations, such as when the carrier disappears but there is still data to be transmitted and there is no normal switch, or the signal is always in an invalid state, etc., it may indicate a transmission failure.

[0086] When obtaining the data stream of in-vehicle Ethernet through the MII interface, fault diagnosis can be performed through the TX_ER and RX_ER signals and the collision detection signal COL:

[0087] TX_ER and RX_ER signals: When the TX_ER of the MII interface is at a high level, it indicates that the data transmitted within the TX_ER validity period is invalid; when the RX_ER is at a high level, it means that the data received within the RX_ER validity period is invalid. These are the most direct signals indicating transmission faults.

[0088] Collision detection signal COL: In half-duplex mode, when a data collision occurs, the COL signal becomes valid. If collisions occur frequently, or if the COL signal is valid when it should not be, it indicates a transmission fault.

[0089] In summary, in the in-vehicle Ethernet packet sniffer and packet sniffing method of this embodiment, the following advantages are achieved:

[0090] 1. Low-latency packet sniffing: Relying on the dual advantages of FPGA technology and back-to-back design, the packet sniffer can achieve real-time and accurate capture of in-vehicle Ethernet data with almost no additional latency, meeting the stringent requirements of autonomous driving for data timeliness.

[0091] 2. High compatibility: There is no need to perform complex modifications or adjustments to the existing in-vehicle Ethernet communication system, and it can be quickly and conveniently integrated into the existing system and put into use, greatly reducing the application cost and implementation difficulty.

[0092] 3. Efficient data monitoring: It can comprehensively and real-time monitor the communication status of in-vehicle Ethernet, timely capture problems such as packet loss and latency, and generate detailed and intuitive reports, providing great convenience for network maintenance and development work.

[0093] 4. Simplified design: Adopting a simple and efficient back-to-back design scheme, it cleverly avoids complex intermediate data processing links, making the system architecture more concise and clear, and significantly improving stability and reliability.

[0094] The in-vehicle Ethernet packet sniffer and packet sniffing method of this embodiment are applicable to all vehicles using in-vehicle Ethernet for communication, especially autonomous driving and intelligent connected vehicles. In an autonomous driving system, vehicles need to exchange data frequently and in large quantities. This packet sniffer can provide crucial support for the network maintenance and fault detection of the autonomous driving system, contributing to the safe and stable development of autonomous driving technology.

[0095] It should be noted that the various embodiments in this specification are described in a progressive manner. Each embodiment focuses on the differences from other embodiments. For the same or similar parts among the various embodiments, reference can be made to each other.

[0096] As described above, the above are only specific embodiments of the present invention, but the protection scope of the present invention is not limited thereto. Any changes or substitutions that can be easily thought of by those skilled in the art within the technical scope disclosed by the present invention should be covered by the protection scope of the present invention. Therefore, the protection scope of the present invention should be subject to the appended claims.

Claims

1. A vehicle-mounted Ethernet packet capture device, characterized in that: The physical layer of the vehicle-mounted Ethernet is connected to the switch through an RGMII / GMII / RMII / MII data line, and the vehicle-mounted Ethernet packet grabber is connected to the bypass of the RGMII / GMII / RMII / MII data line. The vehicle-mounted Ethernet packet grabber includes a data processing unit and a data interface. The data processing unit includes a high-speed logic circuit module, a data receiving module, a data processing and analysis module, and a data output module. The data receiving module and the data output module are both connected to the data interface. The data receiving module is used to be connected to the RGMII / GMII / RMII / MII data line and receive a data stream from the vehicle-mounted Ethernet. The high-speed logic circuit module is used to capture the data stream and perform a packet capture operation. The data processing and analysis module is used to analyze the attribute data of the vehicle-mounted Ethernet according to the data stream after packet capture. The data output module is used to send the attribute data of the vehicle-mounted Ethernet to a host computer.

2. The vehicle-mounted Ethernet packet capture device according to claim 1, characterized in that: The data interface includes an RGMII / GMII / RMII / MII interface, and the RGMII / GMII / RMII / MII interface is connected to the RGMII / GMII / RMII / MII data line, and the RGMII / GMII / RMII / MII data line performs data transmission based on a BASE-T1 twisted pair.

3. The vehicle-mounted Ethernet packet grabber according to claim 1, characterized in that: The data interface includes an MDC / MDIO interface, the MDC / MDIO interface is connected to the physical layer of the in-vehicle Ethernet, and the data processing unit can configure the attribute data of the in-vehicle Ethernet based on the MDC / MDIO interface.

4. The vehicle-mounted Ethernet packet capture device according to claim 1, characterized in that: The data interface includes an SD interface, and the SD interface is used to connect a storage device, and the storage device is used to store the attribute data.

5. The vehicle-mounted Ethernet packet grabber according to claim 1, characterized in that: The data interface includes an RJ45 interface and a USB interface, and both the RJ45 interface and the USB interface are used to connect to the host computer.

6. A vehicle-mounted Ethernet packet capture system, characterized in that: The vehicle-mounted Ethernet packet grabber comprises the vehicle-mounted Ethernet packet grabber according to any one of claims 1 to 5, and further comprises a physical layer of the vehicle-mounted Ethernet and the switch, wherein the physical layer of the vehicle-mounted Ethernet is connected to the switch via an RGMII / GMII / RMII / MII data line, and the vehicle-mounted Ethernet packet grabber is connected to a bypass of the RGMII / GMII / RMII / MII data line.

7. A vehicle Ethernet packet capture method, performed by the vehicle Ethernet packet capture device according to any one of claims 1 to 5 or the vehicle Ethernet packet capture system according to claim 6, characterized in that: The method comprises: Capture data streams from in-vehicle Ethernet and perform packet capture operations; According to the Ethernet communication protocol, analyze the attribute data of the data stream after packet capture; The attribute data is sent to the host computer in a direct mapping manner.

8. The vehicle-mounted Ethernet packet capture method according to claim 7, characterized in that: The analysis of the attribute data of the data stream after packet capture according to the Ethernet communication protocol specifically includes: According to the RGMII\RMII\GMII\RGMII interface timing, the data stream is parsed frame by frame and byte by byte, key information fields in the data stream are extracted, and the attribute data is determined according to the key information fields.

9. The vehicle-mounted Ethernet packet capture method according to claim 7, characterized in that: After analyzing the attribute data of the captured data stream, it also includes: The attribute data is stored in a storage device according to a receiving order corresponding to the attribute data in the data stream.

10. The vehicle-mounted Ethernet packet capture method according to claim 7, characterized in that: After the attribute data is sent to the host computer in a direct mapping manner, the method further includes: When the data stream of the vehicle Ethernet is obtained through the RGMII interface: according to the enable signal of the falling edge and the rising edge, and the CRC check, the transmission between the physical layer of the vehicle Ethernet and the switch is detected for faults; When the data stream of the vehicle Ethernet is obtained through the GMII interface: according to the preset error level signal and the clock synchronization abnormality signal, a fault detection is performed on the transmission between the physical layer of the vehicle Ethernet and the switch; When the data stream of the vehicle Ethernet is obtained through the RMII interface: performing fault detection on the transmission between the physical layer of the vehicle Ethernet and the switch according to a preset level signal and a carrier signal; When the data stream of the vehicle Ethernet is obtained through the MII interface: a fault detection is performed on the transmission between the physical layer of the vehicle Ethernet and the switch according to a preset level signal and a conflict detection signal.

Images