Vehicle-mounted controller test method, device and system and storage medium

Abstract

The invention provides a test method, device and system of a vehicle-mounted controller and a storage medium. The method comprises the following steps: step S10, analyzing an imported test data configuration table for a to-be-tested vehicle-mounted controller, and extracting test case parameters and a communication protocol type of the test; step S11, based on the analysis result, automatically identifying the accessed to-be-tested vehicle-mounted controller, and establishing a mapping relation between the to-be-tested vehicle-mounted controller and a software channel; step S12, generating a test interface according to the display type field in the configuration table, wherein the test interface comprises a test item name, a traffic light state indication and a text block display area; step S13, creating a test thread, a data analysis thread and a result return thread, and sending a test message according to a preset protocol; and step S14, receiving and analyzing the response message, and generating a test result in combination with a threshold judgment rule in the configuration table. According to the invention, the DV / EOL test efficiency, versatility and reusability of the vehicle-mounted controller can be improved, and the cost can be reduced at the same time.

Description

Technical Field

[0001] This invention relates to the fields of design verification (DV) and end-of-life (EOL) testing technology for vehicle controllers, and in particular to a testing method, apparatus, system, and storage medium for vehicle controllers. Background Technology

[0002] Design verification (DV) and end-of-life (EOL) testing of vehicle control systems are core components in the R&D and production of automotive parts. They are crucial for ensuring the functional reliability, integrity, and effectiveness of parts and are essential processes before parts are delivered to vehicle manufacturers. Since parts projects for different vehicle models all require these two critical tests, the need to optimize existing testing solutions is increasingly prominent.

[0003] Currently, the host computer systems for DV and EOL testing are generally developed using LabVIEW graphical programming. These systems send commands to the controller under test (DUT) via CAN card, ADB, and other on-board controllers, and receive the test results returned by the DUT. However, LabVIEW-based host computer systems have the following limitations:

[0004] First, the development cycle is long, inefficient, and has poor code reusability. Even for different vehicle models of the same product, separate LabVIEW host computer systems need to be maintained, resulting in a large amount of repetitive work when developing multiple projects in parallel.

[0005] Secondly, it is highly dependent on hardware. The system is heavily tied to specific brands and models of on-board controllers under test, requiring a separate hardware design for each project, which limits the flexibility and versatility of the solution.

[0006] Furthermore, there is redundant development of protocol code. In each new project, the UDS protocol-related code needs to be repeatedly developed, which increases development costs and reduces implementation efficiency.

[0007] In summary, existing testing solutions have room for improvement in terms of testing efficiency, development costs, system versatility, and scalability. Summary of the Invention

[0008] The technical problem to be solved by this application is to provide a testing method, device, system and storage medium for vehicle controllers, which can improve the efficiency, versatility and reusability of DV / EOL testing of vehicle controllers, while reducing costs.

[0009] To address the aforementioned technical problems, as one aspect of this application, a testing method for an on-board controller is provided, comprising the following steps:

[0010] Step S10: Parse the imported test data configuration table for the vehicle controller under test, and extract the test case parameters and communication protocol type for this test.

[0011] Step S11: Based on the parsing results, automatically identify the connected vehicle controller under test and establish a mapping relationship between the vehicle controller under test and the software channel;

[0012] Step S12: Generate a test interface based on the display type field in the configuration table. The test interface includes the test item name, traffic light status indicator, and text block display area.

[0013] Step S13: Create a test thread, a data parsing thread, and a result feedback thread, and send test messages according to the preset protocol;

[0014] Step S14: Receive and parse the response message, and generate test results by combining the threshold judgment rules in the configuration table.

[0015] This further includes the following steps:

[0016] Step S15: Bind the test results to the corresponding UI component of the test item, and record the test log and error information;

[0017] Step S16: After the test is completed, select the target software version from the cloud repository and perform automated burning process after verifying the burning media.

[0018] The test data configuration table mentioned in step S10 shall include at least the following fields:

[0019] Communication protocol types include: CAN, UDS, or custom protocols;

[0020] TX data packet information, including: frame number, period, and data length;

[0021] RX data parsing rules include: threshold range and data conversion formula;

[0022] The types of displays on the host computer include: traffic lights, text blocks, or numerical displays;

[0023] The activation status of each test item, including: enabled or disabled.

[0024] Step S11, which involves automatically identifying the connected vehicle controller based on the parsing results, further includes:

[0025] Scan the PC interface to detect the model and version of the vehicle controller under test;

[0026] Compare the driver library version with the official website driver version, and automatically install or update the driver.

[0027] Assign a unique DEVICE_ID to the vehicle controller under test and map the physical channel to the soft channel CHN_ID.

[0028] Step S16 further includes:

[0029] Filter the cloud version library list by project or vehicle model information;

[0030] Verify the hardware compatibility of the programming medium and programming method, wherein the programming medium is an Ethernet or serial port, and the programming method is OTA programming or serial port programming.

[0031] After the programming is completed, an automated retest process is triggered, and programming logs and test reports are generated and stored together.

[0032] Accordingly, as another aspect of the present invention, a testing device for an on-board controller is also provided, applied in a host computer platform, comprising:

[0033] The hardware abstraction module is used to uniformly encapsulate the driver and communication protocol of the vehicle controller under test and establish the mapping relationship between the vehicle controller under test and the software channel.

[0034] The communication protocol module is used to generate test cases based on the test data configuration table, and supports automated message sending and receiving of CAN / UDS protocol and custom protocol;

[0035] The view rendering module includes a platform view framework and a project-specific test view, which is used to dynamically generate the test interface layout based on the configuration table.

[0036] The configuration parsing module is used to parse the test configuration table and distribute parameters to the view rendering module and the scheduling management module;

[0037] The scheduling and management module is used to manage test threads, data parsing threads, and result feedback threads, and to control the test process and cycle.

[0038] The testing module is used to receive and parse response messages, and generate test results by combining them with the threshold judgment rules in the configuration table.

[0039] This further includes:

[0040] The burning module is used to support one-click software burning using a specified version number;

[0041] The logging module is used to record test logs, raw messages and error information, and generate test summaries and full reports.

[0042] The hardware abstraction module further includes:

[0043] The driver management unit is used to automatically detect the model and version of the vehicle controller under test, and supports online driver updates;

[0044] The channel mapping unit is used to uniquely identify the physical channel of the vehicle controller under test as a soft channel CHN_ID, which can be called by the test thread.

[0045] The communication protocol module implements protocol extension in the following ways:

[0046] Pre-configured CAN / UDS protocol standardized processing flow;

[0047] Define a mapping table for the custom protocol, which includes the sending command, the receiving data type, and the parsing rules;

[0048] The corresponding protocol processing logic is dynamically loaded based on the protocol type field in the configuration table.

[0049] The view rendering module employs a dual-view mechanism:

[0050] The platform view is used to provide the main framework of the host computer, function buttons, and common interface elements.

[0051] The project view is used to generate test item tabs based on the configuration table. It supports dragging and dropping multiple devices in parallel test views, with each tab bound to an independent test device and channel.

[0052] The interaction between the programming module and the cloud version server includes:

[0053] The version query interface is used to return a list of available software versions based on project / vehicle model parameters;

[0054] The programming verification mechanism is used to check the hardware connection status and compatibility of the programming medium.

[0055] The burning log association is used to bind burning operation records with test reports, supporting closed-loop traceability of issues.

[0056] Accordingly, as another aspect of the present invention, a testing system for an on-board controller is also provided, comprising:

[0057] A test bench is used to set up a test environment for the vehicle controller under test (DUT), which includes the DUT and is used to receive test commands from the host computer platform and return test results.

[0058] The host computer platform is equipped with the aforementioned testing device for the vehicle controller, which is used to perform DV / EOL testing on the vehicle controller under test.

[0059] The cloud server communicates with the burning module of the host computer platform to provide software version information to the host computer platform, so as to realize the one-click burning function of the host computer platform.

[0060] As another aspect of the present invention, a computer-readable storage medium is also provided, storing a computer program that, when executed by a processor, implements the steps of the method described above.

[0061] Implementing this embodiment has the following beneficial effects:

[0062] This invention provides a testing method, apparatus, system, and storage medium for an on-board controller. The host computer platform used for testing adopts a layered and configurable core concept, designing system functional modules such as a hardware abstraction module, communication protocol module, view rendering module, configuration parsing module, scheduling management module, testing module, programming module, and logging module. By abstracting and isolating all hardware involved in the DV / EOL process, and abstracting and encapsulating the common characteristics and protocols of the software layer of each project, a unified platform-based control logic is achieved. This design significantly improves code reusability and maintainability, effectively reduces redundant development and management costs, thereby reducing overall development investment.

[0063] In this embodiment of the invention, the automatic generation of test cases and the host computer interface is achieved through the combination of automation technology and configuration files. Specifically, the configuration files allow for the flexible definition and modification of UI styles, layouts, and test data for different vehicle models, fulfilling customized requirements without altering the core control logic. This approach avoids repetitive development work, reduces the risk of human error, simplifies the development and maintenance process, and significantly improves the development efficiency of the host computer system.

[0064] In this embodiment of the invention, the testing device integrates automated programming functionality and interfaces with a cloud-based software version server. This integration significantly reduces the time required for switching between software versions and testing processes, not only optimizing testing efficiency but also shortening the closed-loop cycle from problem discovery to resolution, providing strong support for product development and iteration. Attached Figure Description

[0065] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, obtaining other drawings based on these drawings without creative effort still falls within the scope of this application.

[0066] Figure 1 A schematic diagram of the structure of an embodiment of a test system for an on-board controller provided by the present invention;

[0067] Figure 2 A schematic diagram of the structure of an embodiment of a testing device for an on-board controller provided by the present invention;

[0068] Figure 3 A schematic diagram of the implementation platform architecture of an example of the testing device for the vehicle controller provided by the present invention;

[0069] Figure 4 for Figure 2 A schematic diagram of the hardware abstraction module in the diagram;

[0070] Figure 5 A schematic diagram of the protocol definition mapping table involved in the device provided by the present invention;

[0071] Figure 6 This is a schematic diagram of the test interface involved in the device provided by the present invention;

[0072] Figure 7 This is a schematic diagram of the main flow of an embodiment of a testing method for an on-board controller provided by the present invention. Detailed Implementation

[0073] To make the objectives, technical solutions, and advantages of this application clearer, the application will be described in further detail below with reference to the accompanying drawings.

[0074] like Figure 1 The diagram shows a schematic representation of an embodiment of a testing system for an in-vehicle controller provided by the present invention. In this embodiment, the testing system for the in-vehicle controller includes at least:

[0075] A test bench is used to set up a test environment for the vehicle controller under test (DUT), which includes the DUT and is used to receive test commands from the host computer platform and return test results.

[0076] The host computer platform is equipped with a test device for the vehicle controller, which is used to perform DV / EOL testing on the vehicle controller under test.

[0077] The cloud server communicates with the burning module of the host computer platform to provide software version information to the host computer platform, so as to realize the one-click burning function of the host computer platform.

[0078] The following text will combine Figures 2 to 6 The test device for the vehicle controller deployed in the host computer platform and the cloud server are described in detail.

[0079] like Figure 2 The diagram shown illustrates a structural schematic of one embodiment of a testing apparatus for an on-board controller provided by the present invention. (In conjunction with...) Figures 3 to 6 As shown, in this embodiment, the testing device 1 for the vehicle controller includes at least:

[0080] Hardware abstraction module 10 is used to uniformly encapsulate the driver and communication protocol of the vehicle controller under test and establish the mapping relationship between the vehicle controller under test and the software channel.

[0081] The communication protocol module 11 is used to generate test cases based on the test data configuration table, and supports automated message sending and receiving of CAN / UDS protocol and custom protocol;

[0082] View rendering module 2 includes a platform view framework and a project-specific test view, which is used to dynamically generate the test interface layout based on the configuration table.

[0083] The configuration parsing module 13 is used to parse the test configuration table and distribute parameters to the view rendering module and the scheduling management module.

[0084] The scheduling management module 14 is used to manage test threads, data parsing threads, and result feedback threads, and to control the test process and cycle.

[0085] Test module 15 is used to receive and parse response messages, and generate test results by combining them with the threshold judgment rules in the configuration table.

[0086] The programming module 16 is used to support one-click software programming using a specified version number;

[0087] Log module 17 is used to record test logs, raw messages and error information, and generate test briefings and full reports.

[0088] The hardware abstraction module 10 further includes:

[0089] The drive management unit 100 is used to automatically detect the model and version of the vehicle controller under test and supports online driver updates.

[0090] The channel mapping unit 101 is used to uniquely identify the physical channel of the vehicle controller under test as a soft channel CHN_ID, which can be called by the test thread.

[0091] The communication protocol module 11 implements protocol extension in the following ways:

[0092] Pre-configured CAN / UDS protocol standardized processing flow;

[0093] Define a mapping table for the custom protocol, which includes the sending command, the receiving data type, and the parsing rules;

[0094] The corresponding protocol processing logic is dynamically loaded based on the protocol type field in the configuration table.

[0095] The view rendering module 12 employs a dual-view mechanism:

[0096] The platform view is used to provide the main framework of the host computer, function buttons, and common interface elements.

[0097] The project view is used to generate test item tabs based on the configuration table. It supports dragging and dropping multiple devices in parallel test views, with each tab bound to an independent test device and channel.

[0098] The interaction between the programming module 16 and the cloud version server includes:

[0099] The version query interface is used to return a list of available software versions based on project / vehicle model parameters;

[0100] The programming verification mechanism is used to check the hardware connection status and compatibility of the programming medium.

[0101] The burning log association is used to bind burning operation records with test reports, supporting closed-loop traceability of issues.

[0102] More specifically, in combination Figures 3 to 6 As shown, in the practical example, the vehicle controller test device 1 in the host computer platform is developed using Python. It adopts a layered and configurable core approach, utilizing the aforementioned hardware abstraction module 10, communication protocol module 11, view rendering module 12, configuration parsing module 13, scheduling management module 14, testing module 15, burning module 16, and log module 17. This abstracts and isolates all relevant hardware used in the DV / EOL process, extracts common characteristics and protocols from the software of each project, and achieves unified platform-based control logic. This improves code reusability and maintainability, reduces redundant development and management work, and lowers development costs. Simultaneously, using configuration files to define and modify the UI style and layout of different vehicle models, as well as control different test data between different projects, allows for flexible customization, avoids modifying the core control logic, and simplifies the development and maintenance process. It is understandable that other languages ​​could be used in other examples.

[0103] More specifically, in this invention, Figure 2 The functions of each module involved are as follows:

[0104] The hardware abstraction module 10 is used to uniformly integrate and encapsulate the hardware and corresponding communication protocols used in various DV / EOL test scenarios, forming a component library consisting of hardware, drivers, communication protocols, and communication APIs. It also provides a visual configuration interface, allowing users to select the required vehicle controller under test (DUT) for different projects. The host computer automatically identifies the various hardware models, types, and versions connected to the PC, matches them to the component library, and extracts the necessary information, mainly including network ports, CAN cards, USB devices, serial ports, programmable power supplies, relays, etc. It compares the hardware driver versions in the driver library with the official driver website to automatically identify and install new drivers. After the hardware driver is loaded, it identifies the unique DEVICE_ID of the hardware and maps the hardware model to hardware characteristics, identifying the type of the DUT, the number of data channels, etc., and mapping the hardware channels to soft channels CHN_IDs. This facilitates specifying the device DEVICE_ID and the device soft channel CHN_ID for data communication when calling the API later.

[0105] The communication protocol module 11 is used to extract commonalities from various projects based on the characteristics of each product line for different vehicle models, forming a set of DV / EOL test data configuration tables for each product line. These tables include communication protocol type, transmit (TX) data message information, receive (RX) data message information, judgment threshold, data conversion formula, and host computer display type. This configuration table is imported into the host computer platform as a test case. The platform generates actual test cases and the host computer's UI display based on the configuration information. The host computer determines whether to display traffic lights or text blocks by judging the display type field in the configuration table. It automatically sends message data, automatically receives and parses messages, and judges whether the data is within the threshold range by using the communication protocol type, TX data information, RX data information, judgment threshold, and data conversion formula. The main communication protocols here are CAN and UDS. These two internationally standardized protocols are used to complete the standardized transmission and reception of data. For other USB, network, ADB, and custom proprietary protocols, the communication methods of this product line need to be encapsulated and defined. For example, a mapping table of sending commands, receiving data, and data types can be formed. Based on the mapping table, a communication protocol unique to the product line can be formed to achieve automated data transmission and reception.

[0106] Mapping table such as Figure 5 As shown, this is the protocol selection in the configuration file, which determines data transmission and reception. The communication protocol needs to be implemented in the host computer platform's protocol library. For example... Figure 6 The communication protocol used is CAN, so the CAN card driver, CAN communication protocol, and API have already been developed in advance.

[0107] The view rendering module 12 is broadly divided into two parts: the platform view and the project view. The platform view serves as the foundational framework for the entire host computer platform; all projects rely on this framework, much like the foundation of a house. It implements the main interface of the host computer, various function buttons, time display, log display, and interface refresh mechanism. The project view is a dedicated test view for each project, built upon the platform view. It is automatically generated by importing test data configuration tables. The generated UI view includes: 1. The number of tabs, supporting multiple views (one to n), enabling simultaneous testing of multiple Device Under Test (DUT) devices (i.e., multiple vehicle controllers under test) from a single host computer; 2. Test items and test results under each tab. Test cases are pre-configured in the configuration file, which can be enabled or disabled.

[0108] The host computer's interface (UI) is as follows: Figure 6 As shown, the UI layout includes a left-side page and a top-level toolbar. The bottom right area is the test page; this part can vary from project to project, with the main differences being in the test items, which can be generated based on a configuration file.

[0109] The configuration parsing module 13 is responsible for parsing the incoming test data configuration table, passing the parsed results to the view rendering module for UI generation, and passing them to the scheduling management module for functions such as test thread creation, data parsing thread creation, and data result feedback thread creation.

[0110] The scheduling management module 14 is responsible for managing the entire testing cycle and creating test thread creation, data parsing thread, and data result feedback thread.

[0111] Test module 15 is used to send data by calling the hardware communication API in the hardware abstraction module within the test thread, and to control the test process and cycle; the data parsing thread is responsible for receiving data returned by various hardware communication interfaces, judging the data type, converting and parsing the data, and obtaining test results; the data result feedback thread is responsible for obtaining the test results, judging the data, and sending it to the corresponding UI component for result display.

[0112] The programming module 15 integrates automated programming functionality into the DV / EOL host computer and connects to the cloud software version server. The host computer can query the project's version library in the cloud and program the software with a single click by specifying a particular version. The main steps include: opening the programming module on the host computer; selecting the project and vehicle model on the interface; automatically retrieving the cloud version library list; selecting the version number; choosing between Ethernet and serial ports as the programming medium; and selecting OTA or serial port programming as the programming method. The hardware abstraction module checks if the required hardware for the current programming method is ready. Once the check is OK, clicking "Start Programming" automatically completes the programming process. This significantly reduces the time spent switching between software versions and test projects, improving testing efficiency and shortening the problem closure cycle.

[0113] Log module 16 is responsible for recording log information for the entire system. Log types include test logs, raw CAN logs, and error logs. It supports automated log parsing to generate a test summary displayed on the UI. The summary includes: total test duration, test type, number of errors, time of occurrence, and error message, facilitating quick assessment of test results and post-testing actions by testers. Upon completion of the test, the test report module automatically generates a test report, uploads it to the cloud, and automatically notifies development, testing, and project management team members via email.

[0114] It is understood that, in this embodiment of the invention, in order to solve the problem of repetitive development of software communication protocols across multiple projects, for different models in each product line, commonalities among the projects are extracted based on the characteristics of the product line to form a set of test data configuration tables for DV / EOL testing of the product line. These tables include communication protocol type, TX data message information, RX data message information, judgment threshold, data conversion formula, and host computer display type. This configuration table is imported into the host computer platform as a test case. The platform generates actual test cases and the host computer's UI display based on the configuration information. The host computer determines whether to display traffic lights or text blocks by judging the display type field in the configuration table. It automatically sends message data, automatically receives and parses messages, and judges whether the data is within the threshold range by using the communication protocol type, TX data information, RX data information, judgment threshold, and data conversion formula. The main communication protocols here are CAN and UDS. These two internationally standardized protocols are used to complete the standardized transmission and reception of data. For other protocols such as USB, network, ADB, and custom proprietary protocols, it is necessary to encapsulate and define the communication methods of this product line. For example, a mapping table of sending commands, receiving data, and data types can be formed. Based on the mapping table, a communication protocol unique to the product line can be formed to achieve automated data transmission and reception.

[0115] like Figure 7 The diagram shows the main flow of an embodiment of a testing method for an in-vehicle controller provided by the present invention. In this embodiment, the method is based on... Figures 1 to 6 The test system for the described vehicle controller is used to achieve this.

[0116] First, the test bench is set up according to the DV / EOL solution requirements. The host computer platform is then opened, and the hardware module abstraction automatically identifies and detects the connected hardware modules. If the driver is not installed or has been updated, it can be downloaded and installed via a pop-up window on the host computer. Based on the actual wiring configuration, the required number of CAN devices and other devices are selected, and a 1-to-n test view is automatically generated. The TAB_IDs of the n test views are automatically mapped to the DEVICE_ID and CHN_ID of the CAN device's on-board controller, enabling each test device to communicate data through the specified device and channel.

[0117] During the testing process, the method provided by this invention includes at least the following steps:

[0118] Step S10: Parse the imported test data configuration table for the vehicle controller under test, and extract the test case parameters and communication protocol type for this test.

[0119] The test data configuration table mentioned in step S10 shall include at least the following fields:

[0120] Communication protocol types include: CAN, UDS, or custom protocols;

[0121] TX data packet information, including: frame number, period, and data length;

[0122] RX data parsing rules include: threshold range and data conversion formula;

[0123] The types of displays on the host computer include: traffic lights, text blocks, or numerical displays;

[0124] The activation status of each test item, including: enabled or disabled.

[0125] It is understood that, in this embodiment of the invention, the DV / EOL solutions of various product lines of the company are pre-organized into a "Test Data Configuration Table" adapted between various vehicle models of the product line. This table mainly identifies the vehicle controller under test, test communication protocol, test cycle and method, data judgment criteria, etc., forming test case configuration items, including test function points, activation status, communication protocol, display type, TX data, data range, conversion relationship, number of sent frames, number of sent times, sending cycle, data length, waiting time, etc. The test function points generate the test item name on the UI interface, the activation status determines whether to test the item, the communication protocol automatically identifies the hardware and API used, and the display type automatically generates the UI, mainly including traffic light and text block types. The TX data, number of sent frames, number of sent times, sending cycle, and data length determine and process the sent data packets, and the data range and conversion relationship determine what kind of data conversion and threshold judgment are performed on the received data. The configuration file for the test data configuration table is imported into the host computer interface. The configuration parsing module is responsible for parsing the configuration file and passing it to the view rendering module and the scheduling management module respectively.

[0126] Step S11: Based on the parsing results, automatically identify the connected vehicle controller under test and establish a mapping relationship between the vehicle controller under test and the software channel;

[0127] Step S11, which involves automatically identifying the connected vehicle controller based on the parsing results, further includes:

[0128] Scan the PC interface to detect the model and version of the vehicle controller under test;

[0129] Compare the driver library version with the official website driver version, and automatically install or update the driver.

[0130] Assign a unique DEVICE_ID to the vehicle controller under test and map the physical channel to the soft channel CHN_ID.

[0131] Understandable

[0132] Step S12: Generate a test interface based on the display type field in the configuration table. The test interface includes the test item name, traffic light status indicator, and text block display area.

[0133] Specifically, after receiving the incoming configuration data, the view rendering module generates the UI, that is, it generates test items and test results on the interface, and provides a binding interface for the UI view to update the test results.

[0134] Step S13: Create a test thread, a data parsing thread, and a result feedback thread, and send test messages according to the preset protocol;

[0135] Specifically, after receiving the incoming configuration data, the scheduling and management module creates a test thread, a data parsing thread, and a data result feedback thread. The test thread calls the hardware communication API in the hardware abstraction module to send data, controlling the test flow and cycle. The data parsing thread is responsible for receiving data returned from various hardware communication interfaces, judging the data type, converting and parsing the data, and obtaining the test results.

[0136] Step S14: Receive and parse the response message, and generate test results by combining the threshold judgment rules in the configuration table;

[0137] Specifically, the data result feedback thread of the scheduling management module is responsible for obtaining the test results, judging the data, and sending it to the corresponding UI component for result display. This time, it is necessary to correctly update the results on the test TAB of the corresponding test device through the mapping relationship of TAB_ID, DEVICE_ID, and CHN_ID.

[0138] Step S15: Bind the test results to the corresponding UI component of the test item, and record the test log and error information;

[0139] Specifically, the scheduling and management module calls the hardware communication API in the hardware abstraction module to send and receive data. The hardware abstraction module uses the communication API to specify TAB_ID, DEVICE_ID, and CHN_ID to identify the unique vehicle controller under test for communication and bind the corresponding test equipment. Different channels have independent data structures to store communication data.

[0140] During testing, the logging system automatically analyzes error logs and generates real-time test summaries synchronized on the test UI, allowing testers to quickly determine test results. In scenarios with multiple test tabs (one-to-many), if an error is found in a particular tab, its title bar is highlighted in red. After testing, a complete test report is generated and synchronized to the cloud.

[0141] Step S16: After the test is completed, select the target software version from the cloud repository and perform automated burning process after verifying the burning media.

[0142] Step S16 further includes:

[0143] Filter the cloud version library list by project or vehicle model information;

[0144] Verify the hardware compatibility of the programming medium and programming method, wherein the programming medium is an Ethernet or serial port, and the programming method is OTA programming or serial port programming.

[0145] After the programming is completed, an automated retest process is triggered, and programming logs and test reports are generated and stored together.

[0146] In a specific example, after the R&D personnel confirm and fix the problem, the testers can perform automated programming in the programming module on the host computer. The main steps include: opening the programming module on the host computer, selecting information such as the project and vehicle model on the interface, automatically obtaining the version library list from the cloud, selecting the version number provided by the software manager, choosing Ethernet or serial port as the programming medium, and OTA or serial port programming as the programming method, checking whether the hardware required for the current programming method is ready based on the hardware abstraction module, and clicking "Start Programming" after the check is OK to automatically complete the programming. After programming is completed, the problem is retested to complete the problem loop.

[0147] For more details, please refer to and combine with the above. Figures 1 to 6 The description of that will not be repeated here.

[0148] In another aspect, the present invention provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the following: Figures 1 to 6 The steps of the described method. For more details, please refer to and combine with the foregoing descriptions. Figures 1 to 6 The description of that will not be repeated here.

[0149] Implementing this embodiment has the following beneficial effects:

[0150] This invention provides a testing method, apparatus, system, and storage medium for an on-board controller. The host computer platform used for testing adopts a layered and configurable core concept, designing system functional modules such as a hardware abstraction module, communication protocol module, view rendering module, configuration parsing module, scheduling management module, testing module, programming module, and logging module. By abstracting and isolating all hardware involved in the DV / EOL process, and abstracting and encapsulating the common characteristics and protocols of the software layer of each project, a unified platform-based control logic is achieved. This design significantly improves code reusability and maintainability, effectively reduces redundant development and management costs, thereby reducing overall development investment.

[0151] In this embodiment of the invention, the automatic generation of test cases and the host computer interface is achieved through the combination of automation technology and configuration files. Specifically, the configuration files allow for the flexible definition and modification of UI styles, layouts, and test data for different vehicle models, fulfilling customized requirements without altering the core control logic. This approach avoids repetitive development work, reduces the risk of human error, simplifies the development and maintenance process, and significantly improves the development efficiency of the host computer system.

[0152] In this embodiment of the invention, the testing device integrates automated programming functionality and interfaces with a cloud-based software version server. This integration significantly reduces the time required for switching between software versions and testing processes, not only optimizing testing efficiency but also shortening the closed-loop cycle from problem discovery to resolution, providing strong support for product development and iteration.

[0153] Those skilled in the art will understand that embodiments of this application can be provided as methods, apparatus, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0154] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the steps in the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0155] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A test method for an on-board controller, characterized in that, Includes the following steps: Step S10: Parse the imported test data configuration table for the vehicle controller under test, and extract the test case parameters and communication protocol type for this test. Step S11: Based on the parsing results, automatically identify the connected vehicle controller under test and establish a mapping relationship between the vehicle controller under test and the software channel; Step S12: Generate a test interface based on the display type field in the configuration table. The test interface includes the test item name, traffic light status indicator, and text block display area. Step S13: Create a test thread, a data parsing thread, and a result feedback thread, and send test messages according to the preset protocol; Step S14: Receive and parse the response message, and generate test results by combining the threshold judgment rules in the configuration table.

2. The method according to claim 1, characterized in that, Further steps include: Step S15: Bind the test results to the corresponding UI component of the test item, and record the test log and error information; Step S16: After the test is completed, select the target software version from the cloud repository and perform automated burning process after verifying the burning media.

3. The method according to claim 2, characterized in that, The test data configuration table described in step S10 shall contain at least the following fields: Communication protocol types include: CAN, UDS, or custom protocols; TX data packet information, including: frame number, period, and data length; RX data parsing rules include: threshold range and data conversion formula; The types of displays on the host computer include: traffic lights, text blocks, or numerical displays; The activation status of each test item, including: enabled or disabled.

4. The method according to claim 3, characterized in that, Step S11, based on the parsing results, automatically identifies the connected vehicle controller under test, further including: Scan the PC interface to detect the model and version of the vehicle controller under test; Compare the driver library version with the official website driver version, and automatically install or update the driver. Assign a unique DEVICE_ID to the vehicle controller under test and map the physical channel to the soft channel CHN_ID.

5. The method according to claim 4, characterized in that, Step S16 further includes: Filter the cloud version library list by project or vehicle model information; Verify the hardware compatibility of the programming medium and programming method, wherein the programming medium is an Ethernet or serial port, and the programming method is OTA programming or serial port programming. After the programming is completed, an automated retest process is triggered, and programming logs and test reports are generated and stored together.

6. A testing device for an on-board controller, applied in a host computer platform, characterized in that, include: The hardware abstraction module is used to uniformly encapsulate the drivers and communication protocols of various vehicle controllers and establish the mapping relationship between the vehicle controller under test and the software channel. The communication protocol module is used to generate test cases based on the test data configuration table, and supports automated message sending and receiving of CAN / UDS protocol and custom protocol; The view rendering module includes a platform view framework and a project-specific test view, which is used to dynamically generate the test interface layout based on the configuration table. The configuration parsing module is used to parse the test configuration table and distribute parameters to the view rendering module and the scheduling management module; The scheduling and management module is used to manage test threads, data parsing threads, and result feedback threads, and to control the test process and cycle. The testing module is used to receive and parse response messages, and generate test results by combining them with the threshold judgment rules in the configuration table.

7. The apparatus according to claim 6, characterized in that, Further includes: The burning module is used to support one-click software burning using a specified version number; The logging module is used to record test logs, raw messages and error information, and generate test summaries and full reports.

8. The apparatus according to claim 7, characterized in that, The hardware abstraction module further includes: The driver management unit is used to automatically detect the model and version of the vehicle controller under test and supports online driver updates. The channel mapping unit is used to uniquely identify the physical channel of the vehicle controller under test as a soft channel CHN_ID, which can be called by the test thread.

9. The apparatus according to claim 8, characterized in that, The communication protocol module implements protocol extension in the following ways: Pre-configured CAN / UDS protocol standardized processing flow; Define a mapping table for the custom protocol, which includes the sending command, the receiving data type, and the parsing rules; The corresponding protocol processing logic is dynamically loaded based on the protocol type field in the configuration table.

10. The apparatus according to claim 9, characterized in that, The view rendering module adopts a dual-view mechanism: The platform view is used to provide the main framework of the host computer, function buttons, and common interface elements. The project view is used to generate test item tabs based on the configuration table. It supports dragging and dropping multiple devices in parallel test views, with each tab bound to an independent test device and channel.

11. The apparatus according to claim 10, characterized in that, The interaction between the programming module and the cloud version server includes: The version query interface is used to return a list of available software versions based on project / vehicle model parameters; The programming verification mechanism is used to check the hardware connection status and compatibility of the programming medium. The burning log association is used to bind burning operation records with test reports, supporting closed-loop traceability of issues.

12. A testing system for an on-board controller, characterized in that, include: The test bench is used to set up the test environment for the vehicle controller under test, receive test instructions from the host computer platform, and return test results. A host computer platform, which is equipped with a test device for the vehicle controller as described in any one of claims 6 to 11, for performing DV / EOL testing on the vehicle controller under test; The cloud server communicates with the burning module of the host computer platform to provide software version information to the host computer platform, so as to realize the one-click burning function of the host computer platform.

13. A computer-readable storage medium storing a computer program, characterized in that, When the program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 5.

Images