Method, apparatus, device and storage medium for vehicle testing

Abstract

The application discloses a vehicle testing method, device, equipment and storage medium, and belongs to the technical field of automobiles. The method specifically comprises the following steps: obtaining an initialized lua script engine; creating a lua state machine and registering a unified interface based on the lua script engine; determining a lua script of a test task of a vehicle based on a preset script database and the lua script engine; performing processing on the lua script of the test task based on the unified interface and the lua state machine, so as to obtain a test execution result; and performing cleaning processing on the lua state machine in response to the determination that the lua script of the test task is executed based on the test execution result.

Description

Technical Field

[0001] This application relates to the field of automotive technology, specifically to vehicle inspection technology, vehicle testing technology and other technical fields, and particularly to a method, apparatus, equipment and storage medium for vehicle testing. Background Technology

[0002] Currently, in the testing and diagnostics of new energy commercial vehicle production lines, commonly used vehicle testing solutions include manual testing based on graphical interfaces, hard-coded testing processes, and automated testing based on scripts in different languages. However, these solutions suffer from problems such as complex script language integration, high learning costs, poor script reusability, insufficient execution context isolation, and poor security. Summary of the Invention

[0003] This application provides a method, apparatus, device, and storage medium for vehicle testing, which can solve the problems of poor script execution reliability and high testing costs in vehicle testing. The technical solution is as follows: Firstly, a method for testing a vehicle is provided, the method comprising: Get the initialized Lua script engine; Based on the aforementioned Lua scripting engine, a Lua state machine is created, and a unified interface is registered. Based on the preset script database and the Lua script engine, the Lua scripts for the vehicle's test tasks are determined. Based on the unified interface and the Lua state machine, the Lua script of the test task is executed to obtain the test execution result; In response to the determination that the Lua script for the test task has been completed based on the test execution result, the Lua state machine is cleaned up.

[0004] In one possible implementation, obtaining the initialized Lua script engine includes: Load Node.js modules; The Lua script engine is assigned values ​​based on the Node.js module. Based on the result of the assignment process, the initialized Lua script engine is obtained.

[0005] In one possible implementation, determining the Lua scripts for the vehicle's testing tasks based on a preset script database and the Lua script engine includes: Based on the preset script database and the Lua script engine, a protocol script table is obtained; Based on the vehicle's test task, determine the identification information of the Lua script corresponding to the test task; Based on the identification information and protocol script table of the Lua script, the Lua script for the vehicle's test task is determined.

[0006] In one possible implementation, the step of executing the Lua script of the test task based on the unified interface and the Lua state machine to obtain the test execution result includes: Based on the unified interface and the Lua state machine, asynchronous functions are used to execute the Lua script of the test task. The result of the execution process is detected to obtain test success information or test failure information; The test execution result is obtained based on the test success information or test failure information.

[0007] In one possible implementation, the step of cleaning up the Lua state machine in response to determining that the Lua script execution of the test task has been completed based on the test execution result includes: In response to the test execution result being a test success message, it is determined that the Lua script execution of the test task has been completed, and the Lua state machine is cleaned up; or, In response to the test execution result being a test failure message, it is determined that the Lua script of the test task has been executed, and the Lua state machine is cleaned up.

[0008] In one possible implementation, the unified interface includes a unified diagnostic service interface, a controller LAN interface, a log interface, and a tool interface.

[0009] Secondly, a vehicle testing apparatus is provided, the apparatus comprising: The retrieval unit is used to retrieve the initialized Lua script engine; A creation unit is used to create a Lua state machine and register a unified interface based on the Lua script engine; The determining unit is used to determine the Lua script for the vehicle's test task based on a preset script database and the Lua script engine. The obtaining unit is used to execute the Lua script of the test task based on the unified interface and the Lua state machine to obtain the test execution result; The cleanup unit is used to clean up the Lua state machine in response to the determination that the Lua script of the test task has been completed based on the test execution result.

[0010] Thirdly, a computer-readable storage medium is provided, wherein at least one instruction is stored therein, the at least one instruction being loaded and executed by a processor to implement the aspects and any possible implementations described above.

[0011] Fourthly, an electronic device is provided, comprising: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the methods described above and any possible implementations.

[0012] The beneficial effects of the technical solution provided in this application include at least the following: As can be seen from the above technical solution, the embodiments of this application can obtain an initialized Lua script engine, create a Lua state machine based on the Lua script engine, register a unified interface, determine the Lua script for the vehicle's test task based on a preset script database and the Lua script engine, and execute the Lua script for the test task based on the unified interface and the Lua state machine to obtain the test execution result. In response to determining that the Lua script for the test task has been completed based on the test execution result, the Lua state machine is cleaned up. Since test tasks can be executed based on the Lua script engine, the created Lua state machine, and the unified interface, the learning cost for testers is reduced, script reusability is improved, execution context is isolated, script errors do not affect the main program, memory leaks are avoided, thereby improving the reliability and stability of vehicle testing.

[0013] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this application, nor is it intended to limit the scope of this application. Other features of this application will become readily apparent from the following description. Attached Figure Description

[0014] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0015] Figure 1 This is a schematic flowchart of a vehicle testing method provided in one embodiment of this application; Figure 2This is a structural block diagram of a vehicle testing apparatus provided in another embodiment of this application; Figure 3 This is a block diagram of an electronic device used to implement the vehicle testing method of the embodiments of this application. Detailed Implementation

[0016] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of this application, including various details to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this application. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0017] Obviously, the described embodiments are only some, not all, of the embodiments in this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without inventive effort are within the scope of protection of this application.

[0018] Furthermore, the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0019] Please refer to Figure 1 This document illustrates a flowchart of a vehicle testing method according to an embodiment of this application. Specifically, the vehicle testing method may include: Step 101: Obtain the initialized Lua script engine.

[0020] Step 102: Based on the Lua script engine, create a Lua state machine and register a unified interface.

[0021] Step 103: Based on the preset script database and the Lua script engine, determine the Lua script for the vehicle's test task.

[0022] Step 104: Based on the unified interface and the Lua state machine, execute the Lua script of the test task to obtain the test execution result.

[0023] Step 105: In response to the determination that the Lua script of the test task has been completed based on the test execution result, the Lua state machine is cleaned up.

[0024] It should be noted that script management for this vehicle testing method can be implemented using a script service. The Electron main process of the Lua script engine's script service can include the Fengari Lua engine, the application programming interface registration mechanism, and execution context management.

[0025] It should be noted that the script service can also interact with the vehicle under test by calling underlying interfaces based on the underlying protocol service. The script service can also load scripts from the database service. The database service allows access to the protocol script table and enables dynamic script loading.

[0026] It should be noted that a unified interface can be a unified application programming interface (API).

[0027] In this way, by obtaining an initialized Lua script engine, creating a Lua state machine based on the Lua script engine, and registering a unified interface, the Lua script for the vehicle's test task is determined based on a preset script database and the Lua script engine. The Lua script for the test task is then executed based on the unified interface and the Lua state machine to obtain test execution results. In response to the determination that the Lua script for the test task has been completed based on the test execution results, the Lua state machine is cleaned up. Because test tasks can be executed based on the Lua script engine, the created Lua state machine, and the unified interface, the learning cost for testers is reduced, script reusability is improved, execution context is isolated, script errors do not affect the main program, and memory leaks are avoided, thereby improving the reliability and stability of vehicle testing.

[0028] Optionally, in one possible implementation of this embodiment, in step 101, firstly, a Node.js module may be loaded. Secondly, based on the Node.js module, the Lua script engine may be assigned values. Thirdly, based on the result of the assignment process, the initialized Lua script engine is obtained.

[0029] In one specific implementation of this approach, the Lua script engine can be initialized based on the script service, and then the initialized Lua script engine can be obtained.

[0030] For example, the code for initializing the Lua scripting engine can be as follows: / / Initialize the Lua engine initLuaEngine() { / / Loading the Fengari Lua engine const fengari = require('fengari'); const interop = require('fengari-interop'); this.lua = fengari.lua; this.lauxlib = fengari.lauxlib; this.lualib = fengari.lualib; this.interop = interop; this.luaAvailable = true; } Understandably, the Fengari library is used here to implement a Lua script interpreter in a Node.js environment. Fengari can be a pure JavaScript implementation of Lua 5.3, without requiring native modules. Data exchange between JavaScript and Lua is achieved through interop.

[0031] In this way, the Lua script engine can be initialized by assigning values ​​based on the loaded Node.js modules, thus ensuring the reliability of the initialized Lua script engine. Furthermore, Lua syntax is concise, has a low learning curve, and testers can quickly get started, improving script writing efficiency by 3 to 5 times compared to hard-coding.

[0032] Optionally, in one possible implementation of this embodiment, in step 103, firstly, a protocol script table can be obtained based on the preset script database and the Lua script engine. Secondly, the identification information of the Lua script corresponding to the vehicle's test task can be determined based on the vehicle's test task. Thirdly, the Lua script for the vehicle's test task can be determined based on the Lua script's identification information and the protocol script table.

[0033] In this implementation, the protocol script table can be a `protocol_script` table. Scripts can be stored in the protocol script table.

[0034] In one specific implementation of this approach, firstly, the vehicle type is determined based on the vehicle's testing task. Secondly, based on the vehicle type, the identifier information of the Lua script corresponding to the testing task is determined. Thirdly, the Lua script for the vehicle's testing task can be retrieved from the protocol script table based on the Lua script's identifier information.

[0035] In another specific implementation of this approach, firstly, based on the vehicle's test task, the vehicle's controller information is determined. Secondly, based on the vehicle's controller information, the identifier information of the Lua script corresponding to the test task is determined. Thirdly, the Lua script for the vehicle's test task can be retrieved from the protocol script table based on the Lua script's identifier information.

[0036] In this implementation, for example, the code for loading scripts from a preset script database can be as follows: async loadScriptFromDatabase(scriptId) { const query = ` SELECT script_content, script_name, version FROM protocol_script WHERE script_id = ? `; const script = await this.databaseService.get(query, [scriptId]); if (!script) { throw new Error(`Script does not exist: ${scriptId}`); } return script.script_content; } Understandably, this allows for script version management and dynamic loading.

[0037] In this implementation, the protocol script table structure can be exemplarily shown below: protocol_script table structure CREATE TABLE protocol_script ( script_id INTEGER PRIMARY KEY AUTOINCREMENT, script_name VARCHAR(100) NOT NULL, script_content TEXT NOT NULL, controller_name VARCHAR(50), vehicle_type VARCHAR(50), version INTEGER DEFAULT 1, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ); ```javascript / / Record execution results this.executionResults.set(`script_${Date.now()}`, { script: scriptContent.substring(0, 200), result: returnValue, duration: Date.now() - startTime, timestamp: Date.now(), success: true }); In this way, version control and unified management can be achieved by storing scripts in a database. It can support dynamic loading and updating of scripts without restarting the program, and different test sites can share the same set of scripts, thus ensuring script consistency.

[0038] It should be noted that the specific implementation process provided in this implementation method can be combined with various specific implementation processes provided in the foregoing implementation methods to implement the vehicle testing method of this embodiment. Detailed descriptions can be found in the relevant content of the foregoing implementation methods, and will not be repeated here.

[0039] Optionally, in one possible implementation of this embodiment, in step 104, firstly, based on the unified interface and the Lua state machine, the Lua script of the test task can be executed using asynchronous functions. Secondly, the result of the execution can be detected to obtain test success information or test failure information. Thirdly, the test execution result can be obtained based on the test success information or test failure information.

[0040] In this implementation, the Lua state machine can be a separate Lua script used to execute the corresponding test task.

[0041] In one specific implementation of this approach, firstly, the result of the execution process can be detected, and in response to determining successful execution based on the detection result, a return value is obtained. Secondly, the return value is used as test success information. Thirdly, the test execution result can be obtained based on the test success information.

[0042] In another specific implementation of this approach, firstly, the result of the execution process can be detected, and in response to determining execution failure based on the detection result, error information can be obtained. Secondly, the error information is used as test failure information. Thirdly, the test execution result can be obtained based on the test failure information.

[0043] In another specific implementation of this method, after obtaining the test execution result, the test execution result can be recorded and saved.

[0044] In this way, by recording the script execution status, error messages, and execution results in real time, it is possible to query the execution history and diagnose problems.

[0045] In this implementation, script execution can be exemplified as follows: log.info("Starting to execute the test script") -- Read controller version information local version = uds.read("VCU", "F190") log.info("VCU version: " .. version) -- Read fault codes local dtcs = uds.readDtc("VCU") log.info("Number of fault codes: " .. #dtcs) -- Send CAN frame can.send(0x18DA27FA, {0x10, 0x03}) -- Delay util.sleep(1000) -- Return results return { success = true, version = version, dtcCount = #dtcs } Understandably, the script here uses a unified API interface, which simplifies writing and supports asynchronous operations and error handling, and can return complex data structures.

[0046] In this way, scripts can be reused across different vehicle models and controllers through a unified API abstraction layer, improving script reusability and reducing maintenance costs by more than 60%.

[0047] Moreover, by creating an independent state machine for each test task, memory leaks can be avoided, execution contexts can be isolated, script errors will not affect the main program, system stability can be improved, and the crash rate can be reduced by more than 90%.

[0048] It should be noted that the specific implementation process provided in this implementation method can be combined with various specific implementation processes provided in the foregoing implementation methods to implement the vehicle testing method of this embodiment. Detailed descriptions can be found in the relevant content of the foregoing implementation methods, and will not be repeated here.

[0049] Optionally, in one possible implementation of this embodiment, in step 105, in response to the test execution result being a test success message, it is determined that the Lua script of the test task has been executed successfully, so as to clean up the Lua state machine. In response to the test execution result being a test failure message, it is determined that the Lua script of the test task has been executed successfully, so as to clean up the Lua state machine.

[0050] In a specific implementation of this approach, after obtaining the test execution result, it can be determined that the Lua script of the test task has been executed, and then the Lua state machine can be cleaned up.

[0051] In this implementation, the execution flow of the Lua script for the test task can be exemplarily shown below: / / Execute Lua script async executeScript(scriptContent, context = {}) { / / 1. Create an independent Lua state machine const L = this.lauxlib.luaL_newstate(); this.lualib.luaL_openlibs(L); try { / / 2. Register the API to the Lua environment this.registerLuaApis(L, context); / / 3. Execute the script const result = this.lauxlib.luaL_dostring( L, this.lua.to_luastring(scriptContent) ); / / 4. Check the execution results if (result !== this.lua.LUA_OK) { const errorMsg = this.lua.lua_tojsstring(L, -1); throw new Error(`Lua execution error: ${errorMsg}`); } / / 5. Get the return value const returnValue = this.getLuaReturnValue(L); return returnValue; finally { / / 6. Clean up the Lua state machine this.lua.lua_close(L); } } Understandably, a new Lua state machine can be created each time a test task is executed to achieve context isolation, and automatic cleanup and resource release are performed after execution. Error capture and return value extraction are supported during test task execution.

[0052] It should be noted that the specific implementation process provided in this implementation method can be combined with various specific implementation processes provided in the foregoing implementation methods to implement the vehicle testing method of this embodiment. Detailed descriptions can be found in the relevant content of the foregoing implementation methods, and will not be repeated here.

[0053] Optionally, in one possible implementation of this embodiment, the unified interface may include a unified diagnostic service interface, a controller area network interface, a log interface, and a tool interface.

[0054] In this implementation, the unified diagnostic service interface can be the UDS API. The controller LAN interface can be the CAN API. The logging interface can be the logging API. The tool interface can be the tool API. In one specific implementation of this approach, the Lua scripting engine's API is registered to obtain a unified diagnostic service interface, a controller LAN interface, a logging interface, and a tool interface. In this implementation, for example, / / Register Lua API registerLuaApis(L, context) { / / UDS API const udsApi = { send: async (controller, service, data) =>{ return await this.udsDiagnosticService.sendDiagnosticRequest( controller, service, data ); }, read: async (controller, did) =>{ return await this.udsDiagnosticService.readDataByIdentifier( controller, did ); }, write: async (controller, did, data) =>{ return await this.udsDiagnosticService.writeDataByIdentifier( controller, did, data ); }, clearDtc: async (controller) =>{ return await this.faultDiagnosticService.clearDtc(controller); }, readDtc: async (controller) =>{ return await this.faultDiagnosticService.readDtc(controller); } }; / / CAN API const canApi = { send: async (canId, data) =>{ return await this.canDataService.sendCanFrame(canId,data); } }; / / Log API const logApi = { info: (message) =>logger.info(`[Lua] ${message}`), error: (message) =>logger.error(`[Lua] ${message}`) }; / / Utility API const utilApi = { sleep: (ms) =>new Promise(resolve =>setTimeout(resolve, ms)) }; / / Register to the Lua global environment this.interop.push(L, udsApi); this.lua.lua_setglobal(L, this.lua.to_luastring('uds')); this.interop.push(L, canApi); this.lua.lua_setglobal(L, this.lua.to_luastring('can')); this.interop.push(L, logApi); this.lua.lua_setglobal(L, this.lua.to_luastring('log')); this.interop.push(L, utilApi); this.lua.lua_setglobal(L, this.lua.to_luastring('util')); Understandably, this allows JavaScript objects to be pushed onto the Lua stack via interop and registered as Lua global variables using `lua_setglobal`. It also bridges asynchronous functions to Lua and supports async / await.

[0055] In this way, a unified Lua API interface can be provided for different protocols such as UDS diagnostics and CAN communication through a unified API interface, such as uds.send, uds.read, and can.send, without needing to understand the details of the underlying protocols, which simplifies script writing. Moreover, based on the unified API abstraction layer, scripts can be reused across different vehicle models and different controllers.

[0056] It should be noted that the specific implementation process provided in this implementation method can be combined with various specific implementation processes provided in the foregoing implementation methods to implement the vehicle testing method of this embodiment. Detailed descriptions can be found in the relevant content of the foregoing implementation methods, and will not be repeated here.

[0057] Figure 2 A structural block diagram of a vehicle testing apparatus according to an embodiment of this application is shown, as follows: Figure 2 As shown. The vehicle testing apparatus 200 of this embodiment may include an acquisition unit 201, a creation unit 202, a determination unit 203, an acquisition unit 204, and a cleanup unit 205. The acquisition unit 201 is used to acquire an initialized Lua script engine; the creation unit 202 is used to create a Lua state machine based on the Lua script engine and register a unified interface; the determination unit 203 is used to determine the Lua script for the vehicle's test task based on a preset script database and the Lua script engine; the acquisition unit 204 is used to execute the Lua script for the test task based on the unified interface and the Lua state machine to obtain a test execution result; and the cleanup unit 205 is used to clean up the Lua state machine in response to the determination that the Lua script for the test task has been executed based on the test execution result.

[0058] Optionally, in one possible implementation of this embodiment, the acquisition unit 201 is used to load a Node.js module; assign values ​​to the Lua script engine based on the Node.js module; and acquire the initialized Lua script engine based on the result of the assignment process.

[0059] Optionally, in one possible implementation of this embodiment, the determining unit 203 is configured to obtain a protocol script table based on the preset script database and the Lua script engine; determine the identification information of the Lua script corresponding to the test task based on the vehicle's test task; and determine the Lua script of the vehicle's test task based on the identification information of the Lua script and the protocol script table.

[0060] Optionally, in one possible implementation of this embodiment, the obtaining unit 204 is used to execute the Lua script of the test task using an asynchronous function based on the unified interface and the Lua state machine; to detect the result of the execution process to obtain test success information or test failure information; and to obtain the test execution result based on the test success information or test failure information.

[0061] Optionally, in one possible implementation of this embodiment, the cleanup unit 205 is configured to, in response to the test execution result being a test success message, determine that the Lua script of the test task has been executed and clean up the Lua state machine; or, in response to the test execution result being a test failure message, determine that the Lua script of the test task has been executed and clean up the Lua state machine.

[0062] Optionally, in one possible implementation of this embodiment, the unified interface includes a unified diagnostic service interface, a controller area network interface, a log interface, and a tool interface.

[0063] In this embodiment, an initialized Lua script engine can be obtained by an acquisition unit. A creation unit then creates a Lua state machine and registers a unified interface based on the Lua script engine. A determination unit determines the Lua script for the vehicle's test tasks based on a preset script database and the Lua script engine. An acquisition unit executes the Lua script for the test tasks based on the unified interface and the Lua state machine to obtain test execution results. A cleanup unit, responding to the determination that the Lua script for the test tasks has been completed based on the test execution results, cleans up the Lua state machine. Because test tasks can be executed using the Lua script engine, the created Lua state machine, and the unified interface, the learning cost for testers is reduced, script reusability is improved, execution context is isolated, script errors do not affect the main program, and memory leaks are avoided, thereby improving the reliability and stability of vehicle testing.

[0064] The technical solution of this application involves the collection, storage, use, processing, transmission, provision, and disclosure of user personal information, such as user image and attribute data, which comply with relevant laws and regulations and do not violate public order and good morals.

[0065] According to embodiments of this application, this application also provides an electronic device, a readable storage medium, and a computer program product.

[0066] Figure 3 A schematic block diagram of an example electronic device 300 that can be used to implement embodiments of this application is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the application described and / or claimed herein.

[0067] like Figure 3 As shown, the electronic device 300 includes a computing unit 301, which can perform various appropriate actions and processes based on a computer program stored in a read-only memory (ROM) 302 or a computer program loaded from a storage unit 308 into a random access memory (RAM) 303. The RAM 303 may also store various programs and data required for the operation of the electronic device 300. The computing unit 301, ROM 302, and RAM 303 are interconnected via a bus 304. An input / output (I / O) interface 305 is also connected to the bus 304.

[0068] Multiple components in electronic device 300 are connected to I / O interface 305, including: input unit 306, such as keyboard, mouse, etc.; output unit 307, such as various types of displays, speakers, etc.; storage unit 308, such as disk, optical disk, etc.; and communication unit 309, such as network card, modem, wireless transceiver, etc. Communication unit 309 allows electronic device 300 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0069] The computing unit 301 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 301 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 301 performs the various methods and processes described above, such as a vehicle testing method. For example, in some embodiments, the vehicle testing method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 308. In some embodiments, part or all of the computer program may be loaded and / or installed on the electronic device 300 via ROM 302 and / or communication unit 309. When the computer program is loaded into RAM 303 and executed by the computing unit 301, one or more steps of the vehicle testing method described above may be performed. Alternatively, in other embodiments, the computing unit 301 may be configured to perform the vehicle testing method by any other suitable means (e.g., by means of firmware).

[0070] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0071] The program code used to implement the methods of this application may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the functions / operations specified in the flowcharts and / or block diagrams are implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0072] In the context of this application, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0073] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0074] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0075] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0076] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this application can be achieved, and this is not limited herein.

[0077] The specific embodiments described above do not constitute a limitation on the scope of protection of this application. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for testing a vehicle, characterized in that, The method includes: Get the initialized Lua script engine; Based on the aforementioned Lua scripting engine, a Lua state machine is created, and a unified interface is registered. Based on the preset script database and the Lua script engine, the Lua scripts for the vehicle's test tasks are determined. Based on the unified interface and the Lua state machine, the Lua script of the test task is executed to obtain the test execution result; In response to the determination that the Lua script for the test task has been completed based on the test execution result, the Lua state machine is cleaned up.

2. The method according to claim 1, characterized in that, The process of obtaining the initialized Lua script engine includes: Load Node.js modules; The Lua script engine is assigned values ​​based on the Node.js module. Based on the result of the assignment process, the initialized Lua script engine is obtained.

3. The method according to claim 1, characterized in that, The method for determining the Lua scripts for vehicle testing tasks based on a preset script database and the Lua script engine includes: Based on the preset script database and the Lua script engine, a protocol script table is obtained; Based on the vehicle's test task, determine the identification information of the Lua script corresponding to the test task; Based on the identification information and protocol script table of the Lua script, the Lua script for the vehicle's test task is determined.

4. The method according to claim 1, characterized in that, The execution of the Lua script for the test task based on the unified interface and the Lua state machine to obtain the test execution result includes: Based on the unified interface and the Lua state machine, asynchronous functions are used to execute the Lua script of the test task. The result of the execution process is detected to obtain test success information or test failure information; The test execution result is obtained based on the test success information or test failure information.

5. The method according to claim 1, characterized in that, The step of cleaning up the Lua state machine in response to determining that the Lua script for the test task has completed execution based on the test execution result includes: In response to the test execution result being a test success message, it is determined that the Lua script for the test task has completed execution, and the Lua state machine is cleaned up; or, In response to the test execution result being a test failure message, it is determined that the Lua script of the test task has been executed, and the Lua state machine is cleaned up.

6. The method according to claim 1, characterized in that, The unified interface includes a unified diagnostic service interface, a controller area network interface, a log interface, and a tool interface.

7. A device for vehicle testing, characterized in that, The device includes: The retrieval unit is used to retrieve the initialized Lua script engine; A creation unit is used to create a Lua state machine and register a unified interface based on the Lua script engine. The determining unit is used to determine the Lua script for the vehicle's test task based on a preset script database and the Lua script engine. The obtaining unit is used to execute the Lua script of the test task based on the unified interface and the Lua state machine to obtain the test execution result; The cleanup unit is used to clean up the Lua state machine in response to the determination that the Lua script of the test task has been completed based on the test execution result.

8. An electronic device, characterized in that, include: At least one processor; as well as A memory that is communicatively connected to the at least one processor; The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method according to any one of claims 1-6.

9. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-6.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method according to any one of claims 1-6.

Images