An OTA upgrade system and method that dynamically supports software updates for new controllers.

Abstract

This invention provides an OTA (Over-The-Air) upgrade system and method that dynamically supports software updates for new controllers. The system includes an OTA backend server and an in-vehicle host system. The OTA backend server manages new controller information, configures upgrade parameters, and generates OTA upgrade packages and configuration files. The in-vehicle host system has functions for downloading and parsing upgrade packages, reading and matching component information, and executing upgrades. The upgrade process includes two main stages: creating an upgrade task in the backend and triggering the upgrade on the in-vehicle side. By dynamically adapting the information reading and upgrade methods of new controllers through configuration files, OTA upgrades for new controllers can be achieved without updating the in-vehicle host system. This invention can infinitely expand the types of controllers, adapt to the rapid iteration needs of automotive models, improve the flexibility and timeliness of software upgrades, reduce development and maintenance costs, and has broad application prospects.

Description

Technical Field

[0001] This invention relates to the field of automotive electronics and remote upgrade technology, specifically to an OTA upgrade system and method that dynamically supports software updates for new controllers. Background Technology

[0002] Over-the-Air (OTA) remote upgrade technology, as a key means of enabling remote iteration of automotive software, allows users to update the vehicle's controller software via the internet without having to visit a dealership. This significantly improves the convenience and timeliness of software upgrades, while also reducing after-sales maintenance costs for automakers and enhancing the user experience. Currently, existing OTA upgrade systems can upgrade the software of controllers already configured at the vehicle's factory. The core logic involves pre-installing the component information reading methods, communication protocols, and upgrade processes for each controller in the vehicle's main unit system, and then performing the upgrade operation by matching the preset controller information.

[0003] However, in today's rapidly evolving automotive industry, existing OTA (Over-The-Air) upgrade systems suffer from significant technical shortcomings and are no longer able to meet the industry's evolving needs: First, they cannot adapt to dynamically added controllers. With model updates, configuration upgrades, or user-customized options, vehicles may add various controllers after leaving the factory (such as controllers for new intelligent driving assistance modules, controllers for new in-vehicle entertainment system expansion modules, etc.). Existing OTA upgrade systems do not pre-store the relevant configuration information (including component information reading methods, upgrade methods, etc.) of these new controllers in the vehicle's main unit system, making remote OTA upgrades impossible. To upgrade these new controllers, users must drive their vehicles to a repair shop and perform local upgrades using specialized equipment, severely impacting user experience and contradicting the core advantages of OTA upgrade technology. Second, the system has poor scalability. The adaptability of existing OTA upgrade systems relies on the pre-configuration of the vehicle's main unit system. Each new controller type requires the redevelopment, testing, and upgrading of the vehicle's main unit system software, increasing development costs and time for automakers. It may also introduce new compatibility issues due to main unit system upgrades and cannot achieve unlimited expansion of controller types, making it difficult to meet the rapid iteration needs of the automotive industry. Third, upgrade efficiency is low. For upgrading new controllers, existing technologies require a multi-step process: "vehicle host system adaptation development - host system OTA upgrade - new controller OTA upgrade". The whole process is time-consuming and requires multiple user collaborations, making it impossible to achieve fast and real-time upgrades of new controllers. Summary of the Invention

[0004] The purpose of this invention is to address the shortcomings of existing technologies by proposing an OTA upgrade system and method that dynamically supports software updates for new controllers.

[0005] To achieve the above objectives, the present invention adopts the following technical solution: an OTA upgrade system that dynamically supports software updates for new controllers, including an OTA backend server and an in-vehicle host system. The two establish a communication connection through a wireless communication network (such as 4G, 5G, vehicle networking, etc.) and work together to complete the software upgrade of the new controller.

[0006] The OTA backend server is configured to support a component information management module that manages newly added controller component information, a module that receives and stores upgrade source files for newly added controllers, an OTA upgrade package generation module that merges the upgrade source files and component information to generate an OTA upgrade package, a configuration file generation module that configures the component information reading method and software upgrade method and generates a configuration file, and an upgrade task management module that creates an OTA upgrade task associated with the target vehicle VIN and associates the upgrade task with the configuration file.

[0007] The component information management module is used to receive component information of newly added controllers entered by operators. The component information includes controller name, controller component number, controller supplier code, controller software version number, and controller hardware version number. This module performs format verification on the entered information (such as verifying the encoding rules of the component number, the format of the version number, etc.) to ensure the integrity and validity of the information, and stores the verified component information in the database.

[0008] The upgrade source file processing module is used to receive upgrade source files (including software installation packages, program patches, complete firmware files, etc.) of newly added controllers uploaded by operators, perform integrity verification (by calculating the file MD5 value, SHA256 value, etc.) and virus scanning on the upgrade source files to prevent invalid or malicious files from entering the system, and store the verified upgrade source files to the designated file server.

[0009] The OTA upgrade package generation module communicates with the component information management module and the upgrade source file processing module to obtain the verified component information and upgrade source file. It then merges the two using a preset packaging algorithm (such as ZIP packaging algorithm, custom encryption packaging algorithm, etc.) to generate an OTA upgrade package. The OTA upgrade package contains the upgrade source file, component information, encryption identifier, and verification code. The verification code is used by the vehicle host system to verify the integrity of the upgrade package and prevent the upgrade package from being tampered with or damaged during transmission.

[0010] The configuration file generation module is used to receive the component information reading method and software upgrade method of the newly added controller configured by the operator, and automatically generate a configuration file based on the configuration information. The configuration file adopts a parsable format (such as XML, JSON, etc.). The component information reading method specifies the specific implementation method of the vehicle host system to obtain the information parameters of each component (such as obtaining the controller name through a specific ID frame of the CAN bus, reading the supplier code through the TCP / IP protocol of Ethernet, etc.). The software upgrade method specifies the key parameters of the upgrade process (such as upgrade order, upgrade priority, power failure protection mechanism, breakpoint resume mechanism, upgrade timeout threshold, etc.).

[0011] The upgrade task management module is used to establish the association between the OTA upgrade package and the target vehicle VIN (Vehicle Identification Number), create OTA upgrade tasks, associate the upgrade tasks with configuration files, and manage the status of the upgrade tasks in real time (such as pending execution, in progress, successful, failed, etc.), receive upgrade status information reported by the vehicle host system, and form a complete upgrade log.

[0012] Preferably, the component information reading method includes a method for obtaining the controller name, a method for obtaining the controller component number, a method for obtaining the controller supplier code, a method for obtaining the controller software version number, and a method for obtaining the controller hardware version number.

[0013] The vehicle-mounted host system is communicatively connected to the OTA backend server and is configured with an upgrade task parsing module for obtaining the OTA upgrade task corresponding to the target vehicle and parsing the configuration file in the upgrade task, a component information reading module for reading the real-time component information of the newly added controller according to the configuration file, an information matching module for matching the real-time component information with the component information in the OTA upgrade package, and an upgrade execution module for performing corresponding upgrade operations or prompting operations according to the matching results.

[0014] The vehicle-mounted host system is installed inside the vehicle and establishes communication connections with various controllers in the vehicle (including existing and newly added controllers) through the vehicle network (such as CAN bus, Ethernet, LIN bus, etc.). It has functions such as upgrade task acquisition, configuration parsing, information reading, and upgrade execution. The specific configuration is as follows:

[0015] The upgrade task parsing module is used to receive OTA upgrade tasks issued by the OTA backend server, parse the configuration files in the upgrade task, extract the component information reading method and software upgrade method, and provide a basis for subsequent information reading and upgrade execution.

[0016] The component information reading module establishes communication with the newly added controller through the vehicle network according to the component information reading method extracted from the configuration file. It reads the real-time component information of the newly added controller (including controller name, controller component number, controller supplier code, controller software version number, and controller hardware version number) according to the specified communication protocol and data format, and performs format conversion and preprocessing on the read information for information matching.

[0017] The information matching module compares the preprocessed real-time component information with the component information included in the OTA upgrade package one by one. The specific comparison logic is as follows: it determines whether the controller name, controller component number, controller supplier code, and controller hardware version number are all consistent, and whether the controller software version number is different. If the above conditions are met, the matching is determined to be successful, and the subsequent upgrade process is triggered. If the conditions are not met, the matching is determined to be unsuccessful, and an error message is output.

[0018] After successful information matching and user confirmation of the upgrade, the upgrade execution module sends an upgrade command to the new controller via the vehicle network according to the software upgrade method specified in the configuration file, transmits the original upgrade file (supports breakpoint resumption; if the network is interrupted during transmission, the transmission can resume from the breakpoint after the network is restored), monitors various status parameters during the upgrade process (such as transmission progress, controller response status, upgrade step execution status, etc.), and executes a power failure protection mechanism (if the vehicle loses power unexpectedly during the upgrade process, the upgrade process can be resumed after power is restored to avoid damage to the controller firmware).

[0019] Preferably, the vehicle-mounted host system and the OTA backend server are further provided with a vehicle-mounted host system communication module and an OTA backend server communication module, respectively; the OTA backend server communication module provides a communication interface with the vehicle-mounted host system, supports communication based on protocols such as HTTP, HTTPS, and MQTT, and realizes functions such as upgrade task issuance, upgrade status reporting, and data interaction; the vehicle-mounted host system communication module is adapted to the OTA backend server communication module, and establishes a stable communication connection with the OTA backend server through a wireless communication network to realize data transmission such as upgrade task acquisition and status reporting.

[0020] Preferably, the in-vehicle host system also includes a human-machine interaction module and a status reporting module; the human-machine interaction module provides a visual operation interface, displays upgrade-related prompts to the user (such as "OTA upgrade task available, please confirm upgrade" "Information matching error", etc.), receives user operation commands (such as confirm upgrade, cancel upgrade), and displays upgrade progress, remaining upgrade time, and current upgrade status in real time (such as "Upgrading (30%)" "Upgrade successful", etc.); the status reporting module reports the information matching results and upgrade execution status (success, failure, retry, etc.) to the OTA backend server in real time, facilitating the OTA backend server to monitor and manage the upgrade task.

[0021] An OTA upgrade system that dynamically supports software updates for multiple controllers also includes an OTA upgrade method that dynamically supports software updates for newly added controllers, comprising the following steps:

[0022] S1: The OTA backend server creates an OTA upgrade task, which includes:

[0023] S11: The operator accesses the OTA backend server through the terminal device; enters the component information of the newly added controller into the OTA backend server; the component information includes the controller name, controller component number, controller supplier code, controller software version number, and controller hardware version number;

[0024] S12: The operator uploads the upgrade source file of the newly added controller to the OTA backend server through the terminal device;

[0025] S13: After receiving the upgrade source file, the OTA backend server automatically merges the upgrade source file with the component information to generate an OTA upgrade package;

[0026] S14: The operator configures the component information reading method and software upgrade method of the newly added controller in the OTA backend server through the terminal device. The component information reading method includes a specific implementation method for obtaining the information parameters of each component.

[0027] S15: The OTA backend server automatically generates the corresponding configuration file according to the configured component information reading method and software upgrade method;

[0028] S16: The operator establishes the association between the OTA upgrade package and the target vehicle VIN in the OTA backend server through the terminal device, creates an OTA upgrade task, and the OTA backend server automatically establishes the association between the upgrade task and the configuration file.

[0029] S2: The onboard host system triggers and executes an upgrade, specifically including:

[0030] S21: After the vehicle is powered on, the on-board host system starts up and establishes a communication connection with the OTA backend server. Based on the vehicle's VIN, it sends an upgrade task acquisition request to the OTA backend server and receives the OTA upgrade task corresponding to the vehicle returned by the OTA backend server.

[0031] S22: The vehicle host system parses the configuration file in the OTA upgrade task, extracts the component information reading method and software upgrade method, and reads the real-time component information of the newly added controller on the vehicle side according to the component information reading method;

[0032] S23: The vehicle host system compares the real-time component information it reads with the component information contained in the OTA upgrade package to determine whether the controller name, controller component number, controller supplier code, and controller hardware version number are all consistent and whether the controller software version number is different.

[0033] S24: If the comparison result is inconsistent, the matching is determined to be unsuccessful. The vehicle host system will not trigger the upgrade process, will output a "Information matching error" prompt on its display interface, and will report the "Information matching error" status to the OTA backend server.

[0034] S25: If the comparison results show that the controller name, controller part number, controller supplier code, and controller hardware version number are all the same, but the controller software version number is different, the matching is determined to be successful, and the vehicle host system outputs the prompt "There is an OTA upgrade task, please confirm the upgrade" on its display interface.

[0035] S26: If the user selects "Cancel Upgrade" through the interactive interface of the vehicle host system, the vehicle host system will exit the upgrade interface and re-execute steps S21-S25 after the vehicle is powered on and started again.

[0036] S27: If the user selects "Confirm Upgrade" through the interactive interface of the vehicle host system, the vehicle host system will perform a software update operation on the newly added controller according to the software upgrade method specified in the configuration file, thus triggering the upgrade process;

[0037] S28: If an upgrade fails, the vehicle host system will automatically re-trigger the upgrade. If the upgrade fails three times in a row, the system will report an "OTA upgrade failed" status to the OTA backend server.

[0038] S29: If the upgrade process is completed normally, the vehicle host system reports the "OTA upgrade successful" status to the OTA backend server.

[0039] Preferably, in step S11, the OTA backend server provides a visual operation interface, through which the operator inputs component information. The OTA backend server performs format verification on the input component information to ensure the integrity and validity of each parameter.

[0040] Preferably, in step S12, the upgrade source file is a software installation package, program patch, or complete firmware file corresponding to the new controller, and the OTA backend server performs integrity verification and virus scanning on the uploaded upgrade source file.

[0041] Preferably, in step S13, the OTA backend server uses a preset packaging algorithm to merge the upgrade source file and component information, and the generated OTA upgrade package contains an encryption identifier and a verification code. The verification code is used by the vehicle host system to verify the integrity of the upgrade package.

[0042] Preferably, in step S22, the vehicle host system establishes communication with the newly added controller via CAN bus, Ethernet or LIN bus, and reads real-time component information according to the communication protocol and data format specified in the component information reading method.

[0043] Preferably, in step S27, the software upgrade method includes one or more of the following: upgrade order, upgrade priority, power outage protection mechanism during the upgrade process, and upgrade breakpoint resume mechanism.

[0044] Preferably, during the upgrade process, the vehicle-mounted host system displays the upgrade progress, remaining upgrade time, and current upgrade status to the user in real time, and prohibits operations that may affect the upgrade from being performed during the upgrade process.

[0045] Compared with the prior art, the beneficial effects of the present invention are as follows: The present invention achieves dynamic adaptation of the new controller without upgrading the vehicle host system: The present invention generates a configuration file on the OTA backend server, which clarifies the reading method of the component information and the software upgrade method of the new controller. The vehicle host system only needs to parse the configuration file to obtain the relevant configuration. There is no need to redevelop, test and upgrade the software of the vehicle host system. This solves the technical bottleneck of the prior art that the new controller needs to rely on the host system for adaptation, which greatly reduces the development cost and cycle of car companies, while avoiding the compatibility risks brought about by the host system upgrade.

[0046] Secondly, the core of this invention lies in achieving dynamic adaptation between the vehicle host system and the newly added controller through configuration files. Regardless of the type of controller added (such as intelligent driving controller, in-vehicle entertainment extension controller, body control extension controller, etc.), as long as the corresponding component information is entered into the OTA backend server, the upgrade source file is uploaded, and the relevant reading and upgrade parameters are configured, the corresponding configuration file and OTA upgrade package can be generated to realize the OTA upgrade of the controller. It is not limited by the type and number of controllers and fully meets the needs of rapid iteration of automotive models and diversification of controllers.

[0047] Furthermore, the upgrade process of this invention does not require users to visit a service station. The software upgrade of the new controller can be completed remotely via OTA, and the entire process is highly automated, requiring only simple confirmation operations from the user on the vehicle host interface. At the same time, the system has mechanisms such as breakpoint resume and power failure protection to ensure the stability and reliability of the upgrade process. If the upgrade fails, it can automatically retry, reducing the user's operating costs. The progress and status are displayed in real time during the upgrade process, allowing users to clearly understand the upgrade status and greatly improving the user experience.

[0048] Finally, this invention adds an encryption identifier and verification code when generating the OTA upgrade package, and uses an HTTPS encrypted channel during transmission to prevent the upgrade package from being illegally parsed, tampered with, or stolen; integrity verification and virus scanning are performed when uploading the original upgrade file to prevent malicious files from entering the system; power outage protection and breakpoint resume mechanisms are implemented during the upgrade process to prevent controller firmware damage and ensure the security and reliability of the upgrade process; at the same time, this invention is applicable to various new controllers in various types of vehicles (fuel vehicles, new energy vehicles, intelligent connected vehicles, etc.), supports multiple vehicle communication protocols such as CAN bus, Ethernet, and LIN bus, and can seamlessly interface with existing OTA upgrade systems without requiring large-scale modifications to the hardware and software of existing vehicles, possessing strong compatibility and promotional value. Attached Figure Description

[0049] Figure 1 is a schematic diagram of the process of creating an OTA upgrade task by the OTA backend server of the present invention;

[0050] Figure 2 is a schematic diagram of the process by which the vehicle host system of the present invention triggers and executes the upgrade. Detailed Implementation

[0051] To provide a further understanding of the purpose, structure, features, and functions of the present invention, detailed descriptions are provided below with reference to specific embodiments.

[0052] Please refer to the reference. Figure 1 as well as Figure 2This invention provides an OTA upgrade method that dynamically supports software updates for new controllers, comprising two main stages: an OTA backend server creating an upgrade task and the vehicle host system triggering and executing the upgrade. The specific steps are as follows:

[0053] S1: OTA backend server creates OTA upgrade task

[0054] This step is completed by the operator interacting with the OTA backend server through a terminal device (such as a computer, tablet, etc.). Specific steps are as follows:

[0055] S11: Operators access the OTA backend server's visual operation interface via terminal devices, enter their login account and password for authentication, and then enter the new controller upgrade configuration page. On this page, operators enter the component information of the new controller according to the system prompts. The component information includes the controller name (e.g., "XXXXX controller"), controller component number (e.g., "XXX-20251125"), controller supplier code (e.g., "DLS-001"), controller software version number (e.g., "V1.0.0"), and controller hardware version number (e.g., "H2.1"). The component information management module of the OTA backend server performs format verification on each entered parameter. For example, it verifies whether the component number conforms to the encoding rule of "controller type-date" and whether the version number conforms to the format of "V + number + number + number". If there are missing parameters or incorrect formats, the system will prompt the operator to correct them until the information is verified. The verified component information is stored in the database.

[0056] S12: On the new controller upgrade configuration page, the operator uploads the upgrade source file for the new controller to the OTA backend server via the file upload function. The upgrade source file is a legal file that has been tested and verified by the car manufacturer (such as firmware files with the .bin extension, compressed installation packages with the .zip extension, etc.). After receiving the upgrade source file, the upgrade source file processing module of the OTA backend server calculates the MD5 value of the file for integrity verification. At the same time, it performs a security check on the file using the built-in virus scanning engine. If the file is incomplete or has security risks, the system prompts the operator to re-upload. If the file verification passes, the upgrade source file is stored on the file server, and a unique file index is generated.

[0057] S13: The OTA upgrade package generation module of the OTA backend server obtains the upgrade source file from the file server through the file index, retrieves the corresponding component information from the database, and uses the ZIP packaging algorithm to merge and compress the upgrade source file and component information to generate the OTA upgrade package. During the packaging process, the system automatically adds an encryption identifier (using the AES encryption algorithm to encrypt key information in the package) and a checksum (SHA256 value calculated based on the upgrade source file and component information) to the OTA upgrade package. The encryption identifier is used to prevent the upgrade package from being illegally parsed, and the checksum is used by the vehicle host system to verify the integrity of the upgrade package.

[0058] S14: On the new controller upgrade configuration page, the operator configures the method for reading component information and the method for software upgrade of the new controller:

[0059] Component information reading method configuration: Select or customize the method for obtaining information parameters of each component according to the communication protocol and data interface of the newly added controller.

[0060] Software upgrade configuration: Set upgrade order (e.g., upgrade the underlying driver first, then upgrade the application), upgrade priority (e.g., high priority, prohibit other non-critical tasks from executing during the upgrade process), power failure protection mechanism (e.g., if a power failure is detected during the upgrade process, immediately save the current upgrade progress and automatically resume the upgrade after the next power-on), breakpoint resume mechanism (e.g., save the breakpoint every time 10% of the data is transferred, and resume the transmission from the most recent breakpoint when the network is reconnected after an interruption), upgrade timeout threshold (e.g., set the timeout time for a single upgrade step to 30 seconds, and retry if the timeout occurs), and other parameters.

[0061] S15: The OTA backend server's configuration file generation module automatically generates a JSON-formatted configuration file based on the operator's configured component information reading method and software upgrade method. The generated configuration file is associated with the corresponding OTA upgrade package through a file index. S16: On the OTA backend server's upgrade task creation page, the operator enters the target vehicle's VIN code (supports single VIN entry or batch import of multiple VINs), selects the generated OTA upgrade package, establishes the association between the OTA upgrade package and the target vehicle's VIN, and clicks the "Create Upgrade Task" button. Upon receiving the instruction, the OTA backend server's upgrade task management module creates the OTA upgrade task, assigns a unique task ID, automatically associates the upgrade task with the corresponding configuration file, initializes the upgrade task status to "Pending Execution," and stores the task information in the task database.

[0062] S2: The onboard host system triggers and executes an upgrade:

[0063] This process is automatically triggered after the vehicle is powered on, requiring no operator intervention. Specific steps are as follows:

[0064] S21: After the vehicle is powered on, the on-board host system automatically starts. Its communication module establishes an HTTPS connection with the OTA backend server's communication module via a 4G / 5G network and sends an upgrade task retrieval request to the OTA backend server, carrying the vehicle's VIN code in the request. After receiving the request, the upgrade task management module of the OTA backend server queries the task database according to the VIN code, obtains the OTA upgrade task corresponding to the VIN (status is "pending execution"), and sends the OTA upgrade package (sent through an encrypted transmission channel) and configuration file to the on-board host system. After receiving the file, the on-board host system stores it in the local storage module (such as on-board hard drive, flash memory, etc.).

[0065] S22: The upgrade task parsing module of the vehicle host system parses the received configuration file, extracts two parts: component information reading configuration and upgrade configuration, obtains reading parameters such as communication type, CAN ID, and TCP port for each component information parameter, as well as upgrade parameters such as upgrade order and priority; subsequently, the component information reading module of the vehicle host system establishes a communication connection with the new controller through the corresponding vehicle network (CAN bus or Ethernet) according to the parsed component information reading method, sends a data reading request according to the specified parameters, receives the response data returned by the new controller, decodes and preprocesses the response data, and extracts real-time component information (controller name, controller component number, controller supplier code, controller software version number, controller hardware version number).

[0066] S23: The information matching module of the vehicle host system will compare the extracted real-time component information with the component information contained in the OTA upgrade package one by one:

[0067] First, the controller name is compared. If the controller name read in real time is inconsistent with the controller name in the upgrade package, the matching is directly determined to be unsuccessful.

[0068] If the controller names match, continue comparing the controller part numbers; if they do not match, the matching is deemed a failure.

[0069] If the controller part number matches, continue comparing the controller supplier code; if they do not match, the matching is deemed a failure.

[0070] If the supplier code matches, continue comparing the controller hardware version number; if they do not match, the matching is deemed to have failed.

[0071] If the hardware version numbers are the same, the controller software version numbers are compared last. If the software version numbers are the same, the matching is considered to have failed (no upgrade is needed); if the software version numbers are different, the matching is considered to have succeeded (an upgrade is needed).

[0072] S24: If the information matching module determines that the matching has failed, the human-machine interaction module of the vehicle host system will display a "Information matching error" prompt box on the display interface. At the same time, the status reporting module will report the "Information matching error" status to the OTA backend server through the communication module, along with the specific reason for the matching failure (such as "controller part number is inconsistent" or "software version number is the same"). After receiving the report, the OTA backend server will update the upgrade task status to "matching failure" and record the relevant logs.

[0073] S25: If the information matching module determines that the matching is successful, the human-machine interaction module of the vehicle host system will display a prompt box on the display interface saying "There is an OTA upgrade task, please confirm the upgrade". The prompt box includes information such as the upgrade controller name, the current software version number, the target software version number, and the estimated upgrade time, and provides two operation buttons for the user to choose from: "Confirm Upgrade" and "Cancel Upgrade".

[0074] S26: If the user clicks the "Cancel Upgrade" button, the human-machine interaction module of the vehicle host system closes the upgrade prompt box, exits the upgrade interface, and marks the upgrade task status as "user canceled" and stores it locally; after the vehicle is powered on and started again, the vehicle host system will re-execute steps S21-S25 and prompt the user for upgrade again.

[0075] S27: If the user clicks the "Confirm Upgrade" button, the vehicle's host system's human-machine interface will display the upgrade progress interface, showing the upgrade status in real time; simultaneously, the upgrade execution module will execute the upgrade process according to the software upgrade method parsed from the configuration file and the preset upgrade order.

[0076] First, send an upgrade preparation command to the newly added controller, notifying the controller to enter upgrade mode;

[0077] Subsequently, following the breakpoint resume mechanism, the upgrade source files in the OTA upgrade package are transmitted to the new controller in chunks. Every 10% of the file data is transmitted, a verification request is sent to the new controller to confirm that the data has been received correctly before transmission continues.

[0078] If a network interruption is detected during transmission (e.g., a vehicle enters a no-signal area), the upgrade execution module pauses transmission and saves the current transmission progress; once the network is restored, transmission will automatically resume from the most recent interruption point.

[0079] If the system detects that the vehicle is about to lose power (e.g., the user turns off the ignition switch), the upgrade execution module immediately performs a power failure protection operation, saves the upgrade progress, and sends a power failure protection command to the new controller to ensure that the current firmware of the controller is not damaged.

[0080] After the original upgrade file is transferred, an upgrade execution command is sent to the new controller. The new controller begins to perform the software update operation. The vehicle host system receives the upgrade progress data fed back by the controller in real time and updates and displays it on the human-machine interface.

[0081] S28: If the new controller reports an upgrade failure during the upgrade process (such as file parsing error, upgrade step execution timeout, etc.), the upgrade execution module of the vehicle host system will automatically trigger the retry mechanism and re-execute the upgrade process in step S27. If three consecutive retries fail, the upgrade execution module will stop the upgrade, the human-machine interaction module will display the message "OTA upgrade failed, please contact customer service", and the status reporting module will report the "OTA upgrade failed" status to the OTA backend server, along with the reason for the failure (such as "file transfer timeout", "upgrade step execution failed", etc.). The OTA backend server will update the upgrade task status to "upgrade failed" and record the log.

[0082] S29: If the upgrade process goes smoothly, the new controller will report that the upgrade is complete and verified. The human-machine interaction module of the vehicle host system will display the message "OTA upgrade successful". The status reporting module will report the "OTA upgrade successful" status to the OTA backend server. The OTA backend server will update the upgrade task status to "upgrade successful", record the upgrade completion time, the software version number before and after the upgrade, and other information to complete the entire upgrade process.

[0083] The present invention has been described in the above-described embodiments; however, these embodiments are merely examples for implementing the present invention. It must be noted that the disclosed embodiments do not limit the scope of the present invention. Conversely, any modifications and refinements made without departing from the spirit and scope of the present invention are within the scope of patent protection of the present invention.

Claims

1. An OTA upgrade system that dynamically supports software updates for newly added controllers, characterized in that: The upgrade system includes an OTA backend server and an in-vehicle host system; The OTA backend server is configured to support a component information management module that manages newly added controller component information, an upgrade source file processing module that receives and stores newly added controller upgrade source files, an OTA upgrade package generation module that merges the upgrade source files and component information to generate an OTA upgrade package, a configuration file generation module that configures the component information reading method and software upgrade method and generates a configuration file, and an upgrade task management module that creates an OTA upgrade task associated with the target vehicle VIN and associates the upgrade task with the configuration file. The vehicle-mounted host system is communicatively connected to the OTA backend server and is configured with an upgrade task parsing module that obtains the OTA upgrade task corresponding to the target vehicle and parses the configuration file in the upgrade task, a component information reading module that reads the real-time component information of the newly added controller according to the configuration file, an information matching module that matches the real-time component information with the component information in the OTA upgrade package, and an upgrade execution module that executes the corresponding upgrade operation or prompt operation according to the matching result.

2. The OTA upgrade system that dynamically supports software updates for new controllers as described in claim 1, characterized in that: The component information includes the controller name, controller component number, controller supplier code, controller software version number, and controller hardware version number.

3. The OTA upgrade system that dynamically supports software updates for new controllers as described in claim 1, characterized in that: The methods for reading component information include methods for obtaining the controller name, methods for obtaining the controller component number, methods for obtaining the controller supplier code, methods for obtaining the controller software version number, and methods for obtaining the controller hardware version number.

4. An OTA upgrade method that dynamically supports software updates for newly added controllers, characterized in that: Includes the following steps: S1: The OTA backend server creates an OTA upgrade task, which includes: S11: The operator accesses the OTA backend server through the terminal device; enters the component information of the newly added controller into the OTA backend server; the component information includes the controller name, controller component number, controller supplier code, controller software version number, and controller hardware version number; S12: The operator uploads the upgrade source file of the newly added controller to the OTA backend server through the terminal device; S13: After receiving the upgrade source file, the OTA backend server automatically merges the upgrade source file with the component information to generate an OTA upgrade package; S14: The operator configures the component information reading method and software upgrade method of the newly added controller in the OTA backend server through the terminal device. The component information reading method includes a specific implementation method for obtaining the information parameters of each component. S15: The OTA backend server automatically generates the corresponding configuration file according to the configured component information reading method and software upgrade method; S16: The operator establishes the association between the OTA upgrade package and the target vehicle VIN in the OTA backend server through the terminal device, creates an OTA upgrade task, and the OTA backend server automatically establishes the association between the upgrade task and the configuration file. S2: The onboard host system triggers and executes an upgrade, specifically including: S21: After the vehicle is powered on, the on-board host system starts up and establishes a communication connection with the OTA backend server. Based on the vehicle's VIN, it sends an upgrade task acquisition request to the OTA backend server and receives the OTA upgrade task corresponding to the vehicle returned by the OTA backend server. S22: The vehicle host system parses the configuration file in the OTA upgrade task, extracts the component information reading method and software upgrade method, and reads the real-time component information of the newly added controller on the vehicle side according to the component information reading method; S23: The vehicle host system compares the real-time component information it reads with the component information contained in the OTA upgrade package to determine whether the controller name, controller component number, controller supplier code, and controller hardware version number are all consistent and whether the controller software version number is different. S24: If the comparison result is inconsistent, the matching is determined to be unsuccessful. The vehicle host system will not trigger the upgrade process, will output the "Information matching error" prompt on its display interface, and will report the "Information matching error" status to the OTA backend server. S25: If the comparison results show that the controller name, controller part number, controller supplier code, and controller hardware version number are all the same but the controller software version number is different, the matching is determined to be successful, and the vehicle host system outputs the message "There is an OTA upgrade task, please confirm the upgrade" on its display interface. S26: If the user selects "Cancel Upgrade" through the interactive interface of the vehicle host system, the vehicle host system will exit the upgrade interface and re-execute steps S21-S25 after the vehicle is powered on and started again. S27: If the user selects "Confirm Upgrade" through the interactive interface of the vehicle host system, the vehicle host system will perform a software update operation on the newly added controller according to the software upgrade method specified in the configuration file, triggering the upgrade process; S28: If an upgrade fails, the vehicle host system will automatically re-trigger the upgrade. If the upgrade fails three times in a row, the system will report an "OTA upgrade failed" status to the OTA backend server. S29: If the upgrade process is completed normally, the vehicle host system reports "OTA upgrade successful" status to the OTA backend server.

5. The OTA upgrade method for dynamically supporting software updates of newly added controllers as described in claim 4, characterized in that: In step S11, the OTA backend server provides a visual operation interface. The operator enters component information through the visual operation interface. The OTA backend server performs format verification on the entered component information to ensure the integrity and validity of each parameter.

6. The OTA upgrade method for dynamically supporting software updates of newly added controllers as described in claim 4, characterized in that: In step S12, the upgrade source file is the software installation package, program patch, or complete firmware file corresponding to the new controller. The OTA backend server performs integrity verification and virus scanning on the uploaded upgrade source file.

7. The OTA upgrade method for dynamically supporting software updates of newly added controllers as described in claim 4, characterized in that: In step S13, the OTA backend server uses a preset packaging algorithm to merge the upgrade source file and component information. The generated OTA upgrade package contains an encryption identifier and a verification code. The verification code is used by the vehicle host system to verify the integrity of the upgrade package.

8. The OTA upgrade method for dynamically supporting software updates of newly added controllers as described in claim 4, characterized in that: In step S22, the vehicle host system establishes communication with the newly added controller through CAN bus, Ethernet or LIN bus, and reads real-time component information according to the communication protocol and data format specified in the component information reading method.

9. The OTA upgrade method for dynamically supporting software updates of newly added controllers as described in claim 4, characterized in that: In step S27, the software upgrade method includes one or more of the following: upgrade order, upgrade priority, power outage protection mechanism during the upgrade process, and upgrade breakpoint resume mechanism.

10. The OTA upgrade method for dynamically supporting new controller software updates as described in claim 4, characterized in that: During the upgrade process, the vehicle-mounted host system displays the upgrade progress, remaining upgrade time, and current upgrade status to the user in real time, and prohibits operations that may affect the upgrade during the upgrade process.

Images