Message processing method, device and electronic equipment for vehicle-mounted Ethernet

Abstract

The present application provides a method, device, electronic device, computer-readable storage medium, and computer program product for message processing in an in-vehicle Ethernet network. The method comprises: obtaining a service matrix file of the vehicle in which the in-vehicle Ethernet network is located, and determining a network card device identifier in a configuration parameter based on the network card device identifier in the service matrix file, and generating a filtering condition in the configuration parameter based on the network address in the service matrix file; determining a target network card device corresponding to the network card device identifier in the configuration parameter in the in-vehicle Ethernet network, and performing message capture processing on the message transmitted by the target network card device based on the filtering condition in the configuration parameter to obtain the original message; performing message parsing processing on the original message at each protocol layer to obtain a parsed message; and performing format conversion processing on the parsed message to obtain target data that conforms to the application layer protocol. Through the present application, configuration parameters can be automatically constructed based on the vehicle's service matrix file, thereby realizing automated message processing.

Description

Technical Field

[0001] The present application relates to vehicle technology, and in particular to a message processing method, device, electronic device, computer-readable storage medium, and computer program product for an in-vehicle Ethernet. Background Art

[0002] In today's Internet of Vehicles era, vehicle-side service functions are becoming increasingly rich, such as the gradual rise of Advanced Driver Assistance System (ADAS), autonomous driving, Over-The-Air (OTA), personalized services, etc. This has led to the traditional communication methods, such as Controller Area Network (CAN), Local Interconnect Network (LIN) and other bus methods, being unable to meet the current vehicle function requirements.

[0003] With the advancement of vehicle electronics, in-vehicle Ethernet-based communication has become mainstream, bringing with it the need to collect and analyze packets in these networks. Solutions offered by related technologies typically utilize readily available packet collection and analysis tools (such as Wireshark and TCPDump). However, these tools require manual configuration of the relevant conditions for capturing packets, making the operation relatively cumbersome. Summary of the Invention

[0004] The present application provides a method, device, electronic device, computer-readable storage medium and computer program product for message processing of an in-vehicle Ethernet, which can automatically construct configuration parameters according to the vehicle's service matrix file to realize automated message processing.

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

[0006] The present application provides a method for processing messages in an in-vehicle Ethernet network, comprising:

[0007] Obtain a service matrix file of the vehicle where the in-vehicle Ethernet is located, determine the network card device identifier in the configuration parameters according to the network card device identifier in the service matrix file, and generate a filtering condition in the configuration parameters according to the network address in the service matrix file;

[0008] Determining, in the in-vehicle Ethernet, a target network card device corresponding to the network card device identifier in the configuration parameters, and performing message capture processing on messages transmitted by the target network card device according to the filtering conditions in the configuration parameters to obtain original messages;

[0009] Performing message parsing of each protocol layer on the original message to obtain a parsed message;

[0010] The parsed message is format-converted to obtain target data that complies with the application layer protocol.

[0011] The present application provides a message processing device for an in-vehicle Ethernet, comprising:

[0012] a configuration generation module, configured to obtain a service matrix file of the vehicle where the vehicle-mounted Ethernet is located, determine the network card device identifier in the configuration parameters according to the network card device identifier in the service matrix file, and generate a filtering condition in the configuration parameters according to the network address in the service matrix file;

[0013] a message capture module, configured to determine, in the in-vehicle Ethernet, a target network card device corresponding to the network card device identifier in the configuration parameters, and to capture and process messages transmitted by the target network card device according to the filtering conditions in the configuration parameters to obtain original messages;

[0014] A message parsing module, configured to perform message parsing processing on each protocol layer of the original message to obtain a parsed message;

[0015] The data generation module is used to perform format conversion processing on the parsed message to obtain target data that complies with the application layer protocol.

[0016] The present application provides an electronic device, including:

[0017] a memory for storing executable instructions;

[0018] The processor is used to implement the message processing method of the in-vehicle Ethernet provided by the present application when executing the executable instructions stored in the memory.

[0019] The present application provides a computer-readable storage medium storing executable instructions for causing a processor to execute instructions to implement the vehicle Ethernet message processing method provided in the present application.

[0020] The present application provides a computer program product, which includes executable instructions for causing a processor to execute instructions to implement the vehicle Ethernet message processing method provided in the present application.

[0021] This application has the following beneficial effects:

[0022] The present application obtains the service matrix file of the vehicle where the on-board Ethernet is located, and determines the network card device identifier in the configuration parameters according to the network card device identifier in the service matrix file, and generates the filtering conditions in the configuration parameters according to the network address in the service matrix file; determines the target network card device corresponding to the network card device identifier in the configuration parameters in the on-board Ethernet, and performs message capture processing on the message transmitted by the target network card device according to the filtering conditions in the configuration parameters to obtain the original message; performs message parsing processing on the original message at each protocol layer to obtain the parsed message; performs format conversion processing on the parsed message to obtain the target data that conforms to the application layer protocol. In summary, the present application can automatically construct the configuration parameters according to the service matrix file of the vehicle without manual construction; can accurately locate the target network card device according to the network card device identifier in the configuration parameters, and can accurately capture the original message that meets the requirements according to the filtering conditions in the configuration parameters; and finally obtains the target data that conforms to the application layer protocol, which is helpful for secondary utilization and analysis. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For those skilled in the art, other drawings can be obtained based on these drawings without creative work.

[0024] Figure 1 This is a schematic diagram of the architecture of the in-vehicle Ethernet message processing system provided by an embodiment of the present application;

[0025] Figure 2 This is a structural diagram of the vehicle-mounted device provided in an embodiment of the present application;

[0026] Figure 3A This is a schematic diagram of a first flow chart of a method for processing messages in an in-vehicle Ethernet according to an embodiment of the present application;

[0027] Figure 3B This is a second flow chart of the message processing method of the in-vehicle Ethernet provided by an embodiment of the present application;

[0028] Figure 4 This is a third flow chart of the message processing method for in-vehicle Ethernet provided by an embodiment of the present application;

[0029] Figure 5 This is a schematic diagram of a process for shard reorganization provided by an embodiment of the present application;

[0030] Figure 6 This is a flow chart of the segmented reorganization provided in an embodiment of the present application. DETAILED DESCRIPTION

[0031] In order to make the purpose, technical solutions and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limiting this application. All other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0032] In the following description, references to "some embodiments" describe a subset of all possible embodiments. However, it is understood that "some embodiments" may be the same subset or different subsets of all possible embodiments, and may be combined with each other without conflict. In the following description, the term "plurality" refers to at least two.

[0033] In the following description, the terms "first\second\third" involved are merely used to distinguish similar objects and do not represent a specific ordering of the objects. It can be understood that "first\second\third" can be interchanged with a specific order or sequence where permitted, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0034] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which this application pertains. The terms used herein are for the purpose of describing the embodiments of this application only and are not intended to limit this application.

[0035] Faced with the need to collect and analyze messages in automotive Ethernet, related technologies mainly provide the following solutions:

[0036] 1) Packet Capture Library (libpcap). The Packet Capture Library, abbreviated as libpcap, provides a C function interface for capturing packets from a specified network card device. However, libpcap has issues such as requiring manual construction of packet capture conditions, inability to parse packets, and inability to reassemble fragments and segments. PcapPlusPlus, developed based on libpcap, can implement packet parsing, but because it constructs packets in a specified data format when capturing them, the complexity of the data format causes CPU usage to be over 10 times higher when using PcapPlusPlus than when using libpcap alone.

[0037] 2) Packet collection and analysis tools developed based on libpcap (such as Wireshark and TCPDump). When using packet collection and analysis tools, you need to manually construct the relevant conditions for capturing packets. Since the conditions are often complex, manual construction is difficult. In addition, the captured packets must be saved as files in the format specified by the packet collection and analysis tool. They can only be viewed through the packet collection and analysis tool and cannot be reused or analyzed.

[0038] 3) Automotive Ethernet protocol stack tracking. Specifically, the automotive Ethernet protocol stack is tracked, storing its messages in a central communication node. A data request application is then built to communicate with the central node to retrieve the stored messages. This solution requires an open-source protocol stack, but most current protocol stacks are black boxes, making this solution unfeasible.

[0039] The embodiments of the present application provide a message processing method, device, electronic device, computer-readable storage medium and computer program product for an in-vehicle Ethernet, which can automatically construct configuration parameters based on the vehicle's service matrix file to realize automated message processing; for the black box protocol stack, messages can be captured by packet capture; fragmentation and segmentation reassembly functions can be realized; target data of the application layer protocol can be output and stored in memory or hard disk, which is conducive to secondary utilization and analysis.

[0040] The following describes exemplary applications of the electronic device provided in the embodiments of the present application. The electronic device provided in the embodiments of the present application can be implemented as a vehicle-mounted device or as a server.

[0041] See also Figure 1 , Figure 1 This is an architectural diagram of the message processing system 100 of the in-vehicle Ethernet provided in an embodiment of the present application. The in-vehicle device 400 is connected to the server 200 via the network 300, wherein the network 300 can be a wide area network or a local area network, or a combination of the two.

[0042] In some embodiments, taking the electronic device as an in-vehicle device as an example, the in-vehicle Ethernet message processing method provided in the embodiments of the present application can be implemented by the in-vehicle device. For example, the in-vehicle device 400 obtains the service matrix file of the vehicle in which it is located, determines the network card device identifier in the configuration parameters based on the network card device identifier in the service matrix file, and generates the filtering conditions in the configuration parameters based on the network address in the service matrix file; determines the target network card device corresponding to the network card device identifier in the configuration parameters in the in-vehicle Ethernet, and performs message capture processing on the message transmitted by the target network card device according to the filtering conditions in the configuration parameters to obtain the original message; performs message parsing processing on the original message at each protocol layer to obtain a parsed message; and performs format conversion processing on the parsed message to obtain target data that conforms to the application layer protocol.

[0043] In some embodiments, the message processing method for the in-vehicle Ethernet provided in the embodiments of the present application can be implemented collaboratively by an in-vehicle device and a server. For example, the server 200 can obtain the service matrix file of the vehicle where the in-vehicle device 400 is located, generate configuration parameters based on the service matrix file, and send the configuration parameters to the in-vehicle device 400, so that the in-vehicle device 400 performs message capture processing on the target network card device in the in-vehicle Ethernet of the vehicle according to the configuration parameters to obtain the original message. For another example, the in-vehicle device 400 can send the original message to the server 200, so that the server 200 performs message parsing processing on the original message at each protocol layer to obtain a parsed message, and performs format conversion processing on the parsed message to obtain target data that conforms to the application layer protocol. For another example, the in-vehicle device 400 can perform message parsing processing on the original message at each protocol layer to obtain a parsed message, and performs format conversion processing on the parsed message to obtain target data that conforms to the application layer protocol, and then sends the target data to the server 200 for storage.

[0044] In some embodiments, an electronic device can implement the in-vehicle Ethernet message processing method provided by the embodiments of the present application by running a computer program. For example, the computer program can be a native program or software module in the operating system; it can be a native application (APP), that is, a program that needs to be installed in the operating system to run; it can also be a small program, that is, a program that can be run by simply downloading it into a browser environment; it can also be a small program that can be embedded in any APP, and the small program can be controlled to run or closed by the user. In short, the above-mentioned computer program can be any form of application, module or plug-in.

[0045] Taking the electronic device provided in the embodiment of the present application as an example, which is a vehicle-mounted device, it can be understood that, for the case where the electronic device is a server, Figure 2Parts of the structure shown in FIG (such as the user interface, the presentation module, and the input processing module) may be omitted. Figure 2 , Figure 2 is a structural diagram of the vehicle-mounted device 400 provided in an embodiment of the present application, Figure 2 The vehicle-mounted device 400 shown includes: at least one processor 410, a memory 450, at least one network interface 420, and a user interface 430. The various components in the vehicle-mounted device 400 are coupled together via a bus system 440. It is understood that the bus system 440 is used to achieve connection and communication between these components. In addition to including a data bus, the bus system 440 also includes a power bus, a control bus, and a status signal bus. However, for the sake of clarity, the bus system 440 is not shown in FIG. Figure 2 Various buses are labeled as bus system 440 .

[0046] The processor 410 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc., where the general-purpose processor can be a microprocessor or any conventional processor, etc.

[0047] The user interface 430 includes one or more output devices 431 that enable presentation of media content, including one or more speakers and / or one or more visual display screens. The user interface 430 also includes one or more input devices 432, including user interface components that facilitate user input, such as a keyboard, mouse, microphone, touch screen display, camera, other input buttons and controls.

[0048] The memory 450 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state memory, hard drives, optical drives, etc. The memory 450 may optionally include one or more storage devices that are physically remote from the processor 410.

[0049] The memory 450 includes volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory may be a read-only memory (ROM), and the volatile memory may be a random access memory (RAM). The memory 450 described in the embodiments of the present application is intended to include any suitable type of memory.

[0050] In some embodiments, the memory 450 can store data to support various operations, examples of which include programs, modules, and data structures, or a subset or superset thereof, as exemplified below.

[0051] Operating system 451, including system programs for processing various basic system services and performing hardware-related tasks, such as the framework layer, core library layer, and driver layer, which are used to implement various basic services and process hardware-based tasks;

[0052] A network communication module 452 is used to reach other electronic devices via one or more (wired or wireless) network interfaces 420. Exemplary network interfaces 420 include Bluetooth, Wi-Fi, and Universal Serial Bus (USB).

[0053] a presentation module 453 for enabling presentation of information via one or more output devices 431 (e.g., a display screen, a speaker, etc.) associated with the user interface 430 (e.g., a user interface for operating peripheral devices and displaying content and information);

[0054] The input processing module 454 is configured to detect one or more user inputs or interactions from one of the one or more input devices 432 and to translate the detected inputs or interactions.

[0055] In some embodiments, the vehicle-mounted Ethernet message processing device provided in the embodiments of the present application can be implemented in software. Figure 2 The diagram shows an in-vehicle Ethernet message processing device 455 stored in memory 450. This device can be software in the form of a program or plug-in, and includes the following software modules: a configuration generation module 4551, a message capture module 4552, a message parsing module 4553, and a data generation module 4554. These modules are logical and can be arbitrarily combined or further separated based on the functions they implement. The functions of each module are described below.

[0056] The message processing method of the in-vehicle Ethernet provided by the embodiment of the present application will be explained in combination with the exemplary application and implementation of the electronic device provided by the embodiment of the present application.

[0057] See also Figure 3A , Figure 3A This is a flow chart of a method for processing messages in vehicle Ethernet provided by an embodiment of the present application, which will be combined with Figure 3A The steps shown are explained.

[0058] In step 101, a service matrix file of the vehicle where the vehicle-mounted Ethernet is located is obtained, and the network card device identifier in the configuration parameters is determined according to the network card device identifier in the service matrix file, and the filtering conditions in the configuration parameters are generated according to the network address in the service matrix file.

[0059] Here, the service matrix file for the vehicle in which the in-vehicle Ethernet is located is obtained. The service matrix file is used to describe and define the interactions, interface definitions, and inter-service dependencies between various services in the vehicle, thereby ensuring that the various services in the vehicle system can communicate and collaborate in a predetermined manner. Service matrix files are typically designed by relevant personnel based on the vehicle model, with different service matrix files corresponding to different vehicle models. Therefore, in this embodiment of the present application, a pre-designed service matrix file can be obtained based on the vehicle model in which the in-vehicle Ethernet is located.

[0060] The service matrix file includes relevant information related to message transmission in the automotive Ethernet. Therefore, configuration parameters can be generated based on the service matrix file. The configuration parameters include relevant conditions for implementing message processing.

[0061] For example, read the network card device identifier in the service matrix file, and determine the network card device identifier in the configuration parameters based on the network card device identifier in the service matrix file. For example, the network card device identifier in the service matrix file can be directly determined as the network card device identifier in the configuration parameters.

[0062] At the same time, read the network address in the service matrix file. Wherein, the network address can include an IP address (the local IP address, where the local machine can be a client / server), and can also include a port number. Then, the filter condition in the configuration parameter is generated according to the network address in the service matrix file, wherein the filter condition is a regular condition used for message capture processing. Taking the network address in the service matrix file as an example, the network address includes an IP address ipi and a port number portj, and the template of the filter condition is (host IP address and port number), the filter condition generated is (host ipi and portj). Through the above method, the automatic construction of the filter condition can be realized without the need for manual construction.

[0063] In some embodiments, the above-mentioned determination of the network card device identifier in the configuration parameter according to the network card device identifier in the service matrix file can be implemented in the following manner: when the number of the network card device identifier in the service matrix file is one, the network card device identifier in the service matrix file is determined as the network card device identifier in the configuration parameter; when the number of the network card device identifier in the service matrix file includes multiple network card device identifiers, the network card device identifier in the configuration parameter is determined as any network card device identifier;

[0064] Here, when the number of network card device identifiers in the service matrix file is one, it proves that only one network card device needs to be captured and processed, so the network card device identifier in the service matrix file is determined as the network card device identifier in the configuration parameters; when the number of network card device identifiers in the service matrix file includes multiple, the network card device identifier in the configuration parameters is determined as any network card device identifier (any), and any network card device identifier corresponds to any network card device. In this way, all network traffic can be captured without specifying a specific interface, ensuring that no possible message will be missed.

[0065] In step 102 , a target network card device corresponding to the network card device identifier in the configuration parameters is determined in the in-vehicle Ethernet, and messages transmitted by the target network card device are captured and processed according to the filtering conditions in the configuration parameters to obtain original messages.

[0066] Here, the target network card device corresponding to the network card device identifier in the configuration parameter is determined among the network card devices included in the vehicle Ethernet. If the network card device identifier in the configuration parameter is any network card device identifier, the target network card device is any network card device (i.e., all network card devices).

[0067] After the target network card device has been located, the packets transmitted by the target network card device are captured and processed according to the filtering conditions in the configuration parameters. That is, only the packets that meet the filtering conditions are captured from the packets transmitted by the target network card device. For the sake of convenience, the captured packets are called original packets.

[0068] In some embodiments, the network card device identifier in the configuration parameters is any network card device identifier, and the number of original messages includes multiple; the messages transmitted by the target network card device are captured and processed according to the filtering conditions in the configuration parameters, and after the original messages are obtained, the message processing method of the in-vehicle Ethernet also includes: determining the original message with a virtual local area network VLAN tag among multiple original messages; and discarding the original message with the VLAN tag.

[0069] Here, when the network card device identifier in the configuration parameters is any network card device identifier, the target network card device is any network card device, and the message capture probe may exist in the network card device and the kernel. Based on this, for the message receiving scenario, when a message with a virtual local area network (VLAN) tag enters the network card device, it is captured at the network card device, and then the kernel removes the VLAN tag when processing the message, and the message with the VLAN tag removed is captured again at the kernel; for the message sending scenario, when the message is sent at the kernel, it does not carry a VLAN tag. At this time, the message without a VLAN tag will be captured once at the kernel, and then, when the message without a VLAN tag passes through the network card device, a VLAN tag needs to be added, and the message with a VLAN tag will be captured again at the network card device. Therefore, whether it is a message receiving scenario or a message sending scenario, the same two messages will be captured, one with a VLAN tag and the other without a VLAN tag.

[0070] Therefore, after obtaining multiple original messages through message capture, the original messages with VLAN tags are identified among the multiple original messages and discarded. That is, only the original messages without VLAN tags are subsequently parsed at each protocol layer. This method can achieve message deduplication and avoid the waste of resources caused by subsequent processing of duplicate messages.

[0071] In step 103, the original message is parsed at each protocol layer to obtain a parsed message.

[0072] Here, we will explain the automotive Ethernet protocol stack. The automotive Ethernet protocol stack refers to a set of protocols designed to enable efficient communication between electronic components within a vehicle in an automotive Ethernet environment. The automotive Ethernet protocol stack adheres to specific network models, such as the Open System Interconnect (OSI) model or a simplified Transmission Control Protocol / Internet Protocol (TCP / IP) model. Furthermore, the automotive Ethernet protocol stack is organized in a strict hierarchical structure, with each layer responsible for different communication tasks.

[0073] For example, the automotive Ethernet protocol stack may include the following layers: 1) Physical layer: responsible for handling the physical transmission of Ethernet signals, including signal encoding, decoding, clock synchronization, etc.; 2) Data link layer: defines how data is transmitted on a single link; 3) Network layer: responsible for routing and forwarding data to ensure that data reaches its destination correctly. In the automotive Ethernet protocol stack, network layer protocols (such as IPv4 or IPv6) are used to allocate and manage the vehicle's Internet Protocol (IP) address to achieve interconnection between the vehicle's internal networks; 4) Transport layer: provides reliable end-to-end communication services to ensure the integrity and reliability of data during transmission. Transport layer protocols include Transmission Control Protocol (TCP) and User Datagram Protocol (UDP); 5) Application layer: user-oriented end applications, defines various specific communication protocols and services, such as Scalable Service-Oriented Middleware over IP (SOME / IP) protocol and Diagnostic Communication over Internet Protocol (DoIP).

[0074] Taking the above-mentioned automotive Ethernet protocol stack as an example, the original message obtained through message capture processing is obtained by encapsulating the application layer message through the transport layer, network layer, and data link layer in sequence. Therefore, the original message is subjected to message parsing processing at each protocol layer in the reverse order of encapsulation, that is, data link layer parsing processing, network layer parsing processing, and transport layer parsing processing in sequence. In the embodiment of the present application, the result of the message parsing processing is described by the parsed message, that is, the parsed message is used to describe the specific data of the original message at each protocol layer.

[0075] In step 104, the parsed message is format-converted to obtain target data that complies with the application layer protocol.

[0076] Here, the parsed message is formatted and converted to target data that conforms to the application layer protocol in the automotive Ethernet protocol stack. Since this target data conforms to the application layer protocol, it can be used by other applications, facilitating secondary utilization and analysis. For example, using the SOME / IP application layer protocol as an example, this target data can contribute to other SOME / IP tasks and tool development, such as SOME / IP anomaly detection, troubleshooting, data analysis, and statistics.

[0077] In some embodiments, after converting the parsed message format to obtain target data that complies with the application layer protocol, the in-vehicle Ethernet message processing method further includes storing the target data. For example, the target data may be stored in memory or on a disk, or may be stored on a server for access when needed.

[0078] In some embodiments, the network address in the service matrix file includes the local IP address; after obtaining the service matrix file of the vehicle where the on-board Ethernet is located, the message processing method of the on-board Ethernet also includes: determining the local IP address in the configuration parameters based on the local IP address in the service matrix file; when the parsed message is format converted to obtain target data that complies with the application layer protocol, the message processing method of the on-board Ethernet also includes: when the source IP address in the target data successfully matches the local IP address in the configuration parameters, the on-board Ethernet is set as the sending end in the target data; when the destination IP address in the target data successfully matches the local IP address in the configuration parameters, the on-board Ethernet is set as the receiving end in the target data.

[0079] Here, the network address in the service matrix file includes the local IP address, and the local IP address in the configuration parameters can be determined based on the local IP address in the service matrix file. For example, the local IP address in the service matrix file is directly determined as the local IP address in the configuration parameters.

[0080] Then, the sending and receiving direction of the vehicle Ethernet in the target data can be determined based on the local IP address in the configuration parameters. For example, when the source IP address in the target data successfully matches the local IP address in the configuration parameters (that is, the source IP address in the target data is included in the local IP address in the configuration parameters, and the same applies below), the vehicle Ethernet is set as the sending end in the target data; when the destination IP address in the target data successfully matches the local IP address in the configuration parameters, the vehicle Ethernet is set as the receiving end in the target data. In this way, it can be clearly stated in the target data whether the vehicle Ethernet is the sending end or the receiving end, further improving the accuracy of the target data.

[0081] like Figure 3AAs shown, the embodiment of the present application obtains the service matrix file of the vehicle where the in-vehicle Ethernet is located, and determines the network card device identifier in the configuration parameters based on the network card device identifier in the service matrix file, and generates the filtering conditions in the configuration parameters based on the network address in the service matrix file; determines the target network card device corresponding to the network card device identifier in the configuration parameters in the in-vehicle Ethernet, and performs message capture processing on the message transmitted by the target network card device according to the filtering conditions in the configuration parameters to obtain the original message; performs message parsing processing on the original message at each protocol layer to obtain the parsed message; performs format conversion processing on the parsed message to obtain the target data that conforms to the application layer protocol. In summary, the embodiment of the present application can automatically construct configuration parameters based on the service matrix file of the vehicle without manual construction, thereby realizing automated message processing; and finally obtains the target data that conforms to the application layer protocol, which is conducive to secondary use and analysis.

[0082] In some embodiments, see Figure 3B , Figure 3B This is a flow chart of a message processing method for an in-vehicle Ethernet provided by an embodiment of the present application. Figure 3A Step 103 shown can be implemented through steps 201 to 204 , which will be described in conjunction with each step.

[0083] In step 201, the original message is parsed at the data link layer according to the data link layer protocol to obtain a network layer message.

[0084] Here, the original message is parsed and processed at the data link layer according to the data link layer protocol adopted by the in-vehicle Ethernet protocol stack to obtain a network layer message. The original message can be regarded as a data link layer message.

[0085] In some embodiments, before the original message is parsed and processed according to the data link layer protocol to obtain the network layer message, the message processing method of the in-vehicle Ethernet also includes: when the network card device identifier in the configuration parameters is not any network card device identifier, determining that the data link layer protocol is the Ethernet protocol; when the network card device identifier in the configuration parameters is any network card device identifier, determining that the data link layer protocol is a pseudo protocol.

[0086] Here, when the network card device identifier in the configuration parameters is not an arbitrary network card device identifier, it proves that the target network card device is specified, and thus it can be determined that the data link layer protocol applicable to the target network card device is a standard Ethernet protocol, such as IEEE 802.3Ethernet; when the network card device identifier in the configuration parameters is an arbitrary network card device identifier, the target network card device is an arbitrary network card device. Considering that not all network card devices may have the same data link layer type, or some network card devices may not be able to provide complete link layer header information, the data link layer protocol is determined to be a pseudo-protocol, such as Linux cooked capture, so that packets from different network card devices can be processed more flexibly and accurately.

[0087] In step 202, the network layer message is parsed according to the network layer protocol to obtain a transport layer message.

[0088] Here, the network layer message is parsed and processed according to the network layer protocol (such as IPv4 or IPv6) adopted by the vehicle Ethernet protocol stack to obtain a transport layer message.

[0089] In some embodiments, after performing network layer parsing processing on the network layer message according to the network layer protocol to obtain the transport layer message, the message processing method of the in-vehicle Ethernet further includes: when the fragment field in the message header of the network layer message indicates that there is fragmentation and the offset field indicates that the offset is 0, storing it in the mapping table with the identification field in the message header of the network layer message as the index and the transport layer message as the value; when the fragment field in the message header of the network layer message indicates that there is fragmentation and the offset field indicates that the offset is not 0, storing it according to the value of the network layer message. The identification field in the message header is searched in the mapping table, and the payload part of the transport layer message is spliced ​​to the end of the payload part of the retrieved message; when the fragment field in the message header of the network layer message indicates that the network layer message is the last fragment, the mapping table is searched according to the identification field in the message header of the network layer message, and the payload part of the transport layer message is spliced ​​to the end of the payload part of the retrieved message, the spliced ​​message is determined as the transport layer message for transport layer parsing processing, and the spliced ​​message is deleted from the mapping table.

[0090] Here, the fragment field in the message header of the network layer message is used to indicate information related to fragmentation, such as whether there is a fragment, and if there is a fragment, whether it is the last fragment in the complete message. In the IPv4 protocol, the fragment field can be the Flags field; the offset field in the message header of the network layer message is used to indicate the position of the fragment in the complete message. In the IPv4 protocol, the offset field can be the Offset field. When the fragment field in the message header of the network layer message indicates that there is no fragment, there is no need to perform fragment reassembly, and the subsequent step 203 is directly executed; when the fragment field in the message header of the network layer message indicates that there is a fragment, fragment reassembly is required.

[0091] During the fragment reorganization process, the following situations may occur:

[0092] 1) When the fragment field in the message header of the network layer message indicates that there is a fragment and the offset field indicates that the offset is 0, it proves that the transport layer message is the first fragment. Therefore, in the mapping table (map), the identification field in the message header of the network layer message is used as the index and the transport layer message is used as the value for storage, that is, the first fragment is stored, and the stored data structure is "identification field in the message header of the network layer message - transport layer message".

[0093] 2) When the fragment field in the message header of the network layer message indicates that there is a fragment and the offset field indicates that the offset is not 0, it proves that the transport layer message is not the first fragment, and the relevant data of the previous fragment has been stored in the mapping table. Therefore, the mapping table is searched according to the identification field in the message header of the network layer message, and the payload part of the transport layer message is spliced ​​to the end of the payload part of the retrieved message.

[0094] 3) When the fragment field in the message header of the network layer message indicates that the network layer message is the last fragment, a search is performed in the mapping table according to the identification field in the message header of the network layer message, and the payload part of the transport layer message is spliced ​​to the end of the payload part of the retrieved message. At this time, the fragment reassembly is completed, and the spliced ​​message is used as a complete transport layer message for subsequent transport layer parsing processing (i.e., for the subsequent step 203), and the spliced ​​message is deleted from the mapping table, thereby saving storage resources.

[0095] Implementing fragmentation and reassembly of transport layer messages in the above manner can ensure data integrity and reliability, and help improve the accuracy of subsequent analysis.

[0096] In some embodiments, the in-vehicle Ethernet message processing method further includes: deleting fragments whose storage time in the mapping table exceeds a time threshold. Here, for fragments whose storage time in the mapping table exceeds the time threshold, it is determined that the fragments have failed to be reassembled and are deleted, thereby saving storage resources.

[0097] In step 203, the transport layer message is parsed according to the transport layer protocol to obtain an application layer message.

[0098] Here, the transport layer message is parsed according to the transport layer protocol (such as TCP or UDP) adopted by the in-vehicle Ethernet protocol stack to obtain the application layer message.

[0099] In some embodiments, after the transport layer message is parsed according to the transport layer protocol to obtain the application layer message, the message processing method of the automotive Ethernet also includes: when the source port number and the destination port number of the transport layer message are not located in the mapping table, and it is determined that there is segmentation based on the message length field in the message header of the application layer message and the message length of the application layer message, the source port number and the destination port number of the transport layer message are used as indexes in the mapping table, and the application layer message is used as the value for storage; when the source port number and the destination port number of the transport layer message are located in the mapping table, the mapping table is searched based on the source port number and the destination port number of the transport layer message, the payload part of the application layer message is spliced ​​to the end of the payload part of the retrieved message, and when it is determined that there is no segmentation based on the message length field in the message header of the spliced ​​message and the message length of the spliced ​​message, the spliced ​​message is determined as the application layer message used to generate the parsed message, and the spliced ​​message is deleted from the mapping table.

[0100] Here, the message length field in the message header of the application layer message is used to indicate the message length of the complete message. Based on this, when it is determined that there is no segmentation based on the message length field in the message header of the application layer message and the message length of the application layer message, there is no need to perform segmentation reassembly and the subsequent step 204 is directly executed; when it is determined that there is segmentation based on the message length field in the message header of the application layer message and the message length of the application layer message, segmentation reassembly is required. The message length of the application layer message refers to the length from the end of the message length field of the application layer message to the end of the application layer message. When the message length indicated by the message length field in the message header of the application layer message is equal to the message length of the application layer message, it is determined that there is no segmentation; when the message length indicated by the message length field in the message header of the application layer message is greater than the message length of the application layer message, it is determined that there is segmentation.

[0101] During the segment reassembly process, the following situations may occur:

[0102] 1) When the source port number and destination port number of the transport layer message are not located in the mapping table, and the presence of a segment is determined based on the message length field in the message header of the application layer message and the message length of the application layer message, it is proved that the application layer message is the first segment. Therefore, the mapping table is indexed with the source port number and destination port number of the transport layer message and stored with the application layer message as the value, that is, the stored data structure is "source port number and destination port number of the transport layer message - application layer message".

[0103] 2) When the source port number and the destination port number of the transport layer message are in the mapping table, it proves that the application layer message is not the first segment. Therefore, the mapping table is searched according to the source port number and the destination port number of the transport layer message, and the payload part of the application layer message is spliced ​​to the end of the payload part of the retrieved message. When it is determined that there is no segment based on the message length field in the message header of the spliced ​​message and the message length of the spliced ​​message, it is determined that the segment reassembly is completed, and the spliced ​​message is used as a complete application layer message for the subsequent step 204. In addition, the spliced ​​message is deleted from the mapping table, thereby saving storage resources.

[0104] By implementing segmented reassembly of application layer messages in the above manner, data integrity and reliability can be ensured. It is worth noting that information such as the message length field in the message header of the application layer message and the message length of the application layer message can be obtained by performing application layer parsing of the application layer message based on the application layer protocol in the automotive Ethernet protocol stack (such as SOME / IP or DoIP, etc.).

[0105] In some embodiments, the in-vehicle Ethernet message processing method further includes: deleting segments in the mapping table whose storage duration exceeds a threshold. Here, for segments in the mapping table whose storage duration exceeds the threshold, it is determined that the segments have failed to be reassembled, and the segments are deleted, thereby saving storage resources.

[0106] In some embodiments, the network address in the service matrix file includes a port number; after obtaining the service matrix file of the vehicle where the on-board Ethernet is located, the message processing method of the on-board Ethernet also includes: determining the port number in the configuration parameter based on the port number in the service matrix file; the above-mentioned generation of parsed messages based on the original message, network layer message, transport layer message and application layer message can be achieved in this way: when the port number in the message header of the transport layer message successfully matches the port number in the configuration parameter, a parsed message is generated based on the original message, network layer message, transport layer message and application layer message.

[0107] Here, the network address in the service matrix file includes a port number. The port number in the service matrix file can be determined as the port number in the configuration parameter, or some additional port numbers can be added to complement the port number in the service matrix file. Then, it can be determined whether the message parsing process is necessary based on the port number in the configuration parameter. For example, when the port number in the message header of the transport layer message successfully matches the port number in the configuration parameter (i.e., the port number in the message header of the transport layer message is included in the port number in the configuration parameter), it is proved that the message parsing process is necessary, and thus a parsed message is generated based on the original message, network layer message, transport layer message, and application layer message; when the port number in the message header of the transport layer message fails to match the port number in the configuration parameter (i.e., the port number in the message header of the transport layer message is not included in the port number in the configuration parameter), it is proved that the captured message does not meet the requirements, the message parsing process is unnecessary, and no further processing is required. The original message, network layer message, transport layer message, and application layer message that have been obtained can be discarded.

[0108] Through the above method, the necessity of message parsing and processing can be guaranteed, and the waste of resources caused by useless processing can be avoided.

[0109] In step 204, a parsed message is generated according to the original message, the network layer message, the transport layer message, and the application layer message.

[0110] Here, a parsed message is generated based on the original message (data link layer message), network layer message, transport layer message and application layer message, that is, the original message, network layer message, transport layer message and application layer message are described by the parsed message, wherein the data structure of the parsed message is not limited, for example, it may include member variables corresponding to the original message, network layer message, transport layer message and application layer message, respectively, and each member variable is used to store the corresponding message.

[0111] In some embodiments, the parsed message includes member variables corresponding to the original message, network layer message, transport layer message and application layer message respectively, and the member variables corresponding to the original message and the member variables corresponding to the application layer message both adopt a bidirectional linked list data structure.

[0112] Here, in the parsed message, the member variables corresponding to the original message and the member variables corresponding to the application layer message both use a doubly linked list data structure. This is because, for a given in-vehicle Ethernet network, the network layer and transport layer typically use a fixed protocol, while the data link layer and application layer may have scalable protocols. For example, for the application layer protocol SOME / IP, there is a scalable protocol SOME / IP-SD. By using the doubly linked list data structure described above to maintain the data link layer protocol and the application layer protocol, the scalability requirements of the data link layer protocol and the application layer protocol can be fully met.

[0113] like Figure 3B As shown, the embodiment of the present application parses the original message in the data link layer, network layer and transport layer in turn, and uniformly describes the messages corresponding to each protocol layer through the parsed messages, which can achieve accurate and effective message parsing, and the parsed messages can be easily converted into target data that complies with the application layer protocol, which is conducive to secondary utilization and analysis.

[0114] The following will illustrate an exemplary application of the embodiment of the present application in a practical application scenario. Taking the application layer protocol in the vehicle Ethernet protocol stack using the SOME / IP protocol as an example, the embodiment of the present application provides the following Figure 4 The flow chart of the message processing method of the vehicle Ethernet shown in FIG. Figure 4 , explained in step-by-step form.

[0115] Step 1: The configuration generation module obtains the service matrix file corresponding to the vehicle model and processes it through a Python script to obtain configuration parameters. The service matrix file is pre-designed by relevant personnel for each vehicle model and can be in Excel format.

[0116] Configuration parameters include the following:

[0117] 1) Network card device identifier (or network card device name). Determine the network card device identifier in the configuration parameters based on the network card device identifier in the service deployment item of the service matrix file. If there is only one network card device identifier in the service matrix file, the network card device identifier in the service matrix file is determined as the network card device identifier in the configuration parameters; if there are multiple network card device identifiers in the service matrix file, the network card device identifier in the configuration parameters is determined to be any (corresponding to any network card device identifier above).

[0118] 2) Filtering conditions. Generate filtering conditions in the configuration parameters based on the IP addresses (local IP address, which can be the client / server) and SOME / IP service port numbers involved in the service matrix file, such as (host multicast-ip and port 30490) or (host ip1 and (port ip1port1 or ip1port2or...or port 30490)) or..., where multicast-ip represents the multicast address (multicast address) of the SOME / IP-SD message, and ip i Indicates the IP address in the service matrix file, ip i port j Indicates IP i The SOME / IP service port number corresponding to the address.

[0119] It is worth noting that SOME / IP messages are divided into two types: one is a common message for transmitting data; the other is a SOME / IP-SD message used to implement functions such as service discovery and service subscription request. Some functions in SOME / IP-SD messages, such as offer service and find service, need to send messages to the multicast address multicast-ip to find servers or clients within the multicast address range. In addition, if the server and client have established a service connection, the unicast address is used when transmitting common messages and SOME / IP-SD messages between the two, that is, ip i In the filtering conditions, since the port number used by SOME / IP-SD messages is 30490, only the port number 30490 is used for message capture in multicast-ip; i In addition to the SOME / IP service port number in the service matrix file j To capture and process packets, you also need to capture and process the port number 30490 corresponding to the SOME / IP-SD packet.

[0120] 3) SOME / IP service port number. This includes the SOME / IP service port number specified in the service matrix file and the SOME / IP-SD port number 30490. The SOME / IP service port number in the configuration parameters is used by the message parsing module to determine whether it is a SOME / IP message.

[0121] 4) Local IP address: The local IP address in the service deployment item of the service matrix file is determined as the local IP address in the configuration parameters. The local IP address in the configuration parameters is used to determine the sending and receiving direction of the local machine in the SOME / IP message.

[0122] Step 2: The message capture module captures and processes the message of the target network card device in the vehicle Ethernet according to the configuration parameters to obtain the original message. For example, the message capture module can perform the following steps:

[0123] 1) Load the network card device identifier and filter conditions in the configuration parameters.

[0124] 2) Determine the target network card device corresponding to the network card device identifier in the configuration parameters in the vehicle Ethernet, and capture and process the message transmitted by the target network card device according to the filtering conditions in the configuration parameters to obtain the original message.

[0125] 3) If the NIC device identifier in the configuration parameters is not "any," no duplicate original packets will be captured, and deduplication is not required. However, if the NIC device identifier in the configuration parameters is "any," duplicate original packets will be captured, one with a VLAN tag and the other without. Therefore, the VLAN-tagged original packets are filtered out (discarded) to achieve deduplication. According to the 802.1Q VLAN protocol, an original packet is considered VLAN-tagged if the 15th bit is 0x81 and the 16th bit is 0x00; otherwise, it is considered VLAN-tagged.

[0126] 4) Determine the data link layer protocol and send it along with the original message to the message parsing module. The determination rule is as follows: if the network card device identifier in the configuration parameters is not "any," the data link layer protocol is determined to be IEEE802.3Ethernet (i.e., Ethernet protocol); if the network card device identifier in the configuration parameters is "any," the data link layer protocol is determined to be Linux cooked capture (i.e., a pseudo-protocol).

[0127] Step 3: The message parsing module implements the following functions:

[0128] 1) Load the SOME / IP service port number in the configuration parameters.

[0129] 2) According to the data link layer protocol, the data link layer message (i.e., the original message mentioned above, specifically a bunch of eight-bit data of unsigned integer type) is parsed at the data link layer to obtain a network layer message.

[0130] 3) Perform network layer parsing on the network layer message according to the network layer protocol to obtain a transport layer message. The data link layer message includes a field for describing the network layer protocol, and the network layer protocol used by the in-vehicle Ethernet protocol stack can be determined based on this field.

[0131] 4) If the transport layer message is fragmented, reassemble the fragments. Figure 5As shown, a map is first constructed, which uses the Identification field in the header of the network layer message as the index (key) and the transport layer message as the value (value). Then, the following processing is performed for each network layer message:

[0132] ① If the Flags field in the message header of the network layer message indicates that there is no fragmentation (i.e., DF in the Flags field is 1), it proves that the transport layer message is a complete transport layer message and can be subsequently parsed and processed at the transport layer.

[0133] ② If the Flags field in the message header of the network layer message indicates that there are other fragments (i.e., DF in the Flags field is 0, and MF in the Flags field is 1), and the offset is 0 (i.e., Offset is 0), then it proves that the transport layer message is the first fragment. Therefore, the Identification field in the message header of the network layer message is used as the index in the map, and the transport layer message is used as the value for storage.

[0134] ③ If the Flags field in the message header of the network layer message indicates that there are other fragments (i.e., DF in the Flags field is 0, and MF in the Flags field is 1), and the offset is not 0, it proves that the transport layer message is not the first fragment, nor the last fragment. Therefore, according to the Identification field in the message header of the network layer message, the map is searched and the payload part of the transport layer message is spliced ​​to the end of the payload part of the retrieved message.

[0135] ④ If the Flags field in the message header of the network layer message indicates that the transport layer message is the last fragment (i.e., DF in the Flags field is 0, and MF in the Flags field is 0), then the map is searched according to the Identification field in the message header of the network layer message, and the payload part of the transport layer message is spliced ​​to the end of the payload part of the retrieved message. The spliced ​​message is used as a complete transport layer message for subsequent transport layer parsing and processing, and the spliced ​​message is deleted from the map.

[0136] In addition, a timer function is started to delete the timed-out and unprocessed fragments in the map in a polling manner.

[0137] 5) Perform transport layer parsing on the transport layer message according to the transport layer protocol to obtain an application layer message. The network layer message includes a field for describing the transport layer protocol, and the transport layer protocol used by the automotive Ethernet protocol stack can be determined based on this field.

[0138] 6) If the port number in the message header of the transport layer message is included in the SOME / IP service port number in the configuration parameters, message parsing is necessary, so continue to execute the subsequent steps; if the port number in the message header of the transport layer message is not included in the SOME / IP service port number in the configuration parameters, message parsing is not necessary, and stop executing the subsequent steps.

[0139] 7) If the transport layer protocol uses TCP, there may be TCP segmentation, in which case segment reassembly is required. Figure 6 As shown, a map is first constructed, which uses the source port number and destination port number of the transport layer message as the index and the network layer message as the value. Then, the following processing is performed for each transport layer message:

[0140] ① If the source port number and destination port number of the transport layer message are not in the map, and there is no segmentation according to the Length field in the message header of the application layer message and the message length of the application layer message, then the application layer message is proved to be a complete application layer message, so continue to execute the subsequent steps.

[0141] ② If the source port number and destination port number of the transport layer message are not in the map, and the existence of a segment is determined based on the Length field in the message header of the application layer message and the message length of the application layer message, it is proved that the application layer message is the first segment. Therefore, the source port number and destination port number of the transport layer message are used as indexes in the map, and the application layer message is used as the value for storage.

[0142] ③ If the source port number and destination port number of the transport layer message are in the map, it proves that the application layer message is not the first segment. Therefore, the map is searched according to the source port number and destination port number of the transport layer message, and the payload part of the application layer message is spliced ​​to the end of the payload part of the retrieved message. When it is determined that there is no segment based on the Length field in the message header of the spliced ​​message and the message length of the spliced ​​message, the spliced ​​message is regarded as a complete application layer message, and the subsequent steps are continued. At the same time, the spliced ​​message is deleted from the map.

[0143] In addition, a timer function is started to delete the timed-out and unprocessed segments in the map in a polling manner.

[0144] 8) The data structure of the parsed message is as follows.

[0145]

[0146] At the code level, the PacketProtocol data structure can be represented as:

[0147]

[0148] Since the embodiments of this application are only for the SOME / IP protocol, four member variables, data_link_layer_ (data link layer), network_layer_ (network layer), transport_layer_ (transport layer), and application_layer_ (application layer), are used to represent the message headers and corresponding payload parts of each protocol layer, and smart pointers are used for memory maintenance. The ApplicationLayerBase class and the DataLinkLayerBase class are maintained using a bidirectional linked list to facilitate expansion at the corresponding protocol layer. For example, if there are extended parts belonging to SOME / IP-SD other than the SOME / IP message in SOME / IP-SD, they can be maintained using a bidirectional linked list. The first member of the linked list is the SOME / IP layer protocol message header, and the second member is the content of the SOME / IP-SD protocol. The NetworkLayerBase class and the TransportLayerBase class do not use a linked list for maintenance because the SOME / IP protocol is fixed at the network layer and transport layer protocols. The network layer is basically the IPv4 protocol, and the transport layer is the TCP or UDP protocol. There are no other extensible protocols.

[0149] The four member variable types ApplicationLayerBase, DataLinkLayerBase, NetworkLayerBase, and TransportLayerBase inherit from the base class Layer. The data structure of Layer is:

[0150] class Layer{

[0151] public:

[0152] virtual bool parseLayer(vector<uint8_t> &packet,int&protocol_parse_index)=0;

[0153] vector<uint8_t> payload_;

[0154] };

[0155] payload_ represents the payload part of the protocol layer. Only the payload_ member of the top layer protocol is not empty, while the other layers are empty.

[0156] The data structure of the ApplicationLayerBase class is:

[0157] class ApplicationLayerBase:public Layer{

[0158] public:

[0159] virtual PcapProtocolType getCurrentLayerProtocol()=0;

[0160] virtual PcapProtocolType getNextLayerProtocol()=0;

[0161] shared_ptr <applicationlayerbase>getPreLayer(){return pre_layer_;}

[0162] shared_ptr <applicationlayerbase>getNextLayer(){return next_layer_;}

[0163] shared_ptr <applicationlayerbase>pre_layer_=nullptr;

[0164] shared_ptr <applicationlayerbase>next_layer_=nullptr;

[0165] };

[0166] If the application layer contains more than one protocol, all protocols of the application layer are maintained using a doubly linked list data structure through the pre_layer_ and next_layer_ member variables to achieve scalability of the application layer protocol. The member variable application_layer_ of PacketProtocol only stores the first element of the linked list.

[0167] The data structure of the DataLinkLayerBase class is:

[0168] class DataLinkLayerBase:public Layer{

[0169] public:

[0170] virtual PcapProtocolType getCurrentLayerProtocol()=0;

[0171] virtual PcapProtocolType getNextLayerProtocol()=0;

[0172] shared_ptr <datalinklayerbase>getPreLayer(){return pre_layer_;}

[0173] shared_ptr <datalinklayerbase>getNextLayer(){return next_layer_;}

[0174] shared_ptr <datalinklayerbase>pre_layer_=nullptr;

[0175] shared_ptr <datalinklayerbase>next_layer_=nullptr;

[0176] };

[0177] If the data link layer contains more than one protocol, all protocols of the data link layer are maintained using a doubly linked list data structure through the pre_layer_ and next_layer_ member variables to achieve scalability of the data link layer protocol. The member variable data_link_layer_ of PacketProtocol only stores the first element of the linked list.

[0178] The data structure of the NetworkLayerBase class is:

[0179] class NetworkLayerBase:public Layer{

[0180] public:

[0181] virtual PcapProtocolType getCurrentLayerProtocol()=0;

[0182] virtual PcapProtocolType getNextLayerProtocol()=0;

[0183] };

[0184] The data structure of the TransportLayerBase class is:

[0185] class TransportLayerBase:public Layer{

[0186] public:

[0187] virtual PcapProtocolType getCurrentLayerProtocol()=0;

[0188] virtual PcapProtocolType getNextLayerProtocol()=0;

[0189] };

[0190] In the above example, a base class is provided for each protocol layer. The actual protocol type inherits the base class of the corresponding protocol layer and adds corresponding member variables and member functions. For example, the data structure of the UDP protocol is:

[0191] class UDPLayer final:public TransportLayerBase{

[0192] public:

[0193] bool parseLayer(vector<uint8_t>&packet,int&protocol_parse_index)override;

[0194] PcapProtocolType getCurrentLayerProtocol()override;

[0195] PcapProtocolType getNextLayerProtocol()override;

[0196] inline UDPHeader getUDPHeader()const{

[0197] return udp_header_;

[0198] }

[0199] inline void setUDPHeader(const UDPHeader&udp_header){

[0200] udp_header_=udp_header;

[0201] }

[0202] inline size_t getHeaderLen()const{

[0203] return sizeof(udp_header_);

[0204] }

[0205] inline uint32_t getSourcePort()const{

[0206] return udp_header_.source_port_;

[0207] }

[0208] inline uint32_t getDstPort()const{

[0209] return udp_header_.dest_port_;

[0210] }

[0211] private:

[0212] struct UDPHeader udp_header_;

[0213] };

[0214] Among them, the udp_header_ member variable is added to save the UDP message header, and the getSourcePort, getDstPort and other member functions are used to operate the UDP message header data.

[0215] 9) Send the parsed message to the data generation module.

[0216] Step 4: The data generation module implements the following functions:

[0217] 1) Load the local IP address in the configuration parameters.

[0218] 2) Convert the parsed message into target data in SOME / IP data format, and set the data sending and receiving direction in the target data. For example, if the source IP address in the target data is included in the local IP address in the configuration parameters, it is set as the sending end; if the destination IP address in the target data is included in the local IP address in the configuration parameters, it is set as the receiving end.

[0219] 3) Store the target data in memory and provide an external interface for storing the target data on disk or sending it to a specific application for further processing.

[0220] The data structure of SOME / IP may include SomeipPacketBase, SomeipApplicationData and SomeipServiceDiscoveryData, where SomeipPacketBase is the base class. The data structure of SomeipPacketBase is as follows:

[0221]

[0222] The data structure of SomeipApplicationData is as follows:

[0223]

[0224] The data structure of SomeipServiceDiscoveryData is as follows:

[0225]

[0226] The embodiments of the present application can at least achieve the following technical effects:

[0227] 1) It can be applied to systems using black box protocol stacks to achieve accurate and effective message capture.

[0228] 2) It can automatically build configuration parameters and process messages based on the service matrix file without manual construction; moreover, the service matrix file changes with the vehicle model and is highly targeted.

[0229] 3) Compared with existing open source projects, it can reorganize fragments and segments.

[0230] 4) The data structure used in the message parsing process is relatively simple, which can significantly reduce CPU usage and memory usage compared to projects such as PcapPlusPlus.

[0231] 5) Compared with existing packet collection and analysis tools such as Wireshark and TCPDump, the generated target data can be reused and analyzed, for example, it can be used by other applications.

[0232] The following continues to describe an exemplary structure of the vehicle Ethernet message processing device 455 provided in the embodiment of the present application implemented as a software module. In some embodiments, such as Figure 2 As shown, the software modules in the message processing device 455 of the vehicle-mounted Ethernet stored in the memory 450 may include: a configuration generation module 4551, which is used to obtain the service matrix file of the vehicle where the vehicle-mounted Ethernet is located, and determine the network card device identifier in the configuration parameters according to the network card device identifier in the service matrix file, and generate the filtering conditions in the configuration parameters according to the network address in the service matrix file; a message capture module 4552, which is used to determine the target network card device corresponding to the network card device identifier in the configuration parameters in the vehicle-mounted Ethernet, and perform message capture processing on the message transmitted by the target network card device according to the filtering conditions in the configuration parameters to obtain the original message; a message parsing module 4553, which is used to perform message parsing processing on each protocol layer of the original message to obtain a parsed message; a data generation module 4554, which is used to perform format conversion processing on the parsed message to obtain target data that conforms to the application layer protocol.

[0233] In some embodiments, the message parsing module 4553 is also used to: perform data link layer parsing on the original message according to the data link layer protocol to obtain a network layer message; perform network layer parsing on the network layer message according to the network layer protocol to obtain a transport layer message; perform transport layer parsing on the transport layer message according to the transport layer protocol to obtain an application layer message; generate a parsed message based on the original message, network layer message, transport layer message and application layer message.

[0234] In some embodiments, the message parsing module 4553 is also used to: when the fragment field in the message header of the network layer message indicates that there is fragmentation and the offset field indicates that the offset is 0, store it in the mapping table with the identification field in the message header of the network layer message as the index and the transport layer message as the value; when the fragment field in the message header of the network layer message indicates that there is fragmentation and the offset field indicates that the offset is not 0, search in the mapping table according to the identification field in the message header of the network layer message, and splice the payload part of the transport layer message to the end of the payload part of the retrieved message; when the fragment field in the message header of the network layer message indicates that the network layer message is the last fragment, search in the mapping table according to the identification field in the message header of the network layer message, splice the payload part of the transport layer message to the end of the payload part of the retrieved message, determine the spliced ​​message as the transport layer message for transport layer parsing processing, and delete the spliced ​​message in the mapping table.

[0235] In some embodiments, the message parsing module 4553 is also used for: when the source port number and the destination port number of the transport layer message are not located in the mapping table, and it is determined that there is segmentation based on the message length field in the message header of the application layer message and the message length of the application layer message, the source port number and the destination port number of the transport layer message are used as indexes in the mapping table, and the application layer message is used as the value for storage; when the source port number and the destination port number of the transport layer message are located in the mapping table, the mapping table is searched based on the source port number and the destination port number of the transport layer message, the payload part of the application layer message is spliced ​​to the end of the payload part of the retrieved message, and when it is determined that there is no segmentation based on the message length field in the message header of the spliced ​​message and the message length of the spliced ​​message, the spliced ​​message is determined as the application layer message used to generate the parsed message, and the spliced ​​message is deleted from the mapping table.

[0236] In some embodiments, the message parsing module 4553 is also used to: when the network card device identifier in the configuration parameters is not any network card device identifier, determine that the data link layer protocol is the Ethernet protocol; when the network card device identifier in the configuration parameters is any network card device identifier, determine that the data link layer protocol is a pseudo protocol.

[0237] In some embodiments, the network address in the service matrix file includes a port number; the configuration generation module 4551 is also used to: determine the port number in the configuration parameter based on the port number in the service matrix file; the message parsing module 4553 is also used to: when the port number in the message header of the transport layer message successfully matches the port number in the configuration parameter, generate a parsed message based on the original message, network layer message, transport layer message and application layer message.

[0238] In some embodiments, the parsed message includes member variables corresponding to the original message, network layer message, transport layer message and application layer message respectively, and the member variables corresponding to the original message and the member variables corresponding to the application layer message both adopt a bidirectional linked list data structure.

[0239] In some embodiments, the network card device identifier in the configuration parameters is an arbitrary network card device identifier, and the number of original messages includes multiple; the message processing device 455 of the vehicle Ethernet also includes a message deduplication module, which is used to: determine the original message with a virtual local area network VLAN tag among multiple original messages; and discard the original message with the VLAN tag.

[0240] In some embodiments, the network address in the service matrix file includes the local IP address; the configuration generation module 4551 is also used to: determine the local IP address in the configuration parameters based on the local IP address in the service matrix file; the data generation module 4554 is also used to: when the source IP address in the target data successfully matches the local IP address in the configuration parameters, set the on-board Ethernet as the transmitting end in the target data; when the destination IP address in the target data successfully matches the local IP address in the configuration parameters, set the on-board Ethernet as the receiving end in the target data.

[0241] An embodiment of the present application provides a computer program product or computer program, which includes executable instructions stored in a computer-readable storage medium. A processor of an electronic device reads the executable instructions from the computer-readable storage medium and executes the executable instructions, causing the electronic device to implement the in-vehicle Ethernet message processing method described in the embodiment of the present application.

[0242] An embodiment of the present application provides a computer-readable storage medium storing executable instructions, wherein the executable instructions are stored. When the executable instructions are executed by a processor, the processor will implement the message processing method of the in-vehicle Ethernet provided by the embodiment of the present application.

[0243] In some embodiments, the computer-readable storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash memory, magnetic surface storage, optical disk, or CD-ROM; or various devices including one or any combination of the above memories.

[0244] In some embodiments, executable instructions may be in the form of a program, software, software module, script, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0245] As an example, executable instructions may, but need not, correspond to a file in a file system, may be stored as part of a file that stores other programs or data, such as in one or more scripts in a HyperText Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple coordinating files (e.g., files storing one or more modules, subroutines, or code portions).

[0246] As an example, executable instructions may be deployed to be executed on one electronic device, or on multiple electronic devices located at one site, or on multiple electronic devices distributed across multiple sites and interconnected by a communication network.

[0247] The above are merely examples of the present application and are not intended to limit the scope of protection of the present application. Any modifications, equivalent replacements, and improvements made within the spirit and scope of the present application are included in the scope of protection of the present application.< / datalinklayerbase> < / datalinklayerbase> < / datalinklayerbase> < / datalinklayerbase> < / applicationlayerbase> < / applicationlayerbase> < / applicationlayerbase> < / applicationlayerbase>

Claims

1. A method for processing messages of an in-vehicle Ethernet, characterized in that: include: Obtaining a service matrix file of a vehicle where an in-vehicle Ethernet is located, and determining a network card device identifier in a configuration parameter based on the network card device identifier in the service matrix file, and generating a filtering condition in the configuration parameter based on a network address in the service matrix file, wherein determining the network card device identifier in the configuration parameter based on the network card device identifier in the service matrix file includes: when the number of network card device identifiers in the service matrix file is one, determining the network card device identifier in the service matrix file as the network card device identifier in the configuration parameter; when the number of network card device identifiers in the service matrix file includes multiple, determining the network card device identifier in the configuration parameter as any network card device identifier; Determining, in the in-vehicle Ethernet, a target network card device corresponding to the network card device identifier in the configuration parameters, and performing message capture processing on messages transmitted by the target network card device according to the filtering conditions in the configuration parameters to obtain original messages; Performing message parsing of each protocol layer on the original message to obtain a parsed message; The parsed message is format-converted to obtain target data that complies with the application layer protocol.

2. The method according to claim 1, characterized in that The performing message parsing processing on the original message at each protocol layer to obtain a parsed message includes: Performing data link layer parsing on the original message according to the data link layer protocol to obtain a network layer message; Performing network layer parsing on the network layer message according to the network layer protocol to obtain a transport layer message; Performing transport layer parsing on the transport layer message according to the transport layer protocol to obtain an application layer message; The parsed message is generated according to the original message, the network layer message, the transport layer message and the application layer message.

3. The method according to claim 2, characterized in that After performing network layer parsing on the network layer message according to the network layer protocol to obtain a transport layer message, the method further includes: When the fragment field in the message header of the network layer message indicates that fragments exist and the offset field indicates that the offset is 0, the mapping table is stored with the identification field in the message header of the network layer message as the index and the transport layer message as the value; When the fragment field in the message header of the network layer message indicates that fragments exist and the offset field indicates that the offset is not 0, searching the mapping table according to the identification field in the message header of the network layer message, and splicing the payload part of the transport layer message to the end of the payload part of the retrieved message; When the fragment field in the message header of the network layer message indicates that the network layer message is the last fragment, the mapping table is searched according to the identification field in the message header of the network layer message, the payload part of the transport layer message is spliced ​​to the end of the payload part of the retrieved message, the spliced ​​message is determined as the transport layer message for transport layer parsing processing, and the spliced ​​message is deleted from the mapping table.

4. The method according to claim 2, characterized in that After performing transport layer parsing on the transport layer message according to the transport layer protocol to obtain the application layer message, the method further includes: When the source port number and the destination port number of the transport layer message are not located in the mapping table, and it is determined that there is segmentation according to the message length field in the message header of the application layer message and the message length of the application layer message, storing the message in the mapping table with the source port number and the destination port number of the transport layer message as the index and the application layer message as the value; When the source port number and the destination port number of the transport layer message are located in the mapping table, the mapping table is searched according to the source port number and the destination port number of the transport layer message, the payload part of the application layer message is spliced ​​to the end of the payload part of the retrieved message, and when it is determined that there is no segmentation according to the message length field in the message header of the spliced ​​message and the message length of the spliced ​​message, the spliced ​​message is determined as the application layer message used to generate the parsed message, and the spliced ​​message is deleted from the mapping table.

5. The method according to claim 2, characterized in that Before performing data link layer parsing on the original message according to the data link layer protocol to obtain a network layer message, the method further includes: When the network card device identifier in the configuration parameter is not any network card device identifier, determining that the data link layer protocol is the Ethernet protocol; When the network card device identifier in the configuration parameters is any network card device identifier, it is determined that the data link layer protocol is a pseudo protocol.

6. The method according to claim 2, characterized in that The network address in the service matrix file includes a port number; after obtaining the service matrix file of the vehicle where the vehicle Ethernet is located, the method further includes: Determining the port number in the configuration parameter according to the port number in the service matrix file; The generating the parsed message according to the original message, the network layer message, the transport layer message, and the application layer message includes: When the port number in the message header of the transport layer message successfully matches the port number in the configuration parameter, the parsed message is generated according to the original message, the network layer message, the transport layer message and the application layer message.

7. The method according to claim 2, characterized in that The parsed message includes member variables corresponding to the original message, the network layer message, the transport layer message and the application layer message respectively, and the member variables corresponding to the original message and the member variables corresponding to the application layer message both adopt a bidirectional linked list data structure.

8. The method according to claim 1, characterized in that If the network card device identifier in the configuration parameters is any network card device identifier, and the number of the original messages includes multiple; after performing message capture processing on the messages transmitted by the target network card device according to the filtering conditions in the configuration parameters to obtain the original messages, the method further includes: Determining an original message with a virtual local area network (VLAN) tag among multiple original messages; The original packets with VLAN tags are discarded.

9. The method according to claim 1, characterized in that The network address in the service matrix file includes the local IP address; after obtaining the service matrix file of the vehicle where the vehicle Ethernet is located, the method further includes: Determine the local IP address in the configuration parameters according to the local IP address in the service matrix file; The method further comprises: When the source IP address in the target data successfully matches the local IP address in the configuration parameters, setting the in-vehicle Ethernet as a sending end in the target data; When the destination IP address in the target data successfully matches the local IP address in the configuration parameters, the in-vehicle Ethernet is set as the receiving end in the target data.

10. A message processing device for vehicle-mounted Ethernet, characterized in that: include: A configuration generation module is configured to obtain a service matrix file of a vehicle where the in-vehicle Ethernet is located, determine a network card device identifier in a configuration parameter based on the network card device identifier in the service matrix file, and generate a filtering condition in the configuration parameter based on the network address in the service matrix file, wherein determining the network card device identifier in the configuration parameter based on the network card device identifier in the service matrix file comprises: when the number of network card device identifiers in the service matrix file is one, determining the network card device identifier in the service matrix file as the network card device identifier in the configuration parameter; when the number of network card device identifiers in the service matrix file includes multiple, determining the network card device identifier in the configuration parameter as any network card device identifier; a message capture module, configured to determine, in the in-vehicle Ethernet, a target network card device corresponding to the network card device identifier in the configuration parameters, and to capture and process messages transmitted by the target network card device according to the filtering conditions in the configuration parameters to obtain original messages; A message parsing module, configured to perform message parsing processing on each protocol layer of the original message to obtain a parsed message; The data generation module is used to perform format conversion processing on the parsed message to obtain target data that complies with the application layer protocol.

11. An electronic device, characterized in that: include: a memory for storing executable instructions; A processor, configured to implement the method according to any one of claims 1 to 9 when executing the executable instructions stored in the memory.

12. A computer-readable storage medium, characterized in that Executable instructions are stored, and when executed by a processor, they are used to implement the method described in any one of claims 1 to 9.

Images