Vehicle remote batch management method, server and vehicle

Abstract

This application relates to the field of power-off control technology in vehicle remote control systems, and particularly to a method, server, and vehicle for remote batch management of vehicles. The method includes: acquiring vehicle identifiers of multiple vehicles and the power-off time of each vehicle; generating a power-off command for each vehicle based on the vehicle identifier and power-off time; generating batch management commands for multiple vehicles based on the power-off commands for each vehicle; sending the batch management commands to the vehicle-mounted communication terminals of the multiple vehicles; the vehicle-mounted communication terminals parsing the batch management commands and determining the corresponding power-off command for each vehicle based on the vehicle identifier; the battery management system executing the power-off operation according to the power-off command and feeding back the power-off result to the vehicle-mounted communication terminals via a communication path; and the vehicle-mounted communication terminals, powered by a backup power supply, feeding back the power-off result to the server. This solves the problems of lack of remote batch power-off for vehicles and the inability to provide feedback on power-off status in related technologies.

Description

Technical Field

[0001] This application relates to the field of power failure control technology in vehicle remote control systems, and particularly to a method for remote batch management of vehicles, a server, and a vehicle. Background Technology

[0002] During the export storage (which often exceeds 45 days) and storage at 4S stores, new energy electric vehicles are prone to battery depletion due to prolonged idleness. The relevant technology uses a method of manually opening the hood and disconnecting the negative terminal of the battery to cut off the power, which takes a long time per vehicle and is inefficient. Summary of the Invention

[0003] This application provides a method for remote batch management of vehicles, a server, and a vehicle to solve problems such as the lack of remote batch power-off for vehicles and the inability to provide feedback on power-off status in related technologies.

[0004] The first aspect of this application provides a method for remote batch management of vehicles. The method is applied to a server that communicates with multiple vehicles. Each vehicle includes a battery management system and an on-board communication terminal. Multiple communication paths are established between the battery management system and the on-board communication terminal. The on-board communication terminal is equipped with a backup power supply. The method includes the following steps: acquiring vehicle identifiers and power-off times for each of the multiple vehicles; generating a power-off command for each vehicle based on the vehicle identifier and power-off time; generating batch management commands for multiple vehicles based on the power-off commands for each vehicle; sending the batch management commands to the on-board communication terminals of the multiple vehicles; the on-board communication terminals parsing the batch management commands and determining the corresponding power-off command for each vehicle based on the vehicle identifier; the battery management system executing a power-off operation according to the power-off command and feeding back the power-off result to the on-board communication terminal through the communication paths; and the on-board communication terminal, powered by the backup power supply, feeding back the power-off result to the server.

[0005] Based on the aforementioned technical means, this application embodiment is based on a communication architecture between a server and multiple vehicles. Utilizing a battery management system with multiple communication paths and an onboard communication terminal with backup power on the vehicle side, it generates batch management instructions by acquiring multiple vehicle identifiers and power-off times. These instructions are then issued and power-off operations are triggered. The complete process of feedback through multiple paths and backup power ensures seamless data transmission. This solves the problems of low efficiency in manual single-vehicle power-off in related technologies, enabling remote batch management of multiple vehicles. It also addresses the open-loop problem of unfeedback after power-off in related technologies. Furthermore, the combination of multiple communication paths and backup power enhances the stability and reliability of result feedback, ultimately meeting the needs for efficient and controllable remote power-off management of vehicle batteries in scenarios such as vehicle warehousing and 4S store storage.

[0006] Optionally, after issuing batch management instructions to the vehicle communication terminals of multiple vehicles, the method further includes: obtaining feedback data from multiple vehicles; marking the execution status of multiple vehicles based on the feedback data; and displaying the marked execution status of multiple vehicles.

[0007] Based on the aforementioned technical means, this application embodiment, by obtaining feedback data from multiple vehicles after the batch management command is issued, marking the execution status of each vehicle according to the feedback data, and displaying the marked status, saves the time for managers to query the execution results of each vehicle individually. It can quickly grasp the power-off status of all vehicles (such as success, failure, abnormality, etc.), greatly improving the efficiency of batch management. In addition, by clearly marking the status, it accurately locates abnormal vehicles that have not successfully disconnected from power, avoiding management omissions caused by ambiguous results, and facilitating subsequent targeted remedial measures such as reissuing commands and manual investigation. At the same time, the visualized status display makes the results of batch operations (such as success rate and abnormality ratio) intuitively visible, further enhancing the transparency and controllability of remote batch management, and adapting to the efficient and accurate vehicle management needs in warehousing scenarios.

[0008] Optionally, the execution status of multiple vehicles is marked based on the feedback data, including: identifying the power failure result in the feedback data; marking the execution status of multiple vehicles based on the power failure result; if no feedback data from the vehicle is received within a preset time, the execution status of multiple vehicles is marked based on the historical heartbeat signal of the corresponding vehicle.

[0009] Based on the aforementioned technical means, this application implements state marking adapted for both normal and abnormal scenarios, achieving complete coverage of execution state marking in remote batch vehicle management: In normal scenarios, the server directly uses the power outage result reported by the vehicle as the basis for state marking. The power outage result originates from the actual execution data transmitted by the vehicle's battery management system to the on-board communication terminal (powered by a backup power supply) through multiple communication paths, ensuring the directness and accuracy of the marking; In abnormal scenarios where no feedback is received for more than a preset time, the server calls the historical heartbeat signal of the corresponding vehicle (this signal is based on historical data such as communication stability and command reception status before offline, which has basic reliability) to supplement the state marking. This solves the gap in related technologies where no feedback means no state, achieving coverage of the execution status of all vehicles. It also avoids misjudgment of execution failure due to the lack of feedback by referring to historical heartbeat signals. At the same time, the server automatically completes the vehicle state marking, eliminating the need for managers to manually check vehicles without feedback, significantly reducing labor costs, adapting to the actual needs of some vehicles that may be offline in warehouse scenarios, and further improving the completeness, accuracy, and efficiency of remote batch management.

[0010] Optionally, the execution status includes at least one of a pending execution status, an execution status, a success status, and a failure status. After displaying the execution status of multiple vehicles after marking, the method further includes: identifying the target vehicle whose execution status is a pending execution status or a failure status; obtaining the retransmission status of the target vehicle; and updating the execution status of the target vehicle based on the retransmission status.

[0011] Based on the aforementioned technical means, the embodiments of this application clearly define the execution status as including at least one type: pending execution, in execution, successful, and failed, providing a clear basis for distinguishing the status of vehicles in remote batch management. After displaying the execution status of multiple vehicles after marking, the target vehicles with the execution status of pending execution or failed can be directly and accurately identified without the need for management personnel to check each vehicle one by one, avoiding the omission of abnormal vehicles. Subsequently, by obtaining the retransmission status of these target vehicles (such as whether retransmission was initiated, whether retransmission was successful, etc.), the execution status of the target vehicles is dynamically updated, making the execution status marking more flexible, saving the repetitive operation of manually following up on target vehicles, and further improving the accuracy and efficiency of remote batch management of vehicles.

[0012] Optionally, the multiple communication paths include a first communication path and a second communication path. The first communication path is used for communication between the battery management system and the vehicle communication terminal before the power-off operation, and the second communication path is used for communication between the battery management system and the vehicle communication terminal after the power-off operation.

[0013] Based on the aforementioned technical means, in this embodiment, the first communication path is specifically used for communication between the battery management system and the vehicle communication terminal before the power-off operation, while the second communication path is specifically used for communication after the power-off operation, ensuring that the battery management system performs feedback of results after the power-off. By splitting the communication path into stages, the interruption of the feedback link due to the failure of a single path caused by the power-off operation (such as the impact of changes in the power supply of some vehicle modules on path stability after the power-off) is avoided, ensuring that the power-off results can be stably transmitted to the vehicle communication terminal, laying a solid foundation for subsequent result feedback to the server; it can also match the communication needs of different stages according to the differences in communication needs before and after the power-off (such as focusing on command issuance efficiency before the power-off and focusing on result transmission accuracy after the power-off), reducing mutual interference between communication tasks at different stages, further improving the reliability of the overall communication link, and providing support for closed-loop management of remote batch management.

[0014] Optionally, the vehicle communication terminal identifies the power-off time in the power-off command, wakes up the battery management system after the power-off time is reached, sends a power-off command to the battery management system, the battery management system executes the power-off command after a delay, and triggers the vehicle to power down after disconnecting the transistor according to the power-off command. The backup power supply of the vehicle communication terminal supplies power to the vehicle communication terminal before the vehicle is powered down, and the vehicle communication terminal enters a low-power mode after feeding back the power-off result.

[0015] According to the above technical means, in the process of remotely powering off a vehicle, the vehicle communication terminal first identifies the preset power-off time in the power-off command. After the time is reached, it wakes up the battery management system and sends a power-off command. After receiving the command, the battery management system does not operate immediately, but reserves a buffer time by delaying execution. Then, it disconnects the transistor according to the command to trigger the vehicle to power down. At the same time, the backup power supply of the vehicle communication terminal will continue to supply power to the vehicle before the vehicle is powered down, ensuring that the power-off result can be completely fed back to the server. After the feedback is completed, the vehicle communication terminal automatically switches to low-power mode. By waking up and executing according to the preset time, the precise control of the power-off timing is achieved, which is suitable for the needs of planned batch power-off in warehousing scenarios. Furthermore, the delayed operation of the battery management system avoids the impact of sudden power-off on key vehicle modules (such as data storage modules), reducing the risk of data loss or hardware damage. The backup power supply ensures the integrity of the power-off result feedback, while the low-power mode reduces the ineffective energy consumption of the backup power supply, extends its service life, and reserves power support for possible emergency communication or command reception.

[0016] Optionally, before sending batch management instructions to the vehicle communication terminals of multiple vehicles, the method further includes: obtaining the battery health status of the backup power supply of the vehicle communication terminal; and monitoring and issuing warnings for the backup power supply of the vehicle communication terminal based on the battery health status.

[0017] Based on the above technical means, this application embodiment adds a pre-screening and control step for the status of backup power supply before sending batch management instructions to the vehicle communication terminals of multiple vehicles. First, it actively obtains the battery health data (such as remaining power, aging degree, etc.) of the backup power supply of each vehicle communication terminal, and then uses the health data as a basis to monitor the operating status of the backup power supply in real time. For example, if the health is lower than a preset threshold (such as less than 30% power, aging index exceeding the standard, etc.), an early warning is immediately triggered. By proactively managing backup batteries, potential problems with backup power supplies can be identified in advance, preventing issues such as power failure of the vehicle communication terminal and inability to transmit power failure results after a power outage due to insufficient backup power supply health, thus ensuring the stability of the feedback link. Furthermore, real-time monitoring and timely warnings guide managers to charge, maintain, or replace abnormal backup power supplies in advance, ensuring reliable power supply during the power outage feedback process and reducing the risk of batch management loss of control due to backup power supply failures. Simultaneously, vehicle management shifts from passively responding to feedback failures after a power outage to proactively preventing potential problems before instructions are given, reducing the costs of secondary manual verification due to missing feedback and further improving the stability and reliability of remote batch vehicle management.

[0018] A second aspect of this application provides a method for remote batch management of vehicles. The vehicle includes a battery management system and an in-vehicle communication terminal. Multiple communication paths are established between the battery management system and the in-vehicle communication terminal. The in-vehicle communication terminal is equipped with a backup power supply and communicates with a server. The method is applied to the in-vehicle communication terminal of the vehicle. The method includes the following steps: obtaining a batch management instruction issued by the server, which is generated by the server based on power-off instructions from multiple vehicles. The power-off instructions are generated based on vehicle identification and power-off time; parsing the batch management instruction, determining the power-off instruction for the corresponding vehicle based on the vehicle identification, identifying the power-off time from the power-off instruction, and waking up the battery management system after the power-off time is reached; sending the power-off instruction to the battery management system, which performs a power-off operation according to the power-off instruction and feeds back the power-off result to the in-vehicle communication terminal through the communication path; and the in-vehicle communication terminal, powered by the backup power supply, feeds back the power-off result to the server.

[0019] Based on the aforementioned technical means, this application embodiment allows the vehicle's onboard communication terminal to act as the execution subject, collaborating with the server and battery management system to form a complete process from receiving instructions, executing operations, to providing feedback results: The onboard communication terminal first obtains batch management instructions issued by the server (these instructions are generated by the server based on the identifiers of multiple vehicles and the power-off time), then parses the batch instructions, determines the corresponding power-off instruction by matching its own vehicle identifier, and extracts the power-off time from the instruction; after the time reaches a preset value, the terminal wakes up the battery management system, which is in standby mode, and sends the power-off instruction to the battery management system to trigger the power-off operation; after the battery management system executes the power-off, it feeds back the power-off result to the terminal through the communication path between the two, while the terminal relies on the backup power supply to maintain power supply, ensuring that the power-off result can be stably transmitted back to the server. By parsing instructions and matching identifiers, the system ensures that each vehicle only executes its corresponding power-off task, avoiding the problem of multiple vehicles executing incorrectly or out of order under batch instructions. This provides orderly support for batch management of the server and is suitable for standardized vehicle management in warehousing scenarios. Furthermore, by leveraging backup power and communication paths, the system solves the problem of terminal power loss and inability to provide feedback after vehicle power failure. At the same time, the system periodically wakes up the battery management system to avoid continuous standby power consumption of the terminal and battery management system, reducing data processing redundancy. This ensures accurate execution while reducing energy consumption and extending the lifespan of the backup power supply.

[0020] A third aspect of this application provides a server, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the vehicle remote batch management method of the above embodiments.

[0021] A fourth aspect of this application provides a vehicle, including: a memory, a processor, and a computer program stored in the memory and executable on the processor. The processor executes the program to implement the vehicle remote batch management method as described in the above embodiments.

[0022] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0023] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein:

[0024] Figure 1 This is an architecture diagram of a vehicle remote batch management system provided according to an embodiment of this application;

[0025] Figure 2 This is a flowchart of a remote batch management method for vehicles provided according to an embodiment of this application;

[0026] Figure 3 This is a flowchart of a remote batch management method for vehicles according to another embodiment of this application;

[0027] Figure 4 This is a schematic diagram of dual-path feedback provided according to an embodiment of this application;

[0028] Figure 5 This is a flowchart of batch instruction provided according to an embodiment of this application;

[0029] Figure 6 This is a schematic diagram of the structure of a server provided according to an embodiment of this application.

[0030] Figure 7 This is a structural schematic diagram of a vehicle provided according to an embodiment of this application. Detailed Implementation

[0031] The embodiments of this application are described in detail below. Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0032] Currently, the storage period for exported vehicles generally exceeds 45 days. Related technologies require manual power disconnection, which necessitates opening the battery cover and disconnecting the negative terminal, taking at least 5 minutes per vehicle, resulting in extremely low efficiency. Furthermore, if vehicles are stored for extended periods after being shipped to 4S dealerships, they face the risk of battery depletion. The relevant technologies for remote vehicle power disconnection management have the following shortcomings:

[0033] First, the functions and batch management are lacking. Existing models do not have remote power-off functions and only support single-vehicle operation. They lack the ability to import VINs (Vehicle Identification Numbers) in batches and summarize execution status, which cannot meet the needs of modern management and warehousing of thousands of vehicles.

[0034] Second, there is a problem with open-loop feedback and insufficient power supply. When the battery is disconnected, the entire vehicle loses power. The on-board terminal cannot provide feedback due to the lack of power supply. During batch operations, users cannot confirm whether the power outage was successful.

[0035] Third, it has poor offline scenario adaptation. When the vehicle has no network, it cannot receive commands and there is no local caching or timed execution mechanism, which causes offline commands to become invalid.

[0036] Fourth, the lack of anomaly protection, such as the absence of self-processing capabilities for scenarios like short circuits and communication interruptions, may cause damage to vehicle circuits or chaotic command execution, affecting management reliability.

[0037] The following description, with reference to the accompanying drawings, outlines a vehicle remote batch management method, server, and vehicle according to embodiments of this application. Addressing the issues mentioned in the background art, such as the lack of remote and batch power-off functionality for vehicles and the inability to provide feedback on power-off status, this application provides a vehicle batch power-off and status feedback system. This system utilizes the collaboration of an LBMS (Low Voltage Battery Management System), a TBOX (Telematics Box), and a cloud platform. The LBMS integrates a discharge MOS (Metal-Oxide-Semiconductor Field-Effect Transistor) and communicates with the TBOX via a CAN (Controller Area Network) bus. The TBOX has a built-in backup battery to ensure continued feedback after a power outage. The cloud platform supports batch command issuance and real-time status monitoring. Through dual-path feedback—CAN bus and GPIO (General Purpose Input / Output) hardwired connections, offline command caching and timed wake-up, and backup power switching technologies—closed-loop control for remote batch power-off of vehicles is achieved. It solves the problems in related technologies such as the lack of remote and batch power-off functions for vehicles and the inability to provide feedback on power-off status, and is suitable for vehicle warehousing and 4S store storage scenarios.

[0038] Figure 1 This is an architecture diagram of the electric vehicle remote batch management system according to an embodiment of this application, such as... Figure 1As shown, the remote batch management system for electric vehicles includes: a server, multiple vehicles, and each vehicle includes a battery management system and an onboard communication terminal.

[0039] The system incorporates multiple communication paths between the battery management system (BMS) and the vehicle-mounted communication terminal, with the latter equipped with a backup power supply. The system is divided into a hardware interaction layer and a software logic layer. The hardware logic layer includes the LBMS module: connected to the battery, integrating a discharge MOSFET, communicating with the TBOX via a CAN bus, and sending a level signal to the TBOX as a hard-wired confirmation after power failure via an independent GPIO pin; and the TBOX module: supporting 4G / 5G communication, with a built-in backup battery, switching to the backup power supply to send feedback signals after power failure. The software logic layer includes a cloud platform: deploying a batch command management system, supporting importing vehicle VIN codes from Excel, setting power failure times, batch issuing commands, and real-time display of execution status; TBOX firmware: parsing commands, controlling execution, and providing feedback results, supporting offline command caching; and LBMS firmware: verifying commands, delaying MOSFET disconnection, and caching battery status.

[0040] It's important to note that the LBMS's disconnection of the vehicle's low-voltage power supply and provision of hard-wired confirmation are essential steps. This is because the CAN bus may lose power after a power outage, and hard-wired confirmation is the only way to ensure feedback is independent of communication. Additionally, the TBOX's receiving of commands, execution of operations and feedback of results, and the cloud platform's batch command distribution and status display are also crucial; the absence of any of these steps may lead to system failure.

[0041] The following will be based on Figure 1 The structure shown illustrates the remote batch management method for vehicles provided in this application embodiment. This method is applied to a server, such as... Figure 2 As shown, it includes the following steps:

[0042] In step S201, the vehicle identifiers of multiple vehicles and the power outage time of each vehicle are obtained.

[0043] It is understood that the embodiments of this application can accurately locate specific vehicles through vehicle identification, effectively avoiding mis-issuance of commands or operational deviations. At the same time, each vehicle is configured with a dedicated power-off time, which can be flexibly adapted to the needs of different vehicles to achieve differentiated power-off management and ensure the accuracy of power-off operations. In addition, by acquiring vehicle identification and power-off time for multiple vehicles simultaneously, the pre-configuration of commands for multiple vehicles can be completed at one time, improving the efficiency of remote management of large-scale vehicles and reducing the cost of repetitive manual operations. It provides the operation objects and execution timing basis for subsequent command generation, issuance, power-off execution and other links, further ensuring the reliability and integrity of the remote batch management process of vehicles.

[0044] In step S202, a power-off command for each vehicle is generated based on the vehicle identifier and power-off time, and a batch management command for multiple vehicles is generated based on the power-off command for each vehicle.

[0045] It is understood that, in this embodiment of the application, a unique power-off command is generated for each vehicle based on its unique vehicle identifier and preset power-off time. This ensures that each command accurately matches the management needs of the corresponding vehicle, effectively avoiding problems such as mismatched vehicles and incorrect execution times caused by misaligned command information. In addition, multiple batch management commands for multiple vehicles are generated based on the power-off command for each vehicle. This eliminates the need to generate and issue commands separately for each vehicle, reducing the frequency of communication and operational redundancy between the server and vehicles. This significantly improves the remote management efficiency of large-scale clusters such as fleets or warehouses with thousands of vehicles, and reduces repetitive manual operations and time costs. At the same time, this step provides a key command carrier for the entire remote batch management process that includes both the personalized needs of individual vehicles and supports batch transmission, ensuring coordination from information collection to command implementation, and further strengthening the integrity and reliability of the management process.

[0046] Specifically, batch command generation in the cloud: The operations platform imports an Excel spreadsheet containing VIN, power outage time, and priority; the system verifies the validity of the VIN, generates a unique command ID, and encrypts it using AES-128 (key pre-shared); the command format is JSON containing cmd_id, cmd_type, target_vin, execute_time (accurate to the second), delay_off_time (5 seconds), and feedback_timeout (10 seconds). Specifically: json{"cmd_id":"XXXXXXXX","cmd_type":"BATCH_POWER_OFF","target_vin":"LHGCM82633A000001","execute_time":"XXXXXXXX","delay_off_time":5000, / / unit: milliseconds"feedback_timeout":10000}.

[0047] In step S203, a batch management command is sent to the vehicle communication terminals of multiple vehicles. The vehicle communication terminals parse the batch management command, determine the power-off command of the corresponding vehicle based on the vehicle identifier, and the battery management system executes the power-off operation according to the power-off command. The power-off result is fed back to the vehicle communication terminal through the communication path. The vehicle communication terminal is powered by the backup power supply and feeds back the power-off result to the server.

[0048] It is understood that the embodiments of this application realize a remote batch management process for vehicles, from server to vehicle and then from vehicle back to the result: the server uniformly sends batch management instructions to the vehicle communication terminals of multiple vehicles, which avoids communication redundancy of sending instructions to each vehicle individually, greatly improving the management efficiency of large-scale clusters such as thousands of warehouse vehicles; and by matching the corresponding power-off instruction according to the vehicle identifier when the vehicle communication terminal parses the instruction, it ensures that each vehicle only executes the task matched to itself, balancing the scalability of batch management with the precision of single-vehicle control, and avoiding the risk of instruction mismatch. At the same time, after the battery management system performs a power-off operation, it uses multiple communication paths with the vehicle communication terminal to feed back the result, preventing information loss caused by single-path interruption; and the vehicle communication terminal relies on backup power to maintain power supply, solving the open-loop problem of terminal power loss and inability to send back results after vehicle power failure, allowing the server to accurately obtain the power failure status of each vehicle.

[0049] Specifically, the instruction issuance and caching process is as follows: Online issuance: In real time, instructions are issued to the TBOX via the MQTT protocol (QoS=2); Offline caching: When the TBOX detects a signal strength < -100dBm, the instructions are stored in the EEPROM (sorted by ID, maximum 100 instructions). The TBOX can cache a maximum of 100 instructions to ensure that tasks can still be executed when the vehicle is offline. The 100 instructions represent a 12.5% ​​redundancy design based on the maximum batch operation (800 vehicles) in a warehouse scenario, which can meet the caching requirements of 3 consecutive batch instructions and avoid cache overflow; Instruction verification: The TBOX verifies the instruction signature (cloud private key hash) and VIN matching.

[0050] In this embodiment of the application, before sending the batch management command to the vehicle communication terminals of multiple vehicles, the method further includes: obtaining the battery health of the backup power supply of the vehicle communication terminal; and monitoring and issuing early warnings for the backup power supply of the vehicle communication terminal based on the battery health.

[0051] It is understood that, before sending batch management instructions to the vehicle communication terminals of multiple vehicles, this application embodiment adds a pre-screening and control step for the status of backup power. First, it actively obtains the battery health data (such as remaining power, aging level, etc.) of the backup power of each vehicle communication terminal, and then uses the health data as a basis to monitor the operating status of the backup power in real time. For example, if the health is lower than a preset threshold (such as less than 30% power, aging index exceeding the standard, etc.), an early warning is immediately triggered. By proactively managing backup batteries, potential problems with backup power supplies can be identified in advance, preventing issues such as power failure of the vehicle communication terminal and inability to transmit power failure results after a power outage due to insufficient backup power supply health, thus ensuring the stability of the feedback link. Furthermore, real-time monitoring and timely warnings guide managers to charge, maintain, or replace abnormal backup power supplies in advance, ensuring reliable power supply during the power outage feedback process and reducing the risk of batch management loss of control due to backup power supply failures. Simultaneously, vehicle management shifts from passively responding to feedback failures after a power outage to proactively preventing potential problems before instructions are given, reducing the costs of secondary manual verification due to missing feedback and further improving the stability and reliability of remote batch vehicle management.

[0052] Specifically, the backup battery monitoring process is as follows: the backup battery health status is displayed in the cloud (an alarm is triggered when SOC (State of Charge) < 20%) to prevent feedback failure due to battery depletion. This application does not specify the exact value of the preset threshold for health status, but it is necessary to avoid wasting power redundancy due to an excessively high threshold or interrupting critical feedback due to an excessively low threshold.

[0053] In this embodiment of the application, after the batch management instruction is sent to the vehicle communication terminals of multiple vehicles, the method further includes: obtaining feedback data from multiple vehicles; marking the execution status of multiple vehicles based on the feedback data; and displaying the marked execution status of multiple vehicles.

[0054] It is understood that the embodiments of this application, by obtaining feedback data from multiple vehicles after the batch management command is issued, marking the execution status of each vehicle based on the feedback data, and displaying the marked status, saves the time for managers to query the execution results of each vehicle individually. This allows for a quick grasp of the power-off status of all vehicles (such as success, failure, abnormality, etc.), significantly improving the efficiency of batch management. In addition, the clear status marking accurately locates abnormal vehicles that have not successfully shut down, avoiding management omissions caused by ambiguous results, and facilitating subsequent targeted remedial measures such as reissuing commands and manual investigation. At the same time, the visualized status display makes the results of batch operations (such as success rate and abnormality rate) intuitively visible, further enhancing the transparency and controllability of remote batch management, and adapting to the efficient and accurate vehicle management needs in warehousing scenarios.

[0055] In this embodiment of the application, marking the execution status of multiple vehicles based on feedback data includes: identifying power outage results in the feedback data; marking the execution status of multiple vehicles based on the power outage results; if no feedback data from a vehicle is received within a preset time period, marking the execution status of multiple vehicles based on the historical heartbeat signal of the corresponding vehicle.

[0056] The preset duration can be set according to the actual situation, such as 10 seconds, 11 seconds, etc.

[0057] Understandably, this application implements state marking for both normal and abnormal scenarios, achieving complete coverage of execution state marking in remote batch vehicle management: In normal scenarios, the server directly uses the power outage result reported by the vehicle as the basis for state marking. The power outage result originates from the actual execution data transmitted by the vehicle's battery management system to the on-board communication terminal (powered by backup power) through multiple communication paths, ensuring the directness and accuracy of the marking; In abnormal scenarios where no feedback is received for more than a preset time, the server calls the historical heartbeat signal of the corresponding vehicle (this signal is based on historical data such as communication stability and command reception status before offline continuously uploaded during the normal communication phase, possessing basic reliability) to supplement the state marking. This solves the gap in related technologies where no feedback means no state, achieving coverage of the execution status of all vehicles. It also avoids misjudgment of execution failure due to a lack of feedback by referring to historical heartbeat signals. At the same time, the server automatically completes vehicle state marking, eliminating the need for managers to manually check vehicles without feedback, significantly reducing labor costs, adapting to the actual needs of some vehicles that may be offline in warehouse scenarios, and further improving the completeness, accuracy, and efficiency of remote batch management.

[0058] Specifically, dual-path confirmation: In both the first and second communication paths, the TBOX simultaneously receives CAN messages and GPIO level signals; a valid signal is considered a success. Timeout handling: If no feedback is received from the cloud within 10 seconds, the status is marked based on the vehicle's historical heartbeat record. This application does not specify a particular value for the preset timeout period, but the setting must meet the following requirements: preventing the abnormal status of timed-out vehicles from being marked indefinitely due to excessive timeout, thus affecting the user's overall control over the execution results of batch vehicles; and preventing misjudgments caused by occasional situations such as excessively short timeouts, network fluctuations, or momentary signal interruptions. The status monitoring and batch management process is as follows: The cloud displays the command execution status in real time (pending execution, in execution, successful, failed), and supports batch power-off cancellation. The abnormal handling types and methods are shown in Table 1.

[0059] Table 1

[0060]

[0061] Among them, short-circuit protection, as the core protection mechanism for circuit safety, runs through the entire process of the battery management system's monitoring of the battery circuit. One of the functions of the battery management system is to monitor the current, voltage and other states of the battery circuit in real time. Short-circuit protection is the basic logic of its passive protection. No matter what stage the vehicle is in, whether it is in normal operation, standby, or executing a remote power-off command, as long as a short-circuit characteristic (such as a line short circuit, abnormal load, etc.) with a current > 100A and lasting for 10ms appears in the circuit, the short-circuit protection mechanism will be triggered immediately, forcibly disconnecting the MOSFET and mechanical relay, and cutting off the circuit to avoid damage to the battery and lines due to large current.

[0062] In this embodiment of the application, the execution state includes at least one of the following: pending execution state, in-process execution state, successful state, and failed state. After displaying the execution states of multiple vehicles after marking, the method further includes: identifying the target vehicle whose execution state is pending execution state or failed state; obtaining the retransmission state of the target vehicle; and updating the execution state of the target vehicle according to the retransmission state.

[0063] It is understood that the embodiments of this application first clearly define the execution status as including at least one type: pending execution, in execution, successful, and failed, providing a clear basis for distinguishing the status of vehicles in remote batch management. After displaying the execution status of multiple vehicles after marking, the target vehicles with the execution status of pending execution or failed can be directly and accurately identified without the need for management personnel to check each vehicle one by one, avoiding the omission of abnormal vehicles. Subsequently, by obtaining the retransmission status of these target vehicles (such as whether retransmission was initiated, whether retransmission was successful, etc.), the execution status of the target vehicles is dynamically updated, making the execution status marking more flexible, saving the repetitive operation of manually following up on target vehicles, and further improving the accuracy and efficiency of remote batch management of vehicles.

[0064] Specifically, when powered by backup battery, if the 4G signal is restored, the TBOX will automatically retransmit feedback (up to 3 times); the cloud will mark "execution failed / pending confirmation" based on historical heartbeat records and retransmission status.

[0065] In this embodiment of the application, the multiple communication paths include a first communication path and a second communication path. The first communication path is used for communication between the battery management system and the vehicle communication terminal before the power-off operation, and the second communication path is used for communication between the battery management system and the vehicle communication terminal after the power-off operation.

[0066] It is understood that in this embodiment, the first communication path is specifically used for communication between the battery management system and the vehicle communication terminal before the power outage operation, while the second communication path is specifically used for communication after the power outage operation, ensuring that the battery management system performs feedback of results after the power outage. By splitting the communication path into stages, the interruption of the feedback link due to the failure of a single path caused by the power outage operation (such as the impact of changes in the power supply of some vehicle modules on path stability after the power outage) is avoided, ensuring that the power outage results can be stably transmitted to the vehicle communication terminal, laying a solid foundation for subsequent result feedback to the server; it can also match the communication needs of different stages according to the differences in communication needs before and after the power outage (such as focusing on command issuance efficiency before the power outage and focusing on result transmission accuracy after the power outage), reducing mutual interference between communication tasks at different stages, further improving the reliability of the overall communication link, and providing support for closed-loop management of remote batch management.

[0067] Specifically, the first communication path is LBMS→CAN→TBOX (normal communication); the second communication path is LBMS→GPIO hardwire signal→TBOX (backup after power failure).

[0068] In this embodiment, the vehicle communication terminal identifies the power-off time in the power-off command, wakes up the battery management system after the power-off time is reached, and sends a power-off command to the battery management system. The battery management system executes the power-off command after a delay, and triggers the vehicle to power down after disconnecting the transistor according to the power-off command. The backup power supply of the vehicle communication terminal supplies power to the vehicle communication terminal before the vehicle is powered down. After the vehicle communication terminal reports the power-off result, it enters a low-power mode.

[0069] It is understood that in the process of remotely powering off the vehicle in this embodiment, the vehicle communication terminal first identifies the preset power-off time in the power-off command. After the time is reached, it wakes up the battery management system and sends a power-off command. After receiving the command, the battery management system does not operate immediately, but reserves a buffer time by delaying execution. Then, it disconnects the transistor according to the command to trigger the vehicle to power down. At the same time, the backup power supply of the vehicle communication terminal will continue to supply power to the vehicle before the vehicle is powered down, ensuring that the power-off result can be completely fed back to the server. After the feedback is completed, the vehicle communication terminal automatically switches to low-power mode. By waking up and executing according to the preset time, the precise control of the power-off timing is achieved, which is suitable for the needs of planned batch power-off in warehousing scenarios. Furthermore, the delayed operation of the battery management system avoids the impact of sudden power-off on key vehicle modules (such as data storage modules), reducing the risk of data loss or hardware damage. The backup power supply also ensures the integrity of the power-off result feedback, while the low-power mode reduces the ineffective energy consumption of the backup power supply, extends its service life, and reserves power support for possible emergency communication or command reception in the future.

[0070] Specifically, the timed wake-up and command triggering process is as follows: The TBOX wakes up when the execute_time arrives via its built-in RTC (Real-Time Clock); it sends a pre-power-off command (including the command ID) to the LBMS via the CAN bus. The LBMS delayed power-off control process is as follows: Upon receiving the command, real-time detection of the loop current is immediately initiated (if the current is greater than 100A and the duration is greater than or equal to 10ms, short-circuit protection will be triggered directly, and the MOSFET will be disconnected without waiting for subsequent delays); at the same time, a delay_off_time (default 5000ms) is initiated. This delay is designed to reserve feedback time to ensure that the vehicle status before power-off can be fully transmitted back to the vehicle communication terminal; during the delay, after the LBMS confirms the validity of the command, it caches the real-time status of the battery (including key parameters such as voltage, SOC, and health); if short-circuit protection is not triggered during the delay, the MOSFET will be disconnected normally after the delay is reached, and the mechanical relay will be triggered to disconnect synchronously, thus balancing the timing rationality of the power-off operation and circuit safety.

[0071] The vehicle remote batch management method proposed in this application is based on a communication architecture between a server and multiple vehicles. It utilizes a battery management system with multiple communication paths and an on-board communication terminal with backup power in the vehicle. The complete process involves obtaining multiple vehicle identifiers and power outage times, generating batch management instructions, issuing instructions and triggering power outage operations, and receiving feedback results through multiple paths and backup power to ensure data transmission. This method solves the problems of low efficiency in manual single-vehicle power outages in related technologies, enabling remote batch management of multiple vehicles. It also solves the open-loop problem in related technologies where the on-board module loses power after a power outage, resulting in no feedback. Furthermore, the design of multiple communication paths and backup power enhances stability and reliability, ultimately meeting the needs for efficient and controllable remote power outage management of vehicle batteries in scenarios such as vehicle warehousing and 4S store storage.

[0072] The following will be based on Figure 1 The structure shown illustrates another embodiment of the vehicle remote batch management method provided in this application. This method is applied to the vehicle's in-vehicle communication terminal, such as... Figure 3 As shown, it includes the following steps:

[0073] In step S301, a batch management instruction issued by the server is obtained. The batch management instruction is generated by the server based on the power-off instructions of multiple vehicles. The power-off instruction is generated based on the vehicle identifier and the power-off time.

[0074] Understandably, in this embodiment, the server first generates a single-vehicle power-off command based on the vehicle identifier and power-off time, and then aggregates them into a batch management command. The vehicle-mounted communication terminal directly obtains this batch command containing information about multiple vehicles, without the server needing to issue it to each vehicle individually. This reduces the communication frequency between the vehicle-mounted communication terminal and the server, lowers network resource consumption, and is adaptable to large-scale management scenarios such as fleets and warehouses with thousands of vehicles, meeting the remote control needs of vehicle clusters. At the same time, the batch command synchronously carries core information such as the identifier and power-off time of each vehicle, providing a direct basis for the vehicle-mounted communication terminal to accurately parse its corresponding power-off task, ensuring the accuracy of command execution.

[0075] In step S302, the batch management instruction is parsed, the power-off instruction for the corresponding vehicle is determined according to the vehicle identifier, the power-off time is identified from the power-off instruction, and the battery management system is woken up after the power-off time is reached.

[0076] It is understood that the embodiments of this application transform batch management instructions into specific tasks that can be executed by a single vehicle: the vehicle communication terminal first parses the batch instructions, and then accurately locks its own corresponding power-off instruction through the vehicle identifier to avoid confusion with instructions from other vehicles and ensure that the operation target is not deviated; at the same time, it identifies the exclusive power-off time from the power-off instruction, and wakes up the battery management system after the time is reached. This not only avoids the battery management system from consuming power by sitting idle for a long time, but also ensures that the power-off operation is accurately started at the preset time, laying a clear time and operation foundation for the subsequent execution of power-off actions by the battery management system.

[0077] In step S303, a power-off command is sent to the battery management system. The battery management system performs a power-off operation according to the power-off command and feeds back the power-off result to the vehicle communication terminal through the communication path. The vehicle communication terminal is powered by the backup power supply and feeds back the power-off result to the server.

[0078] Understandably, the vehicle communication terminal sends the matched power-off command to the battery management system, providing the battery management system with a clear basis for execution and ensuring that the power-off operation is accurately implemented. At the same time, after the battery management system executes the power-off, it feeds back the result through the second communication path. The vehicle communication terminal relies on the backup power supply to maintain power supply, so even if the whole vehicle is powered off, it can still transmit the power-off result back to the server, solving the problem of not being able to feed back the status after the power-off. This not only ensures that the server can monitor the execution result of each vehicle in real time, but also makes the remote batch management process a closed loop.

[0079] Specifically, such as Figure 4As shown, from the perspective of the collaborative logic of the dual communication paths: before the power-off operation, the first communication path (LBMS→CAN bus→TBOX) is responsible for issuing commands. The core processor of TBOX transmits the power-off command to the control logic of the battery management system through the CAN bus. The control logic drives the discharge MOS control circuit accordingly. At this time, the CAN bus, with its "high bandwidth and high efficiency" characteristics, ensures the smooth transmission of the power-off command from the vehicle terminal to the battery management system. After the power-off operation, the second communication path (LBMS GPIO output pin→GPIO hardwire→TBOX core processor) is responsible for result feedback. Since the main circuit of the vehicle is powered off, the CAN bus may be affected by power supply fluctuations. When the stability of the battery management system decreases, it sends a level signal through the GPIO hardwire, allowing the core processor of the TBOX to stably capture the power failure result. The connection process between the backup power switching and feedback upload is as follows: 1 second before the MOSFET is disconnected, the TBOX switches to the built-in battery (backup power supply) for power. Then, the core processor uploads the power failure feedback result obtained through the second communication path to the cloud server via the 4G / 5G communication module. After the feedback is completed, the TBOX enters a low-power mode (power consumption < 0.1W), which reduces the power consumption of the backup power supply and reserves energy for subsequent wake-up or communication, ultimately achieving a balance between reliable power failure result transmission and efficient energy utilization.

[0080] According to the vehicle remote batch management method proposed in this application, the vehicle's on-board communication terminal acts as the execution subject, cooperating with the server and battery management system to form a complete process from receiving instructions, executing operations to feedback results: The on-board communication terminal first obtains the batch management instructions issued by the server (these instructions are generated by the server based on the identification of multiple vehicles and the power-off time), then parses the batch instructions, determines the corresponding power-off instructions by matching its own vehicle identification, and extracts the power-off time from the instructions; after the time reaches a preset value, the terminal wakes up the battery management system in standby mode and sends the power-off instructions to the battery management system to trigger the power-off operation; after the battery management system executes the power-off, it feeds back the power-off result to the terminal through the communication path between the two, while the terminal relies on the backup power supply to maintain power supply, ensuring that the power-off result can be stably transmitted back to the server. By parsing instructions and matching identifiers, the system ensures that each vehicle only executes its corresponding power-off task, avoiding the problem of multiple vehicles executing incorrectly or out of order under batch instructions. This provides orderly support for batch management of the server and is suitable for standardized vehicle management in warehousing scenarios. Furthermore, by leveraging backup power and communication paths, the system solves the problem of terminal power loss and inability to provide feedback after vehicle power failure. At the same time, the system periodically wakes up the battery management system to avoid continuous standby power consumption of the terminal and battery management system, reducing data processing redundancy. This ensures accurate execution while reducing energy consumption and extending the lifespan of the backup power supply.

[0081] The workflow of a vehicle remote batch control system will be described below through a specific embodiment, such as... Figure 5 As shown, this application constructs a closed-loop workflow of instruction generation, instruction issuance, instruction execution, power-off operation, result feedback, and status marking through the collaboration of hardware modules (MOSFETs of the LBMS and backup batteries of the TBOX) and software logic (dual-path feedback and offline caching), as detailed below:

[0082] Command generation stage: The cloud imports the vehicle VIN code via Excel, encrypts the command and assigns a unique ID, giving each vehicle's power-off command a precise identifier;

[0083] Command issuance phase: After generating encrypted commands in the cloud, the commands are sent to the TBOX via MQTT (supporting online real-time reception, and cached in EEPROM if the vehicle is offline) to ensure that commands are not lost in offline scenarios;

[0084] Instruction execution phase: TBOX wakes up at the scheduled time via RTC clock and sends a pre-power-down instruction to LBMS;

[0085] Power-off operation phase: After LBMS verifies the validity of the instruction, it caches the battery status within delay_off_time. After the delay_off_time expires, it disconnects the MOSFET and mechanical relay to complete the power-off operation.

[0086] Result feedback phase: 1 second before power failure, TBOX switches to backup power supply, receives power failure confirmation signal from LBMS via CAN or GPIO (dual-path redundancy confirmation is used when successful, and the exception type is classified and marked when failing), uploads the result to the cloud and then enters low power mode.

[0087] Status marking phase: The cloud updates the status in real time, displaying it visually in four states: "pending execution, executing, successful, and failed." Throughout the process, hardware modules (LBMS MOSFETs and TBOX backup batteries) and software logic (dual-path feedback and offline caching) work together to achieve closed-loop control from instruction generation to status visibility.

[0088] The workflow will be further elaborated below, combining two classic scenarios: export vehicle storage (1,000 vehicles, centrally parked, with good network signal) and 4S store scattered storage (20 vehicles, distributed in different areas, with some weak signals).

[0089] Taking a warehouse scenario as an example, a user imports the VIN codes of 1000 vehicles through a cloud platform and sets the planned power outage time to 00:00 the next day. After the command is issued, the TBOX wakes up at the planned time and triggers the LBMS to power down. The LBMS delays for 5 seconds to disconnect the MOSFET and simultaneously sends a high-level signal to the TBOX via the GPIO pin. The TBOX switches to the backup battery, uploads the successful power outage status to the cloud, and enters low-power mode after the feedback is completed. The cloud displays in real time that 998 vehicles succeeded and 2 failed due to communication timeout, allowing the user to handle the unsuccessful vehicles accordingly.

[0090] Taking a scenario of scattered storage at a 4S store as an example, a user imports VINs for 20 vehicles and sets the power-off time to 22:00 daily. For 5 vehicles, due to weak signal (4G strength < -100dBm), the TBOX caches the instructions in the EEPROM. At 22:00, the TBOX wakes up via RTC, sends instructions to the LBMS, and provides feedback via GPIO hardwired after the power-off (due to weak 4G signal and unstable CAN communication). Ultimately, 19 vehicles are successfully stored, while 1 vehicle fails due to short-circuit protection, and the cloud displays a fault code.

[0091] This application effectively solves the efficiency and reliability problems of mass power outages in vehicles through the collaborative design of hardware and software, and is applicable to scenarios such as vehicle warehousing, logistics and 4S store management.

[0092] In summary, this application has at least the following beneficial effects:

[0093] (1) This application can quickly and efficiently update the controller software program in batches through remote program upgrade method, and at the same time supports unified management and monitoring of the vehicle controller software version; on the other hand, it replaces manual operation, reduces the power outage time of a single vehicle from ≥5 minutes to automatic completion, and can handle batch operations of multiple vehicles at the same time, greatly shortening the processing time of a single vehicle and the batch operation cycle.

[0094] (2) This application uses a backup power supply and dual-path communication (GPIO hardware direct connection, CAN bus) to form a closed-loop feedback mechanism to solve the problem that the status cannot be reported after the battery is powered off, realize the real-time confirmation of the power off status, and avoid the situation where the user cannot know the success or failure of the vehicle power off in the open-loop scenario; it has active fault tolerance and protection capabilities for abnormal scenarios such as communication interruption and short circuit, which can effectively prevent the vehicle from being damaged due to abnormal operation and improve the reliability of system operation.

[0095] (3) This application supports batch issuance and status tracking of instructions for thousands of vehicles. The cloud platform can display the status of vehicle instruction execution (pending execution / in execution / success / failure) in real time, and further subdivide the failure types (such as communication timeout, MOS failure) to facilitate users to accurately control the progress of batch operations and handle exceptions.

[0096] (4) When the vehicle is without network, TBOX can cache instructions locally through EEPROM (which supports 100 queue management) and rely on RTC timed wake-up mechanism to ensure that the cached instructions can be executed on time at the preset time, thus solving the problem of instruction failure in offline scenarios.

[0097] (5) This application can reduce battery warranty and after-sales rescue costs by up to 30%, and reduce the maintenance costs of the vehicle throughout its entire life cycle.

[0098] Figure 6 A schematic diagram of the structure of a server provided in an embodiment of this application. The server may include:

[0099] The memory 601, the processor 602, and the computer program stored on the memory 601 and capable of running on the processor 602.

[0100] When the processor 602 executes the program, it implements the server remote batch management method provided in the above embodiments.

[0101] Furthermore, the server also includes:

[0102] Communication interface 603 is used for communication between memory 601 and processor 602.

[0103] The memory 601 is used to store computer programs that can run on the processor 602.

[0104] The memory 601 may include high-speed RAM (Random Access Memory) memory, and may also include non-volatile memory, such as at least one disk storage.

[0105] If the memory 601, processor 602, and communication interface 603 are implemented independently, then the communication interface 603, memory 601, and processor 602 can be interconnected via a bus to complete communication between them. The bus can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 6 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0106] Optionally, in a specific implementation, if the memory 601, processor 602, and communication interface 603 are integrated on a single chip, then the memory 601, processor 602, and communication interface 603 can communicate with each other through an internal interface.

[0107] The processor 602 may be a CPU (Central Processing Unit), an ASIC (Application Specific Integrated Circuit), or one or more integrated circuits configured to implement the embodiments of this application.

[0108] Figure 7 A schematic diagram of the structure of a vehicle provided in an embodiment of this application. The vehicle may include:

[0109] The memory 701, the processor 702, and the computer program stored on the memory 701 and executable on the processor 702.

[0110] When the processor 702 executes the program, it implements the vehicle remote batch management method provided in the above embodiments.

[0111] Furthermore, the vehicle also includes:

[0112] Communication interface 703 is used for communication between memory 701 and processor 702.

[0113] The memory 701 is used to store computer programs that can run on the processor 702.

[0114] The memory 701 may include high-speed RAM (Random Access Memory) memory, and may also include non-volatile memory, such as at least one disk storage.

[0115] If the memory 701, processor 702, and communication interface 703 are implemented independently, then the communication interface 703, memory 701, and processor 702 can be interconnected via a bus to complete communication between them. The bus can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 7 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0116] Optionally, in a specific implementation, if the memory 701, processor 702, and communication interface 703 are integrated on a single chip, then the memory 701, processor 702, and communication interface 703 can communicate with each other through an internal interface.

[0117] The processor 702 may be a CPU (Central Processing Unit), an ASIC (Application Specific Integrated Circuit), or one or more integrated circuits configured to implement the embodiments of this application.

[0118] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0119] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0120] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or N executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0121] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any of the following techniques known in the art, or a combination thereof: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (FPGAs), field-programmable gate arrays (FPGAs), etc.

[0122] Those skilled in the art will understand that all or part of the steps of the methods implementing the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0123] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. A vehicle remote bulk management method, characterized by, The method is applied to a server that communicates with multiple vehicles. Each vehicle includes a battery management system and an in-vehicle communication terminal. Multiple communication paths are established between the battery management system and the in-vehicle communication terminal. The in-vehicle communication terminal is equipped with a backup power supply. The method includes the following steps: Obtain the vehicle identification number of multiple vehicles and the power outage time of each vehicle; A power-off command is generated for each vehicle based on the vehicle identifier and the power-off time, and a batch management command for the multiple vehicles is generated based on the power-off command for each vehicle. The batch management command is sent to the vehicle communication terminals of multiple vehicles. The vehicle communication terminals parse the batch management command and determine the power-off command for the corresponding vehicle based on the vehicle identifier. The battery management system executes the power-off operation according to the power-off command and feeds back the power-off result to the vehicle communication terminals through the communication path. The vehicle communication terminals are powered by the backup power supply and feed back the power-off result to the server.

2. The vehicle remote bulk management method according to claim 1, characterized by, After issuing the batch management instructions to the vehicle communication terminals of multiple vehicles, the method further includes: Obtain feedback data from the multiple vehicles; The execution status of the multiple vehicles is marked based on the feedback data; The execution status of the multiple vehicles is displayed after the marker is displayed.

3. The vehicle remote bulk management method according to claim 2, characterized by, The step of marking the execution status of the plurality of vehicles based on the feedback data includes: Identify the power outage result in the feedback data; The execution status of the plurality of vehicles is marked according to the power outage result; If no feedback data is received from the vehicle within a preset time period, the execution status of the multiple vehicles is marked according to the historical heartbeat signal of the corresponding vehicle.

4. The vehicle remote bulk management method according to claim 2, characterized by, The execution status includes at least one of a pending execution status, an execution in progress status, a success status, and a failure status. After displaying the execution status of the plurality of vehicles with the marker, it also includes: Identify target vehicles whose execution status is either pending or failed. Obtain the retransmission status of the target vehicle, and update the execution status of the target vehicle based on the retransmission status.

5. The vehicle remote bulk management method according to claim 1, characterized by, The multiple communication paths include a first communication path and a second communication path. The first communication path is used for communication between the battery management system and the vehicle communication terminal before the power-off operation, and the second communication path is used for communication between the battery management system and the vehicle communication terminal after the power-off operation.

6. The vehicle remote bulk management method according to claim 1, characterized by, The vehicle communication terminal identifies the power-off time in the power-off command, wakes up the battery management system after the power-off time is reached, and sends the power-off command to the battery management system. The battery management system executes the power-off command after a delay, and triggers the vehicle to power down after disconnecting the transistor according to the power-off command. The backup power supply of the vehicle communication terminal supplies power to the vehicle communication terminal before the vehicle is powered down. After the vehicle communication terminal reports the power-off result, it enters a low-power mode.

7. The vehicle remote bulk management method according to claim 1, characterized by, Before issuing the batch management instructions to the vehicle communication terminals of multiple vehicles, the method further includes: Obtain the battery health status of the backup power supply of the vehicle communication terminal; The backup power supply of the vehicle communication terminal is monitored and warned based on the battery health status.

8. A vehicle remote bulk management method characterized by, The vehicle includes a battery management system and an on-board communication terminal. Multiple communication paths are established between the battery management system and the on-board communication terminal. The on-board communication terminal is equipped with a backup power supply and communicates with a server. The method is applied to the on-board communication terminal of the vehicle, and the method includes the following steps: Obtain the batch management instruction issued by the server, which is generated by the server based on the power-off instructions of multiple vehicles, and the power-off instructions are generated based on the vehicle identifier and the power-off time; The batch management command is parsed, the power-off command for the corresponding vehicle is determined based on the vehicle identifier, the power-off time is identified from the power-off command, and the battery management system is woken up after the power-off time is reached. The power-off command is sent to the battery management system, which performs a power-off operation according to the command and feeds back the power-off result to the vehicle communication terminal through the communication path. The vehicle communication terminal is powered by the backup power supply and feeds back the power-off result to the server.

9. A server, characterized by include: A memory, a processor, and a computer program stored in the memory and executable on the processor, the processor executing the program to implement the vehicle remote batch management method according to any one of claims 1-7.

10. A vehicle characterized by comprising: include: The system includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the vehicle remote batch management method of claim 8.

Images