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

Abstract

The invention provides a message processing method and device of a vehicle-mounted Ethernet, electronic equipment, a computer readable storage medium and a computer program product. The method comprises the following steps: acquiring a service matrix file of a vehicle where a vehicle-mounted Ethernet is located, determining a network card equipment identifier in configuration parameters according to the network card equipment identifier in the service matrix file, and generating a filtering condition in the configuration parameters according to a network address in the service matrix file; determining a target network card device corresponding to the network card device identifier in the configuration parameters in the vehicle-mounted Ethernet, and performing message capture processing on a message transmitted by the target network card device according to a filtering condition in the configuration parameters to obtain an original message; performing message analysis processing of each protocol layer on the original message to obtain an analyzed message; and performing format conversion processing on the analysis message to obtain target data conforming to an application layer protocol. According to the invention, the configuration parameters can be automatically constructed according to the service matrix file of the vehicle, and automatic message processing is realized.

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 systems (ADAS), autonomous driving, over-the-air (OTA), personalized services, etc., which has led to the traditional communication methods, such as controller area network (CAN), local interconnect network (LIN) and other bus methods can no longer meet the current vehicle function requirements.

[0003] With the development of vehicle electronic technology, communication based on vehicle Ethernet has gradually become the mainstream, which has also brought about the need to collect and analyze messages in vehicle Ethernet. In the solutions provided by related technologies, ready-made message collection and analysis tools (such as Wireshark, TCPDump, etc.) are usually used. However, these message collection and analysis tools require manual construction of relevant conditions for capturing messages, which makes the operation more cumbersome. Summary of the invention

[0004] The present application provides 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 according to a service matrix file of the vehicle to realize automated message processing.

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

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

[0007] 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;

[0008] Determine, in the in-vehicle Ethernet, a target network card device corresponding to the network card device identifier in the configuration parameters, and perform 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 processing on 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, used to obtain a 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 a filtering condition in the configuration parameters according to the network address in the service matrix file;

[0013] A message capture module, used to determine the target network card device corresponding to the network card device identifier in the configuration parameters in the vehicle Ethernet, and to 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;

[0014] A message parsing module, used for performing 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 message processing method of the in-vehicle Ethernet provided by the present application.

[0020] The present application provides a computer program product, which includes executable instructions for causing a processor to execute and implement the message processing method of the in-vehicle Ethernet provided by 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 vehicle-mounted 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 vehicle-mounted 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 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 use 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 drawings required for use in the description of the embodiments will be briefly introduced below. 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 It is a schematic diagram of the architecture of a message processing system for an in-vehicle Ethernet provided in an embodiment of the present application;

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

[0026] Figure 3A It is a first flow chart of the message processing method of the vehicle-mounted Ethernet provided in an embodiment of the present application;

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

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

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

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

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

[0032] In the following description, reference is made to "some embodiments", which describes a subset of all possible embodiments, but 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, reference is made to the term "multiple" to mean 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 those commonly understood by those skilled in the art to which this application belongs. The terms used herein are only for the purpose of describing the embodiments of this application 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. Packet Capture Library is referred to as libpcap. The C function interface provided by the library is used to capture data packets of the specified network card device. However, libpcap has problems such as the need to manually construct the relevant conditions for capturing messages, the inability to implement message parsing, and the inability to implement fragment reassembly and segment reassembly functions. PcapPlusPlus, developed based on libpcap, can implement the message parsing function, but because it constructs the specified data format when capturing messages, its data format is too complicated, resulting in the CPU usage rate when using PcapPlusPlus for message capture to be more than 10 times that of using libpcap alone.

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

[0038] 3) Car Ethernet protocol stack tracking. Specifically, the car Ethernet protocol stack is tracked so that the protocol stack messages are stored in the central node of communication. Then, a data request application is built, which communicates with the central node to obtain the stored messages. The implementation of this solution requires an open source protocol stack, but most of the current protocol stacks are black boxes, making this solution impossible to implement.

[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 according to the vehicle's service matrix file to realize automated message processing; for the black box protocol stack, messages can be captured by packet capture; fragment reassembly and segment reassembly functions can be realized; target data of the application layer protocol can be output and stored in memory or hard disk, which is helpful for secondary utilization and analysis.

[0040] The following describes an exemplary application 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 It is an architectural diagram of a message processing system 100 for an in-vehicle Ethernet provided in an embodiment of the present application, wherein an in-vehicle device 400 is connected to a server 200 via a network 300, wherein the network 300 may 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 message processing method of the in-vehicle Ethernet provided in the embodiment 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, 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 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.

[0043] In some embodiments, the message processing method of the vehicle Ethernet provided in the embodiment of the present application can be implemented by the vehicle-mounted device and the server in collaboration. For example, the server 200 can obtain the service matrix file of the vehicle where the vehicle-mounted device 400 is located, generate configuration parameters according to the service matrix file, and send the configuration parameters to the vehicle-mounted device 400, so that the vehicle-mounted device 400 performs message capture processing on the target network card device in the vehicle-mounted Ethernet of the vehicle according to the configuration parameters to obtain the original message. For another example, the vehicle-mounted device 400 can send the original message to the server 200, so that the server 200 performs message parsing processing of each protocol layer on the original message, obtains the parsed message, and performs format conversion processing on the parsed message to obtain the target data that conforms to the application layer protocol. For another example, the vehicle-mounted device 400 can perform message parsing processing of each protocol layer on the original message, obtains the parsed message, and performs format conversion processing on the parsed message to obtain the 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, the electronic device can implement the message processing method of the vehicle Ethernet provided in the embodiment 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, Application), 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 only by downloading it to 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 in the case where the electronic device is a server, Figure 2Parts of the structure shown in FIG. 1 (such as a user interface, a presentation module, and an input processing module) may be omitted. Figure 2 , Figure 2 is a structural diagram of a 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 the 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 described in detail. Figure 2 Various buses are labeled as bus system 440 .

[0046] 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 disk drives, optical disk 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 a volatile memory or a non-volatile memory, and may also include both volatile and non-volatile memories. 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, 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 exemplarily described below.

[0051] Operating system 451, including system programs for processing various basic system services and performing hardware-related tasks, such as a framework layer, a core library layer, a driver layer, etc., for implementing various basic services and processing hardware-based tasks;

[0052] A network communication module 452, used to reach other electronic devices via one or more (wired or wireless) network interfaces 420, exemplary network interfaces 420 include: Bluetooth, Wireless Compatibility Certification (WiFi), and Universal Serial Bus (USB), etc.;

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

[0054] The input processing module 454 is used to detect one or more user inputs or interactions from one of the one or more input devices 432 and 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 a software manner. Figure 2 The vehicle-mounted Ethernet message processing device 455 stored in the memory 450 is shown, which can be software in the form of a program and a plug-in, etc., including 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 therefore can be arbitrarily combined or further split according to the functions implemented. The functions of each module will be described below.

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

[0057] See also Figure 3A , Figure 3A This is a flow chart of a message processing method for vehicle Ethernet provided in 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 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 of the vehicle where the vehicle Ethernet is located is obtained. Among them, the service matrix file is used to describe and define the interaction relationship, interface definition and dependency relationship between various services in the vehicle, so as to ensure that various services in the vehicle system can communicate and collaborate in a predetermined manner. The service matrix file is usually designed by relevant personnel according to the vehicle model, that is, different vehicle models correspond to different service matrix files. Therefore, in the embodiment of the present application, a pre-designed service matrix file can be obtained according to the vehicle model where the vehicle Ethernet is located.

[0060] The service matrix file includes relevant information related to message transmission in the vehicle Ethernet. Therefore, configuration parameters can be generated according to 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 according to 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 may include an IP address (the local IP address, where the local machine may be a client / server), and may 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 generated filter condition is (host ipi and portj). Through the above method, the automatic construction of the filter condition can be achieved without 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 identifiers 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 identifiers 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 vehicle Ethernet, and a message transmitted by the target network card device is captured and processed according to the filtering conditions in the configuration parameters to obtain an original message.

[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 (ie, all network card devices).

[0067] On the basis of locating the target network card device, the messages transmitted by the target network card device are captured and processed according to the filtering conditions in the configuration parameters, that is, only the messages that meet the filtering conditions are captured from the messages transmitted by the target network card device. For the convenience of distinction, the captured messages here are called original messages.

[0068] 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 transmitted by the target network card device is captured and processed according to the filtering conditions in the configuration parameters, and after the original message is obtained, the message processing method of the vehicle-mounted 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 from 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, there is no VLAN tag, and the message without the VLAN tag will be captured once at the kernel, and then, when the message without the VLAN tag passes through the network card device, the VLAN tag needs to be added, and the message with the 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 processing, the original message with VLAN tag is determined among the multiple original messages, and the original message with VLAN tag is discarded, that is, only the original message without VLAN tag is subsequently parsed at each protocol layer. In the above manner, message deduplication can be achieved, avoiding the waste of resources caused by the 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, the automotive Ethernet protocol stack is explained. The automotive Ethernet protocol stack refers to a set of protocols designed to achieve effective communication between various electronic devices inside the vehicle in the automotive Ethernet environment. The automotive Ethernet protocol stack follows a specific network model, such as the Open System Interconnect (OSI) model or the simplified Transmission Control Protocol / Internet Protocol (TCP / IP) model, and 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 multiple 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 to transmit data on a single link; 3) Network layer: responsible for data routing and forwarding, ensuring that data can reach the destination correctly. In the automotive Ethernet protocol stack, the network layer protocol (such as IPv4 or IPv6) is used to allocate and manage the Internet Protocol (IP) address of the vehicle to achieve interconnection between the internal networks of the vehicle; 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: facing the user's final application, defines various specific communication protocols and services, application layer protocols such as Scalable service-oriented MiddlewarE over IP (SOME / IP) protocol and Diagnostic communication over Internet Protocol (DoIP) protocol based on IP.

[0074] Taking the above-mentioned vehicle Ethernet protocol stack as an example, the original message obtained by the message capture process 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 of each protocol layer in the reverse order of the encapsulation order, that is, data link layer parsing processing, network layer parsing processing and transport layer parsing processing are performed in sequence. In the embodiment of the present application, the result of the message parsing processing is described by parsing the message, that is, the parsing 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 processed to obtain target data that conforms to the application layer protocol in the vehicle Ethernet protocol stack. Since the target data conforms to the application layer protocol, it can be used by other applications, which is helpful for secondary utilization and analysis. Taking the application layer protocol as the SOME / IP protocol as an example, the target data can be helpful for the development of other SOME / IP work and tools, such as SOME / IP anomaly detection, problem troubleshooting, data analysis, statistics, etc.

[0077] In some embodiments, after format conversion is performed on the parsed message to obtain target data that complies with the application layer protocol, the message processing method of the vehicle Ethernet further includes: storing the target data. For example, the target data may be stored in a memory or a disk, or in a server so that it can be retrieved 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 according to 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, setting the on-board Ethernet 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, setting the on-board Ethernet 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 can be 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 according to 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 the above manner, 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 vehicle-mounted 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 vehicle-mounted 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 according to 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 helpful for secondary use and analysis.

[0082] In some embodiments, see Figure 3B , Figure 3B is a flow chart of a message processing method of an in-vehicle Ethernet provided in an embodiment of the present application, Figure 3A The illustrated step 103 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 vehicle Ethernet protocol stack to obtain a network layer message, wherein 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 vehicle-mounted 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 is proved that the target network card device is specified, and then 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 messages 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, etc.) 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 vehicle Ethernet also includes: when the fragmentation 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, 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 in the mapping table; when the fragmentation 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, according to the 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 whether it is the last fragment in the complete message if there is a fragment. 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 reassemble the fragments, 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, there are the following situations:

[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 "the identification field in the message header of the network layer message - the 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 message processing method of the vehicle Ethernet further includes: deleting the fragments whose storage time in the mapping table exceeds the time threshold. Here, for the fragments whose storage time in the mapping table exceeds the time threshold, it is determined that the fragment reassembly fails, and the fragments 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, etc.) adopted by the 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 vehicle 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 according to 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 the index 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 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.

[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 according to 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 according to 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. Among them, 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 reorganization process, there are the following situations:

[0102] 1) When the source port number and the destination port number of the transport layer message are not located in the mapping table, and the existence of segmentation 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 stored 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, 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 according to 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 the segmentation and reassembly of the application layer message in the above manner, the integrity and reliability of the data can be ensured. It is worth noting that the message length field in the message header of the application layer message and the message length of the application layer message and other information can be obtained by performing application layer parsing on the application layer message according to the application layer protocol (such as SOME / IP or DoIP, etc.) in the vehicle Ethernet protocol stack.

[0105] In some embodiments, the message processing method of the vehicle Ethernet further includes: deleting the segments whose storage time in the mapping table exceeds the time threshold. Here, for the segments whose storage time in the mapping table exceeds the time threshold, it is determined that the segment reassembly fails, 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 vehicle-mounted Ethernet is located, the message processing method of the vehicle-mounted Ethernet also includes: determining the port number in the configuration parameter according to 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 according to 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, and 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 according to 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 (that is, 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, so the parsed message is generated according to the original message, the network layer message, the transport layer message and the 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 (that is, 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. For the original message, network layer message, transport layer message and application layer message that have been obtained, it can be discarded.

[0108] Through the above method, the necessity of message parsing 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 according to the original message (data link layer message), the network layer message, the transport layer message and the application layer message, that is, the original message, the network layer message, the transport layer message and the 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, the network layer message, the transport layer message and the 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 adopt the data structure of a two-way linked list. The reason is that for a certain in-vehicle Ethernet, the network layer and the transport layer usually adopt a fixed protocol, while the data link layer and the application layer may have extensible protocols. For example, for the application layer protocol SOME / IP, there is an extensible protocol SOME / IP-SD. In the above manner, the data link layer protocol and the application layer protocol are maintained with the data structure of a two-way linked list, which can fully meet the extensibility requirements of the data link layer protocol and the application layer protocol.

[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 conforms to the application layer protocol, which is helpful for secondary utilization and analysis.

[0114] The following will describe 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 A flow chart of a message processing method of an in-vehicle Ethernet is shown, which will be combined with Figure 4 , explained in step form.

[0115] Step 1: The configuration generation module obtains the service matrix file corresponding to the vehicle model, and processes the service matrix file through a python script to obtain configuration parameters. Among them, the service matrix file is pre-designed by relevant personnel for the vehicle model, and the specific format can be an Excel file.

[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 as 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 (the local IP address, which can be the client / server) and the SOME / IP service port number 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 Represents 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 for realizing functions such as service discovery and establishing service subscription requests. 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 the 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 port in the service matrix file j To capture and process the message, it is also necessary to capture and process the message on the port number 30490 corresponding to the SOME / IP-SD message.

[0120] 3) SOME / IP service port number. This includes the SOME / IP service port number in the service matrix file and the port number 30490 of SOME / IP-SD. 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 performs message capture processing on 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 identification and filtering 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 perform message capture and 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.

[0125] 3) When the network card device identifier in the configuration parameters is not any, no duplicate original messages will be captured, and no message deduplication is required; when the network card device identifier in the configuration parameters is any, duplicate original messages will be captured, one of which has a VLAN tag and the other does not have a VLAN tag, so the original message with a VLAN tag is filtered out (discarded) to achieve message deduplication. According to the provisions of the 802.1Q VLAN protocol, when the 15th bit of an original message is 0x81 and the 16th bit is 0x00, it is determined that the original message has a VLAN tag, otherwise it does not have a VLAN tag.

[0126] 4) Determine the data link layer protocol and send it to the message parsing module along with the original message. The judgment rule is: if the network card device identifier in the configuration parameters is not any, then 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, then the data link layer protocol is determined to be Linux cooked capture (i.e., 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) Performing 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 vehicle Ethernet protocol stack can be determined based on the field.

[0131] 4) If the transport layer message is fragmented, reassemble the fragments. Figure 5As shown, first a map is 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 (ie, DF in the Flags field==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 the existence of other fragments (i.e., DF in the Flags field==0, and MF in the Flags field==1), and the offset is 0 (i.e., Offset==0), it proves that the transport layer message is the first fragment. Therefore, the map 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.

[0134] ③ If the Flags field in the message header of the network layer message indicates the existence of 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, the Identification field in the message header of the network layer message is searched in the map, 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 Identification field in the message header of the network layer message is searched in the map, 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) Performing 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 vehicle Ethernet protocol stack can be determined based on the 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, it proves that message parsing is necessary, so continue to execute 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, it proves that message parsing is not necessary, and stop executing 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, first a map is 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 it is proved that the application layer message is 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 segmentation 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 proves 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 the 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 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 segmentation 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 shown below.

[0145]

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

[0147]

[0148] Since the embodiment of the present application is 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 of each protocol layer and the corresponding payload part, and smart pointers are used for memory maintenance, wherein the ApplicationLayerBase class and the DataLinkLayerBase class are maintained using a bidirectional linked list, which is convenient for expansion at the corresponding protocol layer. For example, in SOME / IP-SD, there are extended parts belonging to SOME / IP-SD other than SOME / IP messages, so they can be maintained through 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 in the network layer and the transport layer protocols, the network layer is basically the IPv4 protocol, the transport layer is the TCP or UDP protocol, and 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 the scalability of the application layer protocol. The member variable application_layer_ of PacketProtocol only saves 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 the scalability of the data link layer protocol. Only the first element of the linked list is saved in the member variable data_link_layer_ of PacketProtocol.

[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 added udp_header_ member variable is used to save the UDP message header, and the member functions such as getSourcePort and getDstPort 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 interface to the outside world 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 based on the service matrix file and perform message capture and processing without manual construction; in addition, 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 is a description of an exemplary structure of a vehicle Ethernet message processing device 455 provided in an embodiment of the present application implemented as a software module. In some embodiments, for example, 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, the network layer message, the transport layer message and the application layer message.

[0234] In some embodiments, the message parsing module 4553 is also used for: when the fragmentation 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 fragmentation 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, searching in the mapping table according to the identification field in the message header of the network layer message, splicing the payload part of the transport layer message to the end of the payload part of the retrieved message; when the fragmentation field in the message header of the network layer message indicates that the network layer message is the last fragment, searching in the mapping table according to the identification field in the message header of the network layer message, splicing the payload part of the transport layer message to the end of the payload part of the retrieved message, determining the spliced ​​message as the transport layer message for transport layer parsing processing, and deleting 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 according to 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 the index and the application layer message is used as the value for storage in the mapping table; 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.

[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, the network layer message, the transport layer message and the 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-mounted 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 matches the local IP address in the configuration parameters successfully, set the on-board Ethernet as the transmitting end in the target data; when the destination IP address in the target data matches the local IP address in the configuration parameters successfully, set the on-board Ethernet as the receiving end in the target data.

[0241] The embodiment of the present application provides a computer program product or a computer program, which includes executable instructions stored in a computer-readable storage medium. The processor of the electronic device reads the executable instructions from the computer-readable storage medium, and the processor executes the executable instructions, so that the electronic device implements the above-mentioned vehicle Ethernet message processing method of the embodiment of the present application.

[0242] An embodiment of the present application provides a computer-readable storage medium storing executable instructions, wherein 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 in 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 it may be 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 coordinated files (e.g., files storing one or more modules, subroutines, or code portions).

[0246] As an example, the 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 at multiple sites and interconnected by a communication network.

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

Claims

1. A message processing method for vehicle-mounted Ethernet, characterized in that: include: 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; Determine, in the in-vehicle Ethernet, a target network card device corresponding to the network card device identifier in the configuration parameters, and perform 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 processing on 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 of each protocol layer on the original message to obtain a parsed message includes: Performing data link layer parsing processing on the original message according to the data link layer protocol to obtain a network layer message; Performing network layer parsing processing on the network layer message according to the network layer protocol to obtain a transport layer message; Performing transport layer parsing processing 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 processing on the network layer message according to the network layer protocol to obtain the transport layer message, the method further includes: When the fragmentation field in the message header of the network layer message indicates that there is a fragmentation and the offset field indicates that the offset is 0, 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 in the mapping table; When the fragmentation 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, 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 processing 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, 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 a 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 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 processing 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 an Ethernet protocol; When the network card device identifier in the configuration parameter 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: Determine 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 comprises: 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 The determining the network card device identifier in the configuration parameter according to the network card device identifier in the service matrix file includes: When the number of the 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 the network card device identifications in the service matrix file includes multiple network card device identifications, the network card device identification in the configuration parameter is determined to be an arbitrary network card device identification.

9. The method according to claim 1, characterized in that: The network card device identifier in the configuration parameter is any network card device identifier, and the number of the original messages includes multiple; after the message capture processing is performed on the message transmitted by the target network card device according to the filtering condition in the configuration parameter to obtain the original message, the method further includes: Determine an original message with a virtual local area network VLAN tag among multiple original messages; The original message with the VLAN tag is discarded.

10. 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 vehicle Ethernet in the target data as a sending end; 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 a receiving end in the target data.

11. A message processing device for vehicle-mounted Ethernet, characterized in that: include: A configuration generation module, used to obtain a 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 a filtering condition in the configuration parameters according to the network address in the service matrix file; A message capture module, used to determine the target network card device corresponding to the network card device identifier in the configuration parameters in the vehicle Ethernet, and to 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, used for performing 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.

12. 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 10 when executing the executable instructions stored in the memory.

13. A computer-readable storage medium, characterized in that: Executable instructions are stored, and when executed by a processor, the method described in any one of claims 1 to 10 is implemented.

Images