Vehicle ota control system, processing method, vehicle, medium, and program

Abstract

This application relates to the field of vehicle technology, and particularly to a vehicle OTA control system, processing method, vehicle, medium, and program. The system includes: a first communication link and a second communication link disposed between an onboard communication module and a vehicle controller; the vehicle controller receives a remote flashing request command transmitted from the cloud via the onboard communication module through the first communication link; after meeting preset conditions, it broadcasts a command to enter flashing mode or exit flashing mode to at least one target controller according to the remote flashing request command; after at least one target controller enters flashing mode, the vehicle controller and the onboard communication module are configured to communicate via the second communication link. This solves the problem in related technologies where, when flashing the onboard communication module itself or when the vehicle experiences a network failure, the vehicle remains in a flashing state, causing the vehicle to malfunction and potentially leading to battery depletion.

Description

Technical Field

[0001] This application relates to the field of vehicle technology, and in particular to a vehicle OTA control system, processing method, vehicle, medium and program. Background Technology

[0002] With the development of advanced driver assistance systems (ADAS) and the introduction of autonomous driving, cars are becoming increasingly intelligent. These intelligent vehicles are equipped with massive amounts of software programs, and updating these programs at dealerships is a cumbersome task in the traditional way. To address the convenience and cost reduction of software upgrades, OTA (Over-The-Air) software updates, originally only available on mobile devices, have been introduced into vehicles. OTA allows customers to receive the latest software version promptly without visiting a dealership, thus reducing the time and cost associated with updating software at a dealership.

[0003] OTA (Over-The-Air) is a technology that remotely manages the firmware, data, and applications on automotive components via mobile communication networks (4G / 5G or Wi-Fi). However, while OTA offers advantages such as convenience, time-saving, and labor-saving, it also has drawbacks. Issues such as network communication failures and software bugs can cause the software upgrade process to stall, leading to upgrade failures, and even causing the battery to drain due to the vehicle's inability to enter sleep mode.

[0004] In related technologies, during vehicle OTA upgrades, to ensure the reliability of the flashing process, it is often necessary to stop sending CAN bus application messages. This leads to the interruption of communication between the master control node (such as TBOX (Telematics Box, vehicle communication module)) and VCU (Vehicle Control Unit, vehicle controller), making it impossible to monitor the vehicle status in real time. Once the upgrade process is stuck due to network failure, software defects, or TBOX failure, the vehicle will not be able to exit the flashing mode normally and will continue to consume power, which can easily cause the small battery to run out of power, making the vehicle unable to power on and drive normally, posing serious safety and reliability risks. Summary of the Invention

[0005] This application provides a vehicle OTA control system, processing method, vehicle, medium, and program to solve the problems in related technologies where the vehicle will be in a continuous flashing state when the vehicle communication module itself is being flashed or the vehicle experiences a network failure, resulting in the vehicle being unable to drive normally and causing battery depletion.

[0006] A first aspect of this application provides a vehicle OTA control system, including: an in-vehicle communication module and a vehicle controller; a first communication link and a second communication link disposed between the in-vehicle communication module and the vehicle controller; wherein, the vehicle controller receives a remote flashing request command transmitted from the OTA cloud via the in-vehicle communication module through the first communication link, and after meeting preset conditions, sends a command to enter flashing mode or exit flashing mode to at least one target controller in a broadcast manner according to the remote flashing request command; after the at least one target controller enters flashing mode, the vehicle controller and the in-vehicle communication module are configured to communicate through the second communication link, wherein the vehicle controller monitors whether it receives a message from the in-vehicle communication module through the second communication link within a preset time period; if no message is received within the preset time period, it autonomously controls the at least one target controller to exit flashing mode and triggers a vehicle reset operation.

[0007] Optionally, it further includes: a battery management system, a drive motor controller, and a DC-DC converter controller, wherein the battery management system is configured to enter a low-power static mode in response to an instruction from the vehicle controller to enter the flashing mode, and continuously send battery power data to the vehicle controller via the first communication link; the drive motor controller is configured to lock the output torque of the drive motor to a first preset threshold in response to an instruction from the vehicle controller to enter the flashing mode, and cooperate in locking the vehicle gear in the first gear; the DC-DC converter controller is configured to cut off the power supply to at least one load in response to an instruction from the vehicle controller to enter the flashing mode, and ensure the power supply to the on-board communication module, the vehicle controller, and at least one target controller.

[0008] Optionally, the vehicle controller further includes: forwarding battery power data received from the battery management system to the vehicle communication module via the second communication link; if the battery power data is lower than a second preset threshold, controlling the system to exit the OTA flashing state.

[0009] A second aspect of this application provides a processing method for a vehicle OTA control system. The method is applied to a vehicle and implemented using the aforementioned vehicle OTA control system. The method includes the following steps: obtaining a remote flashing request sent from the OTA cloud; the vehicle communication module sending a remote flashing request instruction to the vehicle controller via a first communication link; the vehicle controller responding to the remote flashing request instruction, after determining that the vehicle status meets preset conditions, feeding back a flashing permission flag via the first communication link; upon receiving the flashing permission flag, the vehicle communication module sending an OTA mode activation signal to the vehicle controller via a second communication link; the vehicle controller responding to the OTA mode activation signal, controlling at least one target controller to enter a flashing preparation state via the first communication link; and maintaining communication between the vehicle communication module and the vehicle controller via the second communication link during the flashing process.

[0010] Optionally, it further includes: the vehicle controller monitoring whether it receives a message from the vehicle communication module through the second communication link within a preset time period; if no message is received within the preset time period, the vehicle controller controls the at least one target controller to exit the flashing preparation state through the first communication link and triggers a vehicle reset operation.

[0011] Optionally, controlling at least one target controller to enter the flashing preparation state via the first communication link includes: the vehicle controller broadcasting a remote flashing mode signal for the entire vehicle via the first communication link; the battery management system responding to the remote flashing mode signal entering a low-power static mode and continuously monitoring the battery charge; the drive motor controller responding to the remote flashing mode signal locking the output torque of the drive motor to a first preset threshold and cooperating to lock the vehicle gear in the first gear; and the DC-DC converter controller responding to the remote flashing mode signal cutting off the power supply to at least one load and ensuring the power supply to the vehicle communication module, the vehicle controller, and at least one target controller.

[0012] Optionally, it further includes: the battery management system continuously sends battery power data to the vehicle controller through the first communication link, and the vehicle controller forwards the power data to the vehicle communication module through the second communication link; if the vehicle communication module or the vehicle controller determines that the power data is lower than a preset threshold, it initiates a termination command through the second communication link or the first communication link, autonomously controls the at least one target controller to exit the OTA flashing state, and triggers a vehicle reset operation.

[0013] A third 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, wherein the processor executes the program to perform the processing method of the vehicle OTA control system as described in the above embodiments.

[0014] A fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which is executed by a processor to perform the processing method of the vehicle OTA control system as described in the above embodiments.

[0015] A fifth aspect of this application provides a computer program product, including a computer program or instructions, which, when executed, implement the processing method of the vehicle OTA control system as described in the above embodiments.

[0016] Therefore, this application has at least the following beneficial effects: In this embodiment, the first communication link is responsible for transmitting flashing commands and verifying the vehicle status, ensuring that the flashing process is only initiated when the vehicle is in a safe state. The second communication link maintains reliable communication between key controllers during the flashing process, enabling real-time monitoring of the flashing status. When the loss of messages from the vehicle communication module exceeds a preset time, the vehicle controller autonomously triggers a forced exit mechanism, controlling each controller to safely exit the flashing mode and performing a vehicle reset. This effectively prevents process blockage, system hang-up, and battery depletion caused by communication interruption or module failure, significantly improving the reliability, security, and robustness of OTA updates. Therefore, by establishing dual redundant communication links between the vehicle communication module and the vehicle controller, safe and controllable entry and redundant fault-tolerant exit of the OTA flashing process are achieved.

[0017] 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

[0018] 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: Figure 1 This is a block diagram of a vehicle OTA control system according to an embodiment of this application; Figure 2 This is a schematic diagram of a vehicle OTA control system provided according to an embodiment of this application; Figure 3 This is a flowchart of a vehicle OTA control system processing method provided according to an embodiment of this application; Figure 4 This is a schematic diagram of the OTA access process provided in the embodiments of this application; Figure 5 This is a schematic diagram of the OTA exit process provided according to an embodiment of this application; Figure 6 This is a structural schematic diagram of a vehicle provided according to an embodiment of this application. Detailed Implementation

[0019] 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.

[0020] The vehicle OTA control system, processing method, vehicle, medium, and program according to embodiments of this application are described below with reference to the accompanying drawings.

[0021] Specifically, Figure 1 This is a block diagram of a vehicle OTA control system according to an embodiment of this application.

[0022] like Figure 1 As shown, the vehicle OTA control system 10 includes: an on-board communication module 100, a vehicle controller 200, a first communication link 300, and a second communication link 400.

[0023] The first communication link 300 and the second communication link 400 are configured between the vehicle communication module 100 and the vehicle controller 200. The vehicle controller 200 receives remote flashing request instructions transmitted from the vehicle communication module 100 via the first communication link 300. After meeting preset conditions, the vehicle controller 200 broadcasts instructions to at least one target controller to enter or exit the flashing mode. After at least one target controller enters the flashing mode, the vehicle controller 200 and the vehicle communication module 100 are configured to communicate via the second communication link 400. The vehicle controller 200 monitors whether it receives any messages from the vehicle communication module 100 via the second communication link 400 within a preset time period. If no messages are received within the preset time period, the vehicle controller 200 autonomously controls at least one target controller to exit the flashing mode and triggers a vehicle reset operation.

[0024] The preset duration can be set according to actual needs without specific limitations.

[0025] It is understood that the first communication link in this application embodiment undertakes the functions of transmitting flashing instructions and verifying the vehicle status safety, ensuring that the start of the flashing process strictly depends on the vehicle's safety status (such as vehicle speed, battery level, fault status, etc.). The second communication link maintains a real-time monitoring channel between the on-board communication module and the vehicle controller during the flashing process, overcoming the communication interruption problem caused by CAN bus silence. When the vehicle controller detects that the on-board communication module message on the second communication link has been lost for a timeout, it automatically triggers the redundancy control mechanism, forcing each controller to exit the flashing mode and perform a vehicle reset, thereby effectively avoiding the risks of process blocking, system suspension, and battery depletion caused by communication abnormalities, T-Box failures, or network timeouts, and significantly improving the robustness of the OTA system and the overall vehicle safety level.

[0026] It should be noted that the first communication link can be a CAN bus, used to transmit high-priority real-time control signals and status feedback, such as "remote flash request commands" and "flash enable flags." CAN offers high robustness, low latency, and broad compatibility, making it suitable for transmitting critical control commands related to functional safety and supporting reliable communication in complex electromagnetic environments. The second communication link can be an automotive Ethernet network, used to transmit high-bandwidth OTA mode activation signals or subsequent firmware data streams. Ethernet provides higher data transmission rates (100 Mbps and above), supports service-oriented architecture (SOA), and IP-based communication, meeting the needs of large-capacity firmware package transmission and rapid mode switching. It also creates physical and protocol layer redundancy with CAN, improving the overall system availability and fault tolerance.

[0027] In the embodiments of this application, such as Figure 2 As shown, it also includes: a battery management system, a drive motor controller, and a DC-DC converter controller.

[0028] The battery management system is used to respond to the command to enter the flashing mode issued by the vehicle controller, enter a low-power static mode, and continuously send battery power data to the vehicle controller through the first communication link; the drive motor controller is used to respond to the command to enter the flashing mode issued by the vehicle controller, lock the output torque of the drive motor to a first preset threshold, and cooperate in locking the vehicle gear to the first gear; the DC-DC converter controller is used to respond to the command to enter the flashing mode issued by the vehicle controller, cut off the power supply to at least one load, and ensure the power supply of the on-board communication module, the vehicle controller and at least one target controller.

[0029] The first preset threshold can be set according to actual needs without specific limitations.

[0030] It is understood that the embodiments of this application can achieve system-level protection for vehicle energy safety, power safety, and power supply safety through the coordinated control of the battery management system, drive motor controller, and DC-DC converter in OTA flashing mode. The battery management system enters a low-power static mode and continuously feeds back battery power data, providing real-time energy status monitoring for the vehicle controller and preventing system abnormalities due to battery depletion during the flashing process. The drive motor controller locks the drive torque to zero and coordinates with fixed gears to completely eliminate the risk of accidental vehicle movement, ensuring static safety during the flashing process. The DC-DC converter performs intelligent power supply reconfiguration, cutting off power to unnecessary loads to reduce overall power consumption, while ensuring continuous power supply to key controllers, improving system reliability from the energy distribution level. The three work together to form a multi-level safety protection mechanism, significantly reducing energy and operational risks during the OTA process and comprehensively improving the stability of the flashing process and vehicle safety.

[0031] In this embodiment, the vehicle controller 200 further includes: forwarding battery power data received from the battery management system to the vehicle communication module 100 via the second communication link 400; if the battery power data is lower than a second preset threshold, the control system exits the OTA flashing state.

[0032] The second preset threshold can be set according to actual needs without specific limitations.

[0033] Understandably, in this embodiment, the vehicle controller forwards the battery power data reported by the battery management system to the vehicle communication module in real time via a highly reliable second link, forming a cloud-aware energy status monitoring channel. Simultaneously, the vehicle controller incorporates dynamic threshold judgment logic. When the battery power is detected to be below a second preset threshold, it immediately and autonomously triggers a system-level protection mechanism, controlling the vehicle to safely exit the OTA (Over-The-Air) flashing state. This design constructs a dual local and cloud-based power monitoring system, effectively avoiding the risk of deep battery depletion caused by excessive flashing time, abnormal power consumption control, or initial power assessment deviations. It achieves full-cycle safety protection for the OTA process from an energy perspective, significantly improving the precision and reliability of system management.

[0034] Specifically, according to the OTA functional design flow, the TBOX is the master control node for OTA, and the VCU is the guide node for the entire vehicle's OTA process, guiding other controllers to enter or exit the OTA process. The TBOX and VCU need to maintain real-time communication for transmitting flashing commands and providing status feedback. However, during vehicle software upgrades, to eliminate interference on the CAN bus, all controllers must stop sending messages according to specifications, thus cutting off communication between the TBOX and VCU. To solve this problem, an Ethernet channel is added between the TBOX and VCU for controlling the OTA flashing process and transmitting program packages. During OTA upgrades, CAN messages are stopped, but Ethernet communication remains normal. The system design is shown in Table 1 below, where Table 1 is the signal list.

[0035] Table 1 Signal List

[0036] According to the vehicle OTA control system proposed in this application, the first communication link undertakes the functions of transmitting flashing instructions and verifying the vehicle status safety, ensuring that the start of the flashing process strictly depends on the vehicle's safety status (such as vehicle speed, battery level, fault status, etc.). The second communication link maintains a real-time monitoring channel between the on-board communication module and the vehicle controller during the flashing process, overcoming the communication interruption problem caused by CAN bus silence. When the vehicle controller detects that the on-board communication module message on the second communication link has been lost for a timeout, it automatically triggers the redundancy control mechanism, forcing each controller to exit the flashing mode and perform a vehicle reset. This effectively avoids the risks of process blocking, system hang-up, and battery depletion caused by communication abnormalities, T-Box failures, or network timeouts, significantly improving the robustness of the OTA system and the overall vehicle safety level.

[0037] Figure 3 This is a flowchart illustrating a processing method for a vehicle OTA control system provided in an embodiment of this application.

[0038] like Figure 3 As shown, the processing method of this vehicle OTA control system includes the following steps: In step S101, a remote flashing request issued by the OTA cloud is obtained. It is understood that the embodiments of this application can obtain remote flashing requests issued by the OTA cloud in order to subsequently control the vehicle to perform flashing actions.

[0039] In step S102, the vehicle communication module sends a remote flashing request command to the vehicle controller through the first communication link. In response to the remote flashing request command, the vehicle controller, after determining that the vehicle status meets the preset conditions, sends back a flashing permission flag through the first communication link. The preset conditions are: the vehicle is in park (P gear), the braking system is activated (valid braking signal), the vehicle's high-voltage system is powered off, the low-voltage battery voltage is within the normal range (e.g., the 12V system voltage is between 11V and 14.5V), there are no other critical ECU flashing tasks in progress, the ambient temperature is within the controller's safe operating range, and all target flashing nodes (such as BMS, MCU, DCDC, etc.) have completed their ready self-checks and reported their ready status.

[0040] It is understood that the embodiments of this application can introduce multi-dimensional vehicle status criteria as preset access conditions in the OTA entry process, thereby realizing security constraints and risk prevention and control for remote flashing operations. The vehicle controller performs comprehensive arbitration based on the vehicle dynamic status, power system health and the readiness status of peripheral controllers, and authorizes flashing only under static conditions that meet functional safety requirements. This effectively avoids the risks of flashing failure, controller lock-up or high-voltage system abnormality caused by erroneous OTA start-up under unsafe conditions (such as driving, power failure or controller busy), and significantly improves the reliability and robustness of remote firmware upgrades.

[0041] In step S103, after receiving the write permission flag, the vehicle communication module sends an OTA mode activation signal to the vehicle controller through the second communication link. It is understood that, in this embodiment of the application, after the vehicle communication module receives the write permission flag fed back by the vehicle controller through the first communication link, it sends an OTA mode activation signal through the second communication link. This achieves redundant transmission of control commands and physical isolation of communication paths. By using a dual-channel communication mechanism to cross-verify and transmit key control signals through separate channels, the communication reliability and fault tolerance during the OTA mode switching process are enhanced. Even if one communication link fails or is interfered with, the system can still complete the mode activation through the other link, avoiding the interruption of the upgrade process or falling into an uncertain state due to a single point of communication failure. This improves the stability and security of the remote write process and meets the design requirements for redundant control of key operations in the vehicle functional safety architecture.

[0042] In this embodiment of the application, it further includes: the vehicle controller monitors whether it receives a message from the vehicle communication module through the second communication link within a preset time period; if no message is received within the preset time period, the vehicle controller controls at least one target controller to exit the flashing preparation state through the first communication link and triggers a vehicle reset operation.

[0043] It is understood that in this embodiment, the vehicle controller continuously monitors the real-time status of messages from the vehicle communication module after activating OTA mode, realizing dynamic diagnosis of the health status of the communication link and timeout failure protection. When no valid message is received through the second communication link (such as vehicle Ethernet) within a preset time period, it is determined that the TBOX or communication link has malfunctioned (such as a system crash or network interruption). The VCU immediately sends an instruction to exit the flashing preparation state to the target controllers such as BMS, MCU, and DCDC through the first communication link (such as CAN bus), and triggers the vehicle system reset operation. This effectively avoids the risk of continuous low-voltage battery power consumption or system unavailability caused by flashing process suspension due to main control module or high-bandwidth link failure, or the controller remaining in an abnormal working mode for a long time. Through the collaborative monitoring and fault response mechanism of heterogeneous communication channels, the autonomous recovery capability and functional safety of the OTA process are significantly improved, ensuring that the vehicle can quickly return to a safe operating state under abnormal conditions.

[0044] In step S104, the vehicle controller responds to the OTA mode activation signal and controls at least one target controller to enter the flashing preparation state through the first communication link; during the flashing process, the vehicle communication module and the vehicle controller maintain communication through the second communication link.

[0045] It is understood that, in this embodiment, after receiving the OTA mode activation signal transmitted via the second communication link (such as vehicle Ethernet), the vehicle controller responds and sends a control command to at least one target controller (such as BMS, MCU, DCDC, etc.) to enter the flashing preparation state via the first communication link (such as CAN bus). This realizes the phased and hierarchical orderly start of the flashing process, and uses the highly reliable CAN bus to complete the broadcasting and status synchronization of key safety-related instructions, ensuring that each target controller is fully prepared in terms of power management, communication scheduling, and function deactivation, avoiding flashing failure or data corruption due to inconsistent controller status. At the same time, in the subsequent flashing process, high-bandwidth, low-latency communication between the vehicle communication module and the vehicle controller is continuously maintained through the second communication link for transmitting firmware data packets, flashing progress feedback, and control command interaction. This fully leverages the advantages of Ethernet in large data transmission, improves flashing efficiency and real-time performance, meets the functional safety requirements for reliable instruction transmission, ensures the efficiency and stability of large-scale firmware upgrades, and enhances the robustness and scalability of the vehicle OTA system.

[0046] In this embodiment, controlling at least one target controller to enter a flashing preparation state via a first communication link includes: the vehicle controller broadcasting a remote flashing mode signal for the vehicle via the first communication link; the battery management system responding to the remote flashing mode signal entering a low-power static mode and continuously monitoring the battery charge; the drive motor controller responding to the remote flashing mode signal locking the output torque of the drive motor to a first preset threshold and cooperating to lock the vehicle gear in the first gear; and the DC-DC converter controller responding to the remote flashing mode signal cutting off the power supply to at least one load and ensuring the power supply to the vehicle communication module, the vehicle controller, and at least one target controller.

[0047] It is understood that in this embodiment, the battery management system (BMS) enters a low-power static mode after receiving the flashing mode signal, continuously monitors the battery power, effectively reduces unnecessary energy consumption, prevents excessive discharge of the low-voltage battery due to prolonged flashing, and ensures the power supply stability of the core control unit. The drive motor controller (MCU) forcibly locks the motor output torque to zero (first preset threshold) and, in coordination with the vehicle gear control system, locks the gear in parking or safety first gear, achieving active anti-rollover and mechanical safety isolation from the power output end, preventing safety hazards caused by mis-drive. The DC-DC converter (DCDC) responds to the flashing mode command, cuts off the power supply to non-critical loads (such as entertainment systems, air conditioning controllers, etc.), realizes power path reconstruction, prioritizes the continuous power supply to OTA core nodes such as TBOX, VCU and various target controllers, and improves the system's anti-interference capability and operational reliability in low-voltage environments.

[0048] In this embodiment, the system further includes: the battery management system continuously sends battery power data to the vehicle controller via a first communication link; the vehicle controller forwards the power data to the vehicle communication module via a second communication link; if the vehicle communication module or the vehicle controller determines that the power data is lower than a preset threshold, it initiates a termination command via the second communication link or the first communication link, autonomously controls at least one target controller to exit the OTA flashing state, and triggers a vehicle reset operation.

[0049] It is understood that, in this embodiment of the application, the battery management system (BMS) can continuously report battery power data to the vehicle controller (VCU) via a first communication link (such as a CAN bus), and the VCU can forward the data in real time to the vehicle communication module (TBOX) via a second communication link (such as an in-vehicle Ethernet), thus constructing a closed loop for power status monitoring with multi-node collaboration during the OTA process. This mechanism enables dynamic perception and remote visualization of the health status of the low-voltage power system, ensuring that both the TBOX and VCU can make autonomous decisions based on real-time power information. When any node (TBOX or VCU) determines that the battery voltage or remaining capacity is lower than a preset safety threshold, it can actively initiate an OTA termination command through a highly reliable first communication link or a high-bandwidth second communication link, triggering each target controller (such as BMS, MCU, DCDC, etc.) to exit the flashing preparation state, exit the OTA flashing state, and restore to the normal operating firmware. At the same time, a collaborative reset operation of the vehicle controller is performed, allowing the vehicle's electronic control system to safely return to the normal power supply and operation mode.

[0050] According to the processing method of the vehicle OTA control system proposed in the embodiments of this application, the security and reliability of OTA upgrades are significantly improved through the dual communication link coordination mechanism. After the vehicle communication module receives the cloud flashing request, it sends an instruction to the vehicle controller via the first communication link (such as CAN). The VCU performs safety judgment based on preset conditions such as vehicle parking status, power health, and high voltage power-off. It only feeds back an allow flag when the conditions are met to prevent accidental start under unsafe conditions. It sends an OTA mode activation signal through the second communication link (such as Ethernet) to achieve high bandwidth and low latency mode switching and improve response efficiency. Based on this, the VCU coordinates each target controller to enter the flashing preparation state through the first communication link, completes power blocking, load management and power supply guarantee, and ensures that the system is in a stable environment. During the flashing process, communication is continuously carried out through the second link to ensure the continuity and real-time performance of large-capacity data transmission. The heterogeneous network has a clear division of labor and the control flow and data flow are separated, which not only meets the functional safety requirements, but also improves the upgrade success rate and effectively prevents risks such as communication interruption and power abnormality, so as to realize the controllability, monitoring and recovery of the OTA process. The following will combine Figure 4-5 The processing method of the vehicle OTA control system of this application is described in detail, and the specific steps are as follows: OTA access process: Step 1: Create a software update task on the OTA remote management platform; Step 2: After receiving the task in the OTA cloud, the task is sent to TBOX; Step 3: The TBOX is woken up by the network, and at the same time, the TBOX sends a network management message to wake up other controllers on the vehicle. Step 4: TBOX sends a "remote flash request command = 1: request received" to VCU via CAN; Step 5: After receiving the "Remote flashing request command = 1: Request received", the VCU determines whether the vehicle conditions are met. Vehicle conditions mainly include vehicle speed, battery charge, vehicle malfunctions, and gear position, to ensure vehicle safety during flashing. If the vehicle conditions are met, the VCU will report "Vehicle flashing permission flag = 1: Flashing allowed"; otherwise, it will report "Vehicle flashing permission flag = 2: Flashing not allowed". Step 6: If the TBOX receives the "Vehicle flashing flag = 1: flashing allowed" feedback from the VCU, it sends "Remote start flag = 1: start flashing" to the VCU; otherwise, it jumps to step 4 and starts again (maximum 3 attempts). After the OTA remote management platform establishes the task through the above process and notifies the entire vehicle, and the vehicle environment is ready for OTA, the software update can begin. However, to improve the success rate of the software update and avoid interference from network messages, after step 6 is completed, the TBOX will send a diagnostic message requesting the controller to stop sending application messages. This disconnects the controllers, and if the vehicle environment does not meet the requirements, the TBOX will not be able to recognize it, potentially harming the vehicle. For example, if the battery is low on power, continuing the OTA will cause the battery to drain, resulting in OTA failure and the vehicle failing to power on due to low battery voltage. Therefore, to solve this problem, in addition to CAN communication, an Ethernet communication channel was designed between the TBOX and VCU. CAN communication is disabled during the OTA process, but Ethernet communication remains normal. This allows the TBOX and VCU to exchange information via Ethernet, ensuring real-time information exchange.

[0051] Step 7: After receiving the "Remote flash start flag = 1: Start flashing" sent by the VCU, the TBOX sends "OTA mode = 1: Flash mode" to the VCU via Ethernet. Step 8: After receiving "OTA mode=1: flashing mode" from TBOX, VCU sends "vehicle remote flashing mode power-on requirement=1: required" to controllers such as TBOX, BMS, MCU, and DCDC to guide the vehicle status.

[0052] At the same time, after the "Vehicle remote flashing mode power-on requirement = 1: there is a requirement" signal is received, the VCU module responsible for guiding the vehicle status needs to guide the vehicle status to the flashing state. In this state, the vehicle cannot be driven, the gear is locked in P gear, and the vehicle is in a safe state.

[0053] In addition, the "Power-on requirement for remote vehicle flashing mode" will also be sent to the TBOX via Ethernet to inform it of the current vehicle status. When the vehicle status does not meet the requirements, such as when the battery power is too low, the VCU will send "Power-on requirement for remote vehicle flashing mode = 0: initial value" to notify the TBOX. After receiving the notification, the TBOX will terminate the OTA process to prevent the battery from running out of power.

[0054] Step 10: The VCU must complete the flashing process within 10 seconds. If successful, the VCU will send a message to the TBOX via Ethernet saying "Vehicle flashing guide status = 1: Success". If the flashing process is not completed within 10 seconds, the VCU will send a message to the TBOX saying "Vehicle flashing guide status = 2: Failure". The TBOX will then terminate the OTA process after receiving the negative response.

[0055] OTA flashing process: After entering OTA mode, the entire vehicle will enter the flashing process, updating the software of each component sequentially according to the flashing specifications. During this period, each controller will stop sending messages on the CAN bus, and the TBOX and VCU will maintain communication via Ethernet.

[0056] OTA Exit Process: Under normal circumstances, when OTA ends, the TBOX can control the vehicle to exit OTA by sending "Remote flash request command = 0: initial value", "OTA mode = 0: initial value", and "Remote flash start flag = 0: initial value". However, when flashing the TBOX itself or when the vehicle experiences a network failure, the VCU cannot receive the CAN and Ethernet messages sent by the TBOX. Therefore, the VCU cannot stop OTA according to the TBOX command, and the vehicle will remain in the flashing state, causing the vehicle to be unable to drive normally. Over time, this can even lead to battery depletion.

[0057] To resolve this issue, the VCU needs to identify whether the TBOX is in a normal flashing state or has malfunctioned. The VCU addresses this by detecting TBOX Ethernet packet loss. Normally, the TBOX software update time is 20 minutes, and Ethernet communication will resume after the flashing process is complete. Therefore, the communication loss time is judged to be 25 minutes. If the VCU does not receive TBOX Ethernet packets after 25 minutes, it considers a malfunction to have occurred.

[0058] Procedure when no communication loss occurs in TBOX: Step 1: The VCU receives the "Remote flashing request command = 0: initial value", "OTA mode = 0: initial value", and "Remote flashing start flag = 0: initial value" sent by the TBOX; Step 2: The VCU sends "Power-on requirement for vehicle remote flashing mode = 0: initial value" to the TBOX, BMS, MCU, DCDC and other components via CAN and Ethernet to inform them to exit the OTA process; Step 3: When the VCU module responsible for guiding the vehicle status receives "Power-on requirement for remote flashing mode = 0: initial value", it will exit the flashing state, and the vehicle can be put into gear and driven normally. Step 4: TBOX controls the power on / off of the vehicle to reset the vehicle's state.

[0059] Procedure when TBOX experiences communication loss: Step 1: The VCU diagnoses a communication loss at the TBOX; Step 2: The VCU sends "Power-on requirement for vehicle remote flashing mode = 0: initial value" to the BMS, MCU, DCDC and other components via CAN and Ethernet respectively to inform them to exit the OTA process; Step 3: When the VCU module responsible for guiding the vehicle status receives "Power-on requirement for remote flashing mode = 0: initial value", it will exit the flashing state, and the vehicle can be put into gear and driven normally. Step 4: TBOX controls the power on / off of the vehicle to reset the vehicle's state.

[0060] In summary, this application employs both CAN and Ethernet communication between the TBOX and VCU, enabling real-time transmission of the current status of the TBOX and VCU and the delivery of commands. It also provides redundant control functionality, accurately identifying and promptly exiting OTA mode when the TBOX malfunctions to prevent battery drain. The OTA entry process, which involves interaction between the TBOX and VCU, also enhances the assessment of the overall vehicle status, improving the safety and success rate of software updates. Furthermore, the OTA abnormal exit process design prevents battery drain and controller damage caused by abnormal flashing.

[0061] Figure 6 A schematic diagram of the structure of a vehicle provided in an embodiment of this application. The vehicle may include: The memory 601, the processor 602, and the computer program stored on the memory 601 and capable of running on the processor 602.

[0062] When the processor 602 executes the program, it implements the processing method of the vehicle OTA control system provided in the above embodiments.

[0063] Furthermore, the vehicle also includes: Communication interface 603 is used for communication between memory 601 and processor 602.

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

[0065] The memory 601 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0066] 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 Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, 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.

[0067] 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.

[0068] The processor 602 may be a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application.

[0069] This application also provides a computer-readable storage medium storing a computer program or instructions thereon, which, when executed by a processor, implements the above-described processing method of the vehicle OTA control system.

[0070] This application also provides a computer program product, including a computer program or instructions, which, when executed, implement the above-described vehicle OTA control system processing method.

[0071] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is 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.

[0072] 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.

[0073] 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.

[0074] It should be understood that the various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, the N 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 one or more of the following techniques known in the art: 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 (PGAs), field-programmable gate arrays (FPGAs), etc.

[0075] Those skilled in the art will understand that all or part of the steps of the methods in 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.

Claims

1. A vehicle OTA control system, characterized in that, include: Vehicle communication module and vehicle controller; A first communication link and a second communication link are configured between the vehicle communication module and the vehicle controller; The vehicle controller receives a remote flashing request instruction transmitted via the vehicle communication module and sent from the cloud via the first communication link. After meeting the preset conditions, it sends an instruction to enter the flashing mode or an instruction to exit the flashing mode to at least one target controller in a broadcast manner according to the remote flashing request instruction. After at least one target controller enters the flashing mode, the vehicle controller and the vehicle communication module are configured to communicate through the second communication link. The vehicle controller monitors whether it receives a message from the vehicle communication module through the second communication link within a preset time period. If no message is received within the preset time period, the vehicle controller autonomously controls the at least one target controller to exit the flashing mode and triggers a vehicle reset operation.

2. The vehicle OTA control system according to claim 1, characterized in that, Also includes: Battery management system, drive motor controller, and DC-DC converter controller, among which, The battery management system is used to respond to the instruction issued by the vehicle controller to enter the flashing mode, enter a low-power static mode, and continuously send battery power data to the vehicle controller through the first communication link. The drive motor controller is used to respond to the command issued by the vehicle controller to enter the flashing mode, lock the output torque of the drive motor to a first preset threshold, and cooperate in locking the vehicle gear position to the first gear. The DC-DC converter controller is used to cut off the power supply to at least one load in response to the command issued by the vehicle controller to enter the flashing mode, and to ensure the power supply to the vehicle communication module, the vehicle controller and at least one target controller.

3. The vehicle OTA control system according to claim 1, characterized in that, The vehicle controller also includes: The battery power data received from the battery management system is forwarded to the vehicle communication module via the second communication link. If the battery power data is lower than a second preset threshold, the system is controlled to exit the OTA flashing state.

4. A processing method for a vehicle OTA control system, characterized in that, The method is applied to the vehicle end and implemented through the vehicle OTA control system according to any one of claims 1-3, wherein the method includes the following steps: Obtain the remote flashing request issued by the OTA cloud; The vehicle communication module sends a remote flashing request command to the vehicle controller through the first communication link. In response to the remote flashing request command, the vehicle controller, after determining that the vehicle status meets the preset conditions, feeds back a flashing permission flag through the first communication link. After receiving the write permission flag, the vehicle communication module sends an OTA mode activation signal to the vehicle controller through the second communication link; In response to the OTA mode activation signal, the vehicle controller controls at least one target controller to enter the flashing preparation state through the first communication link; during the flashing process, the vehicle communication module and the vehicle controller maintain communication through the second communication link.

5. The processing method of the vehicle OTA control system according to claim 4, characterized in that, Also includes: The vehicle controller monitors whether it receives a message from the vehicle communication module through the second communication link within a preset time period; If no message is received within the preset time period, the vehicle controller will use the first communication link to control the at least one target controller to exit the flashing preparation state and trigger a vehicle reset operation.

6. The processing method of the vehicle OTA control system according to claim 4, characterized in that, The step of controlling at least one target controller to enter the write preparation state via the first communication link includes: The vehicle controller broadcasts a remote vehicle flashing mode signal via the first communication link; In response to the remote flashing mode signal, the battery management system enters a low-power static mode and continuously monitors the battery power. In response to the remote flashing mode signal, the drive motor controller locks the output torque of the drive motor to a first preset threshold and, in conjunction with this, locks the vehicle gear in the first gear position. In response to the remote write mode signal, the DC-DC converter controller cuts off power to at least one load and ensures power supply to the vehicle communication module, the vehicle controller, and at least one target controller.

7. The processing method of the vehicle OTA control system according to claim 6, characterized in that, Also includes: The battery management system continuously sends battery power data to the vehicle controller through the first communication link, and the vehicle controller forwards the power data to the vehicle communication module through the second communication link; If the vehicle communication module or the vehicle controller determines that the battery data is lower than a preset threshold, it will initiate a termination command through the second communication link or the first communication link, autonomously control the at least one target controller to exit the OTA flashing state, and trigger a vehicle reset operation.

8. A vehicle, characterized in that, 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 processing method of the vehicle OTA control system as described in any one of claims 4-7.

9. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed by the processor, they are used to implement the processing method of the vehicle OTA control system as described in any one of claims 4-7.

10. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed, they implement the processing method of the vehicle OTA control system as described in any one of claims 4-7.

Images