BMS Cross-Domain Functional Automated Testing Methods and Systems

Abstract

This application provides an automated testing method and system for cross-domain functions of a Battery Management System (BMS), belonging to the field of electronic testing technology for new energy vehicles. The method includes: driving a target application on a mobile terminal to execute preset user interface operations via image recognition; responding to the completion of the user interface operation, triggering bus simulation to monitor the target cross-domain signal corresponding to the user interface operation, and verifying the mapping relationship between the target cross-domain signals; wherein, the target cross-domain signals include Ethernet service signals and controller area network (CLAN) signals; when the mapping relationship verification is successful and the target cross-domain signal emitted by the battery management system is detected, performing interface assertion verification on the mobile terminal and the vehicle's central control screen via image recognition to obtain the verification result. This application integrates image recognition with bus simulation monitoring, realizing end-to-end closed-loop verification from real user operation to cross-domain signal links and multi-terminal interface feedback, significantly improving testing efficiency and problem localization accuracy.

Description

Technical Field

[0001] This application belongs to the field of electronic testing technology for new energy vehicles, specifically relating to an automated testing method and system for cross-domain functions of a BMS. Background Technology

[0002] With the intelligent development of new energy vehicles, remote vehicle control via mobile applications (APPs), such as scheduled charging and remote battery pack heating, has become a core function. This function involves complex cross-domain collaboration between the mobile APP (mobile domain), the Telematics Box (TBOX), the cloud (Vehicle Networking Platform), the central domain controller (cockpit domain / body domain), the Vehicle Control Unit (VCU, power domain), the On-Board Charger (OBC, power domain), and the Battery Management System (BMS, power domain). Signal transmission requires conversion and transmission through a process of "Ethernet service signal → Service to Signal (S2S) mapping → Controller Area Network (CAN) bus signal".

[0003] Currently, existing testing solutions have the following significant drawbacks, making it impossible to perform efficient and automated closed-loop verification of this complete link: First, testing tools and testing processes are disconnected. Current testing is divided into two independent parts: the first part is vehicle network and logic testing, which uses tools such as CAN open environment (CANoe) to simulate nodes, simulate bus communication (including CAN, Controller Area Network Flexible Data Rate, Ethernet, etc.), and perform protocol testing. These tools can simulate VCU, charging piles, and even Ethernet signals to verify the correctness of S2S mapping and BMS response behavior, but they cannot automatically simulate and verify user operations and interface feedback from mobile apps. The second part is user interface (UI) testing, which targets mobile apps or vehicle screens. This typically uses automated scripts based on element location or manual operation, resulting in low testing efficiency, high maintenance costs, and complete disconnect from the underlying bus signals. When interface display anomalies, testers struggle to quickly pinpoint the problem as originating from the app itself, network transmission, domain controller signal mapping, VCU logic, or BMS logic.

[0004] Secondly, existing technologies lack end-to-end automated closed-loop testing capabilities. While some system-level hardware-in-the-loop (HIL) testing solutions focus on multi-controller integration, their testing starting point is usually simply injecting signals directly into the bus, failing to cover the complete scenario starting from the actual user interaction entry point (i.e., mobile phone touch operation). For the end-to-end testing of "mobile phone click → signal cross-domain flow → hardware execution → dual-screen UI feedback," there is currently no publicly available solution that can achieve one-click automated testing and correlation assertions.

[0005] Furthermore, the test scenarios are not fully covered. For remote control scenarios involving Ethernet services and CAN signal mapping, traditional testing methods rely on multiple independent tools and manual data splicing, making the testing process cumbersome, inefficient, and unable to automatically verify the correctness and real-time performance of signal conversion at cross-domain gateways.

[0006] In summary, how to provide a method that can automatically drive and fully track the transmission and conversion process of commands in the vehicle-to-cloud network and the vehicle's internal bus, starting from the real user interaction entry point, and ultimately synchronously verify all relevant user interface status feedback, thereby achieving end-to-end automated testing and accurate problem localization, has become an urgent technical problem to be solved. Summary of the Invention

[0007] The purpose of this application is to provide a method and system for automated testing of cross-domain functions of BMS, in order to solve the problems of fragmented tools, inability to automatically link assertions and accurately locate problems in existing testing solutions, and to improve testing efficiency and problem location accuracy.

[0008] This application is achieved through the following technical solution: The first aspect of this application provides an automated testing method for cross-domain functions of a BMS based on image recognition and bus simulation, the automated testing method comprising: Image recognition drives the target application on the mobile terminal to perform preset user interface operations; In response to the completion of the user interface operation, a bus emulation is triggered to listen for the target cross-domain signal corresponding to the user interface operation and to verify the mapping relationship between the target cross-domain signals; wherein, the target cross-domain signal includes Ethernet service signals and controller area network signals; When the mapping relationship is verified and the expected target cross-domain signal issued by the battery management system is detected, interface assertion verification is performed on the mobile terminal and the vehicle central control screen through image recognition to obtain the assertion verification result.

[0009] Optionally, triggering bus emulation to listen for the target cross-domain signal corresponding to the user interface operation includes: Listen to the target controller LAN signals emitted by the central domain controller after being converted according to the signal-to-signal mapping rules; Listen to the high-voltage control command issued by the vehicle controller after receiving the target controller's local area network signal, as well as the charging gun connection command issued by the on-board charger. Listen for the final execution response signal from the battery management system.

[0010] Optionally, image recognition can be used to drive a target application on a mobile terminal to perform preset user interface operations, including: If the target application is launched by its package name, and launch fails, the system will switch to launching by clicking on the desktop icon image. After entering the target application, the function entry points are located sequentially according to priority through image recognition, control text search, or click at preset coordinates; After entering the configuration interface of the function entry, parameters can be set by at least one of the following methods: control sliding, coordinate positioning sliding, and direct text input; Identify the user interface feedback after the confirmation operation to verify that the settings have taken effect.

[0011] Optionally, when the preset user interface operation includes a scheduled task, the automated testing method further includes an intelligent waiting process, which includes: The status check is performed cyclically at fixed time intervals until the current time reaches the preset timer task execution time; During each status check, it is detected whether the target application on the mobile terminal is running in the foreground. If the target application is detected to be in the background, then the target application is restarted.

[0012] Optionally, when the preset user interface operation is a scheduled charging operation, interface assertion verification is performed on the mobile terminal and the vehicle central control screen through image recognition, including: When the controller area network signal confirming the closing of the high voltage issued by the battery management system is detected, image recognition is used in parallel to identify whether the preset charging status user interface elements appear on the screen of the mobile terminal and the vehicle central control screen respectively.

[0013] Optionally, before performing interface assertion verification, the following is also included: After the preset appointment time is reached, multiple rounds of cyclical checks are performed at fixed time intervals; In each round of inspection, evidence of charging activation is searched in parallel from both visual and textual dimensions. The visual evidence is a screenshot template that matches a preset charging status icon or animation, while the textual evidence is charging-related keywords scanned on the screen. If evidence of at least one dimension is found in any round of inspection, the charging is deemed to have been successfully activated.

[0014] Optionally, performing interface assertion verification on the mobile terminal and the vehicle central control screen via image recognition further includes: Key information representing the charging status is extracted from the mobile terminal and the vehicle central control screen respectively, and the extracted key information is compared for consistency. The key information includes at least one of the following: remaining time, battery percentage, charging type, and charging power. The consistency comparison is determined using a preset tolerance range.

[0015] Optionally, the bus emulation supports at least one network protocol among CAN, CAN FD, and SOME / IP, and the bus emulation is loaded with a database file for parsing bus messages or service signals that conform to the network protocol.

[0016] A second aspect of this application provides an automated testing system for cross-domain functions of a BMS based on image recognition and bus emulation, comprising: The image recognition unit is used to drive the target application on the mobile terminal to perform preset user interface operations, and to perform interface assertion verification on the mobile terminal and the vehicle central control screen. The bus emulation unit is used to monitor the target cross-domain signals corresponding to the user interface operation and verify the mapping relationship between the target cross-domain signals; the target cross-domain signals include Ethernet service signals and controller area network signals. The test scheduling platform is communicatively connected to the image recognition unit and the bus simulation unit, respectively. In response to an event where the image recognition unit completes the user interface operation, the test scheduling platform triggers the bus simulation unit to listen to the target cross-domain signal corresponding to the user interface operation and verify the mapping relationship between the target cross-domain signals. When the mapping relationship is verified and the bus simulation unit detects the expected target cross-domain signal issued by the battery management system, the platform triggers the image recognition unit to perform interface assertion verification on the mobile terminal and the vehicle central control screen to obtain the assertion verification result.

[0017] Optionally, the bus emulation unit is also used to perform automatic verification of the mapping relationship between the Ethernet service signal and the controller area network signal.

[0018] Compared with the prior art, the beneficial effects of this application are: Achieving end-to-end automated closed-loop verification: This application deeply integrates image recognition-driven UI operation with cross-domain signal monitoring of bus simulation through a test scheduling platform. Starting from the real mobile terminal user interaction entry point, it fully tracks the entire link of "UI operation → Ethernet service signal → mapping conversion → Controller Area Network signal → Battery Management System response → Dual-end UI feedback", achieving end-to-end automated closed-loop verification and filling the gap in existing technology.

[0019] Establish a cross-domain signal monitoring and multi-terminal UI synchronous assertion mechanism: When the expected target cross-domain signal (such as a confirmation of closed high voltage signal) issued by the battery management system is detected, this application simultaneously triggers interface assertion verification on the mobile terminal and the vehicle central control screen, realizing automated verification with millisecond-level correlation. It can directly determine whether the signal conversion and the interface display are consistent, which greatly improves the reliability of the test.

[0020] Precisely pinpointing the problem area: When a test fails, this application can quickly pinpoint whether the problem belongs to the cloud / TBOX stage, the signal mapping stage, the power domain controller stage, or the cockpit domain UI stage, avoiding the inefficiency of manually checking multiple system logs in the traditional approach. Attached Figure Description

[0021] The above and other objects, features, and advantages of this application will become more apparent from the more detailed description of the embodiments of this application in conjunction with the accompanying drawings. The accompanying drawings are used to provide a further understanding of the embodiments of this application and form part of the specification. They are used together with the embodiments of this application to explain this application and do not constitute a limitation thereof.

[0022] Figure 1 A flowchart illustrating an automated testing method for cross-domain functions of a BMS based on image recognition and bus simulation, provided for an embodiment of this application; Figure 2 A schematic diagram of the structure of a BMS cross-domain function automated test system based on image recognition and bus simulation provided in this application embodiment; Figure 3 A schematic diagram of the architecture of another automated test system for cross-domain functions of BMS based on image recognition and bus simulation provided for an embodiment of this application; Figure 4 A flowchart illustrating another automated testing method for cross-domain functions of a BMS based on image recognition and bus simulation, provided for an embodiment of this application; Figure 5 This is a flowchart of the Airtest test provided in an embodiment of this application; Figure 6 A flowchart illustrating the application startup, function navigation, and verification process in the Airtest test provided in this application embodiment; Figure 7 A flowchart of the scheduled charging settings in the Airtest test provided in this application embodiment; Figure 8 A flowchart of intelligent waiting and monitoring in Airtest testing provided in this application embodiment; Figure 9 A flowchart of the charging activation check in the Airtest test provided in this application embodiment; Figure 10 This is a flowchart illustrating the extraction and consistency comparison of data from both ends in the Airtest test provided in this application embodiment. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of this application more apparent, exemplary embodiments according to this application will be described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this application, and not all embodiments of this application. It should be understood that this application is not limited to the exemplary embodiments described herein. Based on the embodiments of this application described herein, all other embodiments obtained by those skilled in the art without inventive effort should fall within the protection scope of this application.

[0024] To address the shortcomings of existing testing solutions, such as fragmented tools, inability to automate assertions, and inaccurate problem localization, this application proposes a cross-domain functional automated testing method and system for BMS. This method starts from the real user interaction entry point (mobile APP), automatically drives and fully tracks the transmission and conversion process of commands in the vehicle-to-cloud network and the vehicle's internal bus, and ultimately synchronously verifies the status feedback of all relevant user interfaces, achieving end-to-end automated testing and accurate problem localization. The following is a further detailed description of this application with reference to the accompanying drawings.

[0025] To facilitate understanding of this application, a detailed description of an automated testing method for cross-domain functions of a BMS based on image recognition and bus simulation, as disclosed in the embodiments of this application, will be provided first. Figure 1 A flowchart illustrating an automated testing method for cross-domain functions of a BMS based on image recognition and bus simulation, provided in an embodiment of this application, is shown below. Figure 1 As shown, the automated testing method for cross-domain functions of BMS based on image recognition and bus simulation in this application includes at least the following steps S100 to S300.

[0026] Step S100: Drive the target application on the mobile terminal to perform preset user interface operations through image recognition.

[0027] Here, image recognition refers to the automatic location and matching of target images or text in the test screen interface using computer vision technology and preset screenshot templates or feature points. In this application, image recognition is used to drive the application on the mobile terminal to perform operations (such as clicking buttons or swiping to select), and also to perform assertion verification on screen feedback (such as determining whether a charging icon appears). Specifically, it can be implemented using open-source UI automation testing frameworks such as Airtest.

[0028] Mobile terminals refer to smart devices carried by users, such as smartphones. These terminals communicate with the vehicle-to-everything (V2X) cloud via 4G / 5G networks. The target application refers to the vehicle control application (such as a car manufacturer's app) running on the mobile terminal, which has functions such as remote charging scheduling and remote battery pack heating. Pre-defined user interface operations refer to a series of pre-designed UI interactions to trigger the cross-domain function under test, such as clicking the "schedule charging" button, setting the charging start time, and swiping to confirm. These operations can be executed automatically using image recognition technology.

[0029] Step S200: In response to the completion of the user interface operation, trigger the bus emulation to listen for the target cross-domain signal corresponding to the user interface operation, and verify the mapping relationship between the target cross-domain signals; wherein, the target cross-domain signal includes Ethernet service signal and controller area network signal.

[0030] Bus emulation refers to the use of software tools to simulate the communication behavior of a vehicle bus network, including sending, receiving, listening to, and analyzing bus messages. In this application, bus emulation is used to monitor cross-domain signals in the vehicle network.

[0031] In this application, the target cross-domain signal refers to the response signal issued by the BMS after receiving a valid charging or heating command and completing safety checks, indicating that high voltage is allowed to be applied or that charging / heating is in progress. The target cross-domain signal is a critical signal that needs to be monitored throughout the entire signal chain, specifically including: Ethernet service signals: Service call signals based on the SOME / IP protocol transmitted between the TBOX and the central domain controller, such as remote scheduled charging instructions (including Service ID, Method ID, and Payload data).

[0032] Controller Area Network (CAN) signals: CAN messages transmitted between the central domain controller and actuators such as VCU, OBC, and BMS, such as high-voltage relay closing commands and charging status messages.

[0033] The mapping relationship between target cross-domain signals is used to identify the correspondence between Ethernet service signals and Controller Area Network (CAN) signals, i.e., the S2S mapping rule. For example, the "remaining charging time" parameter in the Ethernet service signal is mapped to a signal field in the CAN message. Verifying the correctness of the mapping conversion means checking whether the Ethernet service signal and the CAN signal correspond one-to-one according to the preset rules.

[0034] Step S300: When the mapping relationship verification is successful and the expected target cross-domain signal issued by the battery management system is detected, the interface assertion verification is performed on the mobile terminal and the vehicle central control screen through image recognition to obtain the assertion verification result.

[0035] Here, the expected target cross-domain signal refers to the characteristic response signal issued by the battery management system after successfully executing a remote command, such as a CAN message confirming the closure of the high-voltage relay. The monitoring of this signal is independent of the verification of the aforementioned mapping relationship; both are verified through back-end trigger interface assertions.

[0036] Bus simulation continuously monitors the BMS response signal while verifying the correctness of the mapping relationship. An assertion is triggered when both conditions are met. The assertion validation result refers to the conclusion output after the interface assertion validation is executed, which is usually either Pass or Fail.

[0037] This application provides an automated testing method for cross-domain functions of a Battery Management System (BMS) based on image recognition and bus simulation. It utilizes image recognition technology to simulate real user operations on a mobile app, triggering the transmission of cross-domain signal chains in the vehicle. Simultaneously, bus simulation technology monitors key signals throughout the signal chain. When the expected response signal from the battery management system is detected, image recognition is immediately triggered to perform interface assertion verification on both the mobile phone screen and the vehicle's central control screen, thereby determining the correctness of the entire chain from user operation to vehicle execution and then to interface feedback. Through this method, this application achieves fully automated closed-loop testing from the real user interaction entry point to the underlying bus signals and multi-terminal UI feedback, solving the problems of fragmented tools and the inability to automatically link assertions in existing technologies, significantly improving testing efficiency and problem localization accuracy.

[0038] The method described in this application can be used to verify the integrity and correctness of complex signal links involving user mobile terminals, vehicle networking cloud, and vehicle domain controllers (such as central domain controllers and vehicle controllers).

[0039] This application also provides an automated testing system for BMS cross-domain functions based on image recognition and bus simulation, used to perform the above testing methods, such as... Figure 2As shown, the BMS cross-domain functional automated testing system 100 includes: an image recognition unit 110, a bus simulation unit 120, and a test scheduling platform 130.

[0040] The image recognition unit 110 is used to drive the target application on the mobile terminal to perform preset user interface operations, and to perform interface assertion verification on the mobile terminal and the vehicle central control screen.

[0041] The image recognition unit is an automated testing module based on computer vision technology. Its core functions include: Simulated user operation: By using image recognition to locate graphic elements (such as buttons, icons, and sliders) on the mobile terminal screen, it automatically performs interactive actions such as clicking, long pressing, swiping, and text input, thereby driving the target application to execute a preset user interface operation sequence.

[0042] Verification interface feedback: When specific trigger conditions are met (as notified by the test scheduling platform), screenshots are taken of the mobile terminal and the vehicle central control screen, and the expected interface elements (such as icons, animations, and text) are determined by methods such as template matching and optical character recognition (OCR), and the assertion verification results are output.

[0043] The bus emulation unit 120 is used to listen to the target cross-domain signals corresponding to the user interface operation and verify the mapping relationship between the target cross-domain signals; the target cross-domain signals include Ethernet service signals and controller area network signals.

[0044] In this system, the bus emulation unit mainly operates in residual bus emulation mode, that is, it does not replace any real controller, but passively listens to the packets in the network, and performs simple simulations on nodes that are not directly involved in the test (such as some sensors) to maintain normal bus communication.

[0045] The test scheduling platform 130 is communicatively connected to the image recognition unit 110 and the bus simulation unit 120 respectively. The test scheduling platform 130 is used to respond to the event that the image recognition unit completes the user interface operation, trigger the bus simulation unit 120 to listen to the target cross-domain signal corresponding to the user interface operation, and verify the mapping relationship between the target cross-domain signals. When the mapping relationship is verified and the bus simulation unit 120 listens to the expected target cross-domain signal issued by the battery management system, the image recognition unit 110 is triggered to perform interface assertion verification on the mobile terminal and the vehicle central control screen to obtain the assertion verification result.

[0046] The test scheduling platform is the core coordination module of the entire system. It can run in software on the same test host computer that runs the image recognition unit 110 and the bus simulation unit 120.

[0047] The BMS cross-domain function automated testing system based on image recognition and bus simulation provided in this application embodiment is used to execute the corresponding method provided above. Therefore, the beneficial effects it can achieve can be referred to the beneficial effects in the corresponding method provided above, and will not be repeated here.

[0048] Next, refer to Figure 3 This application describes an embodiment of an automated test system for cross-domain functions of a BMS based on image recognition and bus simulation.

[0049] The BMS cross-domain function automated testing system based on image recognition and bus simulation in this embodiment includes: a hardware testing system and a mobile UI automation agent module, a vehicle UI monitoring module, a vehicle network monitoring module, and a test scheduling platform deployed in the host computer.

[0050] The mobile UI automation proxy module is built on the open-source UI automation testing project Airtest. The mobile UI automation proxy module connects to the test mobile phone and automatically executes specific operations on the mobile APP (such as clicking the "Schedule Charging" button or setting the heating time) through image recognition technology, and captures the screen feedback on the operation results (such as "Schedule Successful" prompt).

[0051] The vehicle-mounted UI monitoring module is also built on Airtest. The mobile UI automation agent module connects to the vehicle's central control screen and monitors changes in the vehicle interface during the test process (such as the display of charging status icons and battery heating animations) through image recognition.

[0052] Airtest is developed using Python, so a Python environment needs to be set up on the host computer. Airtest is an image recognition-based UI automation testing framework that uses screenshots to find matching images in the displayed interface, simulate mouse clicks, and recognize icons or text for UI automation testing.

[0053] The vehicle network monitoring module is built on the CANoe bus development environment software. It monitors the entire vehicle network, including the TBOX (for sending / receiving Ethernet service signals), the central domain controller (for performing S2S mapping), VCU, OBC, BMS, MCU, and vehicle infotainment controller. Its core function is to listen for cross-domain signals: monitoring CAN signals mapped by the central domain controller, the VCU injecting expected command signals into the BMS, and monitoring the BMS's response messages.

[0054] CANoe supports many automotive network protocols, including CAN, Local Interconnect Network (LIN), FlexRay, Ethernet, and Media Oriented System Transport (MOST), as well as several CAN-based communication protocols such as J1939 and CANopen. CANoe's simulation and testing functions are implemented using the CAPL programming language. Due to its widespread use and extensive support for vehicle bus systems, CANoe is particularly suitable for ECU development in traditional vehicles, hybrid vehicles, and electric vehicles.

[0055] The test scheduling platform acts as a bridge, deeply integrating Airtest and CANoe to automate the driving and monitoring of the serial signal chain connecting the "mobile domain - cloud - cockpit domain - power domain". The test scheduling platform receives "UI operation completed" events from the Airtest module, converts them into test commands, and synchronously monitors the CANoe module to execute corresponding Ethernet service signals (such as the TBOX issuing a remote scheduled charging command).

[0056] The hardware testing system uses the VT System, a modular and scalable automotive Electronic Control Unit (ECU) testing system. It is primarily used for various automated and manual testing and verification scenarios, including ECU functional testing, bus compliance testing, Unified Diagnostic Services (UDS) diagnostic testing, and environmental endurance testing. The VT System is powered and grounded via a backplane and consists of a series of hardware boards. It can simulate all environments of the ECU, test it by connecting to the ECU's input / output lines, and seamlessly integrates with CANoe, providing functions such as residual bus simulation.

[0057] like Figure 3 As shown, the VT System is responsible for supplying power to the TBOX controller, central domain controller, VCU controller, OBC controller, BMS controller, MCU controller, and vehicle controller. It also simulates bus current, total voltage inside / outside the battery pack, individual cell voltage, smoke, temperature, insulation resistance, accelerator pedal opening, and control pilot (CP) signals through various sensor simulation boards. At the same time, the VT System integrates a charging pile module, which can simulate a fast charging pile and test the fast charging function of the BMS.

[0058] The mobile phone has a vehicle-specific app installed, which features remote heating and scheduled charging functions. Clicking the corresponding button in the app sends commands to the TBOX controller via 4G / 5G signals and the vehicle networking platform. The TBOX then sends the corresponding Ethernet service signal (SOME / IP) to the central domain controller via an Ethernet twisted-pair interface. The central domain controller converts this signal into a CAN signal according to the S2S mapping rules and sends it to the VCU, OBC, and MCU controllers via the power CAN bus. The VCU, OBC, and MCU controllers determine if there is a serious fault. If no serious fault is found, the VCU controller sends a relay closure command, and the OBC sends a charging gun connection command to the BMS controller. The BMS controller determines if the power-on conditions are met. If so, it closes the relay and sends SOC and other signals to the central domain controller. The central domain controller, through its gateway function, sends these signals to the vehicle's infotainment controller via the entertainment CAN bus. The vehicle's infotainment screen is connected to the vehicle's infotainment controller via a Low-Voltage Differential Signaling (LVDS) transmission harness and can display vehicle status, such as vehicle SOC and remaining charging time.

[0059] Airtest connects to mobile phones and vehicle screens via USB cable. After opening the Airtest IDE, clicking the connect button in the mobile device connection window allows you to project the content displayed on your mobile phone or vehicle screen onto your desktop computer. CANoe and Airtest are deployed on the same computer; CANoe is responsible for monitoring the CAN / Ethernet signals of each controller.

[0060] In this embodiment, CANoe is used as the bus operating environment, and the acquisition and monitoring of the vehicle's CAN signals are completed using the Communication Access Programming Language (CAPL) and the Vector vTESTstudio testing tool. During the test, the bus monitoring end simultaneously acquires multiple interactive signals: first, it acquires the target CAN signal sent by the central domain controller after mapping according to the preset S2S rules; after this signal is sent, it continues to acquire the high-voltage control command output by the vehicle's VCU and the charging gun connection command output by the OBC; at the same time, it acquires the response signal fed back by the BMS after executing the corresponding command. The platform performs timing constraints on all the above-mentioned acquired signals to ensure that strict timing correlation is maintained between each signal.

[0061] This solution configures cross-domain assertion triggering logic within the test cases, using the BMS high-voltage closure confirmation CAN signal as the trigger condition. When the CANoe detects this signal, the system automatically issues a scheduling command, invoking two sets of mobile UI automation proxy modules. These mobile UI automation proxy modules are supported by Airtest and possess screen image recognition capabilities; one module performs image recognition on the mobile phone screen, and the other performs image recognition on the vehicle's infotainment system screen, sequentially verifying the display status of preset UI elements such as "Charging" on the interface, completing automated assertion judgments, and simultaneously capturing screenshots of the interface.

[0062] After the entire testing process is completed, the system will perform unified time alignment on the original CAN bus message data, screenshots of each terminal interface, image recognition and assertion results, integrate and archive the multi-dimensional test data, and finally generate a time-synchronized integrated test report.

[0063] Next, we will explain in detail the automated testing method for cross-domain functions of BMS based on image recognition and bus simulation through four examples.

[0064] Example 1 This embodiment uses a mobile app for scheduled charging as an example. The automated testing method for BMS cross-domain functions provided in this embodiment can be achieved through the above... Figure 3 The test system implementation is shown. Figure 4 As shown, the overall process of the automated testing method in this embodiment is as follows: S1. Test Environment Setup and Configuration Set up an automated test environment for scheduled charging linkage, configure Airtest and CANoe tools and write test scripts (Python and CAPL languages). Prepare Airtest operation steps (screenshots), expect dual-screen UI feedback (screenshot templates), and set up CANoe to expect cross-domain Ethernet / CAN signals (such as ID and Data). Connect the test equipment correctly to the Vector VT system according to the working principle diagram, completing the hardware and software preparation of the test system.

[0065] S2, Stand-side charging connection parameter configuration Set the fast / slow charging gun connection status in the test bench, and configure parameters such as the voltage of the Connection Confirmation (CC) signal and the Control Pilot (CP) signal to simulate the state of the charging gun being physically connected.

[0066] S3, Simulation of Mobile Phone Reservation Charging Command Use the Airtest tool to set the scheduled charging duration and charging type parameters for the mobile app, and simulate clicking the scheduled charging button in the mobile app to trigger the scheduled charging command.

[0067] S4, T-BOX and Central Domain Controller Signal Monitoring The CANoe tool is used to monitor the Ethernet and CAN signals emitted by the T-BOX and the central domain controller to determine whether they meet the expected state under the scheduled charging scenario.

[0068] S5, vehicle control unit and power domain signal monitoring The CANoe tool is used to further monitor the CAN signals sent by VCU, OBC, BMS, and MCU to verify whether the command interaction of each control unit in the scheduled charging process meets expectations.

[0069] S6, Central Domain Controller Response Signal Monitoring The CANoe tool is used to monitor the CAN and Ethernet signals emitted by the central domain controller to verify whether its response status in the scheduled charging process meets expectations.

[0070] S7, Multi-terminal UI Status Verification and Test Result Judgment The Airtest tool is used to monitor the displayed information in the UI windows of the mobile phone and the vehicle, including whether the parameters such as charging type, charging power, SOC value, and remaining charging time are consistent with expectations; if all parameters meet expectations, the scheduled charging linkage test is considered to have passed.

[0071] In addition, this embodiment can also generate different types of charging faults through CANoe settings VT system, such as single cell voltage overvoltage, charging overcurrent, overheating, thermal runaway and other fault scenarios, to check whether the UI on both ends is consistent.

[0072] In this embodiment, the system ultimately generates a HyperText Markup Language (HTML) associated report containing UI screenshots and bus signal verification results. Using CAPL language, it sequentially inserts UI screenshots from the mobile phone and vehicle-mounted system saved in the Airtest folder, along with verification results for key Ethernet signal transmission events monitored by CANoe, CAN signals after S2S mapping, VCU commands, OBC commands, BMS response messages, etc., according to their runtime timestamps. Any timeout or failure in any step can be accurately located.

[0073] Example 2 This embodiment describes the Airtest testing process.

[0074] like Figure 5As shown, the Airtest testing process includes the following 6 steps.

[0075] Step A1: Application Launch, Function Navigation and Verification: Initialize the test environment and enter the charging function interface. The goal of this phase is to reliably enter the testing phase, such as... Figure 6 As shown, this ensures a high success rate for startup under various UI differences. Application launch: First, try to launch the application precisely by its package name; if that fails, then downgrade to clicking on the application icon image on the phone's home screen. Function Navigation: After entering the application, the system will attempt to locate the "Charging Management" entry point in the following ways: Preferred (Image Recognition): Matches preset charging function icons or tab screenshots.

[0076] Alternative (Control Finder): Use the Poco framework to scan the interface text and find clickable controls containing keywords such as "charging" or "energy". Emergency (Coordinate Click): If the above methods fail, a backup click operation is triggered at preset coordinates on the screen. Verification: Navigation success is confirmed by recognizing unique visual elements (such as the title) on the charging function page. This multi-path design is key to addressing differences between various vehicle infotainment systems or app versions.

[0077] Step A2, Scheduled Charging Settings: Configure the scheduled start / end time and other charging parameters.

[0078] This stage simulates a user completing a full booking process. The key lies in simulating the flexibility of human operation, such as... Figure 7 As shown. Enter the reservation interface: Using a fault-tolerant positioning method similar to Phase 1, find and click the "Reserve Charging" button. Time settings: For this complex control, the time picker, the system provides three interaction methods: 1. Use Poco for precise scrolling. Position the time picker wheel control and use the swipe() method to scroll. 2. First, click to select the time selector UI, and then slide it using the coordinates of Airtest to reach the preset time.

[0079] 3. When input is allowed, locate the input box and directly call the click() or text() function to input the time. It should be noted that, Figure 7 The time setting sub-process shown can be used not only to set the start time, but also to set the end time.

[0080] Parameter settings and confirmation: After setting the target charging level, battery preheating and other optional parameters, click the confirmation button and verify that the settings have taken effect by recognizing the "Reservation successful" pop-up or text feedback.

[0081] Step A3, Intelligent Waiting and Monitoring: Dynamically wait until the scheduled time and maintain the application status. This stage addresses the stability issue during long-term waiting, achieving proactive waiting rather than passive dormancy, such as... Figure 8 As shown. Dynamic wait time calculation: The system accurately calculates the required waiting time based on the difference between the set appointment time and the current time. Segmented loop monitoring: Long wait times are divided into multiple short-cycle loops. Within each loop: • The system will briefly hibernate. • After waking up, check whether the app under test is still running in the foreground on the phone.

[0082] If the system detects that the app has been switched to the background, the app will be automatically restarted to ensure that the testing process is not interrupted.

[0083] This mechanism effectively avoids test interruptions caused by factors such as system power-saving strategies and unexpected user operations.

[0084] Step A4, Charging Activation Check: Verify that the vehicle has started charging as scheduled. Upon arrival of the scheduled time, the system proactively verifies whether the charging action has been correctly triggered, employing a multi-round, multi-evidence verification strategy, such as... Figure 9 As shown. Cyclic check mechanism: The system initiates a round of checks at fixed intervals (e.g., 30 seconds) and repeats it up to N times (e.g., 10 times) to avoid misjudgments caused by network or vehicle response delays. Multi-dimensional state awareness: In each round of inspection, the system simultaneously searches for evidence that charging has been activated from two dimensions: Visual dimension: Try to match the screenshot template of the "charging" status icon or animation. Text dimension: Scan the screen for keywords such as "charging" or "Charging". If valid evidence is found in any dimension or in any round of inspection, the charging is considered successfully activated. If no evidence is found after reaching the maximum number of rounds, the scheduled charging is considered a failure. Step A5: Dual-end data extraction and consistency comparison: Extract key charging data from the mobile phone and vehicle screens and compare them. This is the assertion phase of the test. By comparing the data displayed on the mobile app and the in-vehicle central control screen, the correctness of the entire system's data link is verified. Figure 10 As shown. Dual-end data extraction: The system extracts data from the mobile APP interface and the vehicle screen interface in parallel or sequentially. The data extraction logic includes: first, locating the target data element on the interface; then, selecting the extraction method according to the data presentation format, including parsing text data through regular expression matching, extracting image data through image recognition based on Optical Character Recognition (OCR), or directly reading the attribute values ​​of interface controls; and finally, processing the extracted data. Figure 10 (Taking the remaining time as an example) is summarized for subsequent consistency comparison and verification.

[0085] Ultimately, the following key charging information can be extracted: Remaining time: such as parsing text in the format of "2 hours 30 minutes" into minutes. State of Charge (SOC) (Battery Percentage): Extracts the digital percentage value. Charging type: Determines whether it is "fast charging / DC" or "slow charging / AC".

[0086] Real-time power: Extracts power values ​​in kW. It should be noted that, Figure 10 The data extraction logic shown can be used not only for data extraction on mobile devices, but also for data extraction on in-vehicle systems.

[0087] Consistency comparison: Based on physical facts and measurement errors, intelligent comparison is performed by setting a reasonable tolerance range for the engineering process, such as: The remaining time is allowed to have a deviation of ±3 minutes. The allowable deviation for State of Charge (SOC) is ±1%. The charging power is allowed to deviate by ±0.5kW. The charging type must be exactly the same, such as DC charging / AC charging. Step A6: Generate the final test report based on the comparison results.

[0088] If all data items are consistent within the tolerance range, the test passes; if any item exceeds the tolerance or the data type is inconsistent, the test fails. Regardless of whether the test passes or fails, the system will generate a detailed test report containing all original data, comparison results, screenshots, and logs. Example 3 This embodiment describes the verification of cross-domain signal chains.

[0089] In the scheduled charging test, the cross-domain signal chain verification includes the following sub-steps: Step B1: Verify Ethernet service signal.

[0090] After the Airtest operation is completed, the platform triggers CANoe to monitor whether the TBOX sends an Ethernet service signal to the central domain controller. In CANoe, combined with the ARXML file, the CAPL statement calls the function on value_change / update to capture event changes / updates. Event names can be quickly generated by dragging and dropping. Then, in the event body, the event parameter values ​​are read using the $ operator and the this keyword to verify whether the Service ID, Method / Event ID, and Payload data values ​​of the Ethernet packet are consistent with expectations.

[0091] Step B2: Verify the CAN signal after S2S mapping. Set assertion statements to enable CANoe to automatically monitor whether the central domain controller sends the correct target CAN signal within a specified time according to the S2S mapping rules.

[0092] Step B3: Verify VCU, OBC, and BMS responses CANoe continues to monitor, such as whether the VCU receives the CAN signal and issues a command to close the high-voltage relay, and whether the OBC issues a command to connect the charging gun, etc.

[0093] If the BMS meets the power-on conditions, it powers on normally. CANoe monitors whether the charging signal sent by the BMS is correct and whether the CAN signal to Ethernet signal conversion for the charging function conforms to the S2S mapping rules. Specifically, it checks the type, ID, DLC, and Data of the CAN signal messages sent by controllers such as VCU, BMS, OBC, and vehicle infotainment system, as well as the Service ID, Method / Event ID, and Payload data values ​​of the Ethernet signals sent by the central domain controller to the vehicle infotainment system / TBOX to confirm whether they meet expectations. Table 1 shows a partial map of mapped signal types. As shown in Table 1, the mapping relationship is checked based on Table 1 to ensure it is correct. For example, the CAPL statement is used to automatically determine whether the CAN signal CAN_A and the Ethernet signal ETH_A for the remaining charging time are correctly mapped.

[0094] Table 1

[0095] Example 4 The technical solution of this application is also applicable to the testing of the remote scheduled battery heating function. The following description, in conjunction with Embodiment 4, provides a detailed explanation.

[0096] I. Test Preparation Connect the controllers, including BMS, VCU, OBC, vehicle infotainment system, and central domain controller, to the VT System bench.

[0097] Connect the test phone (with the vehicle app installed) and the vehicle screen to the host computer running Airtest, start the CANoe project, and load the ARXML and DBC database files for parsing Ethernet and CAN messages.

[0098] II. Test Case Configuration Create a new test case “TC_Remote_Battery_Heating” in the test platform and define it as follows: Step C1 (Airtest - Mobile App): Recognize and click the "Battery Heating" button in the app → Set the heating time → Click "Confirm".

[0099] Step C2 (CANoe-signal chain): Listen for expected Ethernet and CAN signals, including heating request signals from the central domain controller, heating enable signals from the VCU, plug-in request signals from the OBC, and heating relay closing signals from the BMS, and set their timing and numerical thresholds.

[0100] Step C3 (Airtest - Two-Ended Assertion): When the BMS heating relay closing signal is captured, execute in parallel: Airtest on the mobile phone recognizes the "Heating" status icon on the APP interface; Airtest on the vehicle system recognizes the "Battery Heating" animation icon on the central control screen.

[0101] III. Execution and Judgment Upon initiating the test, the platform schedules the following steps in sequence: Airtest operates the mobile phone to complete the setup; CANoe is triggered to monitor the TBOX and send a remote heating service signal; CANoe automatically monitors and records the signals from the central domain controller after S2S mapping, as well as subsequent VCU and BMS signals. If any link in the signal chain does not meet expectations, the test case fails, and the failure point is recorded.

[0102] If the signal chain passes, the platform immediately sends instructions to the Airtest module to perform image recognition assertions. Only if all signal chains are correct and both UIs on both ends successfully recognize the image, is the test case considered passed.

[0103] IV. Report Analysis Generate a report. If the report shows that the signal chain is correct but the vehicle's UI fails to recognize the signal, the problem can be directly determined to originate from the cockpit domain software or screen driver, eliminating the need to check the cloud, TBOX, and powertrain domain controllers, greatly improving the efficiency of problem localization.

[0104] The method in this application may also include: generating different types of charging faults through CANoe settings for the VT System, such as single-cell voltage overvoltage, charging overcurrent, overheating, and thermal runaway fault scenarios, and checking whether the UI on both ends is consistent. In this way, the protection logic of the BMS under abnormal conditions can be verified, as well as whether the mobile APP / vehicle screen correctly displays fault prompts.

[0105] Through the above specific implementation methods, this application achieves the following beneficial effects: End-to-end automated closed loop: Starting from real mobile phone touch operation, it fully tracks the entire link of "mobile APP -> Ethernet service -> S2S mapping -> CAN signal -> VCU -> OBC -> BMS -> dual-screen UI" to achieve one-click automated testing and correlation assertion.

[0106] Cross-domain signal monitoring and UI synchronization assertion: Using BMS response messages as trigger conditions, the UI of both mobile phones and vehicle systems is verified in parallel, changing the traditional method of verifying UI and signals separately and comparing them manually afterward, and strongly correlated with bus signals.

[0107] Precise problem location: The integrated report directly locates the problem link (such as abnormal bus signal, mapping error, UI not updated, etc.), greatly shortening the troubleshooting time.

[0108] High robustness and test coverage: Mechanisms such as multi-path fault-tolerant operation, intelligent wait-and-keep, and multi-round dual-dimensional checks significantly improve the stability of test scripts and the scope of scenario coverage.

[0109] Finally, it should be noted that the above technical solution is only one implementation method of this application. For those skilled in the art, based on the application methods and principles disclosed in this application, it is easy to make various types of improvements or modifications, and not limited to the methods described in the specific implementation methods above. Therefore, the methods described above are only preferred and have no limiting significance.

Claims

1. An automated testing method for cross-domain functions of a BMS based on image recognition and bus simulation, characterized in that, The automated testing method includes: Image recognition drives the target application on the mobile terminal to perform preset user interface operations; In response to the completion of the user interface operation, a bus emulation is triggered to listen for the target cross-domain signal corresponding to the user interface operation and to verify the mapping relationship between the target cross-domain signals; wherein, the target cross-domain signal includes Ethernet service signals and controller area network signals; When the mapping relationship is verified and the expected target cross-domain signal issued by the battery management system is detected, interface assertion verification is performed on the mobile terminal and the vehicle central control screen through image recognition to obtain the assertion verification result.

2. The automated testing method for cross-domain functions of BMS based on image recognition and bus simulation according to claim 1, characterized in that, Trigger bus emulation to listen for target cross-domain signals corresponding to the user interface operations, including: Listen to the target controller LAN signals emitted by the central domain controller after being converted according to the signal-to-signal mapping rules; Listen to the high-voltage control command issued by the vehicle controller after receiving the target controller's local area network signal, as well as the charging gun connection command issued by the on-board charger. Listen for the final execution response signal from the battery management system.

3. The automated testing method for cross-domain functions of BMS based on image recognition and bus simulation according to claim 1, characterized in that, Using image recognition to drive a target application on a mobile terminal to perform preset user interface operations, including: If the target application is launched by its package name, and launch fails, the system will switch to launching by clicking on the desktop icon image. After entering the target application, the function entry points are located sequentially according to priority through image recognition, control text search, or click at preset coordinates; After entering the configuration interface of the function entry, parameters can be set by at least one of the following methods: control sliding, coordinate positioning sliding, and direct text input; Identify the user interface feedback after the confirmation operation to verify that the settings have taken effect.

4. The automated testing method for cross-domain functions of BMS based on image recognition and bus simulation according to claim 1, characterized in that, When the preset user interface operation includes a scheduled task, the automated testing method further includes an intelligent waiting process, which includes: The status check is performed cyclically at fixed time intervals until the current time reaches the preset timer task execution time; During each status check, it is detected whether the target application on the mobile terminal is running in the foreground. If the target application is detected to be in the background, then the target application is restarted.

5. The automated testing method for cross-domain functions of BMS based on image recognition and bus simulation according to claim 1, characterized in that, When the preset user interface operation is a scheduled charging operation, interface assertion verification is performed on the mobile terminal and the vehicle central control screen through image recognition, including: When the controller area network signal confirming the closing of the high voltage issued by the battery management system is detected, image recognition is used in parallel to identify whether the preset charging status user interface elements appear on the screen of the mobile terminal and the vehicle central control screen respectively.

6. The automated testing method for cross-domain functions of BMS based on image recognition and bus simulation according to claim 5, characterized in that, Before performing interface assertion verification, the following is also included: After the preset appointment time is reached, multiple rounds of cyclical checks are performed at fixed time intervals; In each round of inspection, evidence of charging activation is searched in parallel from both visual and textual dimensions. The visual evidence is a screenshot template that matches a preset charging status icon or animation, while the textual evidence is charging-related keywords scanned on the screen. If evidence of at least one dimension is found in any round of inspection, the charging is deemed to have been successfully activated.

7. The automated testing method for cross-domain functions of BMS based on image recognition and bus simulation according to claim 5, characterized in that, The interface assertion verification of the mobile terminal and the vehicle central control screen through image recognition also includes: Key information representing the charging status is extracted from the mobile terminal and the vehicle central control screen respectively, and the extracted key information is compared for consistency. The key information includes at least one of the following: remaining time, battery percentage, charging type, and charging power. The consistency comparison is determined using a preset tolerance range.

8. The automated testing method for cross-domain functions of BMS based on image recognition and bus simulation according to claim 1, characterized in that, The bus emulation supports at least one of the network protocols CAN, CAN FD, and SOME / IP, and the bus emulation is loaded with a database file for parsing bus messages or service signals that conform to the network protocol.

9. An automated testing system for cross-domain functions of a BMS based on image recognition and bus simulation, characterized in that, include: The image recognition unit is used to drive the target application on the mobile terminal to perform preset user interface operations, and to perform interface assertion verification on the mobile terminal and the vehicle central control screen. A bus emulation unit is used to monitor target cross-domain signals corresponding to the user interface operation and verify the mapping relationship between the target cross-domain signals; the target cross-domain signals include Ethernet service signals and controller area network signals; The test scheduling platform is communicatively connected to both the image recognition unit and the bus simulation unit. The test scheduling platform is used to respond to the event that the image recognition unit completes the user interface operation, trigger the bus simulation unit to listen to the target cross-domain signal corresponding to the user interface operation, and verify the mapping relationship between the target cross-domain signals; And when the mapping relationship is verified and the bus simulation unit detects the expected target cross-domain signal issued by the battery management system, the image recognition unit is triggered to perform interface assertion verification on the mobile terminal and the vehicle central control screen to obtain the assertion verification result.

10. The automated testing system for cross-domain functions of a BMS based on image recognition and bus simulation according to claim 9, characterized in that, The bus emulation unit is also used to perform automatic verification of the mapping relationship between the Ethernet service signals and the controller area network signals.

Images