A vehicle testing method, system, device and computer readable storage medium

Abstract

The application discloses a vehicle testing method, system, device and computer readable storage medium, relates to the technical field of vehicle development and testing, and obtains a service interface description file of a SOME / IP protocol; the service interface description file is parsed to obtain metadata; a simulation end is constructed based on a data packet operation library according to the metadata, the data packet operation library is used for capturing original network messages at a data link layer; the simulation end is applied to establish a communication connection with a target component in a vehicle; the simulation end is applied to interact with the target component based on the communication connection and the SOME / IP protocol; and a test result of the target component is generated according to an interaction result of the SOME / IP protocol. The application does not need to depend on a Vector CANoe tool, reduces test cost, improves test flexibility, the simulation end can simulate a real vehicle-mounted network environment based on multicast discovery, test accuracy and platform compatibility are enhanced, and the application has good applicability.

Description

Technical Field

[0001] This application relates to the field of vehicle development and testing technology, and more specifically, to a vehicle testing method, system, device, and computer-readable storage medium. Background Technology

[0002] In the development and testing of vehicle electronic systems, SOME / IP (Scalable service-oriented middleware over IP) protocol testing typically relies on specific tools, such as Vector CANoe. However, these tools are expensive, have strong hardware dependencies, require complex manual configuration, and cannot reliably capture and process multicast packets widely used in automotive Ethernet, resulting in high limitations and poor applicability for vehicle testing.

[0003] In conclusion, improving the applicability of vehicle testing based on the SOME / IP protocol is a problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0004] The purpose of this application is to provide a vehicle testing method that can, to some extent, address the technical problem of how to improve the applicability of vehicle testing based on the SOME / IP protocol. This application also provides a vehicle testing system, electronic equipment, and a computer-readable storage medium.

[0005] To achieve the above objectives, this application provides the following technical solution: A vehicle testing method, comprising: Obtain the service interface description file for the SOME / IP protocol; The service interface description file is parsed to obtain metadata; Based on the aforementioned metadata, a simulation terminal is constructed using a packet manipulation library, which is used to capture raw network packets at the data link layer. Using the simulation terminal, a communication connection is established between the simulation terminal and the target component to be tested in the vehicle; Based on the communication connection, the simulation terminal is used to interact with the target component via the SOME / IP protocol. Based on the interaction results of the SOME / IP protocol, the test results of the target component are generated.

[0006] In an exemplary embodiment, the application of the simulation terminal to establish a communication connection with the target component to be tested in the vehicle includes: Using the aforementioned simulation terminal, obtain UDP packets; Extract the raw payload of the UDP packet; The original payload is parsed to obtain the SOME / IP protocol header data; In response to the fact that the SOME / IP header contains an identifier of the target component to be tested in the vehicle, the original payload is parsed into an SD header; A communication connection is established with the target component based on the entries in the SD protocol header.

[0007] In an exemplary embodiment, establishing a communication connection with the target component based on entries in the SD protocol header includes: The entries in the SD protocol header are parsed; If the entry in the SD protocol header is a FindService entry, then the target content in the FindService entry is copied to obtain a copied entry; Change the type of the copied entry to an OfferService entry; Enter your own port number into the OfferService entry; The OfferService entry is packaged into an SD message and sent to the target component in unicast form.

[0008] In an exemplary embodiment, after parsing the entries in the SD protocol header, the method further includes: If the entry in the SD protocol header is an OfferService entry, then the OfferService entry is copied to generate a Subscribe entry. The Subscribe entry contains its own port number for receiving event notifications. Subscribe entries are sent to the target component via unicast.

[0009] In an exemplary embodiment, after parsing the entries in the SD protocol header, the method further includes: If the entry in the SD protocol header is a SubscribeAck entry, then the communication connection with the target component is established. If the entry in the SD protocol header is a SubscribeNAck entry, an error log is logged and the Subscribe entry is resent to the target component.

[0010] In an exemplary embodiment, obtaining the service interface description file of the SOME / IP protocol includes: Obtain the service interface description file of the SOME / IP protocol. The service interface description file includes basic service information, data types used by the service interface, service communication behavior data, parameters used for service discovery, and ECU network configuration data. The basic service information includes service ID, service name, major version number, and minor version number; the data types used by the service interface include structures, arrays, and enumerations; the service communication behavior data includes methods and events; the parameters used for service discovery include multicast address, time to live, and SD_Entry configuration; and the ECU network configuration data includes ECU name, VLAN_ID, IP_Address, and the name of the bound network interface card.

[0011] In an exemplary embodiment, constructing the simulation terminal based on the data packet manipulation library according to the metadata includes: Based on the aforementioned metadata, a simulation client is built using the Scapy library.

[0012] A vehicle testing system, comprising: The file acquisition module is used to obtain the service interface description file of the SOME / IP protocol. The parsing module is used to parse the service interface description file to obtain metadata; The configuration module is used to build a simulation terminal based on the data packet manipulation library according to the metadata. The data packet manipulation library is used to capture raw network packets at the data link layer. The communication establishment module is used to establish a communication connection between the simulation terminal and the target component to be tested in the vehicle. The interaction module is used to interact with the target component via the SOME / IP protocol based on the communication connection and the simulation terminal. The test result generation module is used to generate test results for the target component based on the interaction results of the SOME / IP protocol.

[0013] An electronic device, comprising: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of any of the vehicle testing methods described above.

[0014] A computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of any of the vehicle testing methods described above.

[0015] This application provides a vehicle testing method that involves: obtaining a service interface description file for the SOME / IP protocol; parsing the service interface description file to obtain metadata; constructing a simulation terminal based on a packet manipulation library according to the metadata, the packet manipulation library being used to capture raw network packets at the data link layer; establishing a communication connection between the simulation terminal and the target component under test in the vehicle; interacting with the target component using the SOME / IP protocol based on the communication connection; and generating test results for the target component based on the interaction results of the SOME / IP protocol. This application can automatically construct a SOME / IP protocol simulation terminal according to the service interface description file of the SOME / IP protocol, and use the simulation terminal to interact with the target component under test in the vehicle to determine the test results. It can automatically complete the simulation test of the vehicle SOME / IP protocol without relying on tools such as Vector CANoe, reducing testing costs and improving testing flexibility. Furthermore, the packet manipulation library used in the simulation terminal has the ability to capture raw network packets at the data link layer, simulating a real, multicast-discovery-based in-vehicle network environment, enhancing test accuracy and platform compatibility, and demonstrating good applicability. The vehicle testing system, electronic device, and computer-readable storage medium provided in this application also solve the corresponding technical problems. Attached Figure Description

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

[0017] Figure 1 A flowchart of a vehicle testing method provided in this application embodiment; Figure 2 A schematic diagram of the data flow for vehicle testing; Figure 3 A schematic diagram of the interaction sequence for service discovery; Figure 4 Architecture diagram for vehicle testing; Figure 5 This is a diagram illustrating a multi-VLAN deployment. Figure 6 This is a schematic diagram of the structure of a vehicle testing system provided in an embodiment of this application; Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application; Figure 8 This is another structural schematic diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0018] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0019] Please see Figure 1 , Figure 1 This is a flowchart of a vehicle testing method provided in an embodiment of this application.

[0020] This application provides a vehicle testing method that may include the following steps: Step S101: Obtain the service interface description file of the SOME / IP protocol.

[0021] In practical applications, when testing target components in a vehicle based on the SOME / IP protocol, a simulation terminal capable of communicating with the target component is required. This application can independently generate such a simulation terminal. Considering that the interaction between the simulation terminal and the target component based on the SOME / IP protocol is a client-server type, a service interface description file for the SOME / IP protocol can be obtained to subsequently build the simulation terminal using this service interface description file. It should be noted that the type of target component can be flexibly determined according to the vehicle's development requirements, such as the vehicle's intelligent driving domain, etc., without specific limitations here.

[0022] In an exemplary embodiment, the content of the obtained SOME / IP protocol service interface description file can be flexibly set according to the application scenario. For example, the obtained SOME / IP protocol service interface description file includes basic service information (Service Definition), data types used by the service interface (Data Type), service communication behavior data (SOMEIP Com Behavior), parameters used for service discovery (SOMEIP-SD Definition), and ECU (Electronic Control Unit) network configuration data (SOMEIP-SD ECU Configuration). The basic service information includes service ID (service_id), service name (service_name), major version number (major_version), and minor version number (minor_version), etc. The data types used by the service interface include structures (Struct), arrays (Array), enumerations (Enum), etc. For example, a record can contain type_name (type name), base_type (base type, such as uint32, float, string), array_length (if it is an array), struct_members (if it is a structure, a list of record members), etc. The service communication behavior data includes... The service interface description file can include methods and events. Each record can contain a method_id or event_id (ID number, uint16 type), name, message_type (message type, such as REQUEST, RESPONSE, NOTIFICATION, FIRE_AND_FORGET), reliability (whether the transmission is reliable), etc. Parameters used for service discovery include multicast address, time-to-live (TTL), and SD_Entry configuration. ECU network configuration data includes ECU name (ECU_Name), VLAN_ID, IP_Address, and the name of the bound network interface card (Network_Interface), etc. Furthermore, the service interface description file can be an Excel file or an ARXML file, etc., without specific limitations.

[0023] Step S102: Parse the service interface description file to obtain metadata.

[0024] Step S103: Based on the metadata, construct the simulation terminal using the packet manipulation library, which is used to capture raw network packets at the data link layer.

[0025] In practical applications, when obtaining the service interface description file of the SOME / IP protocol, the service interface description file can be parsed first to obtain metadata used to guide the simulation terminal to interact with the target component using the SOME / IP protocol. The metadata can be a nested dictionary or a collection of instances of custom classes. For example, the metadata can be obtained by recursively processing the nested data structures in the service interface description file. For instance, when parsing a structure type, its struct_members list can be looked up. If the members are still custom types, the parsing continues recursively until all members are basic data types (such as int, float). After parsing, all service information is converted into an internally unified, object-oriented metadata structure; then the simulation terminal is built according to the metadata. In this process, considering the limitations of the standard socket API in capturing non-native destination IP packets (especially multicast packets) passing through the network interface, such as FindService requests typically being sent to predefined multicast addresses (e.g., 239.255.0.0 / 16), standard transport layer sockets cannot reliably capture and process multicast packets widely used in automotive Ethernet, for example, they cannot implement SOME / IP SD (Service... The critical FindService / OfferService broadcast / multicast discovery mechanism in the Discovery protocol, especially in multi-VLAN or complex network configurations, suffers from significant shortcomings. This necessitates complex low-level socket option settings and results in poor cross-platform compatibility. To address this issue, this application constructs the simulation client based on a packet manipulation library. This library is used to capture raw network packets at the data link layer. The simulation client can then use the packet manipulation library to set the network card to promiscuous mode or leverage its low-level packet capture mechanism to ensure that all UDP packets (unicast, broadcast, or multicast) related to the target service_id or originating from the server_ip are reliably captured. This simulates a real, multicast-discovery-based in-vehicle network environment, enhancing test accuracy and platform compatibility. It should be noted that when the target component is a client in the SOME / IP protocol, the constructed simulation client is a server; conversely, when the target component is a server in the SOME / IP protocol, the constructed simulation client is a client.

[0026] In an exemplary embodiment, the type of packet manipulation library can be flexibly selected according to actual needs, as long as it can capture raw network packets at the data link layer. For example, in the process of building a simulation terminal based on the packet manipulation library according to metadata, the simulation terminal can be built based on the scapy library according to the metadata.

[0027] In specific application scenarios, the code for building a simulation terminal based on the scapy library can be as follows: from scapy.all import sniff, Ether, IP, UDP; # Start listening, key point: use scapy's sniff and specify the network interface; The `filter` parameter can be flexibly configured, for example, to capture packets from a specific source IP or a specific UDP port; sniff( filter=f\"udp and (host {self.para.server_ip} or dst net 239.255.0.0 / 16)\", # Capture UDP packets from the server or destined for the SD multicast address; iface=self.para.network_interface, # Get the bound network interface name from the configuration; prn = self.auto_subscribe, # Callback function; store=False # Do not store messages, saving memory; ).

[0028] In an exemplary embodiment, the simulation client can also be built based on the Python open-source ecosystem (such as pysomeip). In this way, with the help of the pysomeip library and scapy, a complete SOME / IP client function can be implemented without relying on expensive commercial tools such as Vector CANoe and dedicated hardware. It can run using only the standard Ethernet interface of an ordinary computer, simplifying hardware requirements and reducing testing costs. In addition, the scapy library provides the ability to capture raw network packets at the data link layer (Layer 2), which can reliably capture all packets flowing through the network interface, including packets whose destination address is a multicast address (such as the default 239.255.0.0 / 16 network segment of SOME / IPSD). This allows the simulation client to automatically complete the cumbersome service discovery and service subscription processes in the SOME / IP protocol and simulate complete service interaction behaviors, including remote method calls (RPC) and event notifications, to achieve comprehensive testing of the real SOME / IP server or network environment, and thus achieve accurate simulation of the real in-vehicle Ethernet environment.

[0029] In specific application scenarios, the simulation end can be constructed using the `parameters` data class. Taking Python `dataclass` as an example, the definition of the `parameters` data class can be: import dataclasses; import struct; from typing import ClassVar; @dataclasses.dataclass(frozen=True); class parameters: """Immutable configuration parameter set for the simulation client."""; # Protocol header format reference (not the actual complete format); __format: ClassVar[struct.Struct] = struct.Struct("!HHIHHBBBB"); ; # Network configuration; client_ip: str # The simulated client's own IP address; server_ip: str # The IP address of the target server being tested; client_port: int # The UDP port for the simulated client; server_port: int # Target server UDP port; ; # SOME / IP service configuration; service_id: int # Target service ID; method_id: list[int] # List of method IDs to be simulated; ttl: int # Subscription time-to-live (seconds); payload: bytes = b"" # Default message payload.

[0030] Step S104: Use the simulation terminal to establish a communication connection with the target component to be tested in the vehicle.

[0031] In practical applications, after building a simulation terminal that can simulate a real, multicast-discovery-based in-vehicle network environment, the simulation terminal can be used to establish a communication connection with the target component to be tested in the vehicle, providing a foundation for subsequent SOME / IP protocol interaction with the target component.

[0032] In an exemplary embodiment, the process of establishing a communication connection between the application simulation terminal and the target component under test in the vehicle can be implemented by the SomeIpClient class in the someipclient.py module. For example, the application simulation terminal first obtains UDP packets and extracts the raw payload of the UDP packets, for example, by extracting the raw payload of the UDP packets using the auto_subscribe method; then, using pysomeip or a custom parsing library, the raw payload is parsed to obtain the SOME / IP protocol header data (SOMEIPHeader); in response to the SOME / IP protocol header containing the identifier of the target component under test in the vehicle, that is, service_id is a dedicated ID of SOME / IP SD (service discovery), which can be 0xFFFF, etc., the raw payload is parsed into an SD protocol header (SOMEIPSDHeader), where the identifier of the target component can be provided by the service interface description file, etc.; and finally, a communication connection is established with the target component based on the entry (SOMEIPSDEntry) in the SD protocol header.

[0033] In specific application scenarios, during the process of establishing a communication connection with the target component based on the entries in the SD protocol header, Python's match-case statement (or other equivalent multi-branch logic) can be used to implement this process. Specifically, the entries in the SD protocol header are first parsed; if the response in the SD protocol header is a FindService entry, it indicates that a component on the network is looking for this service. At this time, the emulator client automatically constructs an OfferService entry as a response, that is, copies the target content in the FindService entry, for example, by calling the copy_entire method to copy and obtain a copied entry. The target content can be a service ID, instance ID, etc.; the type of the copied entry is changed to an OfferService entry; the client's own port number is filled into the OfferService entry, which can be self.para.client_port; the OfferService entry is packaged into an SD message and sent to the target component in unicast form to simulate the process of a service provider going online and announcing itself, so that the target component can find the emulator client using this port number and thus establish a communication connection.

[0034] In specific application scenarios, after parsing the entries in the SD protocol header, if the response in the SD protocol header is an OfferService entry, it indicates that the target component is online and has announced its service. The simulation end needs to automatically initiate a subscription, which means that the OfferService entry needs to be copied, for example, using the copy_entire method to copy it and generate a Subscribe entry. The Subscribe entry contains its own port number used to receive event notifications. The Subscribe entry is sent to the target component in unicast form so that the target component can receive events using this port number.

[0035] In specific application scenarios, after parsing the entries in the SD protocol header, if the response in the SD protocol header is a SubscribeAck entry, it indicates that the target component has confirmed the subscription, and the simulation end immediately enters the "connected" state, thus completing the establishment of a communication connection with the target component. If the response in the SD protocol header is a SubscribeNAck entry, it indicates that the subscription has been rejected. The simulation end can record an error log and wait for a random period of time before resending the Subscribe entry to the target component to test the target component's error handling capabilities. Of course, other operations are also possible, and no specific limitations are made here. The data flow in this process can be as follows: Figure 2 As shown, service discovery sequence interactions can be as follows: Figure 3 As shown.

[0036] Step S105: Based on the communication connection, use the application simulation terminal to interact with the target component via the SOME / IP protocol.

[0037] Step S106: Generate the test results of the target component based on the interaction results of the SOME / IP protocol.

[0038] In practical applications, after establishing a communication connection with the target component, the simulation client can interact with the target component via the SOME / IP protocol based on this connection. Interaction methods can include calling remote methods (Request & Response), one-way communication (Fire & Forget), receiving event data published by the server (Notification), and accessing service fields (Getter / Setter). Then, based on the interaction results of the SOME / IP protocol, test results for the target component are generated. The complete process can be described as follows: Figure 4 As shown.

[0039] In an exemplary embodiment, during the SOME / IP protocol interaction with the target component, after receiving the SubscribeAck entry, periodic test data transmission can be automatically initiated. For example, a loop can be started, within which application messages of the SOME / IP NOTIFICATION type are constructed according to a predefined time interval, such as 200ms. The payload content of the application message can be configured according to test needs, such as b"\xde\xad", etc., and then the application message is sent to the target component. This process continues within the loop until the TTL time specified in the OfferService entry is reached, to simulate the scenario in the SOME / IP protocol where the server continuously pushes event data to the client. This can be used to test the server's concurrent processing capabilities, network stability, etc.

[0040] In an exemplary embodiment, during the interaction with the target component via the SOME / IP protocol, the interaction can be conducted through messages exchanged with the target component. For example, if a SOME / IP application message, such as an RPC response, is received from the target component, it can be passed to a user-customizable message handling handle (user_message_handler) to verify the correctness of the target component's business logic.

[0041] It should be noted that multiple simulation clients can be instantiated simultaneously as SomeIpClient objects according to the scheme of this application. Specifically, service information in the metadata can be read, combined with predefined network configurations (such as VLAN and IP mapping relationships) extracted from the "SOMEIP-SD ECUConfiguration" table, to automatically instantiate one or more parameter objects. An available simulation client port number is assigned to each service instance to be simulated, and its bound network interface is determined. Then, each object corresponds to an independent service instance or ECU role, and these instances can run on different network interfaces or ports on the same machine, thereby constructing a complex, distributed SOME / IP system simulation test environment to simulate a multi-VLAN (Virtual Local Area Network) test environment, such as... Figure 5 As shown.

[0042] This application provides a vehicle testing method that involves: obtaining a service interface description file for the SOME / IP protocol; parsing the service interface description file to obtain metadata; constructing a simulation terminal based on a packet manipulation library according to the metadata, the packet manipulation library being used to capture raw network packets at the data link layer; establishing a communication connection between the simulation terminal and the target component under test in the vehicle; interacting with the target component using the SOME / IP protocol based on the communication connection; and generating test results for the target component based on the interaction results of the SOME / IP protocol. This application can automatically construct a SOME / IP protocol simulation terminal according to the service interface description file of the SOME / IP protocol, and use the simulation terminal to interact with the target component under test in the vehicle to determine the test results. It can automatically complete the simulation test of the vehicle SOME / IP protocol without relying on tools such as Vector CANoe, reducing testing costs and improving testing flexibility. Furthermore, the packet manipulation library used in the simulation terminal has the ability to capture raw network packets at the data link layer, simulating a real, multicast-discovery-based in-vehicle network environment, enhancing test accuracy and platform compatibility, and demonstrating good applicability.

[0043] Please see Figure 6 , Figure 6 A schematic diagram of the structure of a vehicle testing system provided in this application embodiment. Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0044] This application provides a vehicle testing system that may include: The file acquisition module 101 is used to acquire the service interface description file of the SOME / IP protocol. Parsing module 102 is used to parse the service interface description file to obtain metadata; Configuration module 103 is used to build a simulation terminal based on the data packet manipulation library according to the metadata. The data packet manipulation library is used to capture raw network packets at the data link layer. The communication establishment module 104 is used by the application simulation terminal to establish a communication connection with the target component to be tested in the vehicle. Interaction module 105 is used to interact with the target component via SOME / IP protocol based on the communication connection and application simulation terminal; The test result generation module 106 is used to generate test results for the target component based on the interaction results of the SOME / IP protocol.

[0045] This application provides a vehicle testing system, wherein the communication establishment module may include: The UDP packet acquisition unit is used by the application simulation end to acquire UDP packets. The raw payload extraction unit is used to extract the raw payload of UDP packets; The load parsing unit is used to parse the raw load and obtain the SOME / IP protocol header data; The protocol header parsing unit is used to parse the original payload into an SD protocol header in response to the SOME / IP protocol header containing the identifier of the target component to be tested in the vehicle; The communication establishment unit is used to establish a communication connection with the target component according to the entries in the SD protocol header.

[0046] This application provides a vehicle testing system in which a communication establishment unit is configured to: parse entries in the SD protocol header; in response to an entry in the SD protocol header being a FindService entry, copy the target content in the FindService entry to obtain a copied entry; modify the type of the copied entry to an OfferService entry; fill in its own port number into the OfferService entry; package the OfferService entry into an SD message and send the SD message to the target component in unicast form.

[0047] This application provides a vehicle testing system in which the communication establishment unit parses the entries in the SD protocol header. If the entry in the SD protocol header is an OfferService entry, the OfferService entry is copied to generate a Subscribe entry. The Subscribe entry contains its own port number used to receive event notifications. The Subscribe entry is then sent to the target component in unicast form.

[0048] The vehicle testing system provided in this application embodiment includes a communication establishment unit that, after parsing the entries in the SD protocol header, completes the establishment of a communication connection with the target component if the entry in the SD protocol header is a SubscribeAck entry; otherwise, it records an error log and resends the Subscribe entry to the target component if the entry in the SD protocol header is a SubscribeNAck entry.

[0049] This application provides a vehicle testing system, in which a file acquisition module may include: The file acquisition unit is used to acquire the service interface description file of the SOME / IP protocol. The service interface description file includes basic service information, data types used by the service interface, service communication behavior data, parameters used for service discovery, and ECU network configuration data. The basic service information includes service ID, service name, major version number, and minor version number; the data types used by the service interface include structures, arrays, and enumerations; the service communication behavior data includes methods and events; the parameters used for service discovery include multicast address, time to live, and SD_Entry configuration; and the ECU network configuration data includes ECU name, VLAN_ID, IP_Address, and the name of the bound network interface card.

[0050] This application provides a vehicle testing system, the configuration module of which may include: The configuration unit is used to build the simulation client based on the Scapy library according to the metadata.

[0051] This application also provides an electronic device and a computer-readable storage medium, both of which have the corresponding effects of the vehicle testing method provided in the embodiments of this application. Please refer to... Figure 7 , Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0052] An electronic device provided in this application includes a memory 201 and a processor 202. The memory 201 stores a computer program, and the processor 202 executes the computer program to implement the steps of the vehicle testing method described in any of the above embodiments.

[0053] Please see Figure 8 Another electronic device provided in this application embodiment may further include: an input port 203 connected to the processor 202 for transmitting commands input from the outside to the processor 202; a display unit 204 connected to the processor 202 for displaying the processing results of the processor 202 to the outside; and a communication module 205 connected to the processor 202 for enabling communication between the electronic device and the outside. The display unit 204 may be a display panel, a laser scanning display, etc.; the communication method adopted by the communication module 205 includes, but is not limited to, Mobile High-Definition Link (MHL), Universal Serial Bus (USB), High-Definition Multimedia Interface (HDMI), wireless connection: Wireless Fidelity (WiFi), Bluetooth communication technology, Bluetooth Low Energy communication technology, and communication technology based on IEEE 802.11s.

[0054] This application provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the steps of the vehicle testing method described in any of the above embodiments.

[0055] The computer-readable storage media involved in this application include random access memory (RAM), memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disks, removable disks, CD-ROMs (compact disc read-only memory), or any other form of storage media known in the art.

[0056] This application provides a computer program product, including a computer program / instructions, which, when executed by a processor, implement the steps of the vehicle testing method described in any of the above embodiments.

[0057] For descriptions of relevant parts of the vehicle testing system, electronic device, and computer-readable storage medium provided in this application's embodiments, please refer to the detailed description of the corresponding parts in the vehicle testing method provided in this application's embodiments; they will not be repeated here. Furthermore, parts of the technical solutions provided in this application that are consistent with the implementation principles of corresponding technical solutions in the prior art have not been described in detail to avoid excessive elaboration.

[0058] It should also be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0059] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A vehicle testing method, characterized in that, include: Obtain the service interface description file for the SOME / IP protocol; The service interface description file is parsed to obtain metadata; Based on the aforementioned metadata, a simulation terminal is constructed using a packet manipulation library, which is used to capture raw network packets at the data link layer. Using the simulation terminal, a communication connection is established between the simulation terminal and the target component to be tested in the vehicle; Based on the communication connection, the simulation terminal is used to interact with the target component via the SOME / IP protocol. Based on the interaction results of the SOME / IP protocol, the test results of the target component are generated.

2. The method according to claim 1, characterized in that, The application of the simulation terminal establishes a communication connection with the target component to be tested in the vehicle, including: Using the aforementioned simulation terminal, obtain UDP packets; Extract the raw payload of the UDP packet; The original payload is parsed to obtain the SOME / IP protocol header data; In response to the fact that the SOME / IP header contains an identifier of the target component to be tested in the vehicle, the original payload is parsed into an SD header; A communication connection is established with the target component based on the entries in the SD protocol header.

3. The method according to claim 2, characterized in that, The step of establishing a communication connection with the target component based on the entries in the SD protocol header includes: The entries in the SD protocol header are parsed; If the entry in the SD protocol header is a FindService entry, then the target content in the FindService entry is copied to obtain a copied entry; Change the type of the copied entry to an OfferService entry; Enter your own port number into the OfferService entry; The OfferService entry is packaged into an SD message and sent to the target component in unicast form.

4. The method according to claim 3, characterized in that, After parsing the entries in the SD protocol header, the process also includes: If the entry in the SD protocol header is an OfferService entry, then the OfferService entry is copied to generate a Subscribe entry. The Subscribe entry contains its own port number for receiving event notifications. Subscribe entries are sent to the target component via unicast.

5. The method according to claim 4, characterized in that, After parsing the entries in the SD protocol header, the process also includes: If the entry in the SD protocol header is a SubscribeAck entry, then the communication connection with the target component is established. If the entry in the SD protocol header is a SubscribeNAck entry, an error log is logged and the Subscribe entry is resent to the target component.

6. The method according to claim 1, characterized in that, The process of obtaining the SOME / IP protocol service interface description file includes: Obtain the service interface description file of the SOME / IP protocol. The service interface description file includes basic service information, data types used by the service interface, service communication behavior data, parameters used for service discovery, and ECU network configuration data. The basic service information includes service ID, service name, major version number, and minor version number; the data types used by the service interface include structures, arrays, and enumerations; the service communication behavior data includes methods and events; the parameters used for service discovery include multicast address, time to live, and SD_Entry configuration; and the ECU network configuration data includes ECU name, VLAN_ID, IP_Address, and the name of the bound network interface card.

7. The method according to claim 1, characterized in that, The step of constructing a simulation client based on the data packet manipulation library according to the metadata includes: Based on the aforementioned metadata, a simulation client is built using the Scapy library.

8. A vehicle testing system, characterized in that, include: The file acquisition module is used to obtain the service interface description file of the SOME / IP protocol. The parsing module is used to parse the service interface description file to obtain metadata; The configuration module is used to build a simulation terminal based on the data packet manipulation library according to the metadata. The data packet manipulation library is used to capture raw network packets at the data link layer. The communication establishment module is used to establish a communication connection between the simulation terminal and the target component to be tested in the vehicle. The interaction module is used to interact with the target component via the SOME / IP protocol based on the communication connection and the simulation terminal. The test result generation module is used to generate test results for the target component based on the interaction results of the SOME / IP protocol.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the vehicle testing method as described in any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the vehicle testing method as described in any one of claims 1 to 7.

Images