A method and related apparatus for testing complex drive functions of a vehicle controller

Abstract

This application relates to the field of chip testing technology, and more particularly to a method and related apparatus for testing complex drive functions of a vehicle controller. The method includes constructing a complex drive test code library; receiving parameter information of the controller chip under test and test function requirements information for the controller chip under test; generating a register interface declaration file conforming to embedded development standards and a standardized functional requirements file based on register addresses; calling the standardized test code for the controller chip under test based on the register interface declaration file and the standardized functional requirements file; and performing functional testing based on the called standardized test code for the controller chip under test. This application can achieve unified standardization of multiple test codes, improve the versatility of test codes, and efficiently perform functional testing on the controller chip under test.

Description

Technical Field

[0001] This application relates to the field of chip testing technology, and in particular to a method and related apparatus for testing complex drive functions of a vehicle controller. Background Technology

[0002] Functional testing is an indispensable and crucial step in the development of automotive controllers, playing a vital role in ensuring product functionality, operational reliability, and driving safety. As a core component of the vehicle's electrical architecture, the automotive controller directly impacts the operational status of powertrain, chassis, and safety systems, necessitating systematic functional testing to verify its performance under various operating conditions. In the development process, functional testing is a mandatory means of ensuring requirement traceability and design verifiability, enabling the identification of defects early in development and reducing later rectification costs and quality risks. Therefore, functional testing is fundamental to ensuring controller compliance, safety, and mass production feasibility, holding an irreplaceable position within the entire R&D system.

[0003] Functional test code, as the core of functional testing, directly determines whether functional tests can comprehensively cover the controller's operating conditions, thereby minimizing later quality risks. In the current AUTOSAR architecture, complex driver code development cannot be standardized, requiring embedded engineers to perform extensive hand-writing work. The development quality of complex driver functional test code largely depends on the embedded engineer's development experience, hardware and software knowledge, and understanding of the complex driver's operating conditions. Furthermore, if the driver chip is replaced during subsequent development, engineers need to redevelop the test code. Therefore, the current development of complex driver functional test code suffers from the following pain points: 1. The quality of test code depends heavily on the professional level of embedded engineers, and there are no unified standards. 2. Complex driver chips with the same function need to be redeveloped due to differences in communication protocols, register addresses, or working mechanisms, resulting in low universality of test code; 3. Complex driver test code needs to be written by hand, which is inefficient and has a high error rate. Summary of the Invention

[0004] To address the aforementioned problems, this application provides a method and related apparatus for testing complex driving functions of a vehicle controller, which can solve at least one of the problems mentioned above.

[0005] According to one aspect of the embodiments of this application, a method for testing complex drive functions of a vehicle controller is proposed, applied to a functional testing system. The functional testing system includes a protocol layer for classifying and organizing communication protocols, a specification layer for establishing test code development specifications, a functional layer for generating callable functions according to the test function requirements of the controller chip, and an architecture layer for establishing the overall calling logic of the test code. The method includes: A complex driver test code library is constructed, which stores multiple standard test codes. Each standard test code is generated through the protocol layer, the specification layer, the functional layer, and the architecture layer. Receive parameter information of the controller chip under test and test function requirements information for the controller chip under test. The parameter information includes register address, electrical attributes and communication protocol. Generate a register interface declaration file conforming to embedded development standards based on the register address, and generate a standardized functional requirements file based on the communication protocol, the functional requirements information, and the parameter configuration corresponding to the electrical attributes. Based on the register interface declaration file and the standardized functional requirements file, the standardized test code for the controller chip under test is called from the complex driver test code library; The controller chip under test is functionally tested according to the standard test code invoked for the controller chip under test.

[0006] The above scheme includes: Collect test code for various complex driver functions that have been developed in the past. Each of the test code for complex driver functions corresponds to a communication protocol and a calling function. Construct the overall calling logic architecture for each of the complex driver function test codes, and encapsulate the communication protocol and corresponding calling function of each of the complex driver function test codes to obtain the calling logic module under the corresponding overall calling logic framework; The calling logic module is subject to normative constraints, which determine the structure design, variable naming, function call format, and comment specifications for the calling logic module. Based on the structure design, variable naming, function call format, and comment specifications for each of the aforementioned call logic modules, generate standardized test code that corresponds one-to-one with the test code for each of the aforementioned complex driver functions. The complex driver test code library is constructed based on the standardized test codes that correspond one-to-one with the test codes for each of the complex driver functions.

[0007] In the above scheme, the standardized test code is generated in the following way: For each complex driver function test code, the communication protocol used by the complex driver function test code is determined through the protocol layer, the test function requirements of the complex driver function test code are determined through the function layer, the overall calling logic framework of the complex driver function test code is determined through the architecture layer, and the format of the communication protocol, the test function requirements and the overall calling logic framework is standardized through the specification layer. The standardized test code is generated based on the communication protocol, the test function requirements, and the overall call logic framework after the format is standardized.

[0008] In the above scheme, the step of calling the standardized test code for the controller chip under test from the complex driver test code library according to the register interface declaration file and the standardized functional requirements file includes: Extract the communication protocol, functional requirements information, and parameter configuration of the controller chip under test from the standardized functional requirements document; The register address of the controller chip under test is extracted from the register interface declaration file, and the standard test code for the controller chip under test is called from the driver test code library according to the register address, the parameter configuration, the communication protocol of the controller chip under test, and the functional requirement information.

[0009] In the above scheme, the step of calling the standard test code for the controller chip under test from the driver test code library based on the register address, the parameter configuration, the communication protocol of the controller chip under test, and the functional requirements information includes: The overall calling logic framework for the controller chip under test is determined based on the register address and the parameter configuration. Within the overall calling logic framework for the controller chip under test, the standardized test code for the controller chip under test is determined based on the communication protocol and functional requirements of the controller chip under test.

[0010] In the above scheme, the method further includes: If it is not possible to call the specification test code for the controller chip under test in the complex driver test code library, then the target specification test code for the controller chip under test is generated through the protocol layer, the specification layer, the functional layer and the architecture layer.

[0011] In the above scheme, generating target specification test code for the controller chip under test through the protocol layer, the specification layer, the functional layer, and the architecture layer includes: The protocol layer determines the communication protocol used by the controller chip under test, the functional layer determines the functional requirements information for the controller chip under test, and the architecture layer determines the overall calling logic framework for the target specification test code. The calling function is determined based on the functional requirements information for the controller chip under test; The specification layer standardizes the format of the communication protocol used by the controller chip under test, the calling functions, and the overall calling logic framework of the target specification test code. Based on the standardized format, the communication protocol used by the controller chip under test, the calling function, and the overall calling logic framework for the target specification test code are used to generate the target specification test code for the controller chip under test.

[0012] According to one aspect of the embodiments of this application, a complex drive function testing device for a vehicle controller is proposed, applied to a functional testing system. The functional testing system includes a protocol layer for classifying and organizing communication protocols, a specification layer for establishing test code development specifications, a functional layer for generating callable functions according to the test function requirements of the controller chip, and an architecture layer for establishing the overall calling logic of the test code. The device includes: A building unit is used to build a complex driver test code library, which stores multiple standard test codes. Each standard test code is generated through the protocol layer, the specification layer, the functional layer, and the architecture layer. The receiving unit is used to receive parameter information of the controller chip under test and test function requirement information for the controller chip under test. The parameter information includes register address, electrical attributes and communication protocol. The generation unit is used to generate a register interface declaration file that conforms to the embedded development standard based on the register address, and to generate a standardized functional requirement file based on the communication protocol, the functional requirement information, and the parameter configuration corresponding to the electrical attributes. The calling unit is used to call the standard test code for the controller chip under test from the complex driver test code library according to the register interface declaration file and the standardized functional requirements file; The test unit is used to perform functional tests on the controller chip under test according to the called standard test code for the controller chip under test. According to one aspect of the embodiments of this application, an electronic device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the vehicle controller complex drive function test method as described above.

[0013] According to one aspect of the embodiments of this application, a computer program product is provided, the computer program product including a computer program, the computer program being read and executed by a processor of an electronic device, causing the electronic device to perform the vehicle controller complex drive function test method as described above.

[0014] The beneficial effects of this application are as follows: This application generates multiple standardized test codes by classifying and organizing communication protocols into a protocol layer, establishing test code development specifications into a specification layer, generating callable functions based on the test function requirements of the controller chip into a functional layer, and establishing an architecture layer for the overall calling logic of the test code into an architecture layer. This constructs a complex driver test code library that includes multiple standardized test codes, thereby achieving a unified specification for multiple test codes and improving the versatility of the test codes.

[0015] During the functional testing of the controller chip under test, a register interface declaration file conforming to embedded development standards is generated using register addresses. A standardized functional requirement file is also generated based on the communication protocol, functional requirements information, and parameter configurations corresponding to the electrical attributes. The standardized test code for the controller chip under test is then called from the complex driver test code library based on the register interface declaration file and the standardized functional requirement file. This method of calling the standardized test code for functional testing of the controller chip under test is highly efficient and enables efficient functional testing of the controller chip under test. Attached Figure Description

[0016] Figure 1 This is a system architecture diagram of the vehicle controller complex drive function testing method provided in the embodiments of this application; Figure 2 A flowchart illustrating the complex drive function testing method for a vehicle controller provided in this application embodiment; Figure 3 An architecture diagram of the functional testing system provided in the embodiments of this application; Figure 4 A logical schematic diagram of the vehicle controller complex drive function test method provided in the embodiments of this application; Figure 5 A block diagram of a vehicle controller complex drive function testing device provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of a terminal provided in an embodiment of this application; Figure 7 This is a schematic diagram of the structure of a server provided in an embodiment of this application. Detailed Implementation

[0017] To enable those skilled in the art to better understand the solutions of this application, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0018] It should be noted that while some processes described in the specification, claims, and accompanying drawings include multiple steps appearing in a specific order, it should be clearly understood that these steps may not be performed in the order they appear herein, or may be performed in parallel. The step numbers are merely used to distinguish different steps and do not themselves represent any execution order. Furthermore, descriptions such as "first," "second," or "objective" in this document are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. "Multiple" in this document refers to at least two.

[0019] It is worth noting that in the specific embodiments of this application, test code, callable functions, and other related data are involved. When the above embodiments of this application are applied to specific products or technologies, permission or consent from the target object is required, and the collection, use, and processing of related data must comply with relevant laws, regulations, and standards. For example, when an embodiment of this application needs to obtain test code, callable functions, and other related data, separate permission or consent from the target object can be obtained through pop-ups or redirection to a confirmation page. After obtaining the target object's separate permission or consent, the test code, callable functions, and other related data used to enable the embodiments of this application to operate normally can then be obtained.

[0020] Please see Figure 1 , Figure 1 This is a system architecture diagram of the vehicle controller complex drive function testing method provided in this application embodiment. It includes a terminal 140, an Internet connection 130, a gateway 120, a server 110, etc.

[0021] Terminal 140 can take various forms, including desktop computers, laptops, PDAs (personal digital assistants), mobile phones, vehicle terminals, and dedicated terminals. Furthermore, it can be a single device or a collection of multiple devices. For example, multiple desktop computers can be interconnected via a local area network, sharing a single monitor to work collaboratively, forming a single terminal 140. Terminal 140 can communicate with the Internet 130 via wired or wireless means to exchange data.

[0022] Server 110 refers to a computer system capable of providing certain services to terminal 140. Compared to ordinary terminal 140, server 110 has higher requirements in terms of stability, security, and performance. Server 110 can be a single high-performance computer in a network platform, a cluster of multiple high-performance computers, a portion of a single high-performance computer (e.g., a virtual machine), or a combination of portions of multiple high-performance computers (e.g., virtual machines). Server 110 can also communicate with the Internet 130 via wired or wireless means to exchange data.

[0023] Gateway 120, also known as an internetwork connector or protocol converter, is a computer system or device that acts as a translator, enabling network interconnection at the transport layer. It bridges the gap between two systems using different communication protocols, data formats, languages, or even completely different architectures. Gateways can also provide filtering and security functions. Messages sent from terminal 140 to server 110 are forwarded to the corresponding server 110 via gateway 120. Messages sent from server 110 to terminal 140 are also forwarded to the corresponding terminal 140 via gateway 120.

[0024] The following provides a detailed description of the specific implementation methods of the embodiments of this application: Please see Figure 2 , Figure 2 This is a flowchart illustrating the vehicle controller complex drive function testing method provided in this application embodiment. The vehicle controller complex drive function testing method can be implemented by server 110 and / or terminal 140. Figure 2 The test methods for complex drive functions of vehicle controllers shown include: Step 210: Construct a complex driver test code library, which stores multiple standard test codes. Each standard test code is generated through the protocol layer, the specification layer, the functional layer, and the architecture layer. Step 220: Receive parameter information of the controller chip under test and test function requirements information for the controller chip under test. The parameter information includes register address, electrical attributes and communication protocol. Step 230: Generate a register interface declaration file conforming to embedded development standards based on the register address, and generate a standardized functional requirements file based on the communication protocol, the functional requirements information, and the parameter configuration corresponding to the electrical attributes; Step 240: Call the standard test code for the controller chip under test from the complex driver test code library according to the register interface declaration file and the standardized functional requirements file; Step 250: Perform functional testing on the controller chip under test according to the called standard test code for the controller chip under test.

[0025] Specifically, such as Figure 3 As shown, Figure 3 This is a schematic diagram of the architecture of the functional testing system of this application. The complex driver test code library is constructed through a protocol layer for classifying and organizing communication protocols, a specification layer for establishing test code development specifications, a functional layer for generating callable functions according to the test function requirements of the controller chip, and an architecture layer for establishing the overall calling logic of the test code.

[0026] like Figure 4 As shown, Figure 4 The logic diagram generated for the test code of this application is shown. In this diagram, the parameter information of the controller chip under test is extracted and organized using an AI model. The user manual (PDF / Word format) of the driver chip (controller chip under test) is input to the AI ​​summarization and organization module through the API interface. Intelligent analysis: The AI ​​model automatically analyzes the user manual, identifies and extracts the chip's core information, including register addresses, electrical attributes, operating mechanisms, communication protocol types, interface definitions, etc. 3. Structured Output: The extracted unstructured information is transformed into standardized structured data and organized according to a standardized format. This provides accurate chip parameter data for the subsequent automatic file generation module, replacing the manual work of analyzing chip manuals and extracting key parameters. This avoids omissions and errors in manual analysis, improves the efficiency and accuracy of parameter extraction, and lays a precise data foundation for subsequent code generation.

[0027] This application proposes an intelligent development system for complex drive function test code of vehicle controllers. It is an intelligent development architecture (functional testing system) combining software and hardware, and its core consists of four main parts: a complex drive test code library, an AI summarization and organization module, an automatic file generation module, and an intelligent code generation module. The system is built on a computer terminal and supports commonly used embedded development systems such as Windows and Linux. Through modular architecture design, it achieves standardized and intelligent development of test code. The following is a related application... Figure 3 (The structure and usage of a complex driver test code library) Figure 4 (Workflow diagram of the intelligent development system for complex driver functional test code) details the specific structure, working principle and implementation logic of the functional test system of this application.

[0028] 3.1 Core Component 1: Complex Driver Test Code Library The complex-driven test code library is the foundational core of this system, providing standardized code templates, callable functions, and development specifications for intelligent test code generation. It comprises four layers: protocol layer, specification layer, functional layer, and architecture layer, and supports real-time updates and iterations. The specific construction and usage methods are as follows: 1. Basic Material Organization: Collect various complex drive function test codes that have been completed in the development of automotive controllers (complex drive function test codes that have been developed in the past), covering drive test codes corresponding to mainstream communication protocols such as SPI, I2C, UART, CAN, and LIN, and complete the classification and organization of the original code (complex drive function test codes that have been developed in the past); 2. Modular encapsulation: Modular encapsulate the reorganized historical developments, extract common functions and logic modules for different communication protocols and functional requirements, generate a standardized function library that can be directly called, and achieve code reusability design; 3. Development Standards Establishment: Based on the AUTOSAR architecture development requirements and automotive controller testing industry standards, a unified test code development standard is established through the standard layer, clarifying requirements for structure design, variable naming, function call format, commenting standards, etc., as the core content of the standard layer of the complex driver test code library; 4. Four-layer architecture construction: Based on the protocol layer (encapsulating the core code of communication protocols such as SPI / I2C / UART / CAN / LIN), constrained by the specification layer (unified development specifications), with the functional layer (functional logic code for various complex driving conditions) as the core, and the architecture layer (the overall code calling architecture) as the framework, a complete complex driver test code library is built. 5. Real-time updates and iterations: When embedded engineers input new communication protocols, functional requirements, or complete the development of new test code, the new content can be encapsulated into the corresponding level of the code library according to the specifications, realizing real-time updates of the code library and continuously enriching the coverage of the code library.

[0029] Beneficial effects achieved: By standardizing the construction and modularizing the code library, the problems of lack of unified standards and low code universality in existing development are solved. Standardized templates are provided for subsequent intelligent code generation, while the real-time update mechanism ensures the adaptability of the code library to new chips, new protocols, and new requirements.

[0030] 3.2 Core Component Two: AI Summarization and Organization Module The AI-powered data processing and organization module is the core of this system. Developed based on natural language processing and machine vision technologies, it incorporates a chip datasheet parsing model and connects to the computer terminal's file input port via an API interface. Its core function is to automatically parse unstructured information from chip datasheets and extract standardized structured data. The specific workflow is as follows: 1. Information Input: Embedded engineers input the official manual (PDF / Word format) of the driver chip into the AI ​​summarization and organization module via the API interface; 2. Intelligent Analysis: The AI ​​model automatically analyzes the chip datasheet, identifies and extracts the chip's core information, including register addresses, electrical attributes, operating mechanisms, communication protocol types, interface definitions, etc. 3. Structured Output: The extracted unstructured information is transformed into standardized structured data, which is then organized according to a preset format to provide accurate chip parameter data for the subsequent automatic file generation module.

[0031] Beneficial effects achieved: It replaces the work of manually analyzing chip manuals and extracting key parameters, avoids omissions and errors in manual analysis, improves the efficiency and accuracy of parameter extraction, and lays a precise data foundation for subsequent code generation.

[0032] 3.3 Core Component Three: Automatic Document Generation Module The automatic file generation module has a bidirectional data connection with the AI ​​summarization and organization module and the intelligent code generation module. It receives the chip structured parameters output by the AI ​​summarization and organization module, and also supports embedded engineers to manually supplement the functional requirements and communication protocol details of the functional test module. Its core function is to automatically generate standardized register interface declaration files (.h files) and functional requirement files (.xlsx files). The specific workflow is as follows: 1. Data Reception: Receives chip parameters such as register addresses, electrical attributes, and communication protocols output by the AI ​​summarization and organization module, and also receives information such as functional requirements (functional requirement information) and interface names manually input by embedded engineers for the functional test module. 2. Standardized document generation: Automatically generate register interface declaration files (.h files) that conform to the C language embedded development standard, as well as standardized functional requirements files (.xlsx files) that include communication protocols, functional requirements, interface names, and parameter configurations, in accordance with the specification layer requirements of the code library. 3. File Output: The generated standardized functional requirements file is output to the code intelligent generation module as the direct input file for generating test code.

[0033] Beneficial effects achieved: It replaces the work of manually writing interface declaration files and functional requirement files, realizes the standardization and automation of file generation, and avoids formatting and parameter errors caused by manual writing.

[0034] 3.4 Core Component Four: Intelligent Code Generation Module The intelligent code generation module is the core output of this system. It has a bidirectional data connection with the complex driver test code library and the automatic file generation module. Its core function is to automatically generate complex driver functional test specification code (standard test code) that conforms to development specifications by retrieving the corresponding modules and functions from the code library based on standardized interface declaration files and functional requirement files. The specific workflow is as follows: 1. File Reception: Receives the register interface declaration file (.h) and functional requirement file (.xlsx) output by the file automatic generation module. Code repository retrieval: Based on the communication protocol type and functional requirements in the functional requirements file, automatically retrieve the corresponding standardized modules, callable functions and code architecture (overall calling logic framework) from the protocol layer, functional layer and architecture layer of the complex driver test code repository. 2. Automatic code generation: Combining the chip parameters (register addresses) in the register interface declaration file, the called code modules are configured with parameters and logically concatenated to generate complete and directly callable complex driver function test specification code (specification test code) according to the requirements of the specification layer. 3. Code Output and Invocation: The generated standardized test code is output to the embedded development environment on the computer terminal. Embedded engineers can directly call the standardized test code to perform controller function tests, or make minor personalized modifications according to actual needs.

[0035] Beneficial effects achieved: It replaces the core work of manually writing test code, realizes the automated generation of test code, greatly improves development efficiency, and ensures code quality and readability because the code fully complies with standardized specifications.

[0036] 3.5 Overall System Workflow The overall workflow of this system follows the logic of "chip information input → AI intelligent analysis → standardized functional requirement document generation → code library retrieval → automatic generation of standardized test code". The specific steps are as follows: 1. Embedded engineers input the driver chip manual into the AI ​​summarization module via the API interface, while manually inputting supplementary information such as the functional requirements, communication protocols, and electrical properties of the functional test module; 2. The AI ​​summarization module intelligently analyzes the chip manual, summarizing and extracting core parameters such as register addresses, electrical attributes, and operating mechanisms; 3. The automatic file generation module automatically generates standardized register interface declaration files (.h) and functional requirement files (.xlsx) based on the chip parameters analyzed by AI and the functional requirements entered manually. 4. The code intelligent generation module receives the above standardized files and automatically retrieves the corresponding protocol modules, functional functions, and code architecture from the complex driver test code library; 5. The intelligent code generation module completes parameter configuration and logic concatenation, automatically generating complex driver function test specification code that conforms to development standards; 6. Embedded engineers can directly call the generated test code, or make minor personalized modifications according to actual working conditions, to complete the test code development.

[0037] Taking the development of complex driver function test code for an automotive controller's CAN bus as an example, this document details the specific implementation process of this system. This embodiment is based on a Linux embedded development system, and the chip involved is a certain automotive-grade CAN driver chip. Specific steps are as follows: Chip information input: The embedded engineer inputs the official PDF manual of the CAN driver chip into the AI ​​summarization module of this system through the API interface, and at the same time manually inputs the functional requirements: to realize the CAN bus transmit / receive, baud rate configuration, fault self-diagnosis, sleep wake-up functions, and the communication protocol is CAN 2.0B; AI Intelligent Analysis: The AI ​​summarization module analyzes the chip manual and extracts core parameters: CAN controller register address (0x40006400~0x400067FF), baud rate configuration range (10kbps~1Mbps), electrical attributes (3.3V power supply), working mechanism (normal / sleep / fault modes), and interface type (CAN_TX / CAN_RX). Standardized document generation: Based on the above parameters, the automatic document generation module automatically generates the CAN register interface declaration file (can_driver.h), defining register address macros, baud rate configuration functions, mode switching functions, etc.; at the same time, it generates the CAN functional requirements file (can_driver_requirement.xlsx), listing information such as communication protocol, functional requirements, interface name, and parameter configuration. Code library retrieval: The intelligent code generation module retrieves the core code of the CAN 2.0B communication protocol from the protocol layer of the complex driver test code library, retrieves the functional logic modules for sending / receiving, fault self-diagnosis, and sleep / wake-up from the functional layer, and retrieves the overall calling architecture of the CAN driver test code from the architecture layer; Test code generation: The intelligent code generation module combines the register parameters in the can_driver.h file to configure the parameters and concatenate the logic of the called code module. In accordance with the system's unified development specifications, it automatically generates complete test code for the complex CAN bus driver function (can_driver_test.c). The code includes initialization functions, sending functions, receiving functions, baud rate configuration functions, fault diagnosis functions, and sleep / wake-up functions. Moreover, the variable naming and structure design all conform to standardized specifications. Code Calling and Fine-tuning: Embedded engineers import the generated can_driver_test.c and can_driver.h files into the Keil MDK development environment and directly call the code to perform complex CAN bus driver function tests. For actual test conditions, only a few personalized modifications are made to the baud rate parameter (configured to 500kbps) to complete the test code development.

[0038] This application addresses the pain points of developing complex drive function test code for existing vehicle controllers by providing an intelligent and standardized development system (functional testing system) that precisely solves the following core problems: 1. To address the lack of unified standards in existing development models and the high dependence of code quality on the professional skills of embedded engineers, establish a standardized test code development system to achieve the standardization and normalization of code development; 2. To address the issue of unusable and low versatility of test code due to differences in hardware parameters and communication protocols among complex driver chips with the same function, this paper proposes to achieve modular encapsulation and flexible invocation of test code, thereby improving code reusability. 3. To solve the problems of low efficiency and high error rate of pure manual development, AI summarizes and organizes code and automatically generates code libraries, replacing a large amount of repetitive manual work, improving the efficiency of test code development and reducing the human error rate; 4. Solve the problem of needing to completely redevelop test code after driver chip replacement, and realize the rapid adaptation and generation of test code based on chip parameters, shortening the test code development cycle after chip iteration.

[0039] 2.2 Beneficial effects: This application establishes a complete intelligent development system for testing complex drive functions of vehicle controllers by constructing a standardized complex drive test code library and an AI-assisted intelligent code generation architecture. The direct and inevitable beneficial effects of its technical features are as follows: 1. Standardize test code development and improve code quality: Establish unified code development standards (structs, variable naming, function calls, etc.) and solidify the standard requirements through the code library to avoid non-standard problems in manual development from the source, greatly improve the readability, maintainability and logical correctness of test code, and ensure the effectiveness of functional testing; 2. Improve code versatility and reusability, and reduce R&D costs: Modularize and protocol-encapsulate the developed test code, extract the common development logic for different chips, realize cross-chip reuse of test code with the same function, avoid redundant development, significantly save embedded engineers' R&D time and energy, and reduce R&D resource investment; 3. Significantly improve development efficiency and reduce error rate: AI automatically summarizes chip manual information, generates standardized interface files and requirement files, and automatically generates test specification code in combination with the code library, replacing more than 80% of manual writing work and improving development efficiency by more than 50%; at the same time, it reduces errors in manual input and logic design, reduces code error rate by more than 60%, and significantly shortens the test code development and debugging cycle; 4. Enables rapid code adaptation after chip replacement, improving R&D iteration efficiency: When driver chips are replaced, only the manual information and functional requirements of the new chip need to be input, and the system can quickly generate adapted test code without the need for full redevelopment. This shortens the development cycle of test code after chip iteration by more than 80% and enhances adaptability. 5. Lowering the development threshold and reducing reliance on senior engineers: The system has solidified professional knowledge such as complex communication protocol parsing and register configuration. Junior engineers only need to input chip parameters and functional requirements according to the specifications to complete the development of high-quality test code, which alleviates the talent shortage of senior embedded engineers in car companies.

[0040] Please see Figure 5 , Figure 5 This is a schematic diagram of the structure of a vehicle controller complex drive function testing device provided in an embodiment of this application. The vehicle controller complex drive function testing device is applied to computer equipment, and may include: Construction unit 401 is used to construct a complex driver test code library, which stores multiple standard test codes, each of which is generated through the protocol layer, the specification layer, the functional layer, and the architecture layer. The receiving unit 402 is used to receive parameter information of the controller chip under test and test function requirement information for the controller chip under test. The parameter information includes register address, electrical attributes and communication protocol. The generation unit 403 is used to generate a register interface declaration file that conforms to the embedded development standard based on the register address, and to generate a standardized functional requirement file based on the communication protocol, the functional requirement information, and the parameter configuration corresponding to the electrical attributes. Calling unit 404 is used to call the standard test code for the controller chip under test from the complex driver test code library according to the register interface declaration file and the standardized functional requirements file; Test unit 405 is used to perform functional tests on the controller chip under test according to the called standard test code for the controller chip under test.

[0041] Reference Figure 6 , Figure 6 To implement the structural block diagram of a portion of the terminal 140 in this application embodiment, the terminal 140 includes: a radio frequency (RF) circuit 710, a memory 715, an input unit 730, a display unit 740, a sensor 750, an audio circuit 760, a wireless fidelity (WiFi) module 770, a processor 780, and a power supply 790, among other components. Those skilled in the art will understand that... Figure 6 The terminal 140 structure shown does not constitute a limitation on a mobile phone or computer, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0042] The RF circuit 710 can be used to receive and transmit signals during information transmission or calls. In particular, it receives downlink information from the base station and processes it with the processor 780; in addition, it transmits uplink data to the base station.

[0043] The memory 715 can be used to store software programs and modules. The processor 780 executes various functional applications of the terminal and complex drive function test processing of the vehicle controller by running the software programs and modules stored in the memory 715.

[0044] The input unit 730 can be used to receive input numeric or character information, and to generate key signal inputs related to the terminal's settings and function control. Specifically, the input unit 730 may include a touch panel 731 and other input devices 732.

[0045] The display unit 740 can be used to display input or provided information, as well as various menus of the terminal. The display unit 740 may include a display panel 741.

[0046] Audio circuitry 760, speaker 761, and microphone 762 provide an audio interface.

[0047] In this embodiment, the processor 780 included in the terminal 140 can execute the vehicle controller complex drive function test method of the previous embodiment.

[0048] The terminal 140 in this application embodiment includes, but is not limited to, mobile phones, computers, intelligent voice interaction devices, smart home appliances, vehicle terminals, and aircraft. This application embodiment can be applied to various scenarios, including but not limited to cloud technology, artificial intelligence, smart transportation, and assisted driving.

[0049] Figure 7This is a partial structural block diagram of a server 110 implementing an embodiment of this application. The server 110 can vary significantly due to different configurations or performance characteristics, and may include one or more central processing units (CPUs) 822 (e.g., one or more processors) and memory 832, and one or more storage media 830 (e.g., one or more mass storage devices) for storing application programs 842 or data 844. The memory 832 and storage media 830 can be temporary or persistent storage. The program stored in the storage media 830 may include one or more modules (not shown in the diagram), each module including a series of instruction operations on the server 110. Furthermore, the CPU 822 may be configured to communicate with the storage media 830 and execute the series of instruction operations in the storage media 830 on the server 110.

[0050] Server 110 may also include one or more power supplies 826, one or more wired or wireless network interfaces 850, one or more input / output interfaces 858, and / or one or more operating systems 841, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

[0051] The central processing unit 822 in server 110 can be used to execute the vehicle controller complex drive function test method of the present application embodiment.

[0052] This application also provides a computer-readable storage medium for storing program code for executing the vehicle controller complex drive function test method of the foregoing embodiments.

[0053] This application also provides a computer program product, which includes a computer program. A processor of a computer device reads and executes the computer program, causing the computer device to perform the aforementioned method for testing the complex drive functions of a vehicle controller.

[0054] Furthermore, the terms “comprising” and “including”, and any variations thereof, are intended to cover non-exclusive inclusion, such that a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units that are explicitly listed, but may include other steps or units that are not explicitly listed or that are inherent to such process, method, product, or apparatus.

[0055] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0056] It should be understood that in the description of the embodiments of this application, "multiple" means two or more, "greater than", "less than", "exceeding" etc. are understood to exclude the number itself, and "above", "below", "within" etc. are understood to include the number itself.

[0057] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.

[0058] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of the embodiments of this application, depending on actual needs.

[0059] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0060] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0061] It should also be understood that the various implementation methods provided in this application can be combined arbitrarily to achieve different technical effects.

[0062] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0063] The above is a detailed description of the embodiments of this application. However, this application is not limited to the above embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of this application. All such equivalent modifications or substitutions are included within the scope defined by the claims of this application.

Claims

1. A method for testing complex drive functions of a vehicle controller, characterized in that, The method is applied to a functional testing system, which includes a protocol layer for classifying and organizing communication protocols, a specification layer for establishing test code development standards, a functional layer for generating callable functions based on the test function requirements of the controller chip, and an architecture layer for establishing the overall calling logic of the test code. A complex driver test code library is constructed, which stores multiple standard test codes. Each standard test code is generated through the protocol layer, the specification layer, the functional layer, and the architecture layer. Receive parameter information of the controller chip under test and test function requirements information for the controller chip under test. The parameter information includes register address, electrical attributes and communication protocol. Generate a register interface declaration file conforming to embedded development standards based on the register address, and generate a standardized functional requirements file based on the communication protocol, the functional requirements information, and the parameter configuration corresponding to the electrical attributes. Based on the register interface declaration file and the standardized functional requirements file, the standardized test code for the controller chip under test is called from the complex driver test code library. The functional tests of the controller chip under test are performed according to the standard test code invoked for the controller chip under test.

2. The method for testing complex drive functions of a vehicle controller according to claim 1, characterized in that, The construction of the complex driver test code library includes: Collect test code for various complex driver functions that have been developed in the past. Each of the test code for complex driver functions corresponds to a communication protocol and a calling function. Construct the overall calling logic architecture for each of the complex driver function test codes, and encapsulate the communication protocol and corresponding calling function of each of the complex driver function test codes to obtain the calling logic module under the corresponding overall calling logic framework; The calling logic module is subject to normative constraints, which determine the structure design, variable naming, function call format, and comment specifications for the calling logic module. Based on the structure design, variable naming, function call format, and comment specifications for each of the aforementioned call logic modules, generate standardized test code that corresponds one-to-one with the test code for each of the aforementioned complex driver functions. The complex driver test code library is constructed based on the standardized test codes that correspond one-to-one with the test codes for each of the complex driver functions.

3. The method for testing complex drive functions of a vehicle controller according to claim 2, characterized in that, The standardized test code is generated in the following way: For each complex driver function test code, the communication protocol used by the complex driver function test code is determined through the protocol layer, the test function requirements of the complex driver function test code are determined through the function layer, the overall calling logic framework of the complex driver function test code is determined through the architecture layer, and the format of the communication protocol, the test function requirements and the overall calling logic framework is standardized through the specification layer. The standardized test code is generated based on the communication protocol, the test function requirements, and the overall call logic framework after the format is standardized.

4. The vehicle controller complex drive function test method according to claim 3, characterized in that, The step of calling the standardized test code for the controller chip under test from the complex driver test code library according to the register interface declaration file and the standardized functional requirements file includes: Extract the communication protocol, functional requirements information, and parameter configuration of the controller chip under test from the standardized functional requirements document; The register address of the controller chip under test is extracted from the register interface declaration file, and the standard test code for the controller chip under test is called from the driver test code library according to the register address, the parameter configuration, the communication protocol of the controller chip under test, and the functional requirement information.

5. The method for testing complex drive functions of a vehicle controller according to claim 4, characterized in that, The step of calling the standard test code for the controller chip under test from the driver test code library based on the register address, the parameter configuration, the communication protocol of the controller chip under test, and the functional requirements information includes: The overall calling logic framework for the controller chip under test is determined based on the register address and the parameter configuration. Within the overall calling logic framework for the controller chip under test, the standardized test code for the controller chip under test is determined based on the communication protocol and functional requirements of the controller chip under test.

6. The method for testing complex drive functions of a vehicle controller according to claim 5, characterized in that, The method further includes: If it is not possible to call the specification test code for the controller chip under test in the complex driver test code library, then the target specification test code for the controller chip under test is generated through the protocol layer, the specification layer, the functional layer and the architecture layer.

7. The method for testing complex drive functions of a vehicle controller according to claim 6, characterized in that, The process of generating target specification test code for the controller chip under test through the protocol layer, specification layer, functional layer, and architecture layer includes: The protocol layer determines the communication protocol used by the controller chip under test, the functional layer determines the functional requirements information for the controller chip under test, and the architecture layer determines the overall calling logic framework for the target specification test code. The calling function is determined based on the functional requirements information for the controller chip under test; The specification layer standardizes the format of the communication protocol used by the controller chip under test, the calling functions, and the overall calling logic framework of the target specification test code. Based on the standardized format, the communication protocol used by the controller chip under test, the calling function, and the overall calling logic framework for the target specification test code are used to generate the target specification test code for the controller chip under test.

8. A testing device for complex drive functions of a vehicle controller, characterized in that, An application is made in a functional testing system, which includes a protocol layer for classifying and organizing communication protocols, a specification layer for establishing test code development standards, a functional layer for generating callable functions based on the test functional requirements of the controller chip, and an architecture layer for establishing the overall calling logic of the test code. The device includes: A building unit is used to build a complex driver test code library, which stores multiple standard test codes. Each standard test code is generated through the protocol layer, the specification layer, the functional layer, and the architecture layer. The receiving unit is used to receive parameter information of the controller chip under test and test function requirement information for the controller chip under test. The parameter information includes register address, electrical attributes and communication protocol. The generation unit is used to generate a register interface declaration file conforming to the embedded development standard based on the register address, and to generate a standardized functional requirement file based on the communication protocol, the functional requirement information, and the parameter configuration corresponding to the electrical attributes. The calling unit is used to call the standard test code for the controller chip under test from the complex driver test code library according to the register interface declaration file and the standardized functional requirements file; The test unit is used to perform functional tests on the controller chip under test according to the called standard test code for the controller chip under test.

9. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the vehicle controller complex drive function test method according to any one of claims 1 to 7.

10. A computer program product, the computer program product comprising a computer program, characterized in that, The computer program is read and executed by the processor of the electronic device, causing the electronic device to perform the vehicle controller complex drive function test method according to any one of claims 1 to 7.

Images