Vehicle robustness test method and device
By obtaining the service configuration information of the underlying modules, determining the address range of the service objects, generating and sending test messages, and combining reply messages and abnormal power-down detection, the problem of insufficient robustness test coverage of the underlying modules is solved, realizing automated full-address testing and improving the reliability and efficiency of testing.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-30
- Publication Date
- 2026-03-31
AI Technical Summary
In existing technologies, the robustness test coverage of the underlying modules is insufficient, resulting in low reliability of test results. Furthermore, manual testing methods have low automation and high labor costs.
By obtaining the service configuration information of the underlying modules, determining the address range of service objects, generating and sending test messages, and combining reply messages and abnormal power-down detection, automated testing is achieved, covering all possible service object addresses.
It improves the coverage and reliability of robustness testing of underlying modules, reduces labor costs, realizes full address testing and automation of the testing process, and improves testing efficiency and reliability.
Smart Images
Figure CN121764043A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of vehicle testing technology, and in particular to a vehicle robustness testing method and apparatus. Background Technology
[0002] The core control unit of an automotive electronic system integrates various underlying modules that provide basic services (such as a fault diagnosis event manager for providing vehicle fault information queries). The stability of these underlying modules directly determines the operational reliability of the vehicle controller; therefore, robustness testing of these modules is necessary.
[0003] In related technologies, the common method for robustness testing of underlying modules is to have testers manually select several commonly used addresses and test the underlying module's ability to perform basic services for each address.
[0004] However, in this testing method, the test results of commonly used addresses cannot fully reflect the basic service capabilities of the underlying modules, resulting in low reliability of the basic service capabilities of the underlying modules obtained from the tests. Summary of the Invention
[0005] In view of this, this application aims to propose a vehicle robustness testing method to improve the coverage of test addresses of the underlying modules, thereby improving the reliability of robustness testing of the underlying modules.
[0006] To achieve the above objectives, the technical solution of this application is implemented as follows: A vehicle robustness testing method, the method comprising: Obtain service configuration information of the underlying modules of the vehicle controller, wherein the underlying modules are used to provide basic services for the vehicle controller; Based on the service configuration information, determine the service object address range corresponding to the basic service; Under preset test conditions, test packets corresponding to each service object address in the service object address range are generated respectively; Each of the test messages is sent to the underlying module, and based on the response message generated by the underlying module, it is determined whether the underlying module can provide the basic service normally under the preset test conditions.
[0007] Furthermore, the service configuration information includes the encoding rule configuration for the test message; The encoding rule configuration of the test message includes a first preset field in the test message as a variable field, and the variable field is used to write the address of the service object; The step of determining the service object address range corresponding to the basic service based on the service configuration information includes: Determine the address value boundaries that the variable field can carry; The range defined by the address value boundaries shall be taken as the address range of the service object.
[0008] Furthermore, generating test packets corresponding to each service object address within the service object address range includes: Determine the target polling interval and target change step size corresponding to the basic service; Starting from the boundary of the service object address range, at each target polling interval, the current service object address is selected according to a preset address determination method; The current test message is generated based on the current service object address until the preset termination condition is met and the polling ends.
[0009] Furthermore, the preset address determination method includes: Starting with the service object address corresponding to the boundary, the target change step size is adjusted for the service object address every target polling interval; The preset termination conditions include: The current service object address is the other boundary of the service object address range.
[0010] Furthermore, the method for determining the target change step size includes: The target change step size corresponding to the basic service is determined based on the range length of the service object address range.
[0011] Furthermore, the encoding rule configuration of the test message also includes: the second preset field in the test message is a fixed field, and the fixed field is used to write the preset service identifier corresponding to the basic service; The step of generating test messages corresponding to each of the service object addresses includes: Write the preset service identifier corresponding to the basic service into the second preset field of the test message; Each of the service object addresses is written into the first preset field of the test message to obtain the test message corresponding to each of the service object addresses.
[0012] Furthermore, the method also includes: During the process of sending each of the test messages to the underlying module, the system detects whether the vehicle controller experiences an abnormal power-down. Determining whether the underlying module can normally provide the basic services under the preset test conditions includes: Based on the reply message and the detection results of the abnormal power-down situation, it is determined whether the underlying module can provide the basic services normally under the preset test conditions.
[0013] Furthermore, the service object address includes both developed service object addresses and undeveloped service object addresses; The step of determining whether the underlying module can normally provide the basic services under the preset test conditions based on the reply message and the detection results of the abnormal power-down situation includes: If the reply message meets the preset message conditions and the vehicle controller does not have the abnormal power-down situation, it is determined that the underlying module can provide the basic service normally under the preset test conditions; The preset message conditions include: The content of the reply message corresponding to the address of the developed service object conforms to the preset reply message requirements; The reply message corresponding to the address of the undeveloped service object is a preset reply message indicating that the service is not developed.
[0014] Furthermore, the method also includes: Before sending the test message to the underlying module, a preset state variable is set, and the value of the preset state variable is set to a first preset value; Upon completion of traversing the address range of the service object, the value of the preset state variable is switched from the first preset value to the second preset value; Specifically, if the preset state variable is a second preset value, the robustness test of the underlying module is terminated.
[0015] Compared with related technologies, this application has at least the following advantages: The vehicle robustness testing method described in this application adopts the above design. By obtaining the service configuration information of the underlying module providing basic services, and determining the service object address range based on the service configuration information, the service object address range covers all addresses that the underlying module may provide basic services. By generating test packets corresponding to each service object address within the service object address range, the underlying module can be tested across all addresses, thereby improving the coverage of the underlying module robustness test and further improving the reliability of the underlying module robustness test results.
[0016] Furthermore, this application also implements an automated testing scheme for each service object address by traversing the service object address range under preset test conditions, automatically generating and sending corresponding test messages, and confirming the service capabilities of the underlying modules based on their response messages. This eliminates the need for manual configuration and sending of test messages, thereby automating the robustness testing process of the underlying modules and reducing labor costs.
[0017] Meanwhile, in this application, the range of address values that the variable field can carry is also used as the service object address range, so that the service object address range covers all possible service object addresses that request basic services. That is, whether it is a developed service object address, an invalid or undeveloped service object address, it can be tested, thereby enabling full-scenario coverage testing of the basic services of the underlying module, avoiding the limitation of testing only some addresses, and thus improving the reliability of robustness testing.
[0018] Meanwhile, this application also determines the target polling interval and target change step size corresponding to the basic service. Starting from the boundary of the service object address range, the current service object address is selected and a test message is generated every target polling interval according to the preset address determination method. This enables the ordered traversal of service object addresses, avoids address omissions or repeated traversals, and thus achieves automated traversal testing of the service object address range, thereby improving the efficiency and reliability of robustness testing.
[0019] Meanwhile, in this application, starting from the boundary of the service object address range, the target change step size of the service object address is adjusted every target polling interval, and ends when the current service object address reaches another boundary of the address range. This can take into account both the coverage of the service object address and the testing efficiency, and improve the reliability of robustness testing while also improving testing efficiency.
[0020] Meanwhile, this application also determines the corresponding target change step size by the range length of the service object address range, which can realize the dynamic adaptation of the step size parameter. When the address range length is large, a reasonable large step size can be set to improve test efficiency. When the address range length is small, a small step size can be set to ensure test accuracy, thereby achieving a balance between test efficiency and test accuracy.
[0021] Meanwhile, in this application, by writing the preset service identifier corresponding to the basic service into the fixed field, the underlying module can quickly identify the currently requested basic service. Furthermore, by writing the addresses of each service object into the first preset field to generate corresponding test messages, the underlying module can identify the service object address currently requesting the execution of the basic service, thereby enabling the underlying module to quickly execute the corresponding basic service on the requested service object address through the test message.
[0022] Meanwhile, this application also detects whether the vehicle controller has an abnormal power-down situation during the process of sending test messages. By combining the response messages and the detection results of the abnormal power-down situation, the basic service capabilities of the underlying module are determined. This allows for the verification of the functionality and operational stability of the underlying module, thereby improving the reliability of robustness testing.
[0023] Meanwhile, this application also verifies the normal execution of basic services for developed service object addresses by checking the content of the response messages, and verifies the fault tolerance capabilities of the underlying modules for undeveloped service object addresses by checking whether to respond to preset response messages. This covers the response scenarios of the underlying modules to different types of service object addresses, thereby improving the comprehensiveness of the testing.
[0024] Meanwhile, in this application, the value of a preset state variable is set to a first preset value before sending the test message, and the value of the state variable is switched to a second preset value after completing the traversal of the service object address range. The test is terminated when the preset state variable is the second preset value. In this way, by using the preset state variable as the status identifier of the robustness test process, the completion status of the test process can be clearly determined, so as to control the test process based on the change of the value of the state variable and improve the standardization of the test process.
[0025] Another objective of this application is to provide a vehicle robustness testing apparatus for performing the aforementioned vehicle robustness testing method to robustly test the ability of the underlying modules of a vehicle controller to provide basic services.
[0026] The vehicle robustness testing device described in this application can perform testing on all service object addresses, thereby improving the coverage of the robustness test of the underlying modules and further improving the reliability of the robustness test results of the underlying modules. Attached Figure Description
[0027] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a schematic flowchart of the vehicle robustness testing method described in the embodiments of this application; Figure 2 This is a schematic diagram of the polling process of the service object address range in the vehicle robustness testing method described in the embodiments of this application; Figure 3 This is a schematic diagram illustrating the process of generating test messages in the vehicle robustness testing method described in this application embodiment; Figure 4This is a flowchart illustrating the switching process of preset state variables in the vehicle robustness testing method described in this application embodiment; Figure 5 This is a schematic diagram of the overall process of the vehicle robustness testing method described in the embodiments of this application. Detailed Implementation
[0028] To make the technical solution and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.
[0029] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other.
[0030] Furthermore, it should be noted that in the description of this application, if terms such as "upper," "lower," "inner," or "outer" appear, indicating orientation or positional relationship, these are based on the orientation or positional relationship shown in the accompanying drawings and are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation on this application. In addition, if terms such as "first" or "second" appear, they are also used for descriptive purposes only and should not be construed as indicating or implying relative importance.
[0031] Furthermore, in the description of this application, unless otherwise expressly defined, the terms "installation," "connection," "joining," and "connector" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection between two components. Those skilled in the art can understand the specific meaning of the above terms in this application in light of the specific circumstances.
[0032] In this application, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to a specific feature, structure, material, or characteristic described in connection with that embodiment or example, which is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.
[0033] The present application will now be described in detail through exemplary embodiments. However, it should be understood that, without further description, elements, structures, and features in one embodiment may be advantageously incorporated into other embodiments.
[0034] An embodiment of the first aspect of this application provides a vehicle robustness testing method. This method determines the address range of service objects based on service configuration information. This address range covers all addresses where the underlying module may provide basic services. Under preset test conditions, the method traverses the service object address range, automatically generates and sends corresponding test messages, and confirms the service capabilities of the underlying module based on its response messages. This achieves an automatic testing scheme for each service object address. This improves the coverage of the underlying module's robustness testing and, further, enhances the reliability of the underlying module's robustness test results.
[0035] The vehicle controller is the core control unit of the automotive electronic system, and it integrates multiple low-level modules, such as DEM (Diagnostic Event Manager), DCM (Diagnostic Communication Manager), and NVM (Non-Volatile Memory Manager).
[0036] The underlying modules are the core carriers for the vehicle controller to implement basic services. For example, the Diagnostic Event Manager (DEM) is used for monitoring, judging, storing, and managing vehicle faults, and its corresponding basic services include fault code reading and fault snapshot retrieval. The Diagnostic Communication Manager (DCM) is used to establish communication links between the vehicle controller and external diagnostic equipment, and its corresponding basic services include reading vehicle operating data and receiving and parsing diagnostic commands. The Non-Volatile Memory Manager (NVM) is used for persistent storage and retrieval of vehicle controller configuration parameters and fault history data, and its corresponding basic services include data writing, data erasure, and data verification.
[0037] Taking the Diagnostic Time Manager (DEM) as an example, the DEM can provide a fault code reading service, which corresponds to service 19 of the ISO 14229 Diagnostic Protocol (Read DTC Information).
[0038] More specifically, DEM can provide a basic service for reading the number of fault codes (corresponding to service 19.01 in the ISO 14229 diagnostic protocol), as well as a basic service for reading fault codes and status information that match the status (corresponding to service 19.02). In addition, DEM can also provide basic services 19.04 and 19.06 in the ISO 14229 diagnostic protocol.
[0039] The service object address is the specific operation object of the basic service. In the basic services provided by DEM, different service object addresses correspond to different fault data stored in DEM. For example, for service 19 02, the service object address is the second fault of the target fault code, which is equivalent to querying the fault code stored in DEM to find the second fault record corresponding to the target fault code.
[0040] In other words, basic services are the core functions of the underlying modules, and service object addresses are the specific operation objects of the basic services. The stability of the underlying modules directly determines the operational stability and diagnostic reliability of the vehicle controller.
[0041] Therefore, during the research and development and verification phase of the vehicle controller, robustness testing must be conducted on the basic service capabilities of the underlying modules. That is, the vehicle controller should be subjected to complex real-vehicle operating conditions such as in-vehicle network fluctuations and power supply anomalies to test whether the underlying modules can provide the corresponding basic services normally.
[0042] In related technologies, robustness testing of underlying modules generally adopts a manual testing mode. That is, testers select several service object addresses according to requirements, manually configure test messages for diagnosis, and send them to the underlying module.
[0043] After receiving the test message, the underlying module executes the corresponding basic service for the service object address and generates a response message based on the execution result.
[0044] Then, by checking the response messages returned by the underlying module, it can be determined whether the basic service executed by the underlying module at the address of the service object is normal.
[0045] However, this manual testing method has insufficient coverage of service object addresses, only selecting a small number of commonly used addresses, resulting in low reliability of robustness testing for underlying modules. For example, it cannot cover addresses of undeveloped service objects, and even for addresses of undeveloped service objects, it is still necessary to test whether the underlying module can correctly return information indicating that the service is not developed.
[0046] Therefore, due to insufficient coverage of service object addresses, the test results cannot fully reflect the true robustness level of the underlying modules.
[0047] Furthermore, if the full address range test is completed manually, a large amount of manpower is required for message configuration, sending, and result recording, which is time-consuming, labor-intensive, and prone to human error.
[0048] In summary, manual testing methods in related technologies suffer from two main drawbacks: firstly, insufficient coverage of service object addresses leads to low test reliability; secondly, manual testing methods have low automation levels and high labor costs.
[0049] In view of this, to overcome the shortcomings of related technologies, the vehicle robustness testing method in this embodiment is used to perform robustness testing on the ability of the underlying module of the vehicle controller to provide basic services, combined with... Figure 1 In terms of overall design, it includes the following steps S110-S130.
[0050] Step S110: Obtain the service configuration information of the underlying module of the vehicle controller, and determine the address range of the service object corresponding to the basic service based on the service configuration information.
[0051] This underlying module is used to provide the basic services for the vehicle controller.
[0052] The service object address range covers all possible service object addresses that request the underlying module to execute the basic service, including developed service object addresses and undeveloped service object addresses, and may also include illegal service object addresses, thus covering all possible service object addresses for all requests to execute the basic service.
[0053] Step S120: Under the preset test conditions, generate test packets corresponding to the addresses of each service object in the address range of the service object.
[0054] Specifically, in step S120, the address range of the service object can be traversed to generate test packets corresponding to each service object address in sequence.
[0055] Step S130: Send each test message to the underlying module, and determine whether the underlying module can provide basic services normally under the preset test conditions based on the reply message generated by the underlying module.
[0056] The preset test conditions are pre-defined robustness test conditions, such as pre-set complex real-vehicle conditions like in-vehicle network fluctuations or power supply anomalies. The vehicle controller is continuously placed under these preset test conditions (equivalent to the underlying modules being under these preset test conditions), requesting the execution of corresponding basic services from the underlying modules to determine whether the underlying modules can provide basic services normally, thereby testing the vehicle's robustness (more specifically, the robustness of the underlying modules).
[0057] Specifically, the underlying module receives test messages, executes the corresponding basic services based on the service object address in the test message, and after executing the corresponding basic services for the service object address, generates a reply message based on the execution result and returns it.
[0058] Then, based on the returned response message, determine whether the execution result is correct. For example, for finding the fault record of the second target fault mask, determine whether the fault record of the second target fault mask is returned correctly based on the response message (the fault record returned in the response message can be compared with the fault record of the second target fault mask preset in DEM. If the comparison is consistent, it means that it can be returned correctly).
[0059] Then, based on the correctness judgment results of the execution results corresponding to each service object address, it is determined whether the underlying module can provide basic services normally under the preset test conditions.
[0060] In this test, if the execution results corresponding to each service object address are correct, it is determined that the underlying module can provide basic services normally under the preset test conditions.
[0061] If one or more service object addresses have incorrect execution results, it is determined that the underlying module cannot provide basic services normally under the preset test conditions.
[0062] That is, it iterates through all the service object addresses included in the service object address range. For each service object address, it generates a test message corresponding to that service object address and returns it to the underlying module. After receiving the test message, the underlying module executes the corresponding basic service for that service object address, obtains the reply message corresponding to that service object address, and judges whether the reply from the underlying module is correct based on the reply message, thus obtaining the correctness of the execution result corresponding to that service object address.
[0063] During the traversal, if a response message corresponding to the current service object address is detected with an incorrect execution result, the traversal ends, and it is determined that the underlying module is not providing basic services correctly; therefore, the underlying module has failed the robustness test. Alternatively, if an execution result corresponding to the current service object address is detected as incorrect, the traversal can continue. Once the polling of the service object address range is complete, the traversal ends, and the test result indicating that the robustness test failed is returned after the traversal is finished.
[0064] Through steps S110-S130, the service configuration information of the underlying module providing basic services is obtained, and the service object address range is determined based on the service configuration information. This service object address range covers all addresses that the underlying module may provide basic services. By traversing the service object address range, test packets corresponding to each service object address within the service object address range are generated, enabling full address testing of the underlying module. This improves the coverage of the underlying module robustness test and further enhances the reliability of the underlying module robustness test results.
[0065] Furthermore, this embodiment also achieves an automated testing solution for each service object address by traversing the service object address range under preset test conditions, automatically generating and sending corresponding test messages, and confirming the service capabilities of the underlying modules based on their response messages. This eliminates the need for manual configuration and sending of test messages, thereby automating the robustness testing process of the underlying modules and reducing labor costs.
[0066] In some exemplary embodiments, the service configuration information obtained in step S110 may specifically include the encoding rule configuration of the test message.
[0067] The encoding rules configuration for the test message includes setting the first preset field in the test message as a variable field, and the variable field is used to write the service object address.
[0068] The encoding rule configuration for this test message also includes: the second preset field in the test message is a fixed field, which is used to write the preset service identifier corresponding to the basic service.
[0069] Specifically, the first preset field (variable field) is used to write the address of the service object. This value changes continuously as the range of service object addresses is traversed, so that the underlying module can determine the address of the service object that needs to perform the basic service.
[0070] The second preset field (fixed field) is used to write the preset service identifier corresponding to the basic service. This preset service identifier represents the basic service provided by the underlying module, such as the 19 01 service of DEM, which is 19 01.
[0071] It's worth noting that different basic services have different preset service identifiers. After testing one basic service, when testing the next basic service, this second preset field will be filled with the preset service identifier corresponding to that next basic service. For example, it can be changed from 19 01 to 19 02.
[0072] The robustness test of DEM's 19 01 service is used as an example for illustration. For the 19 01 service, its test message is 64 bits long. In the service configuration information, bits 0-7 are defined as the First_FRAME signal, bits 8-15 as the service signal, bits 16-23 as the Subfunction signal, bits 24-31 as the DTCstatusmask signal, and bits 32-64 as the reserved signal.
[0073] Bits 24-31 are the first preset field, and bits 8-15 and 16-23 are equivalent to the second preset field mentioned above.
[0074] Specifically, First_FRAME is the frame type identifier for the diagnostic message, indicating that this is the start frame of the message so that the underlying module can receive the complete message. Usually, First_FRAME is fixed, for example, 03.
[0075] The service signal corresponds to the service identifier of the ISO 14229 protocol. It is the first-level identifier of the basic service. For example, in DEM's 19 01 service, 19 represents "read fault code information service" as the first-level identifier of this basic service. Bits 8-15 are written with "19".
[0076] The Subfunction signal refers to the sub-identifier of a service in the ISO 14229 protocol. It is a secondary identifier of a basic service and, when combined with the service signal, forms a preset service identifier. For example, if the 19 01 service is "counting the number of fault codes that meet the criteria", then "01" is written to the Subfunction signal. "01" represents "reading the number of fault codes according to the status mask".
[0077] The DTCstatusmask signal is a status mask, which is equivalent to the service object address in this embodiment. Each address of the DTCstatusmask corresponds to a service object address, which changes according to the service object address that actually requests the execution of the basic service.
[0078] Bits 32-64 are reserved fields. The reserved signal takes the default value, such as CCCCCCCC.
[0079] For example, the DEM 19 04 service's test message is, for instance, 03 19 04 XX XX XX XX CCCCCCCC. Here, 03 represents the First_FRAME signal, 19 04 is a fixed field (i.e., the second preset field mentioned above), and CCCCCCCC represents the reserved signal. "XX XX XX XX" is a variable field (i.e., the first preset field mentioned above), used to write the service object address.
[0080] Continue by Figure 1 As shown, in step S110 above, determining the address range of the service object corresponding to the basic service based on the service configuration information can specifically include: Determine the address value boundaries that the variable field can carry; use the range formed by the address value boundaries as the address range of the service object.
[0081] Specifically, let's take the DEM's 19 01 basic service as an example. The variable fields for this 19 01 basic service are bits 24-31, for example, in the test message 03 19 01 XX CCCCCCCC. "XX" represents this variable field. The address value boundary for this variable field is 0x00 to 0xFF. The service object address range is [0x00, 0xF target F], that is, from 0x00 to 0xFF.
[0082] For example, consider the DEM's 19 04 basic service. The test message for this basic service is, for instance, 03 19 04 XX XX XXXX CCCCCCCC. "XX XX XX XX" is a variable field, and the address value boundaries for this variable field are 0x00 00 00 00 and 0xFF FF FF FF. Therefore, the address range of the service object corresponding to the DEM's 19 04 basic service is [0x00 00 0000, 0xFF FF FF FF], that is, from 0x00 00 00 00 to 0xFF FF FF FF.
[0083] Since the first preset field in the test message is a variable field used to write the address of the service object, the range of address values that this variable field can carry is used as the range of service object addresses. This range of service object addresses covers all possible service object addresses that may request basic services. In other words, whether the service object address is developed, invalid, or undeveloped, it can be tested. This enables full-scenario coverage testing of the basic services of the underlying modules, avoiding the limitation of testing only some addresses, and thus improving the reliability of robustness testing.
[0084] Continue by Figure 1 and combined Figure 2 As shown, in step S120 above, test packets corresponding to each service object address in the service object address range are generated respectively, which may specifically include the following steps S121-S123.
[0085] Step S121: Determine the target polling interval and target change step size corresponding to the basic service.
[0086] Specifically, the target polling interval refers to the time interval between the sending of two adjacent test packets, which determines the polling frequency. For example, after sending a test packet based on the first service object address, wait for the target polling interval before initiating the next test packet based on the second service object address.
[0087] The target change step size refers to the increment / decrement range of the service object address during polling, determining the number of addresses skipped in each poll. For example, the second service object address is obtained by adding the target change step size to the first service object address. For instance, a target change step size of 1 means that the service object address in each poll is the previous service object address plus 1 (or minus 1).
[0088] Step S122: Starting from the boundary of the service object address range, select the current service object address according to the preset address determination method at every target polling interval.
[0089] Step S123: Generate the current test message based on the current service object address until the preset termination condition is met and the polling ends.
[0090] For example, in step S122, starting from the maximum address boundary of the service object address range, the target change step size can be decreased at the maximum address boundary every target polling interval.
[0091] Taking DEM's 19 01 service as an example, the service object address range is from 0x00 to 0xFF. Assuming the target change step size is 1 and the target polling time is 100ms, the first service object address can be 0xFF. A test message is generated based on the first service object address and sent to the underlying module. After receiving the reply message from the underlying module, wait for 100ms, decrement the current service object address from 0xFF by 1 to obtain the next address 0xFE. Generate the corresponding test message based on 0xFE and send it to the underlying module. After receiving the reply, wait for another 100ms. In the manner of decreasing the address sequentially according to the target change step size of 1 (0xFE-0xFD-…-0x01-0x00), generate test messages and send them sequentially until the test message for address 0x00 is sent and a reply message is received. This completes the full address traversal from 0x00 to 0xFF and ends this round of polling.
[0092] By using steps S121-S123 to determine the target polling interval and target change step size corresponding to the basic service, starting from the boundary of the service object address range, the current service object address is selected and a test message is generated every target polling interval according to the preset address determination method. This enables ordered traversal of service object addresses, avoiding address omissions or repeated traversals, thereby achieving automated traversal testing of the service object address range and improving the efficiency and reliability of robustness testing.
[0093] In some exemplary embodiments, the preset address determination method in step S122 above includes: starting with the service object address corresponding to the boundary, adjusting the target change step size of the service object address every target polling interval; The preset termination conditions in step S123 above include: the current service object address is the other boundary of the service object address range.
[0094] For example, if the initial service object address is the service object address corresponding to the maximum address boundary, the system continuously polls based on the service object address range until the current service object address is the service object address corresponding to the minimum address boundary, which indicates that the preset termination condition has been met and the traversal ends.
[0095] Conversely, if the initial service object address is the service object address corresponding to the minimum address boundary, the system continuously polls based on the service object address range until the current service object address is the service object address corresponding to the maximum address boundary, which indicates that the preset termination condition has been met and the traversal ends.
[0096] Additionally, when polling based on the range of service object addresses, if the initial service object address is the maximum address boundary, the service object address is reduced by the target change step size every target polling interval. Conversely, if the initial service object address is the minimum address boundary, the service object address is increased by the target change step size every target polling interval.
[0097] Starting from the boundary of the service object address range, the target change step size of the service object address is adjusted every target polling interval, and ends when the current service object address reaches another boundary of the address range. This can balance the coverage of service object addresses and testing efficiency, and improve the reliability of robustness testing while also improving testing efficiency.
[0098] In some exemplary embodiments, the method for determining the target change step size in step S121 above includes: Based on the range length of the service object's address range, determine the target change step size corresponding to the basic service.
[0099] The range length refers to the total number of addresses in the service object's address range (range length = maximum address boundary - minimum address boundary + 1, such as the range length of 0x00-0xFF is 256), reflecting the total number of addresses traversed.
[0100] Specifically, the target variation step size can be determined based on the range length and the test accuracy requirements. First, determine the basic variation step size based on the range length. Then, adjust the basic variation step size according to the test accuracy requirements to obtain the target variation step size. For example, if the test accuracy requirements are high, reduce the preset value based on the basic variation step size; if the test accuracy requirements are low, use the basic variation step size as the target variation step size.
[0101] For example, if the address range of the service object is from 0x00 to 0xFF, and the number of polling objects is small with a range length of 256, the target step size can be set to 1. However, for the 19 04 service, which needs to poll from 0x00 00 00 00 to 0xFF FFFF FF, a target step size of 1 would take too long, so it is generally set to 100000 (when the test accuracy requirement is within the preset standard requirement).
[0102] By determining the corresponding target change step size by the range length of the service object's address range, dynamic adaptation of the step size parameter can be achieved. When the address range length is large, a reasonable large step size can be set to improve testing efficiency, and when the address range length is small, a small step size can be set to ensure testing accuracy, thereby achieving a balance between testing efficiency and testing accuracy.
[0103] Continue by Figure 1-2 and combined Figure 3 As shown, in some exemplary embodiments, step S120 above generates test packets corresponding to each service object address, which may specifically include steps S310-S320 below.
[0104] Step S310: Write the preset service identifier corresponding to the basic service into the second preset field of the test message.
[0105] Step S320: Write the address of each service object into the first preset field of the test message to obtain the test message corresponding to each service object address.
[0106] For example, for the DEM's 19 01 service, 19 01 is the preset service identifier corresponding to this basic service. It is written into the second preset field (fixed field) of the test message, and the corresponding test message is 03 19 01 XXCCCCCCCC. Here, "XX" is the variable field used to write the service object address.
[0107] When the service object address is 0x05, writing "05" into the variable field will result in the corresponding test message being 03 19 01 05 CCCCCCCC.
[0108] When the underlying module receives the test message “03 19 01 05 CCCCCCCC”, it uses the preset service identifier “1901” to identify the basic service being requested, and uses “05” to identify the address of the service object being requested. Thus, the underlying module can request to execute the basic service for the service object address, obtain the corresponding execution result, and generate a reply message.
[0109] By writing the preset service identifier corresponding to the basic service into this fixed field, the underlying module can quickly identify the currently requested basic service. Furthermore, by writing the addresses of each service object into the first preset field to generate corresponding test messages, the underlying module can identify the service object address for which the basic service is currently requested. This allows the underlying module to quickly execute the corresponding basic service on the requested service object address through the test message.
[0110] Continue by Figure 1-3 As shown, in some exemplary embodiments, the above-described vehicle robustness testing method further includes: During the process of sending each test message to the underlying module, the system checks whether there is any abnormal power-down situation in the vehicle controller.
[0111] Specifically, step S130 above, determining whether the underlying module can provide basic services normally under preset test conditions, may include: Based on the response message and the detection results of abnormal power-down conditions, determine whether the underlying module can provide basic services normally under the preset test conditions.
[0112] Specifically, abnormal power-down refers to an unexpected power-down state in which the vehicle controller experiences a power outage or stops operating its core functions without receiving a normal power-down command (such as a manually triggered shutdown command).
[0113] In this embodiment, during the process of sending each test message to the underlying module, the power supply status of the vehicle controller (detecting whether the power supply voltage of the vehicle controller is lower than the preset voltage threshold), the operating status of the core chip (detecting whether the operating clock signal of the core processor is interrupted) and the power-down command signal (for example, detecting whether a person triggers the power-off command) are also monitored in real time.
[0114] An abnormal power-down situation is determined to exist if at least one of the following preset abnormal power-down conditions is met. If none of the preset abnormal power-down conditions are met, it is determined that no abnormal power-down situation exists.
[0115] The preset abnormal power-down conditions include a first preset abnormal power-down condition and a second preset abnormal power-down condition. The first preset abnormal power-down condition is: if the power supply voltage is detected to be lower than a preset voltage threshold for a preset duration, and no power-down command signal is received, then an abnormal power-down situation is determined to exist.
[0116] The second preset abnormal power-down condition is: if an interruption of the running clock signal is detected and no power-down command signal is received, then an abnormal power-down situation is determined to exist.
[0117] Conversely, if the operating clock signal is uninterrupted and the supply voltage remains below the preset voltage threshold for less than the preset duration, it indicates that there is no abnormal power-down. If the operating clock signal is uninterrupted and the supply voltage is above the preset voltage threshold, it indicates that there is no abnormal power-down. If the operating clock signal is interrupted and the supply voltage remains below the preset voltage threshold for the preset duration, and a power-down command signal is received, it indicates that there is no abnormal power-down.
[0118] This not only sends test messages to the underlying modules but also monitors whether the vehicle controller experiences abnormal power-down. Once it is determined whether the underlying modules can provide basic services normally under preset test conditions, a judgment can be made based on the response messages from the underlying modules and the detection results of abnormal power-down.
[0119] Since stability failures may occur in the underlying modules during testing, which may lead to abnormal power-down of the vehicle controller, and this situation cannot be reflected in the reply messages, it is necessary to detect whether there is an abnormal power-down of the vehicle controller during the sending of test messages. By combining the detection results of reply messages and abnormal power-down, the basic service capabilities of the underlying modules can be determined. This allows for the verification of the functionality and operational stability of the underlying modules, thereby improving the reliability of robustness testing.
[0120] Continue by Figure 1-3 As shown, in some exemplary embodiments, determining whether the underlying module can provide basic services normally under preset test conditions based on the response message and the detection results of abnormal power-down conditions may specifically include: If the response message meets the preset message conditions and the vehicle controller does not experience any abnormal power-down, it is determined that the underlying module can provide basic services normally under the preset test conditions.
[0121] The preset message conditions include: the content of the reply message corresponding to the address of the developed service object must meet the preset reply message requirements; and the reply message corresponding to the address of the undeveloped service object must be a preset reply message indicating that the service is not yet developed.
[0122] The service object address range includes both developed and undeveloped service object addresses. In other words, the service object address range consists of both developed and undeveloped service object addresses.
[0123] Specifically, the address of a developed service object refers to the address of a service object in the underlying module that has completed functional development and can respond to basic services (e.g., in the DEM19 01 service, addresses such as 0x05 and 0x10 have been debugged, and the address of the developed service object includes addresses such as 0x05 and 0x10).
[0124] Undeveloped service object address refers to the address of the service object in the underlying module that has not yet been functionally developed and cannot provide actual basic services (e.g., in the DEM 19 01 service, the 0xF0-0xFF addresses are reserved but not developed, so the undeveloped service object address includes addresses such as 0xF0-0xFF).
[0125] More specifically, in the preset message conditions, for the address of the developed service object, the reply message must be able to correctly return the requested content. For example, in the case of requesting "find the fault record of the second target fault", the reply message not only requires a standardized format, but should also correctly return the content of the fault record containing the second target fault.
[0126] Therefore, for a developed service object address, its reply message needs to meet the preset reply message requirements in order for the underlying module to be able to perform basic services normally for that developed service object address.
[0127] Specifically, for the address of an already developed service object, the following three checks need to be performed: The first check is to check whether the message format of the reply message is consistent with the preset format specification. Specifically, it is necessary to confirm whether the frame header, frame trailer, data length, and checksum are consistent with the preset format specification.
[0128] The second check is to check whether the status code of the reply message is the preset normal status code, specifically whether the confirmation status code is the preset normal status code corresponding to "service is running normally".
[0129] The third check is to check whether the data fields of the response message correctly display the execution results. Specifically, it is necessary to confirm whether the data fields contain the execution results of the basic service and whether the parameter values in the data fields are correct.
[0130] If the message format is consistent with the preset format specification, the status code is the preset normal status code, and the data fields correctly display the execution result, it is determined that the reply message corresponding to the developed service object address has passed the verification, indicating that the basic service can be executed normally for the developed service object address, which means that the test of the developed service object address has passed.
[0131] Conversely, if at least one of the three elements—message format, status code, and data field—fails the check, it means that the underlying module cannot perform basic services for the developed service object address, which means that the test for the developed service object address has failed.
[0132] For addresses of undeveloped service objects, a predefined response message indicating that the service is not yet developed is required, such as "NRC". If this predefined response message is received, the test for the undeveloped service object address is considered passed.
[0133] If all tests for each service object address pass and there is no abnormal power failure of the vehicle controller during the test, it means that the underlying module can provide basic services normally under the preset test conditions.
[0134] Conversely, if at least one service object address fails the test, then regardless of whether the vehicle controller experiences an abnormal power failure during the test, it indicates that the underlying module cannot provide basic services normally under the preset test conditions.
[0135] Similarly, if the vehicle controller experiences an abnormal power failure during testing, regardless of whether all service object addresses pass the test, it indicates that the underlying module cannot provide basic services normally under the preset test conditions.
[0136] This approach verifies the normal execution of services for developed service object addresses by checking the content of the response messages, and verifies the fault tolerance capabilities of the underlying modules by checking whether to respond to preset response messages for undeveloped service object addresses. This covers the response scenarios of the underlying modules to different types of service object addresses, thereby improving the comprehensiveness of the testing.
[0137] Continue by Figure 1-3 and combined Figure 4 As shown, in some exemplary embodiments, the method further includes steps S410-S420 as described below.
[0138] Step S410: Before sending the test message to the underlying module, set a preset status variable and set the value of the preset status variable to the first preset value.
[0139] Step S420: After completing the traversal of the service object address range, switch the value of the preset state variable from the first preset value to the second preset value.
[0140] Specifically, if the preset state variable is the second preset value, the robustness test of the underlying module is terminated.
[0141] Specifically, the preset state variable refers to the control variable used to identify the running state of the robustness test process. It is the core basis for judging the start, execution and termination of the test. It is stored in the memory of the vehicle controller, and the value of the variable is selected between the first preset value and the second preset value.
[0142] The first preset value indicates that the test process is in the execution state, such as the value 1.
[0143] The second preset value indicates that the test process is in a completed state, for example, a value of 0, which is mutually exclusive with the first preset value.
[0144] When performing robustness testing on the underlying module, the preset state variable is initially set to the second preset value (e.g., 0). Then, when the test starts, the preset state variable is switched to the first preset value (e.g., 1), indicating that the test process can be executed normally. At this time, the test process startup mechanism is triggered, and test messages can be generated and sent to the underlying module.
[0145] During test execution, the progress of traversing the service object address range is monitored in real time. When the last service object address completes the test message sending and the reply message reception is completed, it is determined that the traversal of the service object address range is complete. At this time, the value of the preset status variable is immediately switched from the first preset value (e.g., 1) to the second preset value (e.g., 0), and the test log is updated synchronously to record the variable switching time and the switching reason (address traversal complete).
[0146] The system monitors the value of preset status variables in real time. When the value of a variable is detected to be the second preset value, the polling ends and a termination operation can be performed immediately, such as stopping the generation of new test messages, closing the message sending / receiving port, and saving all test data (sending records, reply messages, exception information, etc.).
[0147] In this way, through steps S410 and S420, the value of the preset status variable is set to the first preset value before sending the test message, and the value of the status variable is switched to the second preset value after the service object address range traversal is completed. The test is terminated when the preset status variable is the second preset value. By using the preset status variable as the status identifier of the robustness test process, the completion status of the test process can be clearly determined, so as to control the test process based on the value change of the status variable and improve the standardization of the test process.
[0148] It is worth noting that, regarding the vehicle robustness testing method of this embodiment, based on the above exemplary implementations, in specific implementation, as a preferred embodiment, it is... Figure 5 As shown, it may include, for example: Set a preset state variable and set its value to a second preset value (such as 0). Then, based on the first preset field (variable field, used to write the service object address) in the test message corresponding to the basic service of the underlying module, determine the address value boundary that the first preset field can carry, so as to determine the service object address range corresponding to the basic service.
[0149] The boundary of the service object address range is set as the initial service object address. The target change step size is determined based on the length of the service object address range, and the target change step size and target polling interval are set.
[0150] After completing the settings, switch the value of the preset status variable to the first preset value (e.g., 1). Immediately afterward, generate a test message based on the initial service object address and send it to the underlying module. The underlying module generates a reply message. Based on this reply message, determine whether the test for the initial service object address has passed.
[0151] After waiting for the target polling interval, the target change step size is incremented (or decremented, incremented if the initial service object address is the minimum address boundary) based on the initial service object address to obtain the current service object address. A test message is then generated based on the current service object address and sent to the underlying module, and so on.
[0152] The polling continues until a test message is generated based on the service object address corresponding to the other boundary in the service object address range, and a reply message is received from the underlying module. In this case, the polling ends, and the value of the preset status variable is switched to the second preset value (such as 0).
[0153] Then, based on the response messages of each service object address, it is determined whether the test of each service object address has passed. If all of them have passed, it means that the underlying module can provide the basic service normally under the preset test conditions, and waits for the next basic service test.
[0154] In the preferred embodiment of the above vehicle robustness testing method, the implementation of each step can still be referred to the description in the above exemplary embodiments, and the beneficial effects brought about by each step in this preferred embodiment can also be referred to the description in the above exemplary embodiments.
[0155] The vehicle robustness testing method in this embodiment adopts the above design. It obtains the service configuration information of the underlying module that provides basic services, and determines the service object address range based on the service configuration information. The service object address range covers all addresses that the underlying module may provide basic services. By traversing the service object address range, full address testing can be achieved, thereby improving the coverage of the underlying module robustness test and further improving the reliability of the underlying module robustness test results.
[0156] Furthermore, this embodiment also achieves an automated testing solution for each service object address by traversing the service object address range under preset test conditions, automatically generating and sending corresponding test messages, and confirming the service capabilities of the underlying modules based on their response messages. This eliminates the need for manual configuration and sending of test messages, thereby automating the robustness testing process of the underlying modules and reducing labor costs.
[0157] Meanwhile, in this embodiment, the range of address values that the variable field can carry is also used as the service object address range, so that the service object address range covers all possible service object addresses that may request basic services. That is, whether it is a developed service object address or an invalid or undeveloped service object address, it can be tested, thereby enabling full-scenario coverage testing of the basic services of the underlying module, avoiding the limitation of testing only some addresses, and thus improving the reliability of robustness testing.
[0158] Meanwhile, in this embodiment, by determining the target polling interval and target change step size corresponding to the basic service, starting from the boundary of the service object address range, the current service object address is selected and a test message is generated every target polling interval according to the preset address determination method. This enables the ordered traversal of service object addresses, avoiding address omissions or repeated traversals, thereby achieving automated traversal testing of the service object address range and improving the efficiency and reliability of robustness testing.
[0159] Meanwhile, in this embodiment, starting from the boundary of the service object address range, the target change step size of the service object address is adjusted every target polling interval, and ends when the current service object address reaches another boundary of the address range. This can take into account both the coverage of the service object address and the testing efficiency, and improve the reliability of robustness testing while also improving testing efficiency.
[0160] Meanwhile, in this embodiment, the target change step size is determined by the range length of the service object address range, which enables dynamic adaptation of the step size parameter. When the address range length is large, a reasonable large step size can be set to improve test efficiency. When the address range length is small, a small step size can be set to ensure test accuracy, thereby achieving a balance between test efficiency and test accuracy.
[0161] Meanwhile, in this embodiment, by writing the preset service identifier corresponding to the basic service into the fixed field, the underlying module can quickly identify the currently requested basic service. Furthermore, by writing the addresses of each service object into the first preset field to generate corresponding test messages, the underlying module can identify the service object address currently requesting the execution of the basic service, thereby enabling the underlying module to quickly execute the corresponding basic service on the requested service object address through the test message.
[0162] Meanwhile, in this embodiment, the vehicle controller is also checked for abnormal power-down during the sending of test messages. By combining the response messages and the detection results of abnormal power-down, the basic service capabilities of the underlying modules are determined. This allows for the verification of the functionality and operational stability of the underlying modules, thereby improving the reliability of robustness testing.
[0163] Meanwhile, in this embodiment, the basic services of developed service object addresses are verified by the content of the response messages, while the fault tolerance capabilities of the underlying modules are verified by determining whether to respond to preset response messages for undeveloped service object addresses. This covers the response scenarios of the underlying modules to different types of service object addresses, thereby improving the comprehensiveness of the testing.
[0164] Meanwhile, in this embodiment, the value of the preset state variable is set to a first preset value before sending the test message. After completing the traversal of the service object address range, the value of the state variable is switched to a second preset value, and the test is terminated when the preset state variable is the second preset value. In this way, by using the preset state variable as the status identifier of the robustness test process, the completion status of the test process can be clearly determined, so as to control the test process based on the change of the value of the state variable and improve the standardization of the test process.
[0165] An embodiment of the second aspect of this application provides a vehicle robustness testing apparatus for performing the vehicle robustness testing method described in the embodiments of the first aspect above, to robustly test the ability of the underlying modules of the vehicle controller to provide basic services.
[0166] Specifically, the implementation process of each function of the vehicle robustness testing device in this embodiment can be found in the relevant descriptions in the above method embodiments, and will not be repeated here.
[0167] The vehicle robustness testing device in this embodiment can perform testing on all service object addresses, thereby improving the coverage of the underlying module robustness test and further improving the reliability of the underlying module robustness test results.
[0168] The above descriptions are merely some embodiments of this application and are not intended to limit this application. The technical features or structures in the foregoing different embodiments can be arbitrarily combined to form other specific technical solutions as needed. For those skilled in the art, this application can have various modifications and variations. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of the claims of this application.
Claims
1. A vehicle robustness testing method, characterized in that, The method includes: Obtain service configuration information of the underlying modules of the vehicle controller, wherein the underlying modules are used to provide basic services for the vehicle controller; Based on the service configuration information, determine the service object address range of the basic service; Under preset test conditions, test packets corresponding to each service object address in the service object address range are generated respectively; Each of the test messages is sent to the underlying module, and based on the response message generated by the underlying module, it is determined whether the underlying module can provide the basic service normally under the preset test conditions.
2. The vehicle robustness testing method according to claim 1, characterized in that, The service configuration information includes the encoding rule configuration for test messages; The encoding rule configuration of the test message includes a first preset field in the test message as a variable field, and the variable field is used to write the address of the service object; The step of determining the service object address range corresponding to the basic service based on the service configuration information includes: Determine the address value boundaries that the variable field can carry; The range defined by the address value boundaries shall be taken as the address range of the service object.
3. The vehicle robustness testing method according to claim 2, characterized in that, The step of generating test packets corresponding to each service object address within the service object address range includes: Determine the target polling interval and target change step size corresponding to the basic service; Starting from the boundary of the service object address range, at each target polling interval, the current service object address is selected according to a preset address determination method; The current test message is generated based on the current service object address until the preset termination condition is met and the polling ends.
4. The vehicle robustness testing method according to claim 3, characterized in that: The preset address determination method includes: Starting with the service object address corresponding to the boundary, the target change step size is adjusted for the service object address every target polling interval; The preset termination conditions include: The current service object address is the other boundary of the service object address range.
5. The vehicle robustness testing method according to claim 4, characterized in that, The method for determining the target change step size includes: The target change step size corresponding to the basic service is determined based on the range length of the service object address range.
6. The vehicle robustness testing method according to claim 2, characterized in that, The encoding rule configuration of the test message further includes: the second preset field in the test message is a fixed field, and the fixed field is used to write the preset service identifier corresponding to the basic service; The step of generating test packets corresponding to each service object address within the service object address range includes: Write the preset service identifier corresponding to the basic service into the second preset field of the test message; Each of the service object addresses is written into the first preset field of the test message to obtain the test message corresponding to each of the service object addresses.
7. The vehicle robustness testing method according to claim 1, characterized in that, The method also includes: During the process of sending each of the test messages to the underlying module, the system detects whether the vehicle controller experiences an abnormal power-down. Determining whether the underlying module can normally provide the basic services under the preset test conditions includes: Based on the reply message and the detection results of the abnormal power-down situation, it is determined whether the underlying module can provide the basic services normally under the preset test conditions.
8. The vehicle robustness testing method according to claim 7, characterized in that, The service object address includes both developed service object addresses and undeveloped service object addresses; The step of determining whether the underlying module can normally provide the basic services under the preset test conditions based on the reply message and the detection results of the abnormal power-down situation includes: If the reply message meets the preset message conditions and the vehicle controller does not have the abnormal power-down situation, it is determined that the underlying module can provide the basic service normally under the preset test conditions; The preset message conditions include: The content of the reply message corresponding to the address of the developed service object conforms to the preset reply message requirements; The reply message corresponding to the address of the undeveloped service object is a preset reply message indicating that the service is not developed.
9. The vehicle robustness testing method according to any one of claims 1 to 8, characterized in that, The method also includes: Before sending the test message to the underlying module, a preset state variable is set, and the value of the preset state variable is set to a first preset value; Upon completion of traversing the address range of the service object, the value of the preset state variable is switched from the first preset value to the second preset value; Specifically, if the preset state variable is a second preset value, the robustness test of the underlying module is terminated.
10. A vehicle robustness testing device, characterized in that: The device is used to perform the vehicle robustness testing method according to any one of claims 1-9 above, to robustly test the ability of the underlying modules of the vehicle controller to provide basic services.