Communication test method and device based on vehicle and electronic equipment
The vehicle-based communication test method and device improve testing efficiency by leveraging the Python vehicle Ethernet Tx to T1 tool and UDS protocol stack for automated diagnostic routing, addressing the challenge of frequent software updates in automotive systems.
Patent Information
- Application Number
- CN202411123614.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-08-15
- Publication Date
- 2024-12-06
AI Technical Summary
The challenge of improving communication test efficiency for vehicle controllers, particularly in the context of frequent software iterations, has become urgent due to the increasing complexity and frequency of software updates in automotive systems.
A vehicle-based communication test method and device that utilizes the Python vehicle Ethernet Tx to T1 tool, integrating the Unified Diagnostic Services (UDS) protocol stack and DoIP module, enabling automated diagnostic routing tests through json configuration and parsing of CAN messages, with support for both CAN and Ethernet protocols.
Enhances the efficiency of communication testing by allowing developers to perform rapid, automated tests on vehicle controllers, ensuring normal communication and reducing the likelihood of software iteration failures.
Smart Images

Figure CN119094378A_ABST
Abstract
Description
Technical Field
[0001] The embodiments of the present invention relate to the field of communication technology, and in particular to a vehicle-based communication test method, device and electronic equipment. Background Art
[0002] At present, the software installed in the controller in the vehicle is frequently iterated, so the demand for controller testing has increased sharply. The communication test of the controller in the vehicle is an important part of the test requirements of the controller. Therefore, how to improve the communication test efficiency of the controller in the vehicle has become an urgent problem to be solved. Summary of the invention
[0003] In view of the above problems, embodiments of the present invention provide a vehicle-based communication test method, device and electronic device, which are used to solve the problem existing in the prior art of how to improve the communication test efficiency of a controller in a vehicle.
[0004] According to one aspect of an embodiment of the present invention, a vehicle-based communication test method is provided, the method comprising:
[0005] Acquire a test case of a controller to be tested in a vehicle; wherein the test case includes at least one test information, and the test information has routing information; the routing information includes a first message type and a second message type, wherein the first message type is a message type required by the controller to be tested to receive the test information, and the second message type is a message type of feedback results of the test information sent by the controller to be tested;
[0006] Based on the first message type corresponding to the test information, encapsulate the test information to obtain a test message, and send the test message to the controller to be tested; wherein the test message is used to obtain a feedback message;
[0007] The feedback message sent by the controller to be tested is received, and based on the second message type corresponding to the test information, the feedback message is parsed to obtain a test result corresponding to the test case.
[0008] According to another aspect of an embodiment of the present invention, there is provided a vehicle-based communication test device, comprising:
[0009] An acquisition module, used for acquiring a test case of a controller to be tested in a vehicle; wherein the test case includes at least one test information, and the test information has routing information; the routing information includes a first message type and a second message type, wherein the first message type is a message type required by the controller to be tested to receive the test information, and the second message type is a message type of a feedback result of the test information sent by the controller to be tested;
[0010] A test module is used to encapsulate the test information based on a first message type corresponding to the test information to obtain a test message, and send the test message to the controller under test; wherein the test message is used to obtain a feedback message; receive the feedback message sent by the controller under test, and parse the feedback message based on a second message type corresponding to the test information to obtain a test result corresponding to the test case.
[0011] According to another aspect of an embodiment of the present invention, a computer-readable storage medium is provided, wherein the storage medium stores at least one executable instruction, and the executable instruction enables an electronic device to execute the operation of the above method.
[0012] The embodiment of the present invention parses the routing information of the test case to determine the first message type required when the controller under test receives the test information and the corresponding second message type when the controller under test outputs the feedback message, so that the electronic device can convert the test information corresponding to the test case into a test message of the first message type, receive the feedback message corresponding to the second message type, and parse it to obtain the test result, thereby realizing rapid testing of the test case and improving the efficiency of communication testing.
[0013] The above description is only an overview of the technical solution of the embodiment of the present invention. In order to more clearly understand the technical means of the embodiment of the present invention, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the embodiment of the present invention more obvious and easy to understand, the specific implementation methods of the present invention are listed below. BRIEF DESCRIPTION OF THE DRAWINGS
[0014] The accompanying drawings are only used to illustrate the embodiments and are not to be considered as limiting the present invention. In addition, the same reference symbols are used to represent the same components throughout the accompanying drawings. In the accompanying drawings:
[0015] Figure 1 A schematic flow chart of a first embodiment of a vehicle-based communication test method provided by the present invention is shown;
[0016] Figure 2 A schematic diagram of information flow between modules of a vehicle-based communication test method provided by the present invention is shown;
[0017] Figure 3 A schematic structural diagram of a first embodiment of a vehicle-based communication test device provided by the present invention is shown;
[0018] Figure 4 A schematic structural diagram of an embodiment of an electronic device provided by the present invention is shown. DETAILED DESCRIPTION
[0019] Exemplary embodiments of the present invention will be described in more detail below with reference to the accompanying drawings. Although exemplary embodiments of the present invention are shown in the drawings, it should be understood that the present invention can be implemented in various forms and should not be limited to the embodiments set forth herein.
[0020] The current automobile industry is booming, and automobiles are developing rapidly in the direction of electrification and intelligence. The software installed in the controllers in the vehicle is being iterated more and more frequently. Reducing the possibility of software iteration failure due to manual operation factors can effectively improve the normal and efficient integrated iteration of the software versions installed in the controllers in the vehicle. Therefore, the work of integrating and processing the calibration data of the controllers in the vehicle is becoming more and more important. In order to more effectively obtain the calibration data of the controllers in the vehicle, it is a prerequisite to ensure that the communication of the controllers in the vehicle is normal. Therefore, how to improve the communication test efficiency of the controllers in the vehicle has become a problem that needs to be solved urgently.
[0021] In order to solve the above problems, the present invention proposes a vehicle-based communication test method. This method can be based on the python vehicle Ethernet Tx to T1 tool, so that developers can directly and easily implement the effect of testing the diagnostic routing of the controller in the vehicle through simple json configuration. And the vehicle-based communication test method integrates the Unified Diagnostic Services (UDS) protocol stack, so that developers can use python to perform UDS diagnostic tests based on the Diagnostic Communication Protocol (Diagnostic Communication over Internet Protocol, DoIP).
[0022] The application mainly realizes the development of a DoIP module. The DoIP module not only realizes the various services in the DoIP specification, but also realizes the UDS protocol and the adaptation of DoIP and UDS. In addition, the vehicle-based communication test method also realizes the callback of the specified CAN message and signal received by different CAN channels based on the dynamic library of ZLGCAN.DLL. Finally, the present invention can realize the automated test of diagnostic routing for different controllers by parsing the json configuration file.
[0023] Specifically, the present invention first needs to prepare ZLG USBCANFD-400U. The ZLG USBCANFD-400U is an in-vehicle Ethernet Tx to T1 tool. Secondly, the developer can configure the source network segment and the target network segment of the UDS diagnostic routing message in the configuration file. Optionally, the source network segment may include a first message type required by the vehicle's controller to receive test information. The target network segment may include a second message type for feedback results of the test information issued by the vehicle's controller. Then, the developer can click on the test interface to start the diagnostic routing test between DoIP and CANFD. Developers can obtain and view the test results. The test result can be the result of whether the communication indicated by the diagnostic routing test between DoIP and CANFD is normal.
[0024] Figure 1 FIG. 1 is a flow chart showing a first embodiment of a vehicle-based communication test method according to the present invention, wherein the method is executed by an electronic device. Figure 1 As shown, the method comprises the following steps:
[0025] Step 110: Obtain a test case of the controller to be tested in the vehicle. The test case includes at least one test information, and the test information has routing information. The routing information includes a first message type and a second message type. The first message type is the message type required by the controller to be tested to receive the test information, and the second message type is the message type of the feedback result of the test information sent by the controller to be tested.
[0026] Among them, the electronic device can determine the controller to be tested in the vehicle that needs to be tested for routing diagnostic testing. The electronic device can obtain test cases for these controllers to be tested. Each test case implements a test on a controller to be tested. Each test case can include at least one test information. For example, in tests such as physical addressing and functional addressing, each test case can include a piece of test information. For another example, in throughput testing and jitter testing, each test case can include multiple test information.
[0027] Each test case may correspond to a piece of routing information. Furthermore, each piece of test information in the test case may correspond to the piece of routing information. Optionally, the routing information may include a first message type and a second message type. The first message type is the message type required for the controller under test to receive the test information. Optionally, the first message type may be the message type corresponding to the source network segment. Optionally, the source network segment may also include the network address when the controller under test receives the test message. The second message type is the message type of the feedback result of the test information sent by the controller under test. Optionally, the second message type may be the message type corresponding to the target network segment. Optionally, the target network segment may also include the network address of the feedback message sent by the controller under test.
[0028] The test information may also include data length. After obtaining the data length in the test information, the electronic device may generate data information according to the data length. Optionally, the data information may be a randomly generated string. Optionally, the data information is set to ensure that messages generated by data information of different data lengths are stable during actual transmission. Optionally, the data length may be a range of lengths. Optionally, the electronic device may randomly select a length from the data length to generate the random string. For example, the data length may be in a range of lengths such as 8-64 bytes, 64-4095 bytes, or more than 4095 bytes. Optionally, the electronic device may dynamically change the length of the data information in the test information by generating an action object containing different lengths. Optionally, such as Figure 2 As shown, the generation of the action object can be implemented in the router module. After generating the data information, the electronic device can write the data information into the test message. Optionally, after heating the data information to the test information, the electronic device can process the test to obtain the test message. Alternatively, the electronic device can also directly add the data information to the test message after generating the test message.
[0029] Step 120: Based on the first message type corresponding to the test information, encapsulate the test information to obtain a test message, and send the test message to the controller to be tested. The test message is used to obtain a feedback message.
[0030] Among them, the electronic device can obtain the first message type corresponding to each test information from the routing information. The electronic device can encapsulate the test information according to the first message type to obtain the test message. Optionally, the first message type can be a CAN type or an Ethernet type. That is, the encapsulated test message can be a CAN message or an Ethernet message. Optionally, the electronic device can send the test message to the corresponding controller to be tested according to the original network segment included in the routing information. Optionally, the controller to be tested can generate a feedback message after receiving the test message. Optionally, in the routing diagnosis test, the controller to be tested can read and parse the test message after obtaining the test message. Optionally, the controller to be tested can obtain parameters in the process of reading and parsing the message to be tested according to a preset routing diagnosis rule. The controller to be tested can generate the feedback message according to the parameter. For example, the parameter can be a delay in obtaining the message to be tested. For another example, the parameter can be the number of messages to be tested processed within a preset time length. For another example, the parameter may be a result of determining whether the length of the data information in the message to be tested read by the controller to be tested is correct.
[0031] The process of the electronic device obtaining the test message can be specifically divided into the following steps:
[0032] Step 121: Parse the routing information of the test information to obtain the first message type corresponding to the test information.
[0033] Among them, after obtaining a test information, the electronic device can obtain the routing information corresponding to the test information. The electronic device can parse the routing information to obtain the first message type therein. Optionally, the first message type is used to indicate the message type corresponding to the message when the controller to be tested receives the test information. Optionally, the message type may include a CAN type or an Ethernet type.
[0034] Step 122: When the first message type corresponding to the test information is of CAN type, the test information is encapsulated according to the CAN protocol to obtain a test message of CAN type.
[0035] Wherein, when the first message type corresponding to the test information is of CAN type, the electronic device may encapsulate the test information according to the CAN protocol to obtain a test message of CAN type. Optionally, the process of encapsulating the test information using the CAN protocol to obtain a test message of CAN type may be performed as follows: Figure 2 The CAN diagnostic message module shown is generated.
[0036] Optionally, during the generation of the test message, the electronic device can determine the sending node of the CAN message based on its own network segment. The electronic device can also parse routing information and obtain the source network segment in the routing information. The electronic device can determine the receiving node of the CAN message based on the source network segment. Optionally, the CAN message can also include information such as data length and sending timestamp.
[0037] Step 123: When the first message type corresponding to the test information is an Ethernet type, the test information is encapsulated according to the Ethernet protocol to obtain an Ethernet type test message.
[0038] Wherein, when the first message type corresponding to the test information is an Ethernet type, the electronic device can encapsulate the test information according to the Ethernet protocol to obtain an Ethernet type test message. Optionally, the process of encapsulating the test information using the Ethernet protocol to obtain an Ethernet type test message can be as follows: Figure 2 The Ethernet diagnostic message module shown is generated.
[0039] Optionally, during the test message generation process, the electronic device can determine the sending node of the Ethernet message based on its own network segment. The electronic device can also parse routing information and obtain the source network segment in the routing information. The electronic device can determine the receiving node of the Ethernet message based on the source network segment. Optionally, the Ethernet message can also include information such as data length and sending timestamp.
[0040] Optionally, the Ethernet protocol may also be an Ethernet diagnostic communication protocol. When the electronic device uses the Ethernet diagnostic communication protocol to encapsulate the test information, the specific encapsulation process is similar to that of the Ethernet protocol. The electronic device may encapsulate to obtain the test message.
[0041] When the first message type corresponding to the test information is a CAN type, the process of the electronic device sending the test message may include:
[0042] Step 124: Based on the CAN driver, access the CAN receiver of the controller under test to notify the CAN receiver of the controller under test that data needs to be transmitted. Send the test message to the controller under test through the transmission mode under the CAN protocol.
[0043] The CAN protocol may be a controller area network transmission protocol (CAN). The electronic device may complete the transmission of the test message based on a CAN driver and the CAN protocol. Specifically, the CAN driver on the electronic device may access the CAN receiver of the controller to be tested to notify the CAN receiver of the controller to be tested to receive the test message. Specifically, the test message may be transmitted through the transmission method of the CAN protocol.
[0044] When the first message type corresponding to the test information is an Ethernet type, the process of the electronic device sending the test message may include:
[0045] Step 125: Use the TCP / IP protocol to send the test message to the controller to be tested.
[0046] The electronic device can transmit the test message of the Ethernet message type through the TCP / IP protocol.
[0047] Step 130: receiving a feedback message sent by the controller to be tested, and parsing the feedback message based on the second message type corresponding to the test information to obtain a test result corresponding to the test case.
[0048] Among them, the electronic device can receive a feedback message sent by the controller under test. The feedback message can be a feedback message generated by the electronic device after collecting parameters of the controller under test after receiving the test message according to the test requirements of the routing diagnostic test. Optionally, the type of the feedback message can be determined according to the settings of the controller under test itself. Optionally, the controller under test can generate a parsing message based on the message type of the feedback message preset by itself and the parameters obtained according to the test message. Optionally, the type of the feedback message in the electronic device can be recorded as a second message type. Optionally,
[0049] Optionally, the feedback message may correspond to a second message type. The second message type may be a CAN message or an Ethernet message. Optionally, when the electronic device receives the feedback message, it may parse the feedback message according to the second message type. The electronic device may parse the feedback message to obtain a test result. The test result may be a test result corresponding to the test case. For example, when the test case is used for delay testing, the parsed result of the feedback message may include the duration of the delay, or the parsed result may include the timestamp when the electronic device sends the test message and the timestamp when the controller to be tested receives the test message. For another example, when the test case is used to test throughput, the timestamp of the feedback message may be the time stamp when the test message is received by the controller to be tested.
[0050] Optionally, the electronic device may also parse the feedback message based on the second message type corresponding to the test information, and parse the test result of the feedback message to obtain the parsing result. Optionally, the generation process of the parsing result may include the following two situations:
[0051] When the second message type corresponding to the test information is a CAN type, the feedback message is parsed based on the CAN protocol to obtain a parsing result of the CAN type corresponding to the feedback message.
[0052] When the second message type corresponding to the test information is an Ethernet type, the feedback message is parsed based on the Ethernet protocol to obtain a parsing result of the Ethernet type corresponding to the feedback message.
[0053] Optionally, the Ethernet protocol may be an Ethernet diagnostic communication protocol. Optionally, when the Ethernet protocol is an Ethernet diagnostic communication protocol, the electronic device may use the Ethernet diagnostic communication protocol to implement parsing of the feedback message.
[0054] Optionally, the electronic device may parse the routing information of the test case to obtain a second message type corresponding to the routing information. Optionally, the second message type may be a CAN message or an Ethernet message. Optionally, the electronic device may, based on the second message type, call a module corresponding to the second message type after sending a test message to parse a feedback message corresponding to the test message of the test case. When receiving the feedback message, the electronic device may implement the parsing through the module. Optionally, the module may be as follows: Figure 2 The CAN diagnostic message module or Ethernet diagnostic message module shown.
[0055] Optionally, the test result may include a parsing result corresponding to the feedback message. The electronic device may also analyze the parsing result, including the following steps:
[0056] Step 131: Obtain communication feedback information in the analysis result corresponding to the feedback message, wherein the communication feedback information indicates whether the communication is normal.
[0057] The electronic device may obtain the parsing result in the feedback message by parsing the feedback message. The parsing result may include communication feedback information. The communication feedback information indicates whether the communication corresponding to the test case is normal. For example, when the test case is used to test delay, the communication feedback information is used to indicate whether the delay corresponding to each test message is within a normal range.
[0058] Step 132: Determine the percentage of the analysis results of normal communication in each analysis result.
[0059] Among them, the electronic device can count the number of feedback messages with delays within a normal range in the communication feedback information of the feedback message of the test message corresponding to the test case. The electronic device can also count the number of test messages of the test case. The electronic device can also determine the proportion of feedback messages with delays within a normal range based on the number of feedback messages with delays within a normal range and the number of test messages of the test case.
[0060] Step 133: Obtain analysis results according to the percentage values, wherein the analysis results indicate whether the test for the test case is successful.
[0061] Among them, the electronic device can obtain the analysis result according to the percentage value. Optionally, the analysis result can be used to indicate the success or failure of the test. Or, the analysis result can be used to indicate the level of abnormality. For example, during the delay test, the electronic device can determine the proportion of delays according to the percentage value, thereby determining the level of delay. For example, a percentage of less than 1% can be level 1, indicating that no processing is required for the time being. For another example, a percentage between 1% and 5% can be level 2, indicating that continuous attention is required. For another example, a percentage greater than 5% can be level 3, indicating that further processing is required for the delay situation.
[0062] In the present invention, the electronic device can determine the controller to be tested in the vehicle that needs to be subjected to routing diagnostic testing. The electronic device can obtain test cases for these controllers to be tested. The test case includes at least one test information, and the test information has routing information. The routing information includes a first message type and a second message type, the first message type is the message type required for the controller to be tested to receive the test information, and the second message type is the message type for the feedback result of the test information sent by the controller to be tested. The electronic device can obtain the first message type corresponding to each test information from the routing information. The electronic device can encapsulate the test information according to the first message type to obtain the test message. The electronic device can receive the feedback message sent by the controller to be tested, and parse the feedback message based on the second message type corresponding to the test information to obtain the test result corresponding to the test case. The present invention can improve the test efficiency of the electronic device for the test case by generating the test message and parsing the feedback message.
[0063] Figure 2 The figure shows the information flow between modules of the vehicle-based communication test method of the present invention, which is executed by an electronic device. Figure 1 Based on the embodiment shown, the electronic device may include multiple modules, and the communication between the modules and the interaction with the test object may be as follows: Figure 2 As shown, it may specifically include:
[0064] Step 201: A router module may be provided in the electronic device. The router module is used to implement the parsing of the routing table. The router may store information such as the DoIP logical address, CAN DID, source network segment, and target network segment to be forwarded into the object of the router module. Optionally, in the router, each test information may correspond to creating an object of a router module.
[0065] Optionally, the rrouter module can configure the DoIP target address, port number, DoIP logical address and other information through a json configuration file.
[0066] Step 202: A CAN diagnostic message module and an Ethernet diagnostic message module may be provided in the electronic device. Optionally, the router module in the electronic device may determine the corresponding module to be transmitted based on the first message type parsed from the object of the test information. If the first message type corresponds to a CAN type, the electronic device may transmit the object of the test information to the CAN diagnostic message module. If the first message type is an Ethernet type, the electronic device may transmit the object of the test information to the corresponding Ethernet diagnostic message. The CAN diagnostic message module may convert the test information into a CAN message. The Ethernet diagnostic message module may convert the test information into an Ethernet message. Optionally, when the Ethernet diagnostic message module uses the DOIP protocol to generate a message, the message may be a DOIP message.
[0067] Step 203: After the electronic device generates a CAN message, the electronic device can use the CAN TP protocol to send the CAN message to the controller under test through the CANdriver.
[0068] Specifically, the electronic device can adapt the CAN message transmission channel through a CAN connection module based on the dynamic library based on ZLGCAN.DLL, and implement a callback function interface based on signal and message reception, which can further implement the message received on the CAN bus. The electronic device can obtain the CAN message output by the controller under test by periodically monitoring the signal on the CAN bus.
[0069] Step 204: The electronic device can implement the packaging and unpacking of DoIP messages through a message module. The electronic device can manage the TCP connection between the PC and the controller through a connector module, and send the DoIP message to the controller under test, or receive the feedback message returned by the controller under test.
[0070] Optionally, the electronic device can also implement the service characteristics of the DoIP protocol through a DoIP Client module. Optionally, the electronic device can also implement the UDS protocol stack through a UDS module, and implement the adaptation of the DoIP connector through a TP layer, thereby implementing the UDS diagnosis function based on DoIP through the UDS module.
[0071] Step 205: When the electronic device receives the feedback message, if the feedback message is a CAN message, the electronic device can input the CAN message into the CAN diagnostic message for parsing to obtain the parsing result. Alternatively, when the electronic device receives the feedback message, if the feedback message is an Ethernet message, the electronic device can input the Ethernet message into the Ethernet message diagnostic module to parse the Ethernet message and obtain the parsing result.
[0072] Step 206: The electronic device can use the router callback module to determine and generate the test results corresponding to the test cases in the router. Optionally, the electronic device can generate a test report through the allure interface.
[0073] Figure 3 FIG. 2 shows a schematic diagram of the structure of an embodiment of a vehicle-based communication test device of the present invention. Figure 3 As shown, the device 300 includes: an acquisition module 301 and a testing module 302 .
[0074] The acquisition module 301 is used to acquire a test case of the controller to be tested in the vehicle; wherein the test case includes at least one test information, and the test information has routing information; the routing information includes a first message type and a second message type, the first message type is the message type required by the controller to be tested to receive the test information, and the second message type is the message type of the feedback result of the test information sent by the controller to be tested;
[0075] The test module 302 is used to encapsulate the test information based on a first message type corresponding to the test information, obtain a test message, and send the test message to the controller under test; wherein the test message is used to obtain a feedback message; receive the feedback message sent by the controller under test, and parse the feedback message based on a second message type corresponding to the test information to obtain a test result corresponding to the test case.
[0076] In an optional manner, the testing module 302 is used to:
[0077] Parsing the routing information of the test information to obtain a first message type corresponding to the test information;
[0078] When the first message type corresponding to the test information is a CAN type, encapsulating the test information according to the CAN protocol to obtain a CAN type test message;
[0079] When the first message type corresponding to the test information is an Ethernet type, the test information is encapsulated according to the Ethernet protocol to obtain a test message of the Ethernet type.
[0080] In an optional manner, the testing module 302 is used to:
[0081] According to the Ethernet diagnostic communication protocol, the test information is encapsulated to obtain a test message.
[0082] In an optional manner, the testing module 302 is used to:
[0083] Based on the CAN driver, access the CAN receiver of the controller under test to notify the CAN receiver of the controller under test to transmit data;
[0084] The test message is sent to the controller under test through the transmission method under the CAN protocol.
[0085] In an optional manner, the testing module 302 is used to:
[0086] Use TCP / IP protocol to send test messages to the controller under test.
[0087] In an optional manner, the testing module 302 is used to:
[0088] When the second message type corresponding to the test information is a CAN type, the feedback message is parsed based on the CAN protocol to obtain a parsing result of the CAN type corresponding to the feedback message;
[0089] When the second message type corresponding to the test information is an Ethernet type, the feedback message is parsed based on the Ethernet protocol to obtain a parsing result of the Ethernet type corresponding to the feedback message.
[0090] In an optional manner, the testing module 302 is used to:
[0091] According to the Ethernet diagnostic communication protocol, the feedback message is parsed to obtain a parsing result of the Ethernet type corresponding to the feedback message.
[0092] In an optional manner, the testing module 302 is used to:
[0093] Obtaining communication feedback information in the parsing result corresponding to the feedback message; wherein the communication feedback information indicates whether the communication is normal;
[0094] Determine the analysis results of normal communication and the proportion of each analysis result;
[0095] The analysis result is obtained according to the proportion value; wherein the analysis result indicates whether the test for the test case is successful.
[0096] In an optional manner, the testing module 302 is used to:
[0097] Generate data information according to the data length; and write the data information into the test message.
[0098] The vehicle-based communication test device 300 provided in the embodiment of the present invention can execute the above method embodiment. Its specific implementation principles and technical effects can be found in the above method embodiment, which will not be described in detail in this embodiment.
[0099] Figure 4 The schematic diagram of the structure of an embodiment of the electronic device of the present invention is shown, and the specific embodiment of the present invention does not limit the specific implementation of the electronic device.
[0100] like Figure 4 As shown, the electronic device may include: a processor (processor) 402 , a communication interface (Communications Interface) 404 , a memory (memory) 406 , and a communication bus 408 .
[0101] The processor 402, the communication interface 404, and the memory 406 communicate with each other via the communication bus 408. The communication interface 404 is used to communicate with other devices such as a client or other server network elements. The processor 402 is used to execute the program 410, which can specifically execute the relevant steps in the above-mentioned embodiment of the vehicle-based communication test method.
[0102] Specifically, the program 410 may include program code including computer executable instructions.
[0103] The processor 402 may be a central processing unit (CPU), or an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present invention. The one or more processors included in the electronic device may be processors of the same type, such as one or more CPUs; or processors of different types, such as one or more CPUs and one or more ASICs.
[0104] The memory 406 is used to store the program 410. The memory 406 may include a high-speed RAM memory, and may also include a non-volatile memory (non-volatile memory), such as at least one disk memory.
[0105] When the program 410 can be specifically called by the processor 402, the electronic device executes the vehicle-based communication test method in any of the above method embodiments, and its implementation method and technical effect are similar, which will not be repeated in this embodiment.
[0106] An embodiment of the present invention provides a computer-readable storage medium, which stores at least one executable instruction. When the executable instruction is executed on an electronic device, the electronic device executes the vehicle-based communication test method in any of the above method embodiments.
[0107] The executable instructions can be specifically used to enable the electronic device to execute the vehicle-based communication test method in any of the above-mentioned method embodiments. The implementation method and technical effect are similar, and this embodiment will not be repeated here.
[0108] The algorithms or displays provided herein are not inherently related to any particular computer, virtual system or other device. In addition, the embodiments of the present invention are not directed to any particular programming language.
[0109] In the description provided herein, a large number of specific details are described. However, it is understood that embodiments of the present invention can be practiced without these specific details. Similarly, in order to simplify the present invention and help understand one or more of the various inventive aspects, in the above description of exemplary embodiments of the present invention, the various features of the embodiments of the present invention are sometimes grouped together into a single embodiment, figure, or description thereof. Wherein, the claims that follow the specific embodiment are hereby expressly incorporated into the specific embodiment, wherein each claim itself is a separate embodiment of the present invention.
[0110] Those skilled in the art will appreciate that the modules in the devices in the embodiments may be adaptively changed and arranged in one or more devices different from the embodiments. The modules or units or components in the embodiments may be combined into one module or unit or component, and further may be divided into a plurality of submodules or subunits or subcomponents. Except that at least some of such features and / or processes or units are mutually exclusive.
[0111] It should be noted that the above embodiments illustrate the present invention rather than limit it, and that those skilled in the art may design alternative embodiments without departing from the scope of the appended claims. In the claims, any reference symbol between brackets shall not be construed as a limitation on the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "one" or "an" preceding an element does not exclude the presence of a plurality of such elements. The present invention may be implemented by means of hardware comprising a number of different elements and by means of a suitably programmed computer. In a unit claim that lists a number of devices, several of these devices may be embodied by the same hardware item. The use of the words first, second, and third, etc. does not indicate any order. These words may be interpreted as names. The steps in the above embodiments, unless otherwise specified, should not be understood as limitations on the order of execution.
Claims
1. A vehicle-based communication test method, characterized in that: The method comprises: Acquire a test case of a controller to be tested in a vehicle; wherein the test case includes at least one test information, and the test information has routing information; the routing information includes a first message type and a second message type, wherein the first message type is a message type required by the controller to be tested to receive the test information, and the second message type is a message type of feedback results of the test information sent by the controller to be tested; Based on the first message type corresponding to the test information, encapsulate the test information to obtain a test message, and send the test message to the controller to be tested; wherein the test message is used to obtain a feedback message; The feedback message sent by the controller to be tested is received, and based on the second message type corresponding to the test information, the feedback message is parsed to obtain a test result corresponding to the test case.
2. The method according to claim 1, characterized in that Encapsulating the test information based on the first message type corresponding to the test information to obtain a test message includes: Parsing the routing information of the test information to obtain a first message type corresponding to the test information; When the first message type corresponding to the test information is a CAN type, encapsulating the test information according to the CAN protocol to obtain a CAN type test message; When the first message type corresponding to the test information is an Ethernet type, the test information is encapsulated according to the Ethernet protocol to obtain a test message of the Ethernet type.
3. The method according to claim 2, characterized in that The Ethernet protocol is an Ethernet diagnostic communication protocol; the test information is encapsulated according to the Ethernet protocol to obtain an Ethernet type test message, including: The test information is encapsulated according to the Ethernet diagnostic communication protocol to obtain a test message.
4. The method according to claim 2, characterized in that: When the first message type corresponding to the test information is a CAN type, sending the test message to the controller to be tested includes: Based on the CAN driver, access the CAN receiver of the controller to be tested to notify the CAN receiver of the controller to be tested to transmit data; The test message is sent to the controller to be tested through a transmission method under the CAN protocol.
5. The method according to claim 2, characterized in that: When the first message type corresponding to the test information is an Ethernet type, sending the test message to the controller to be tested includes: The test message is sent to the controller to be tested using the TCP / IP protocol.
6. The method according to claim 1, characterized in that The test result includes a parsing result corresponding to the feedback message, and the feedback message is parsed based on the second message type corresponding to the test information, including: When the second message type corresponding to the test information is a CAN type, parsing the feedback message based on the CAN protocol to obtain a parsing result of the CAN type corresponding to the feedback message; When the second message type corresponding to the test information is an Ethernet type, the feedback message is parsed based on the Ethernet protocol to obtain a parsing result of the Ethernet type corresponding to the feedback message.
7. The method according to any one of claims 1 to 6, characterized in that The test result includes a parsing result corresponding to the feedback message; the method includes: Acquire communication feedback information in the parsing result corresponding to the feedback message; wherein the communication feedback information indicates whether the communication is normal; Determine the percentage of the analysis results of normal communication in each of the analysis results; An analysis result is obtained based on the proportion value; wherein the analysis result indicates whether the test for the test case is successful.
8. The method according to any one of claims 1 to 6, characterized in that The test information includes data length, and the method includes: Generate data information according to the data length; and write the data information into the test message.
9. An electronic device, characterized in that: include: A processor, a memory, a communication interface and a communication bus, wherein the processor, the memory and the communication interface communicate with each other via the communication bus; The memory is used to store at least one executable instruction, and the executable instruction enables the processor to perform the operation of the method according to any one of claims 1-8.
10. A computer-readable storage medium, characterized in that: The storage medium stores at least one executable instruction, and when the executable instruction is executed on the electronic device, the electronic device executes the operation of the method according to any one of claims 1 to 8.
Citation Information
Cited By
Testing method and device for diagnosing routing physical addressing, computer equipment and medium
CN119544673A
