Testing method and device based on real vehicle operation environment playback

Abstract

The invention discloses a test method and device based on real vehicle operation environment playback, and the method comprises the steps: obtaining a log file according to all message data between a domain controller and each associated port in a real vehicle operation environment; constructing a data playback function based on the log file; sequentially operating the data playback function and the target test case in the simulation bench environment to obtain test data; comparing the test data with the log file to obtain a correction instruction; correcting the data playback function based on the correction instruction to obtain a corrected data playback function; and testing the domain controller based on the corrected data playback function. According to the method, a data playback function is constructed and corrected to ensure that a simulation bench environment is highly consistent with a real vehicle operation environment, so that the accuracy and credibility of a simulation bench test result are remarkably improved. And a test blind area caused by environment distortion of the simulation rack is reduced fundamentally.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of automotive electronic testing, in particular to a test method and device based on real vehicle operation environment playback. BACKGROUND

[0002] At present, with the evolution of automotive electronic architecture to domain controller centralization, the functions of domain controller basic software, including communication, diagnosis, routing, flashing, etc., have become the core to ensure the stable operation of the whole vehicle electronic system. At present, the test and verification of the above-mentioned basic software functions in the industry mainly rely on laboratory bench simulation. The simulation bench test has the advantages of controllable environment and easy automation, and is the main means of early development verification.

[0003] However, there are inherent differences between the simulation bench test environment and the real vehicle operation environment. The bench system is usually difficult to completely reproduce all the associated hardware nodes and their complex interaction signals in the real vehicle, resulting in inconsistent working states of the domain controller on the bench and in the real vehicle. The simulation bench environment lacks relevant signals from some associated hardware, and there are differences in bus load, network topology, etc. with the real vehicle operation environment. These factors make the simulation bench test results differ greatly from the real vehicle test results under some specific conditions, causing defects to be unable to be effectively identified and flow out in the bench test stage.

[0004] When the bench and real vehicle results are inconsistent in the later real vehicle verification, it is often necessary to rely on the real vehicle operation environment for special problem reproduction and verification. Real vehicle testing faces problems such as high cost, long test period, difficulty in reproducing specific conditions, and inability to cover all conditions. Therefore, there is a dual contradiction in the prior art of insufficient consistency of bench test results and low efficiency of real vehicle special testing, which leads to the risk of no error in the early development of the basic software module on the bench, but frequent problems in the later real vehicle verification stage, which may cause huge economic losses.

[0005] In the prior art, there are some schemes for testing by playing back real vehicle data to improve the authenticity of testing. However, these schemes are usually limited to one-way playback of data, cannot identify the source of deviation, and cannot make targeted corrections to the playback logic or test standards, making it difficult to fundamentally solve the deep-seated problem of inconsistency between the simulation bench environment and the real vehicle operation environment. There are still obvious limitations in improving the accuracy and reliability of the simulation bench test results.

[0006] Therefore, there is an urgent need for a testing and correction scheme that can effectively improve the authenticity of the simulation bench environment and thus improve the accuracy of the simulation bench test results. SUMMARY

[0007] In order to ensure that the simulation bench environment is consistent with the real vehicle running environment, and to improve the accuracy of the simulation bench test result, an embodiment of the present application provides a test method and device based on real vehicle running environment playback.

[0008] In a first aspect, an embodiment of the present application provides a test method based on real vehicle running environment playback, which can include: obtaining a log file according to all message data between the domain controller and each associated port in the real vehicle running environment; constructing a data playback function based on the log file; running the data playback function and a target test case in the simulation bench environment in sequence to obtain test data; comparing the test data with the log file to obtain a correction instruction; correcting the data playback function based on the correction instruction to obtain a corrected data playback function; testing the domain controller based on the corrected data playback function.

[0009] In one or some optional embodiments of the present application, the comparison of the test data with the log file to obtain a correction instruction includes: identifying a negative response code returned by the domain controller in the test data; determining a generation reason of the negative response code in the log file; determining a corresponding correction instruction according to the generation reason.

[0010] In one or some optional embodiments of the present application, the correction instruction includes a target time point and a correction statement. The correction of the data playback function based on the correction instruction to obtain a corrected data playback function includes: adding the correction statement at the target time point in the data playback function based on the correction instruction to obtain a corrected data playback function.

[0011] In one or some optional embodiments of the present application, the each associated port includes a plurality of electronic control unit (ECU) ports and a plurality of Ethernet nodes. The construction of the data playback function based on the log file includes: obtaining ECU message logs by obtaining all ECU port corresponding messages in the log file; constructing a data playback function based on the ECU message logs.

[0012] In one or some optional embodiments of the present application, it further includes: comparing the test data with the log file to determine a period tolerance of message sending of the domain controller in the real vehicle running environment and the simulation bench environment respectively; determining a period correction coefficient according to the period tolerance; correcting the target test case based on the period correction coefficient.

[0013] In one or some optional embodiments of the application, the constructing a data playback function based on the log file comprises: In the CANoe environment, the data playback function is constructed using a communication access programming language (CAPL) based on the log file.

[0014] In a second aspect, the application provides a test device based on real vehicle running environment playback, which can comprise: The collecting module is configured to obtain a log file according to all message data between the domain controller and each associated port in a real vehicle running environment. The constructing module is configured to construct a data playback function based on the log file. The test module is configured to sequentially run the data playback function and a target test case in a simulation bench environment to obtain test data. The correcting module is configured to compare the test data with the log file to obtain a correction instruction. The correcting module is configured to correct the data playback function based on the correction instruction to obtain a corrected data playback function. The automatic test module is configured to test the domain controller based on the corrected data playback function.

[0015] In a third aspect, the application provides a computer readable storage medium having a computer program / instruction stored thereon, which, when executed by a processor, implements the test method based on real vehicle running environment playback as described above.

[0016] In a fourth aspect, the application provides a computer program product comprising a computer program / instruction, which, when executed by a processor, implements the test method based on real vehicle running environment playback as described above.

[0017] In a fifth aspect, the application provides a computer device comprising a memory, a processor, and a computer program stored on the memory, wherein the processor, when executing the computer program, implements the test method based on real vehicle running environment playback as described above.

[0018] The above technical solutions provided by the embodiments of the application have at least the following beneficial effects: The embodiment of the present application provides a test method based on real vehicle operation environment playback, which firstly forms a log file according to all message data between a domain controller and each associated port in a real vehicle environment, then constructs a data playback function capable of running in a simulation bench environment based on the log file, to simulate a real vehicle operation scene, then runs the data playback function and a target test case in the simulation bench environment in sequence, obtains test data, and compares the test data with the log file, to identify deviations existing in the test data and determine a correction instruction, and further corrects the data playback function according to the correction instruction, to form a corrected data playback function, and finally realizes the test on the domain controller based on the corrected data playback function.

[0019] The method ensures that the simulation bench environment is highly consistent with the real vehicle operation environment by constructing and correcting the data playback function, thereby significantly improving the accuracy and reliability of the simulation bench test result. The test blind area caused by the distortion of the simulation bench environment is reduced from the root, thereby realizing the automatic test in the simulation bench environment stage, improving the automatic test efficiency, preventing defects from flowing to the real vehicle operation stage, and greatly reducing the verification cost and project risk in the later stage.

[0020] Other features and advantages of the present application will be set forth in the following description, and in part will become apparent to those skilled in the art from the description, or can be learned by practice of the present application. The objects and other advantages of the present application can be achieved and obtained by means of the structure particularly pointed out in the written description and the accompanying drawings.

[0021] The technical solutions of the present application will be further described in detail below with the help of the accompanying drawings and embodiments. BRIEF DESCRIPTION OF DRAWINGS

[0022] The accompanying drawings are included to provide a further understanding of the present application, and constitute a part of the specification, illustrate the present application, and are used to explain the present application together with the embodiments of the present application, and do not constitute a limitation on the present application. In the drawings: Figure 1 A flowchart of a test method based on real vehicle operation environment playback provided by the embodiment of the present application is shown in the figure. Figure 2 A structural schematic diagram of a test device based on real vehicle operation environment playback provided by the embodiment of the present application is shown in the figure. DETAILED DESCRIPTION

[0023] Exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure can be implemented in various forms and should not be limited by the embodiments described herein. Rather, these embodiments are provided so that the present disclosure can be more thoroughly understood and the scope of the present disclosure can be accurately conveyed to those skilled in the art.

[0024] The inventors find that in the prior art, there are some schemes for testing by playing back real vehicle data, aiming to improve the authenticity of testing. However, these schemes are usually limited to one-way playback of data, cannot identify the root cause of deviation, and cannot correct the playback logic or testing standards, so it is difficult to fundamentally solve the deep-seated problem of inconsistency between the simulation bench environment and the real vehicle running environment, and there are still obvious limitations in improving the accuracy and reliability of the simulation bench test results. Therefore, there is an urgent need for a testing and correction scheme that can effectively improve the authenticity of the simulation bench environment and thus improve the accuracy of the simulation bench test results. Based on this, the inventors have made further research and development, and made the present application, providing a testing method and device based on real vehicle running environment playback.

[0025] Embodiment one In the embodiment one of the present application, a testing method based on real vehicle running environment playback is provided, referring to the method can include the following steps S101-S106: Figure 1 As shown in the figure, the method can include the following steps S101-S106: S101: Obtain a log file according to all message data between the domain controller and each associated port in the real vehicle running environment.

[0026] S102: Construct a data playback function based on the log file.

[0027] S103: Run the data playback function and the target test case in the simulation bench environment in sequence to obtain test data.

[0028] S104: Compare the test data with the log file to obtain a correction instruction.

[0029] S105: Correct the data playback function based on the correction instruction to obtain a corrected data playback function.

[0030] S106: Test the domain controller based on the corrected data playback function.

[0031] The embodiment of the present application provides a testing method based on real vehicle running environment playback. The method first forms a log file according to all message data between the domain controller and each associated port in the real vehicle environment, then constructs a data playback function that can run in the simulation bench environment based on the log file to simulate the real vehicle running scenario, then runs the data playback function and the target test case in the simulation bench environment in sequence to obtain test data, and compares the test data with the log file to identify the deviation and determine the correction instruction; then corrects the data playback function according to the correction instruction to form a corrected data playback function, and finally tests the domain controller based on the corrected data playback function.

[0032] The method ensures high consistency between the simulation bench environment and the real vehicle running environment by constructing and correcting the data playback function, thereby significantly improving the accuracy and reliability of the simulation bench test results. The test blind area caused by distortion of the simulation bench environment is reduced from the root, thereby realizing automated testing in the simulation bench environment stage, improving the efficiency of automated testing, preventing defects from flowing to the real vehicle running stage, and greatly reducing the verification cost and project risk in the later stage.

[0033] In the step S101, the log file is obtained according to all message data between the domain controller and each associated port in the real vehicle running environment. The associated ports include a plurality of electronic control unit (ECU) ports and a plurality of Ethernet nodes.

[0034] Specifically, the step aims to obtain complete working condition data of the domain controller in the real vehicle running environment as a reference for subsequent testing and correction in the simulation bench environment.

[0035] First, the vehicle network architecture needs to be clarified. The method divides all associated ports of the domain controller in the vehicle into two categories, namely electronic control unit (ECU) ports and Ethernet nodes. The ECU ports refer to all traditional vehicle-mounted ports except the domain controller itself and the Ethernet nodes in the central gateway. Their communication usually depends on bus such as controller area network (CAN), controller area network with flexible data rate (CAN-FD), local interconnect network (LIN), and the Ethernet nodes refer to various subsystems or controllers that communicate with the domain controller through high-speed Ethernet.

[0036] A professional bus analysis tool such as CANoe of Vector Company can be used in conjunction with multi-channel hardware interfaces such as VN1640A and VN5610A to connect to each associated port through the second generation on-board diagnostic system (OBD-II) diagnostic interface of the vehicle or directly access the bus. These associated ports should cover all their communication channels, including but not limited to CAN, CAN-FD, LIN, automotive Ethernet, and FlexRay.

[0037] To ensure that the log file fully reflects a variety of real vehicle operating environments, the collection process of this step needs to cover a variety of vehicle operating conditions, such as vehicle stationary, power on and off, low-speed driving, high-speed cruising, and sudden acceleration and deceleration. All network messages between the associated ports and the domain controller need to be recorded, including message ID, data field, timestamp, and channel information, and finally saved as a log file in a standard format (such as LOG), laying a data foundation for subsequent construction of a high-fidelity simulation bench environment.

[0038] In the above step S102, a data playback function is constructed based on the log file. Specifically, the following steps S1021-S1022 are included: S1021: Obtain the messages corresponding to all ECU ports in the log file to obtain an ECU message log.

[0039] Specifically, the log file collected in S101 can be preprocessed. Through a script tool or directly in the simulation software, all messages are filtered and classified according to the identifier (ID) of each message in the log file and the communication channel. All messages transmitted through the ECU port are accurately extracted and integrated into an ECU message log.

[0040] S1022: Construct a data playback function based on the ECU message log.

[0041] Specifically, in the CANoe test environment, a data playback function can be constructed using CAN Access Programming Language (CAPL), which will be directly deployed and run in the simulation bench environment. The specific construction process of the data playback function includes: first, by analyzing the ECU message log, the message data and its timestamp of each ECU port are extracted, then based on the extracted message data and timestamp, a data playback function is constructed, in which a corresponding virtual port and message sending logic are created for each ECU port. When the data playback function is called in the simulation bench environment, the constructed virtual port will reproduce the message sending process on the specified hardware channel according to the corresponding timestamp. This process aims to accurately simulate the load and signal assignment interaction of the traditional bus network in the real vehicle operating environment, thereby providing the domain controller with input signals consistent with the real vehicle operating environment.

[0042] In the above step S103, in the simulation bench environment, the data playback function and the target test case are run in sequence to obtain test data.

[0043] Specifically, the data playback function deployed in the simulation bench environment can be run, and then a plurality of target test cases for different basic software function verifications can be run in the simulation bench environment. These target test cases cover verification scenarios of basic software functions such as communication, diagnosis, routing, and flashing. During the process of running the target test cases to perform testing, the data playback function is continuously run to simulate the message sending behavior of each ECU port in the real vehicle running environment, and to provide real input signals for the domain controller. At the same time, the output response of the domain controller, including the message period, signal value change, diagnosis response code, routing forwarding behavior, and flashing process state, is monitored and recorded synchronously by a test tool. Finally, the collected data and the simulation environment data sent by the data playback function are time-aligned and stored in a structured manner to form test data that can be used for subsequent comparative analysis.

[0044] In step S104, the test data is compared with the log file to obtain a correction instruction. Specifically, the following steps S1041-S1043 are included: S1041: Identify the negative response code returned by the domain controller in the test data.

[0045] Specifically, in the test data, the response message of the domain controller to the diagnosis request or specific instruction can be parsed. By comparing the diagnosis service format, the first byte in the response message is extracted. If the highest bit is 1, i.e., the value is in the range of 0x80 to 0xFF, or the predefined negative response code such as 0x22 condition not met, 0x31 request out of range, etc. is directly matched, it is determined that the negative response code is returned for this interaction, indicating that the test of the corresponding function has an error in the simulation bench environment.

[0046] S1042: Determine the generation reason of the negative response code in the log file.

[0047] Specifically, for each negative response code, the complete context in the S103 test process is traced back. The diagnosis request message that triggers the negative response and all input signals (i.e., messages sent by the data playback function) in a specific time window before and after the request, such as 500 milliseconds before the request and 100 milliseconds after the response, are played back in the simulation bench environment, are compared with the signal context in the log file when the same operation is successfully performed. By analyzing the difference in signal state, the generation reason of the negative response code given by the domain controller is located, for example, it is found that the data playback function is missing a certain key signal such as a vehicle speed signal and a gear signal, or the assignment logic of a certain key signal does not match the logic when the vehicle is successful.

[0048] The signal missing here is caused by the limitations of collecting data in real vehicle running environment and the inherent differences of simulation bench environment, that is, the log files collected in real vehicle running environment may not be able to completely record all the instantaneous signals transmitted through hard-wired connection or specific network, at the same time, the simulation bench environment cannot completely reproduce all the complex physical interactions between the ports of the real vehicle, which leads to the fact that part of the state signals indirectly existing in the real vehicle are missed in the simulation bench environment, and cannot form a complete logic condition for the execution of the diagnostic instruction.

[0049] S1043: determining the corresponding correction instruction according to the generation reason.

[0050] Specifically, based on the generation reason located in step S1042, a specific and executable correction instruction can be generated. If the problem is caused by signal missing, the correction instruction is to add rules in the data playback function, which stipulates that the missing signal message is automatically resubmitted before a specific diagnostic request is issued or when a specific condition is met. If the problem is caused by signal value error or logic conflict, the correction instruction is to modify the assignment statement or trigger condition of the corresponding signal in the data playback function, so as to conform to the execution logic in the real vehicle running environment. Finally, the correction instruction is formally defined as a modification instruction of the data playback function source code or an adjustment scheme of the configuration parameters.

[0051] In step S105, the data playback function is corrected based on the correction instruction to obtain a corrected data playback function. The correction instruction includes a target time point and a correction statement. The target time point is a specific condition for triggering signal correction, which can be a fixed time offset relative to a certain key message, or a time when a certain specific signal value appears or changes. The correction statement is a specific CAPL code instruction that needs to be executed to eliminate the error logic identified in S104.

[0052] Specifically, the actual programming implementation can be based on the correction instruction to correct the data playback function.

[0053] According to the correction instruction, a correction statement is inserted at the target time point in the data playback function or the original statement is modified into a correction statement. For example, in the flashing test, when the vehicle speed signal in the data playback function is greater than 5 km / h, the domain controller will reply a negative response because the vehicle speed condition is not met, resulting in interruption of the flashing process, which is contrary to the logic when the vehicle successfully flashes. The correction instruction is determined as “when the flashing diagnosis instruction is executed, if the vehicle speed signal is greater than 5 km / h, it is covered as 0 km / h”. According to this, in the data playback function, a conditional judgment statement if (vehicle speed > 5) {vehicle speed = 0} is added in the on message event handler of the flashing related diagnosis request message, so as to complete the signal correction. In this way, the abstract correction instruction is converted into precise and executable code modification, and finally a corrected data playback function which can avoid the identified test obstacles is generated.

[0054] In order to facilitate researchers in the field to understand the method, the steps S103 to S105 are more clearly explained below in combination with examples: in the real vehicle running environment, the software flashing function test and verification of the domain controller are successful. However, when the target test case of the software flashing function is executed based on the data playback function in the simulation bench environment, the test data obtained show that the domain controller replies a negative response code 0x22 to the “enter programming session” diagnosis request, indicating that the condition is not met and the test fails.

[0055] Subsequently, the test data is compared and analyzed with the log file. It is found through comparison that in the successful flashing scene in the real vehicle running environment, when the “enter programming session” diagnosis request in the flashing process is detected, not only a “vehicle speed = 0” signal exists on the bus, but also a “gear = P gear” signal exists at the same time. However, in the simulation bench environment, the data playback function fails to send the “gear = P gear” signal. Therefore, it is determined that the error logic leading to the negative response is signal missing. Based on this, the correction instruction is determined as: in the data playback function, when the “enter programming session” diagnosis request in the flashing process is detected (corresponding to the target time point), trigger the “gear = P gear” (correction statement) signal to be sent again.

[0056] According to the above correction instruction, the CAPL source code of the data playback function is corrected. The specific correction method is: in the CAPL script, an output statement (correction statement) is added inside the on message event handler (corresponding to the target time point) of the “enter programming session” request message, which is used to send the “gear = P gear” message to the bus. Thus, the corrected data playback function is obtained.

[0057] In the embodiments of the present application, due to the inherent differences between the simulation bench environment and the real vehicle running environment, in addition to the signal missing problem identified and corrected in steps S104-S105, there are also a large number of periodic messages of ECU ports on the bus in the real vehicle running environment, which constitutes the real network load. This load subtly affects the scheduling and execution timing of the internal tasks of the domain controller, which may cause slight fluctuations in the message sending period of the domain controller. In the simulation bench environment with extremely low load or complete isolation, due to the lack of such real network pressure, the sending period of the domain controller message may present unrealistic stability. In addition, in the complex function of flashing, the high bus load of the real vehicle running environment may cause message delay or occasional loss, thereby causing occasional failure of flashing. This situation is difficult to reproduce in the simulation bench environment with insufficient load, resulting in a situation where the simulation bench environment test passes, but the real vehicle test fails. Therefore, in order to correct the data playback function comprehensively and reproduce a more realistic real vehicle running environment, when performing steps S104-S105, steps S114-S116 can also be included: S114: Compare the test data and the log file to determine the period tolerance of the domain controller message sending in the real vehicle running environment and the simulation bench environment, respectively.

[0058] Specifically, the period of the domain controller message sending in the simulation bench environment can be extracted from the test data obtained in step S103, the average period and the period jitter range are calculated, and the simulation period tolerance is obtained. At the same time, the period of the domain controller message sending in the same or similar working conditions is extracted from the log file obtained in step S101, and the same calculation is performed to obtain the real vehicle period tolerance.

[0059] S115: Determine the periodic correction coefficient according to the period tolerance.

[0060] Specifically, the simulation period tolerance and the real vehicle period tolerance can be compared. If there is a difference between the simulation period tolerance and the real vehicle period tolerance, the real vehicle period tolerance is taken as the periodic correction coefficient. For example, the simulation period tolerance is 100ms±2ms, and the real vehicle period tolerance is 100ms±10ms. The periodic correction coefficient is determined as 100ms±10ms, which is consistent with the real vehicle running environment.

[0061] S116: Correct the target test case based on the periodic correction coefficient.

[0062] Specifically, the periodic correction coefficient obtained in S114 can be applied to the target test case. It should be noted that at this time, the correction is not to modify the data playback function, but to update the judgment condition in all target test cases. For example, in a target test case aimed at testing the communication function, the original judgment condition is "message period needs to be in 100ms ± 2ms". According to the periodic correction coefficient determined in S114, the judgment condition is modified to "message period needs to be in 100ms ± 10ms". In this way, the acceptance criteria of the simulation bench environment are aligned with the actual performance of the domain controller in the real vehicle running environment, avoiding misjudgment of normal performance fluctuations in the real vehicle running environment as defects, preventing packet loss, and thus significantly improving the accuracy and reliability of the test results in the simulation bench environment.

[0063] In the above step S106, the domain controller is automatically tested based on the corrected data playback function.

[0064] Specifically, the corrected data playback function can be deployed to the continuous integration process or the automated test management platform. Subsequently, the test system automatically calls the corrected data playback function to construct a test scene in the simulation bench environment that is highly consistent with the real vehicle running environment. In this high-fidelity simulation environment, the automated test engine executes a comprehensive test suite in a predetermined sequence to achieve fast, reliable, and highly consistent automated evaluation of the software quality of the domain controller with the real vehicle results, significantly improving test efficiency and ensuring defect-free flow.

[0065] In the embodiments of the present application, the method can effectively solve the problem of inconsistent simulation environment caused by insufficient load, missing associated hardware, etc. in the simulation bench environment. Through real vehicle data playback and closed-loop correction mechanism, the method can accurately reproduce the real vehicle bus load and signal logic in the simulation bench environment, ensuring that the input signals received by the domain controller meet the real vehicle running conditions in terms of timing, numerical value and logical relationship. Further, by comparing and analyzing the test results in the simulation bench environment with the real vehicle collected data, the method can automatically identify environmental deviations and implement targeted correction, thereby significantly improving the consistency of the simulation bench environment and the real vehicle running environment in the testing of communication, diagnosis, routing, flashing and other basic software functions.

[0066] The method can effectively avoid the test blind area caused by the distortion of the simulation bench environment, such as the controller periodic transmission stability deviation caused by the difference in bus load, or the occasional failure of the flashing process caused by incomplete signal logic. By improving the defect detection capability in the bench test stage, the method can significantly reduce the rework cost and project risk caused by the omission of problems to the real vehicle verification stage, thereby improving the test efficiency while effectively controlling the economic loss in the development process.

[0067] Embodiment two Based on the same inventive concept, the embodiment of the present application also provides a test device based on real vehicle operation environment playback, referring to Figure 2 The device comprises: The collection module 101 is configured to obtain a log file according to all message data between the domain controller and each associated port under a real vehicle operation environment. The construction module 102 is configured to construct a data playback function based on the log file. The test module 103 is configured to sequentially run the data playback function and a target test case in a simulated bench environment to obtain test data. The correction module 104 is configured to compare the test data with the log file to obtain a correction instruction. The correction module 105 is configured to correct the data playback function based on the correction instruction to obtain a corrected data playback function. The automatic test module 106 is configured to test the domain controller based on the corrected data playback function.

[0068] Embodiment three Based on the same inventive concept, the embodiment of the present application also provides a computer readable storage medium having a computer program / instruction stored thereon, and the computer program / instruction is executed by a processor to implement the test method based on real vehicle operation environment playback as described in the above embodiment one.

[0069] Embodiment four Based on the same inventive concept, the embodiment of the present application also provides a computer program product comprising a computer program / instruction, and the computer program / instruction is executed by a processor to implement the test method based on real vehicle operation environment playback as described in the above embodiment one.

[0070] Embodiment five Based on the same inventive concept, the embodiment of the present application also provides a computer device comprising a memory, a processor, and a computer program stored in the memory, and the processor executes the computer program to implement the test method based on real vehicle operation environment playback as described in the above embodiment one.

[0071] Those skilled in the art should understand that the embodiments of the present application can be provided as a method, a system, or a computer program product. Therefore, the present application can take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present application can take the form of a computer program product implemented on one or more computer usable storage media (including, but not limited to, disk storage and optical storage, etc.) containing computer usable program code.

[0072] The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks. Figure 1 one or more flow or blocks Figure 1 one or more flow or blocks

[0073] The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks. Figure 1 one or more flow or blocks Figure 1 one or more flow or blocks

[0074] The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks. Figure 1 one or more flow or blocks Figure 1 one or more flow or blocks

[0075] Obviously, numerous modifications and variations of the present application are possible in light of the above teachings. It is therefore to be understood that within the scope of the appended claims and their equivalents, the application can be practiced otherwise than as specifically described.

Claims

1. A test method based on real vehicle operation environment playback, characterized in that, The method comprises the following steps: According to all message data between the domain controller and each associated port in the real vehicle running environment, a log file is obtained; Based on the log file, a data playback function is constructed; In the simulation bench environment, the data playback function and the target test case are run in sequence to obtain test data; The test data is compared with the log file to obtain a correction instruction; Based on the correction instruction, the data playback function is corrected to obtain a corrected data playback function; Based on the corrected data playback function, the domain controller is tested.

2. The method of claim 1, wherein, The comparison of the test data with the log file to obtain the correction instruction comprises: Identifying the negative response code returned by the domain controller in the test data; Determining the generation reason of the negative response code in the log file; According to the generation reason, the corresponding correction instruction is determined.

3. The method of claim 2, wherein, The correction instruction includes a target time point and a correction statement; Based on the correction instruction, the correction statement is added to the data playback function at the target time point to obtain a corrected data playback function. The various associated ports include a plurality of electronic control unit (ECU) ports and a plurality of Ethernet nodes; 4. The method of claim 1, wherein, Based on the log file, a data playback function is constructed; All ECU port corresponding messages in the log file are obtained to obtain ECU message logs; Based on the ECU message logs, a data playback function is constructed. Further comprising:

5. The method of claim 1, wherein, Comparing the test data with the log file to determine the period tolerance of message sending of the domain controller in the real vehicle running environment and the simulation bench environment respectively; According to the period tolerance, a periodic correction coefficient is determined; Based on the periodic correction coefficient, the target test case is corrected. Based on the log file, a data playback function is constructed in the CANoe environment using the communication access programming language (CAPL) language.

6. The method of claim 1, wherein, The method comprises the following steps: An acquisition module is configured to obtain a log file according to all message data between a domain controller and each associated port in a real vehicle running environment; 7. A test device based on real vehicle operation environment playback, characterized by, A construction module is configured to construct a data playback function based on the log file; A test module is configured to run the data playback function and a target test case in sequence in a simulation bench environment to obtain test data; A correction module is configured to compare the test data with the log file to obtain a correction instruction; A correction module is configured to correct the data playback function based on the correction instruction to obtain a corrected data playback function; An automatic test module is configured to test the domain controller based on the corrected data playback function. The computer program / instruction is executed by the processor to realize the test method based on the real vehicle running environment playback of any one of claims 1-6. The computer program / instruction is executed by the processor to realize the test method based on the real vehicle running environment playback of any one of claims 1-6.

8. A computer readable storage medium having stored thereon computer programs / instructions, characterized in that, ​ 9. A computer program product comprising computer programs / instructions, characterized in that, ​ 10. A computer device comprising a memory, a processor, and a computer program stored on the memory, wherein the computer program comprises instructions that, when executed by the processor, cause the processor to perform the method of any one of claims 1-9. The processor executes the computer program to implement the test method based on real vehicle operation environment playback according to any one of claims 1-6.

Images