Automatic vehicle testing method and system, vehicle and storage medium

Abstract

The invention relates to a vehicle automatic test method and system, a vehicle and a storage medium. The method comprises the following steps: when an automatic test instruction is received, downloading a pre-configured test case; the test case comprises a test object and a test target; generating a control message according to the test object and the test target; after a control message is transmitted to a central control large screen of the vehicle in an interface triggering mode or a voice triggering mode, a signal transmission link of the control message is tracked; wherein the signal transmission link is a link formed by a central control large screen, a domain controller of a test object and a motor of the test object; and when the signal transmission link is tracked to be interrupted, positioning an interruption position so as to determine the ECU corresponding to the interruption position as a fault ECU. According to the scheme provided by the invention, the problems of low test efficiency, high test cost and difficulty in fault positioning in the prior art can be solved.

Description

Technical Field

[0001] The present application relates to the field of vehicle testing technology, and in particular to a vehicle automated testing method, system, vehicle, and storage medium. Background Art

[0002] The Electronic Control Unit (ECU) is the core component of a vehicle's electronic system, responsible for controlling and managing various functions. Therefore, ECU testing is a key step in ensuring vehicle safety, reliability, performance, and compliance.

[0003] Related technologies require testers to manually complete ECU testing. For example, to test the window function, a person needs to manually operate the vehicle's large screen to open the window and observe whether the window is open. However, this manual testing method is not only inefficient and costly, but also difficult to locate the fault. For example, if the window does not open properly, the tester needs to manually record the CAN (Controller Area Network) messages from each channel, and then conduct R&D analysis on each related ECU to locate the specific faulty ECU, which is time-consuming and labor-intensive. Summary of the Invention

[0004] In order to solve or partially solve the problems existing in the related art, the present application provides a vehicle automation testing method, system, vehicle and storage medium, which can solve the problems existing in the related art such as low testing efficiency, high testing cost and difficulty in fault location.

[0005] A first aspect of the present application provides a vehicle automated testing method, comprising: When receiving an automated test instruction, download a pre-configured test case; the test case includes a test object and a test target; Generate a control message according to the test object and the test target; After transmitting the control message to the vehicle's central control screen via an interface trigger or a voice trigger, tracing a signal transmission link of the control message; wherein the signal transmission link is a link formed by the central control screen, the domain controller of the test object, and the motor of the test object; When it is traced that the signal transmission link is interrupted, the interruption position is located to determine the ECU corresponding to the interruption position as a faulty ECU.

[0006] In one embodiment, when the signal transmission link is detected to be interrupted, locating the interruption position includes: parsing the signal transmission link to obtain a plurality of signal values; Determining whether there is an abnormal value among the multiple signal values; If there is an abnormal value among the multiple signal values, the position corresponding to the abnormal value is determined as the interruption position.

[0007] In one embodiment, when receiving an automated testing instruction, downloading a pre-configured test case includes: Receive automated test instructions through the vehicle's central control screen or in-vehicle voice system; Responding to the automated test instruction, obtaining a vehicle identification code; A test case matching the vehicle identification code is determined and downloaded from a plurality of pre-configured test cases.

[0008] In one embodiment, determining the ECU corresponding to the interruption position as a faulty ECU further includes: Obtaining log information corresponding to the signal transmission link; the log information includes a keyword of each ECU in the signal transmission link; Extracting a target keyword of the ECU corresponding to the interrupt position from the log information; If the target keyword indicates that the ECU corresponding to the interruption position has abnormal transmission, the ECU corresponding to the interruption position is determined to be a faulty ECU.

[0009] In one embodiment, the test case further includes an expected result; and before tracing the signal transmission link of the control message, further includes: Obtaining a test result of the test object; When the test result is inconsistent with the expected result, it is determined to execute the step of tracing the signal transmission link of the control message.

[0010] In one embodiment, the test case further includes a test duration; and obtaining the test result of the test object includes: After the test duration is reached, the current status information of the test object is obtained from the central control screen or sensor; The current state information is used as the test result of the test object.

[0011] In one embodiment, it further includes: Generating a test report using the test results and the faulty ECU; The test report is pushed to the user through interface display or voice broadcast.

[0012] A second aspect of the present application provides a vehicle automated testing system, comprising: A test case download module is used to download pre-configured test cases when receiving automated test instructions; the test cases include test objects and test targets; A control message generation module, configured to generate a control message according to the test object and the test target; A signal transmission link tracking module, configured to track the signal transmission link of the control message after transmitting the control message to the vehicle's central control screen via an interface trigger or voice trigger; wherein the signal transmission link is a link formed by the central control screen, the domain controller of the test object, and the motor of the test object; The fault location module is used to locate the interruption position when tracing the interruption of the signal transmission link, so as to determine the ECU corresponding to the interruption position as the faulty ECU.

[0013] A third aspect of the present application provides a vehicle, comprising: processor; and The memory stores executable codes thereon, and when the executable codes are executed by the processor, the processor is caused to execute the method described above.

[0014] A fourth aspect of the present application provides a computer-readable storage medium having executable code stored thereon. When the executable code is executed by a processor of a vehicle, the processor is caused to execute the method described above.

[0015] A fifth aspect of the present application provides a computer program product, which includes computer instructions, and when the computer instructions are executed by a processor, implements the method described above.

[0016] The technical solution provided by this application may include the following beneficial results: The technical solution of the present application is to download a pre-configured test case when receiving an automated test instruction; the test case includes a test object and a test target; a control message is generated according to the test object and the test target; after transmitting the control message to the vehicle's central control screen through an interface trigger or a voice trigger, the signal transmission link of the control message is tracked; wherein, the signal transmission link is a link formed by the central control screen, the domain controller of the test object, and the motor of the test object; when an interruption in the signal transmission link is tracked, the interruption position is located to determine the ECU corresponding to the interruption position as the faulty ECU. The present application can realize automated testing of the vehicle by executing pre-configured test cases without the need for human intervention throughout the process, thereby improving test efficiency and reducing test costs. Moreover, during the automated test process, the faulty ECU can be quickly and accurately located by tracking the signal transmission link of the control message in real time, thereby shortening the fault location time and improving the fault location accuracy.

[0017] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The above and other objects, features and advantages of the present application will become more apparent by describing in more detail exemplary embodiments of the present application in conjunction with the accompanying drawings, wherein the same reference numerals generally represent the same components in the exemplary embodiments of the present application.

[0019] Figure 1 1 is a flow chart of a vehicle automated testing method according to an embodiment of the present application; Figure 2 1 is another flow chart of the vehicle automated testing method shown in an embodiment of the present application; Figure 3 is a functional schematic diagram of a vehicle automated testing system shown in an embodiment of the present application; Figure 4A to Figure 4C is a schematic diagram of tracking different signal transmission links shown in an embodiment of the present application; Figure 5 This is a flow chart of vehicle automated testing shown in an embodiment of the present application; Figure 6 Schematic diagram of the structure of the vehicle automated testing system shown in the embodiment of the present application; Figure 7 It is a schematic structural diagram of a vehicle shown in an embodiment of the present application. DETAILED DESCRIPTION

[0020] The following describes embodiments of the present application in more detail with reference to the accompanying drawings. Although the accompanying drawings illustrate embodiments of the present application, it should be understood that the present application can be implemented in various forms and should not be limited by the embodiments described herein. Rather, these embodiments are provided to make the present application more thorough and complete, and to fully convey the scope of the present application to those skilled in the art.

[0021] The terms used in this application are for the purpose of describing specific embodiments only and are not intended to limit this application. As used in this application and the appended claims, the singular forms "a," "an," "the," and "the" are intended to include the plural forms, unless the context clearly indicates otherwise. It should also be understood that the term "and / or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

[0022] It should be understood that although the terms "first", "second", "third", etc. may be used in this application to describe various information, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from each other. For example, without departing from the scope of this application, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the features. In the description of this application, the meaning of "plurality" is two or more, unless otherwise clearly and specifically defined.

[0023] Related technologies require testers to manually complete ECU testing. For example, to test the window function, they need to manually operate the vehicle's large screen to open the window and observe whether the window is open. However, this manual testing method not only has low testing efficiency and high testing costs, but also makes fault location difficult. For example, if the window does not open normally, the tester needs to manually record each CAN message and then conduct R&D analysis on each related ECU in order to locate the specific faulty ECU, which is time-consuming and labor-intensive.

[0024] In response to the above problems, an embodiment of the present application provides a vehicle automation testing method. By executing pre-configured test cases, automated testing of the vehicle can be achieved without the need for human intervention throughout the process, thereby improving testing efficiency and reducing testing costs. Moreover, during the automated testing process, the signal transmission link of the control message can be tracked in real time to quickly and accurately locate the faulty ECU, thereby shortening the fault location time and improving the fault location accuracy.

[0025] The technical solutions of the embodiments of the present application are described in detail below with reference to the accompanying drawings.

[0026] Figure 1 It is a flow chart of the vehicle automated testing method shown in an embodiment of the present application.

[0027] See also Figure 1 The vehicle automated testing method of the present application comprises: S110 , when receiving an automated test instruction, downloading a pre-configured test case; the test case includes a test object and a test target.

[0028] In embodiments of the present application, a vehicle automated testing system (hereinafter referred to as the "test system") can be applied. The test system includes an APK (Android application package) and a server. The server is deployed in the cloud and is responsible for managing test cases, issuing test tasks, and generating visual test reports. The APK is deployed in the vehicle. Testers can install the APK on the vehicle's central control screen, enabling on-vehicle deployment. The APK is used to download and execute test cases, determine execution results, and report test data. Steps S110 to S140 are performed by the APK.

[0029] In practice, when a tester wants to perform automated testing on a vehicle, they can trigger the automated testing control in the UI (User Interface) on the vehicle's central control screen, allowing the APK to receive automated testing instructions. Furthermore, the tester can select a target test task from the multiple test tasks displayed in the UI, which can include at least one. In response to the automated testing instruction, the APK generates a test request containing information about the target test task and then uploads the test request to the server. The server manages multiple preconfigured test tasks and test cases. Each test task tests a vehicle function. For example, Test Task 1 tests the windows, Test Task 2 tests the trunk, Test Task 3 tests the doors, and Test Task 4 tests the seats. Each test task is bound to at least one test case. For example, Test Task 1 is bound to Test Cases A and B, and Test Task 2 is bound to Test Case C. Test Case A tests the left window, Test Case B tests the right window, and Test Case C tests the trunk. After receiving the test request, the server side responds to the test request, determines the target test task from multiple test tasks, and then sends the target test task to the target execution node, so that the APK side can download at least one test case bound to the target test task from the target execution node.

[0030] Each test case can include a test object and a test target. The test object refers to the specific function, module, system, or component being tested, and the test target refers to the specific requirement or behavior being verified through testing. For example, in test case A, the test object is the left window, and the test target is opening; in test case B, the test object is the right window, and the test target is opening; and in test case C, the test object is the trunk, and the test target is opening.

[0031] S120: Generate a control message according to the test object and the test target.

[0032] If the test case includes one, the APK side can directly execute the test case; if the test case includes at least two, the APK side can execute these test cases in sequence.

[0033] The APK implements automated vehicle testing by executing test cases. Specifically, it extracts the test object and test target from the test case. Based on these test objects and test targets, it generates control messages that instruct the test object to execute the test target. Each test case corresponds to a control message, and each control message is a CAN message.

[0034] S130, after transmitting the control message to the vehicle's central control screen through an interface trigger or a voice trigger, track the signal transmission link of the control message; wherein the signal transmission link is a link formed by the central control screen, the domain controller of the test object, and the motor of the test object.

[0035] In order to call CarService (in-vehicle system service) without human intervention, the APK side can transmit control messages to the central control screen through interface triggering or voice triggering, so that the central control screen can call CarService. CarService is the communication bridge between multiple ECUs. Therefore, control messages are transmitted to the MCU through CarService, and the MCU then transmits the control messages to each ECU.

[0036] During the transmission process, the APK can track the signal transmission link of the control message in real time. CarService belongs to the CDCU SOC (Central Domain Control Unit-System on Chip), and the MCU belongs to the CDCU MCU (Central Domain Control Unit-Microcontroller Unit). Therefore, the signal transmission link of the control message is: central control screen (CarService, MCU) → test object's domain controller → test object's motor.

[0037] S140 , when it is traced that the signal transmission link is interrupted, the interruption position is located to determine the ECU corresponding to the interruption position as a faulty ECU.

[0038] The APK side tracks in real time whether a signal interruption event occurs in the signal transmission link of "central control screen → domain controller of the test object → motor of the test object". If a signal interruption event occurs, it means that the test object cannot execute the test target. For example, the left window does not open normally. Then, the APK side can locate the interruption position (that is, the location where the signal interruption event occurs) from the signal transmission link, so as to identify the ECU corresponding to the interruption position as the faulty ECU, thereby quickly and accurately finding the cause of the problem.

[0039] As can be seen from this example, the solution provided by this application downloads a pre-configured test case when an automated test instruction is received; the test case includes a test object and a test target; a control message is generated based on the test object and the test target; after transmitting the control message to the vehicle's central control screen through an interface trigger or a voice trigger, the signal transmission link of the control message is tracked; wherein, the signal transmission link is a link formed by the central control screen, the domain controller of the test object, and the motor of the test object; when an interruption in the signal transmission link is traced, the interruption position is located to identify the ECU corresponding to the interruption position as the faulty ECU. This application can realize automated testing of vehicles by executing pre-configured test cases without the need for manual intervention throughout the process, thereby improving test efficiency and reducing test costs. Moreover, during the automated testing process, the faulty ECU can be quickly and accurately located by tracking the signal transmission link of the control message in real time, thereby shortening the fault location time and improving the fault location accuracy.

[0040] Figure 2 This is another flowchart of the vehicle automation testing method shown in this application.

[0041] See also Figure 2 The vehicle automated testing method of the present application comprises: S210, when receiving an automated test instruction, downloading a pre-configured test case; the test case includes a test object, a test goal, and an expected result.

[0042] The vehicle automated testing system (hereinafter referred to as the "test system") can include an APK and a server. The server is deployed in the cloud, and the APK is deployed in the vehicle (specifically, installed in the vehicle's central control screen). Steps S210 to S260 are executed by the APK, while steps S270 to S280 are executed by the server.

[0043] like Figure 3As shown in the figure, the server includes the front-end area, the back-end area, the data storage area and the execution node area. Among them, the front-end area provides functions such as use case management, task management, execution node management, vehicle management, test reports and statistical reports. The back-end area provides functions such as node scheduling, automatic vehicle registration, use case distribution, message processing, log parsing, peripheral result acquisition, trace (black box) tracking and report generation. The data storage area includes data storage systems such as MySQL (My Structured Query Language, relational database management system), Redis (Remote Dictionary Server, memory data structure storage system), MQ (Message Queue, message queue), etc. The execution node area includes execution node 1 to execution node N (N is a positive integer greater than 1, in Figure 3 (medium, N=5).

[0044] like Figure 3 As shown, the APK side includes a server-side interaction area, a use case execution area, a result determination area, and a user interface area. The server-side interaction area provides functions such as vehicle registration, use case downloading, and result uploading. The use case execution area provides functions such as use case analysis, script execution, and data storage. The result determination area provides functions such as CAN data analysis, log analysis, and trace tracking. The UI interface area provides functions such as use case set selection, execution progress viewing, and simple test reports.

[0045] In practice, when a tester wants to perform automated testing on a vehicle, they can trigger the automated testing control in the UI of the vehicle's central control screen, allowing the APK to receive automated testing instructions. Furthermore, the tester can select a target use case set from the multiple use case sets displayed on the UI. A target use case set includes at least one test case corresponding to the same test task, so a use case set can be considered a test task. In response to the automated testing instruction, the APK generates a test request that carries information about the target test task (i.e., the target use case set), and then uploads the test request to the server.

[0046] like Figure 3As shown, the front-end area of ​​the server manages a variety of pre-configured test tasks and multiple test cases, wherein each test task is bound to at least one test case. After receiving the test request, the server determines the target test task from the multiple test tasks in response to the test request. Then, the back-end area of ​​the server schedules a target execution node with a relatively small load from the execution node area based on the load of each execution node, so as to send the target test task to the target execution node, so that the APK end can download the target use case set bound to the target test task from the target execution node. The target use case set includes at least one test case corresponding to the target test task.

[0047] Each test case may include a test object, a test objective, and an expected result. The test object refers to the specific function, module, system, or component being tested; the test objective refers to the specific requirement or behavior being verified through testing; and the expected result refers to the correct behavior or output that the test object should have after the test steps are executed. For example, assuming that test case A is used to test the left window function, test case B is used to test the right window function, and test case C is used to test the trunk function, then the test object in test case A is the left window, the test objective is open, and the expected result is that the left window opens normally; the test object in test case B is the right window, the test objective is open, and the expected result is that the right window opens normally; and the test object in test case C is the trunk, the test objective is open, and the expected result is that the trunk opens normally.

[0048] In one embodiment, upon receiving an automated testing instruction, downloading a pre-configured test case may include: Receive automated test instructions through the vehicle's central control screen or in-vehicle voice system; obtain the vehicle identification code in response to the automated test instructions; determine and download the test case that matches the vehicle identification code from multiple pre-configured test cases.

[0049] The APK can receive automated test instructions through the vehicle's central control screen. For example, a tester can trigger an automated test control in the vehicle's central control screen UI, allowing the APK to receive the automated test instructions. Alternatively, the APK can receive automated test instructions through the vehicle's onboard voice system. For example, a tester can input voice information into the onboard voice system, which recognizes the voice information and then generates automated test instructions based on the recognition results, allowing the APK to receive the automated test instructions.

[0050] It can be seen that the embodiment of the present application does not require the aid of external equipment, and can directly receive automated test instructions through the central control screen or the vehicle voice system, so that the APK end responds to the automated test instructions to perform automated testing on the vehicle. It is suitable for real vehicle scenarios such as real vehicle static testing, real vehicle dynamic testing, factory off-line inspection, and can quickly carry out automated testing.

[0051] It should be noted that the embodiments of the present application can also use external devices to receive automated test instructions. For example, the tester establishes a connection between a mobile terminal (such as a mobile phone, laptop computer, etc.) and the central control screen through a USB (Universal Serial Bus). The tester then uses the mobile terminal to send automated test instructions to the APK end, so that the APK end responds to the automated test instructions to perform automated testing on the vehicle.

[0052] If the tester does not select the target test task from the multiple test tasks displayed on the UI interface, or the voice information input by the tester does not contain the target test task, the APK side can directly obtain the VIN (Vehicle Identification Number) of the vehicle. The VIN code is the unique identity of the vehicle. In response to the automated test instruction, the APK side generates a test request, which carries the VIN code of the vehicle, and then uploads the test request to the server. The front-end area of ​​the server manages multiple VIN codes of vehicles, and each VIN code is bound to a corresponding test task. Therefore, after receiving the test request, the server responds to the test request, determines the target VIN code from multiple VIN codes, and then determines the target test task bound to the target VIN code, so as to send the target test task to the target execution node, so that the APK side can download the target use case set bound to the target test task from the target execution node.

[0053] S220: Generate a control message according to the test object and the test target.

[0054] If the test case includes one, the APK side can directly execute the test case; if the test case includes at least two, the APK side can execute these test cases in sequence.

[0055] By executing the test cases on the APK side, automated testing of the vehicle can be achieved. Specifically, the APK side extracts the test object and test target from the test case, and then generates a control message based on the test object and test target. The control message is used to instruct the test object to execute the test target. Each test case corresponds to a control message, and each control message is a CAN message. For example, assuming that test case A corresponds to control message A, test case B corresponds to control message B, and test case C corresponds to control message C, then control message A is used to instruct the opening of the left window, control message B is used to instruct the opening of the right window, and control message C is used to instruct the opening of the tailgate (i.e., the opening of the trunk).

[0056] S230: Transmitting a control message to the vehicle's central control screen via an interface trigger or a voice trigger.

[0057] To enable unattended invocation of CarService, the APK can transmit control messages to the central control screen via either interface or voice triggering. For example, the interface triggering method might involve the APK simulating a click on the central control screen's UI. For example, the voice triggering method might involve the APK inputting voice commands into the vehicle's voice system. Upon receiving the control message, the central control screen can invoke CarService, which then transmits the control message to the MCU. The MCU then transmits the control message to each ECU.

[0058] S240: Obtain the test result of the test object.

[0059] After each test case is executed, the APK can obtain the test results corresponding to the test object targeted by the test case.

[0060] In one embodiment, the test case also includes a test duration; obtaining the test result of the test object may include: After the test duration is reached, the current status information of the test object is obtained from the central control screen or sensor; the current status information is used as the test result of the test object.

[0061] The APK side can extract the test duration from the test case, and then monitor whether the duration of the test process reaches the test duration. When it is monitored that the duration reaches the test duration, the APK side determines that the test process corresponding to the test case is ended, and then the indicator light image or UI element image of the test object can be captured from the UI interface of the central control screen, or the vehicle status data can be obtained from the vehicle's sensors (such as cameras, radars, etc.), and then the current status information of the test object is obtained based on the indicator light image or UI element image or vehicle status data, so that the current status information can be used as the test result of the test object.

[0062] In one example, the APK side captures the indicator light image of the test object from the UI interface of the central control screen, and then compares the indicator light image with the lighted image. If the indicator light image is consistent with the lighted image, it means that the indicator light of the test object is in the lighted state, and the lighted state indicates that the test object is in the open state. Therefore, the APK side obtains the current state information used to characterize that the test object is in the open state; if the indicator light image is inconsistent with the lighted image, it means that the indicator light of the test object is in the off state, and the off state indicates that the test object is in the closed state. Therefore, the APK side obtains the current state information used to characterize that the test object is in the closed state.

[0063] In another example, the APK side captures the UI element image of the test object from the UI interface of the central control screen, and then compares the UI element image with the open image. If the UI element image is consistent with the open image, it means that the test object is in an open state in the UI interface, so the APK side obtains the current state information used to characterize that the test object is in an open state; if the UI element image is inconsistent with the open image, it means that the test object is in a closed state in the UI interface, so the APK side obtains the current state information used to characterize that the test object is in a closed state.

[0064] In another example, the APK acquires vehicle status data from the vehicle's camera and then performs DIC-AI (Digital Image Correlation-Artificial Intelligence) testing on this data to determine the current state of the test object. DIC-AI testing is an advanced inspection method that combines digital image correlation (DIC) and artificial intelligence (AI). The DIC component calculates displacement and strain fields by comparing images of the object's surface before and after a load is applied. The AI ​​component utilizes deep learning mechanisms to optimize image matching, noise suppression, and defect identification, improving the accuracy and efficiency of traditional DIC.

[0065] S250, when the test result is inconsistent with the expected result, trace the signal transmission link of the control message; wherein the signal transmission link is a link formed by the central control screen, the domain controller of the test object, and the motor of the test object.

[0066] The APK side can compare the test results of the test object with the expected results set by the test case. When the test results are consistent with the expected results, it means that there is no faulty ECU, so the test object can successfully execute the test target. For example, if the left window opens normally, the APK side does not need to track the signal transmission link of the control message. When the test results are inconsistent with the expected results, it means that there is a faulty ECU, so the test object cannot execute the test target. For example, if the left window does not open normally, the APK side can track the signal transmission link of the control message to find the cause of the problem based on the tracking situation. Among them, the signal transmission link can be a link formed by the central control screen, the domain controller of the test object, and the motor of the test object.

[0067] As an example, Figure 4A It is the signal transmission link of control message A, such as Figure 4A As shown, the signal transmission link for control message A is: voice (i.e., the in-vehicle voice system) → vehicle control (i.e., the vehicle control system) → CarService layer → HAL (Hardware Abstraction Layer) layer → MCU → LDCU (Left Domain Control Unit) → left window. The LDCU is responsible for centralized control of the vehicle's left-side electronic systems and is therefore the domain controller for the test object (e.g., the left window) in the left area of ​​the vehicle. The left window in this signal transmission link specifically refers to the motor used to control the left window.

[0068] As another example, Figure 4B It is the signal transmission link of control message B, such as Figure 4B As shown, the signal transmission link for control message B is: voice (i.e., the in-vehicle voice system) → vehicle control (i.e., the vehicle control system) → CarService layer → HAL layer → MCU → RDCU (Right Domain Control Unit) → right window. The RDCU is responsible for centralized control of the vehicle's right-side electronic systems and is therefore the domain controller for the test object in the right area of ​​the vehicle (e.g., the right window). The right window in this signal transmission link specifically refers to the motor used to control the right window.

[0069] As another example, Figure 4C It is the signal transmission link of control message C, such as Figure 4CAs shown, the signal transmission link for control message C is: voice (i.e., the in-vehicle voice system) → vehicle control (i.e., the vehicle control system) → CarService layer → HAL layer → MCU → LDCU → RDM (Rear Door Module) → tailgate (i.e., trunk). The RDM is responsible for controlling the vehicle's tailgate and is therefore the domain controller for the test object in the rear area of ​​the vehicle (e.g., the trunk). The tailgate in this signal transmission link specifically refers to the motor used to control the tailgate.

[0070] Since the in-vehicle voice system, vehicle control system, CarService layer, and HAL layer belong to the CDCU SOC, and the MCU belongs to the CDCU MCU, the in-vehicle voice system, vehicle control system, CarService layer, HAL layer, and MCU all belong to the central control screen. Therefore, the signal transmission link for each control message is: central control screen → domain controller of the test object → motor of the test object.

[0071] S260: When it is traced that the signal transmission link is interrupted, the interruption position is located to determine the ECU corresponding to the interruption position as a faulty ECU.

[0072] Since the test results of the test object are inconsistent with the expected results set by the test case, it means that there is a signal interruption event in the signal transmission link of "central control large screen → domain controller of the test object → motor of the test object". The APK side can locate the interruption position (that is, the location where the signal interruption event occurs) from the signal transmission link of "central control large screen → domain controller of the test object → motor of the test object" to identify the ECU corresponding to the interruption position as the faulty ECU, thereby quickly and accurately finding the cause of the problem.

[0073] In one embodiment, when a signal transmission link is detected to be interrupted, locating the interruption location may include: The signal transmission link is analyzed to obtain multiple signal values; whether there is an abnormal value among the multiple signal values ​​is determined; if there is an abnormal value among the multiple signal values, the position corresponding to the abnormal value is determined as the interruption position.

[0074] The APK side can obtain multiple signal values ​​by analyzing the signal transmission link of "central control large screen → domain controller of the test object → motor of the test object", where each signal value corresponds to an ECU. The APK side can determine whether there are abnormal values ​​in these signal values. If there are abnormal values, it means that there is a signal interruption event in the signal transmission link of "central control large screen → domain controller of the test object → motor of the test object", so the position corresponding to the abnormal value can be directly determined as the interruption position.

[0075] In one example, Figure 4AAs shown, test case A (ie case 1) is used to test the left window function. The APK side generates control message A according to test case A. Control message A is used to instruct to open the left window. The APK side transmits control message A to the vehicle voice system through voice triggering. Since the ECU of the vehicle voice system is normal, the vehicle voice system can transmit control message A to the next node (ie vehicle control system) after receiving control message A. Since the ECU of the vehicle control system is normal, the vehicle control system can transmit control message A to the next node (ie CarService layer) after receiving control message A. Since the ECU of the CarService layer is normal, the CarService layer can transmit control message A to the next node (ie HAL layer) after receiving control message A. Since the HAL layer The ECU of the LDCU is faulty, so the LDCU cannot transmit control message A to the motor used to control the left window, resulting in the left window not opening normally. The APK parses the signal transmission link of control message A and obtains multiple signal values: 1-1-1-1-1-0-2, where "1" indicates successful control message transmission, "0" indicates failed control message transmission, and "2" indicates that the control message was not received. The APK can then locate the ECU corresponding to the signal value "0" to quickly and accurately locate the faulty LDCU ECU.

[0076] In another example, Figure 4BAs shown, test case B (ie case2) is used to test the right window function. The APK side generates control message B according to test case B. Control message B is used to instruct to open the right window. The APK side transmits control message B to the vehicle voice system through voice triggering. Since the ECU of the vehicle voice system is normal, the vehicle voice system can transmit control message B to the next node (ie vehicle control system) after receiving control message B. Since the ECU of the vehicle control system is normal, the vehicle control system can transmit control message B to the next node (ie CarService layer) after receiving control message B. Since the ECU of the CarService layer is normal, the CarService layer can transmit control message B to the next node (ie HAL layer) after receiving control message B. Since the ECU of the HAL layer is normal, the HAL layer After receiving control message B, the control message B can be transmitted to the next node (i.e., MCU); since the ECU of the MCU is normal, the MCU can transmit control message B to the next node (i.e., RDCU) after receiving control message B; since the ECU of the RDCU is normal, the RDCU can transmit control message B to the next node (i.e., the motor used to control the right window) after receiving control message B; since the ECU of the motor is faulty, the motor cannot control the right window, resulting in the right window not opening normally; the APK side parses the signal transmission link of control message B and obtains multiple signal values: 1-1-1-1-1-1-0, where "1" indicates successful control message transmission and "0" indicates failure to control the test object. The APK side can then quickly and accurately locate the ECU of the faulty motor by locating the ECU corresponding to the signal value "0".

[0077] In another example, Figure 4CAs shown, test case C (i.e. case 3) is used to test the tailgate function. The APK side generates a control message C according to the test case C. The control message C is used to instruct to open the tailgate. The APK side transmits the control message C to the vehicle voice system through voice triggering. Since the ECU of the vehicle voice system is normal, the vehicle voice system can transmit the control message C to the next node (i.e. the vehicle control system) after receiving the control message C. Since the ECU of the vehicle control system is normal, the vehicle control system can transmit the control message C to the next node (i.e. the CarService layer) after receiving the control message C. Since the ECU of the CarService layer is normal, the CarService layer can transmit the control message C to the next node (i.e. the HAL layer) after receiving the control message C. Since the ECU of the HAL layer is normal, the HAL layer can transmit the control message C to the next node (i.e. the HAL layer) after receiving the control message C. The node (i.e., MCU) transmits control message C; since the ECU of the MCU is normal, the MCU can transmit control message C to the next node (i.e., LDCU) after receiving control message C; since the ECU of the LDCU is normal, the LDCU can transmit control message C to the next node (i.e., RDM) after receiving control message C; since the ECU of the RDM is normal, the RDM can transmit control message C to the next node (i.e., the motor used to control the tailgate) after receiving control message C; since the ECU of the motor is normal, the motor can control the tailgate to open after receiving control message C; the APK side parses the signal transmission link of control message C and obtains multiple signal values: 1-1-1-1-1-1-1-1, among which "1" indicates that the control message is successfully transmitted or the test object is successfully controlled. The APK side can then determine that there is no signal interruption event in the signal transmission link of control message C.

[0078] In one embodiment, determining the ECU corresponding to the interruption position as a faulty ECU may include: Obtain log information corresponding to a signal transmission link; the log information includes keywords of each ECU in the signal transmission link; extract a target keyword of the ECU corresponding to the interruption position from the log information; if the target keyword indicates that the ECU corresponding to the interruption position has a transmission anomaly, determine the ECU corresponding to the interruption position as a faulty ECU.

[0079] In order to ensure the reliability of the test results of the test object without human intervention, the APK side has multi-modal judgment capabilities, supporting multiple result judgment methods such as signal result analysis, log feature extraction, indicator light image comparison, UI element comparison and DIC-AI detection. Among them, the indicator light image comparison, UI element image comparison and DIC-AI detection refer to steps S240 to S250, and the signal result analysis refers to steps S250 to S260, which will not be repeated here.

[0080] Regarding the result determination method of log feature extraction, after locating the interruption position, the APK side can obtain the log information corresponding to the signal transmission link, where the log information can contain the keywords of each ECU in the signal transmission link. The APK side can extract the target keyword of the ECU corresponding to the interruption position from the log information. If the target keyword is "Fail", it means that the ECU corresponding to the interruption position has an abnormal transmission, and the APK side can determine the ECU corresponding to the interruption position as a faulty ECU.

[0081] It can be seen that the embodiment of the present application locates the faulty ECU by combining at least two result determination methods, which can ensure that the test results of the test object are reliable without human intervention, thereby further improving the fault location accuracy.

[0082] In one example, see Figure 4A , the APK side locates the ECU with the interrupt position as LDCU, then the APK side can obtain the log information a corresponding to the signal transmission link of the control message A, where the log information a contains the keywords of each ECU in the signal transmission link: Success→Success→Success→Success→Success→Fail→Null, where "Success" indicates that the control message transmission is successful, "Fail" indicates that the control message transmission fails, and "Null" indicates that the control message is not received. The target keyword of the ECU of the LDCU extracted by the APK side from the log information a is "Fail", so the ECU of the LDCU can be determined as the faulty ECU.

[0083] In another example, see Figure 4B , the APK side locates that the interrupt position is the ECU of the motor, then the APK side can obtain the log information b corresponding to the signal transmission link of the control message B, where the log information b contains the keywords of each ECU in the signal transmission link: Success→Success→Success→Success→Success→Success→Fail, where "Success" indicates that the control message transmission is successful, and "Fail" indicates that the control test object fails. The target keyword of the motor ECU extracted by the APK side from the log information b is "Fail", so the motor ECU can be determined as the faulty ECU.

[0084] It should be noted that indicator light image comparison, UI element comparison and DIC-AI detection are all used to determine whether there is a faulty ECU, and signal result analysis and log feature extraction are both used to locate the faulty ECU. The embodiment of the present application can directly perform signal result analysis and / or log feature extraction, or can first perform indicator light image comparison or UI element comparison or DIC-AI detection, and when the test results are inconsistent with the expected results, perform signal result analysis and / or log feature extraction.

[0085] It should be noted that both signal result analysis and log feature extraction locate the faulty ECU based on the interruption position. The difference is that signal result analysis uses signal value to determine the interruption position, while log feature extraction uses keywords to determine the interruption position. For example, if the ECU of the LDCU is faulty, its signal value is "0" and the target keyword is "Fail", thereby quickly and accurately locating the faulty LDCU ECU.

[0086] It can be seen that compared with the related art that requires testers to manually complete ECU testing, the embodiment of the present application can complete ECU testing using pre-configured test cases after receiving automated testing instructions, without the need for human intervention throughout the process, thereby greatly improving testing efficiency. For example, factory inspection hours are reduced by 30%, and testing costs are also greatly reduced.

[0087] It can be seen that compared with the related art that requires testers to manually complete the faulty ECU positioning, the embodiment of the present application can locate the faulty ECU by real-time tracking of the signal transmission link when the test results are inconsistent with the expected results, without the need for human intervention throughout the process, thereby greatly shortening the fault positioning time, for example, the fault positioning time is shortened by 65%, and also greatly improving the fault positioning accuracy.

[0088] It should be noted that the embodiment of the present application can track the signal transmission link in real time through the APK end, and can also track the signal transmission link in real time through the canoe (can bus development tool) device.

[0089] S270 generates a test report using the test results and the faulty ECU.

[0090] The APK side can provide simple test reports, such as displaying test results to testers through a UI interface. Because the computing power of the APK side is lower than that of the server side, the APK side can synchronize the test data generated during the test process to the target execution node in real time. The test data can include test results, analysis results of the signal transmission link, and faulty ECUs. The target execution node uses this test data to generate a test report. For example, the target execution node fills this test data into a preset template to generate a test report. The test report can be in the form of a table, document, or image.

[0091] S280: Push the test report to the user through an interface display or voice broadcast.

[0092] The target execution node can upload the test report to the front-end area of ​​the server, so that the front-end area can send the test report to the vehicle's central control screen, so that the test report can be pushed to the user (such as the tester) through the interface display; or, the front-end area can send the test report to the user's (such as the tester's) mobile terminal (such as a mobile phone, laptop computer, etc.), so that the test report can be pushed to the user (such as the tester) through the interface display; or, the front-end area can send the test report to the vehicle's in-vehicle voice system, so that the test report can be pushed to the user (such as the tester) through voice broadcast.

[0093] As can be seen from this example, the solution provided in this application can realize automated testing of vehicles by executing pre-configured test cases, without the need for human intervention throughout the process, thereby improving test efficiency and reducing test costs. Moreover, during the automated testing process, by real-time tracking of the signal transmission link of the control message, the faulty ECU can be located quickly and accurately, thereby shortening the fault location time and improving the fault location accuracy.

[0094] Furthermore, the solution provided in this application can directly receive automated test instructions through the central control screen or the in-vehicle voice system without the aid of external equipment, so that the APK side can respond to the automated test instructions to perform automated testing on the vehicle. It is suitable for real vehicle scenarios such as static testing, dynamic testing, and factory offline inspection, and can quickly carry out automated testing.

[0095] Furthermore, the solution provided by this application is that the APK side has multi-modal judgment capabilities, supporting multiple result judgment methods such as signal result analysis, log feature extraction, indicator light image comparison, UI element comparison and DIC-AI detection. By combining at least two result judgment methods to locate the faulty ECU, it can ensure that the test results of the test object are reliable without human intervention, thereby further improving the fault location accuracy.

[0096] In order to enable those skilled in the art to better understand the embodiments of the present application, the embodiments of the present application are described below with the help of the following examples.

[0097] See also Figure 5 , the vehicle automation test process is as follows: S1, the vehicle side triggers the whole vehicle automation. Specifically, the tester can trigger the automated test control in the UI interface of the central control screen, so that the APK side can receive the automated test instructions.

[0098] S2, the platform triggers vehicle automation. Specifically, the tester selects the target test task from the multiple test tasks displayed on the UI interface, so that the test request generated by the APK side carries the information of the target test task, and the APK side uploads the test request to the server.

[0099] S3, sending the target test task, specifically, the server responds to the test request, determines the target test task from a variety of test tasks, and then schedules a target execution node with a relatively small load from the execution node area according to the load situation of each execution node, so as to send the target test task to the target execution node.

[0100] S4, downloading the target use case set, specifically, the APK side downloads the target use case set bound to the target test task from the target execution node, and the target use case set includes at least one test case corresponding to the target test task.

[0101] S5, transmits control messages to the central control screen through interface triggering or voice triggering. Specifically, the APK side can generate control messages according to the test objects and test targets set in the test case, and then transmit the control messages to the central control screen by simulating click operations in the UI interface, or by inputting voice commands into the vehicle voice system to transmit control messages to the central control screen, so that the central control screen calls CarService, and then transmits the control messages to the MCU through CarService. The MCU then transmits the control messages to ECU1~ECUn, where n is an integer greater than 4.

[0102] S6, obtains the test results of the test object with the help of vehicle sensors. Specifically, after the APK detects that the duration of the test process reaches the test duration set by the test case, it obtains vehicle status data from the vehicle camera (such as camera, radar, etc.), and then obtains the current status information of the test object by performing DIC-AI detection on the vehicle status data, so that the current status information can be used as the test result.

[0103] S7, determine whether the test result of the test object is consistent with the expected result set by the test case. If not, jump to step S8; if so, execute the next test case until all test cases are executed.

[0104] S8, parsing the signal transmission link. Specifically, when the test result of the test object is inconsistent with the expected result set by the test case, the APK end can track the signal transmission link of the control message in real time: "central control large screen → domain controller of the test object → motor of the test object", and then parse the signal transmission link to obtain multiple signal values, and then locate the abnormal value among the multiple signal values ​​(such as locating the signal value "0"), so as to determine the position corresponding to the abnormal value as the interruption position, and then determine the ECU corresponding to the interruption position as the faulty ECU.

[0105] S9, real-time synchronization test process, specifically the test data generated by the real-time synchronization test process from the APK end to the target execution node. The test data may include test results, analysis results of the signal transmission link, faulty ECU, etc.

[0106] S10, generating a test report, specifically, the target execution node fills the test data into a preset template to generate a test report.

[0107] S11, push the test report, specifically, the server sends the test report to the vehicle's central control screen so that the test report can be pushed to the tester through the interface display; or, the server sends the test report to the tester's mobile terminal so that the test report can be pushed to the tester through the interface display; or, the server sends the test report to the vehicle's onboard voice system so that the test report can be pushed to the tester through voice broadcast.

[0108] Corresponding to the aforementioned application function implementation method embodiment, the present application also provides a vehicle automation testing system, a vehicle and corresponding embodiments.

[0109] Figure 6 This is another structural diagram of the vehicle automation test system shown in an embodiment of the present application.

[0110] See also Figure 6 The vehicle automated testing system provided in this application includes an APK terminal deployed on the vehicle side. The APK terminal may include a test case downloading module 610, a control message generating module 620, a signal transmission link tracking module 630, and a fault location module 640, wherein: The test case download module 610 is used to download pre-configured test cases when receiving automated test instructions; the test cases include test objects and test targets; A control message generation module 620 is used to generate a control message according to a test object and a test target; The signal transmission link tracking module 630 is used to track the signal transmission link of the control message after transmitting the control message to the vehicle's central control screen through an interface trigger or voice trigger. The signal transmission link is the link formed by the central control screen, the domain controller of the test object, and the motor of the test object; The fault location module 640 is used to locate the interruption position when tracing the interruption of the signal transmission link, so as to determine the ECU corresponding to the interruption position as the faulty ECU.

[0111] In one embodiment, the fault location module 640 may include: A signal analysis submodule is used to analyze the signal transmission link and obtain multiple signal values; Anomaly judgment submodule, used to judge whether there are abnormal values ​​among multiple signal values; The interruption position determination submodule is used to determine the position corresponding to the abnormal value as the interruption position if there is an abnormal value among the multiple signal values.

[0112] In one embodiment, the test case download module 610 may include: The automated test command receiving submodule is used to receive automated test commands through the vehicle's central control screen or in-vehicle voice system; A vehicle identification code acquisition submodule, configured to acquire a vehicle identification code in response to an automated test instruction; The test case download submodule is used to determine and download a test case that matches the vehicle identification code from a plurality of pre-configured test cases.

[0113] In one embodiment, the fault location module 640 may further include: The log information acquisition submodule is used to obtain the log information corresponding to the signal transmission link; the log information includes the keywords of each ECU in the signal transmission link; The target keyword extraction submodule is used to extract the target keyword of the ECU corresponding to the interrupt position from the log information; The faulty ECU determination submodule is used to determine the ECU corresponding to the interruption position as a faulty ECU if the target keyword indicates that the ECU corresponding to the interruption position has abnormal transmission.

[0114] In one embodiment, the test case also includes an expected result. Before tracing the signal transmission link of the control message, the APK side may further include: A test result acquisition module is used to obtain the test results of the test object; An execution module is determined, and when the test result is inconsistent with the expected result, a step of executing a signal transmission link of the tracking control message is determined.

[0115] In one embodiment, the test case also includes a test duration; and the test result acquisition module may include: The current status information acquisition submodule is used to obtain the current status information of the test object from the central control screen or sensor after the test time is reached; The test result definition submodule is used to use the current status information as the test result of the test object.

[0116] In one embodiment, the vehicle automated testing system may further include a server deployed in the cloud. The server may include a test report generation module 650 and a test report push module 660, wherein: A test report generating module 650 is used to generate a test report using the test results and the faulty ECU; The test report push module 660 is used to push the test report to the user through interface display or voice broadcast.

[0117] As can be seen from this example, the solution provided by this application downloads a pre-configured test case when an automated test instruction is received; the test case includes a test object and a test target; a control message is generated based on the test object and the test target; after transmitting the control message to the vehicle's central control screen through an interface trigger or a voice trigger, the signal transmission link of the control message is tracked; wherein, the signal transmission link is a link formed by the central control screen, the domain controller of the test object, and the motor of the test object; when an interruption in the signal transmission link is traced, the interruption position is located to identify the ECU corresponding to the interruption position as the faulty ECU. This application can realize automated testing of vehicles by executing pre-configured test cases without the need for manual intervention throughout the process, thereby improving test efficiency and reducing test costs. Moreover, during the automated testing process, the faulty ECU can be quickly and accurately located by tracking the signal transmission link of the control message in real time, thereby shortening the fault location time and improving the fault location accuracy.

[0118] Regarding the system in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the method, and will not be elaborated again here.

[0119] Figure 7 It is a structural diagram of an electronic device shown in an embodiment of the present application.

[0120] See also Figure 7 , the electronic device 700 includes a memory 710 and a processor 720.

[0121] The processor 720 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor. Memory 710 may include various types of storage units, such as system memory, read-only memory (ROM), and permanent storage. ROM may store static data or instructions required by processor 720 or other computer modules. Permanent storage may be a readable and writable storage device. Permanent storage may be a non-volatile storage device that maintains stored instructions and data even when the computer is powered off. In some embodiments, the permanent storage device utilizes a mass storage device (e.g., a magnetic or optical disk, flash memory). In other embodiments, the permanent storage device may be a removable storage device (e.g., a floppy disk, optical drive). System memory may be a readable and writable storage device or a volatile readable and writable storage device, such as dynamic random access memory (DRAM). System memory may store some or all instructions and data required by the processor during operation. Furthermore, memory 710 may include any combination of computer-readable storage media, including various types of semiconductor memory chips (e.g., DRAM, SRAM, SDRAM, flash memory, programmable read-only memory), as well as magnetic disks and / or optical disks. In some embodiments, the memory 710 may include a readable and / or writable removable storage device, such as a compact disc (CD), a read-only digital versatile disc (e.g., DVD-ROM, dual-layer DVD-ROM), a read-only Blu-ray disc, an ultra-density optical disc, a flash memory card (e.g., SD card, mini SD card, Micro-SD card, etc.), a magnetic floppy disk, etc. Computer-readable storage media do not include carrier waves and transient electronic signals transmitted wirelessly or wired.

[0122] The memory 710 stores executable codes. When the executable codes are processed by the processor 720 , the processor 720 may execute part or all of the above-mentioned methods.

[0123] In addition, the method according to the present application may also be implemented as a computer program or a computer program product, which includes computer program code instructions for executing some or all of the steps in the above method of the present application.

[0124] Alternatively, the present application can also be implemented as a computer-readable storage medium (or non-transitory machine-readable storage medium or machine-readable storage medium), which stores executable code (or computer program or computer instruction code) and, when executed by a processor of a vehicle (or server, etc.), enables the processor to perform part or all of the steps of the above-mentioned method according to the present application.

[0125] The present application also provides a computer program product, which includes computer instructions, and when the computer instructions are executed by a processor, the method described above is implemented.

[0126] The embodiments of the present application have been described above. The above description is exemplary, not exhaustive, and is not limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is selected to best explain the principles of the embodiments, their practical applications, or improvements to the technology in the market, or to enable other persons skilled in the art to understand the embodiments disclosed herein.

Claims

1. A vehicle automated testing method, characterized in that: include: When receiving automated testing instructions, download pre-configured test cases; The test case includes a test object and a test target; Generate a control message according to the test object and the test target; After transmitting the control message to the vehicle's central control screen via an interface trigger or a voice trigger, tracing a signal transmission link of the control message; wherein the signal transmission link is a link formed by the central control screen, the domain controller of the test object, and the motor of the test object; When it is traced that the signal transmission link is interrupted, the interruption position is located to determine the electronic control unit ECU corresponding to the interruption position as a faulty ECU.

2. The method according to claim 1, characterized in that When the signal transmission link is detected to be interrupted, locating the interruption position includes: parsing the signal transmission link to obtain a plurality of signal values; Determining whether there is an abnormal value among the multiple signal values; If there is an abnormal value among the multiple signal values, the position corresponding to the abnormal value is determined as the interruption position.

3. The method according to claim 1, characterized in that When receiving the automated test instruction, downloading the pre-configured test case includes: Receive automated test instructions through the vehicle's central control screen or in-vehicle voice system; Responding to the automated test instruction, obtaining a vehicle identification code; A test case matching the vehicle identification code is determined and downloaded from a plurality of pre-configured test cases.

4. The method according to claim 1, wherein The step of determining the ECU corresponding to the interruption position as a faulty ECU further includes: Obtaining log information corresponding to the signal transmission link; the log information includes a keyword of each ECU in the signal transmission link; Extracting a target keyword of the ECU corresponding to the interrupt position from the log information; If the target keyword indicates that the ECU corresponding to the interruption position has abnormal transmission, the ECU corresponding to the interruption position is determined to be a faulty ECU.

5. The method according to claim 1, wherein The test case also includes an expected result; and before tracing the signal transmission link of the control message, further includes: Obtaining a test result of the test object; When the test result is inconsistent with the expected result, it is determined to execute the step of tracing the signal transmission link of the control message.

6. The method according to claim 5, characterized in that The test case also includes a test duration; and obtaining the test result of the test object includes: After the test duration is reached, the current status information of the test object is obtained from the central control screen or sensor; The current state information is used as the test result of the test object.

7. The method according to claim 5, characterized in that Also includes: Generating a test report using the test results and the faulty ECU; The test report is pushed to the user through interface display or voice broadcast.

8. A vehicle automated testing system, characterized in that: include: A test case download module is used to download pre-configured test cases when receiving automated test instructions; The test case includes a test object and a test target; A control message generation module, configured to generate a control message according to the test object and the test target; A signal transmission link tracking module, configured to track the signal transmission link of the control message after transmitting the control message to the vehicle's central control screen via an interface trigger or voice trigger; wherein the signal transmission link is a link formed by the central control screen, the domain controller of the test object, and the motor of the test object; The fault location module is used to locate the interruption position when tracing the interruption of the signal transmission link, so as to determine the ECU corresponding to the interruption position as the faulty ECU.

9. A vehicle, characterized in that: include: processor; as well as A memory having executable codes stored thereon, which, when executed by the processor, causes the processor to execute the method according to any one of claims 1 to 7. 10 . A computer-readable storage medium having executable codes stored thereon, which, when executed by a processor of a vehicle, causes the processor to perform the method according to claim 1 .

Images