Vehicle ECU upgrade method and vehicle

Abstract

The present application provides a vehicle ECU upgrade method and vehicle, the method comprising: an OTA master controller deployed on a first device obtains a client identifier corresponding to an OTA upgrade program of the target ECU in response to detecting an upgrade instruction corresponding to the target ECU, and sends the data of the installation package to a client corresponding to the client identifier in a middleware deployed on a second device through the OTA upgrade program; during the data transmission process, the OTA master controller suspends data transmission in response to detecting abnormal operation of the client; the middleware restarts the client in response to detecting abnormal operation of the client; and then the OTA master controller continues to send data through the OTA upgrade program when the pause duration reaches a preset duration, thereby realizing non-sensing data transmission of the OTA master controller in the event of abnormality, avoiding the OTA master controller from reapplying for a handle ID in the event of data transmission abnormality, and thereby avoiding upgrade flashing failure caused by the failure of the initial handle ID.

Description

Technical Field

[0001] The present application relates to the field of OTA upgrade technology, and in particular to a vehicle ECU upgrade method and a vehicle. Background Art

[0002] Over-the-Air (OTA) automotive upgrades refer to firmware and software upgrades performed over the air. OTA not only provides a more convenient way to upgrade vehicles but also offers users a smarter and more convenient vehicle experience. OTA updates the system by downloading software update packages from a remote server over the internet.

[0003] Currently, when flashing an ECU (Electronic Control Unit) based on OTA upgrade, the OTA master application usually downloads the ECU upgrade file to the vehicle end, and divides the upgrade file into multiple data messages and flashes it to the ECU through the DoCAN and DoIP protocols. Among them, the OTA master application and the DoCAN and DoIP protocol layers are on the same device.

[0004] However, when the OTA master application is placed on one device and the DoCAN (Diagnostics over Controller Area Network) and DoIP (Diagnostics over Internet Protocol) protocol stacks are placed on another device, if the device where the protocol stack is located fails or the protocol stack has an abnormality, the OTA master will not be able to perceive the failure, causing communication failure and flashing failure. Summary of the Invention

[0005] In view of the above-mentioned defects or deficiencies in the prior art, the present application aims to provide a vehicle ECU upgrade method and vehicle to solve the problem in the related art that OTA cannot perceive protocol stack failures resulting in upgrade failures.

[0006] An embodiment of the present application provides a vehicle ECU upgrade method, which is applied to a distributed communication system. The distributed communication system includes a vehicle gateway, an OTA master controller deployed on a first device, and middleware deployed on a second device. The vehicle ECU upgrade method includes:

[0007] In response to detecting an upgrade instruction corresponding to a target ECU, the OTA master controller obtains a client identifier corresponding to an OTA upgrade program of the target ECU, and sends data of the installation package to a client corresponding to the client identifier in the middleware through the OTA upgrade program;

[0008] During the data transmission process, the OTA master controller suspends data transmission in response to detecting that the client is operating abnormally, and the middleware restarts the client in response to detecting that the client is operating abnormally;

[0009] In response to detecting that the pause duration has reached a preset duration, the OTA master control continues to send the data of the installation package to the client corresponding to the client identifier through the OTA upgrade program, so that the vehicle gateway upgrades the target ECU based on the installation package.

[0010] Optionally, before obtaining the client identifier corresponding to the OTA upgrade program of the target ECU and sending the data of the installation package to the client corresponding to the client identifier in the middleware through the OTA upgrade program, the method further includes:

[0011] The OTA master creates an OTA upgrade program corresponding to the target ECU;

[0012] The OTA master creates a client corresponding to the OTA upgrade program in the middleware through the OTA upgrade program, and associates and stores the client identifier corresponding to the client with the upgrade communication information of the target ECU.

[0013] Optionally, the OTA master creates a client corresponding to the OTA upgrade program in the middleware through the OTA upgrade program, and associates and stores a client identifier corresponding to the client with the upgrade communication information of the target ECU, including:

[0014] The OTA upgrade program calls the middleware, and the middleware creates a client corresponding to the OTA upgrade program and obtains a corresponding client identifier;

[0015] The middleware obtains the upgrade communication information of the target ECU, associates the client identifier with the upgrade communication information and stores it, and synchronizes the client identifier and the upgrade communication information to the OTA master, so that the OTA master stores the client identifier and the upgrade communication information in an associated manner.

[0016] Optionally, after the middleware restarts the client in response to detecting that the client is running abnormally, the method further includes:

[0017] If the middleware fails to restart the client, the middleware reclaims the memory resources occupied by the client, creates a new client, and obtains the client identifier corresponding to the new client;

[0018] The middleware obtains the associated client identifier based on the upgrade communication information of the target ECU, and determines whether the client identifier associated with the upgrade communication information is the same as the new client identifier. If different, the client identifier associated with the upgrade communication information is used to update the new client identifier.

[0019] Optionally, after the middleware uses the client identifier associated with the upgrade communication information to update the new client identifier, the method further includes:

[0020] The middleware stores the updated client identifier in association with the upgrade communication information, and synchronizes the updated client identifier and the upgrade communication information to the OTA master, so that the OTA master updates the content stored in association with the upgrade communication information.

[0021] Optionally, the vehicle gateway upgrades the target ECU based on the installation package, including:

[0022] The client stores the installation package in the second device;

[0023] In response to detecting the flashing request corresponding to the target ECU, the client sends the data of the installation package to the server in the vehicle gateway;

[0024] The server upgrades the target ECU based on the data of the installation package.

[0025] Optionally, the server upgrades the target ECU based on the data in the installation package, including:

[0026] The server obtains the protocol type supported by the target ECU and determines whether data conversion is required based on the protocol type;

[0027] If so, the server performs data conversion on the data of the installation package based on the protocol type, and sends the converted data to the target ECU.

[0028] Optionally, the method further includes:

[0029] In response to detecting an upgrade query request for the target ECU, the middleware sends a current version read request to the vehicle gateway to obtain the current version information of the target ECU, and sends a latest version read request to the OTA master controller to enable the OTA master controller to request the latest version information of the target ECU from the OTA cloud platform;

[0030] If the OTA master determines that the latest version information is different from the current version information, the upgrade confirmation information is displayed to the human-computer interaction interface through the middleware;

[0031] In response to detecting that a user triggers a confirmation upgrade operation on the human-computer interaction interface, it is determined that the upgrade instruction is detected.

[0032] Optionally, the method further includes:

[0033] If the OTA master detects that the client fails to restart and recreate within the preset time period, it generates an upgrade failure message and sends the upgrade failure message to the OTA cloud platform or the vehicle interface.

[0034] An embodiment of the present application further provides a vehicle, comprising a distributed communication system, the distributed communication system comprising a vehicle gateway, an OTA master controller deployed on a first device, and middleware deployed on a second device, wherein:

[0035] In response to detecting an upgrade instruction corresponding to a target ECU, the OTA master controller obtains a client identifier corresponding to an OTA upgrade program of the target ECU, and sends data of the installation package to a client corresponding to the client identifier in the middleware through the OTA upgrade program;

[0036] During the data transmission process, the OTA master controller suspends data transmission in response to detecting that the client is operating abnormally, and the middleware restarts the client in response to detecting that the client is operating abnormally;

[0037] In response to detecting that the pause duration has reached a preset duration, the OTA master control continues to send the data of the installation package to the client corresponding to the client identifier through the OTA upgrade program, so that the vehicle gateway upgrades the target ECU based on the installation package.

[0038] An embodiment of the present application further provides an electronic device, comprising:

[0039] processor and memory;

[0040] The processor is used to execute the steps of the vehicle ECU upgrade method provided in any embodiment of the present application by calling the program or instructions stored in the memory.

[0041] An embodiment of the present application also provides a computer-readable storage medium, which stores a program or instruction, and the program or instruction enables a computer to execute the steps of the vehicle ECU upgrade method provided in any embodiment of the present application.

[0042] In summary, the present application proposes a method for upgrading a vehicle ECU, the method comprising: an OTA master controller deployed on a first device, in response to detecting an upgrade instruction corresponding to a target ECU, obtaining a client identifier corresponding to an OTA upgrade program of the target ECU, and sending, through the OTA upgrade program, the data of an installation package to a client corresponding to the client identifier in a middleware deployed on a second device. During the data transmission process, the OTA master controller, in response to detecting an abnormal operation of the client, suspends data transmission. The middleware, in response to detecting an abnormal operation of the client, restarts the client. Then, in response to detecting that the pause duration has reached a preset duration, the OTA master controller continues to send the data of the installation package through the OTA upgrade program, so that the vehicle gateway can subsequently upgrade the target ECU through the installation package. In this method, the OTA master controller and the middleware can detect abnormal operation of the client. When the client operates abnormally, the OTA master controller suspends data transmission, waits for the middleware to restart the client, and then resumes data transmission through the restarted client, so that the OTA master controller still performs data transmission according to the operation before the abnormality, thereby achieving seamless data transmission, avoiding the OTA master controller from reapplying for a handle ID when the data transmission is abnormal, and thus avoiding the upgrade flash failure caused by the failure of the initial handle ID. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] In order to more clearly illustrate the specific implementation methods of the present application or the technical solutions in the prior art, the following is a brief introduction to the drawings required for use in the specific implementation methods or the description of the prior art. Obviously, the drawings described below are some implementation methods of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0044] Figure 1 This is a vehicle architecture diagram provided by an embodiment of the present application;

[0045] Figure 2 This is a flow chart of a vehicle ECU upgrade method provided by an embodiment of the present application;

[0046] Figure 3 This is a schematic diagram of a parallel flashing of multiple ECUs provided in an embodiment of the present application;

[0047] Figure 4 This is a schematic diagram of converting DoIP data to UDS data provided by an embodiment of the present application;

[0048] Figure 5 This is a schematic diagram of converting UDS data to DoIP data provided by an embodiment of the present application;

[0049] Figure 6 This is a schematic diagram of a distributed communication upgrade provided by an embodiment of the present application;

[0050] Figure 7 This is a schematic diagram of the internal modules of an OTA master control and middleware provided in an embodiment of the present application;

[0051] Figure 8 This is a structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0052] The present application will be further described in detail below with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are merely for the purpose of explaining the relevant invention and are not intended to limit the invention. It should also be noted that, for ease of description, only portions relevant to the invention are shown in the accompanying drawings.

[0053] It should be noted that, in the absence of conflict, the embodiments and features of the embodiments in this application can be combined with each other. The present application will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0054] As mentioned in the background technology, in response to the problems in the existing technology, this application proposes a vehicle ECU upgrade method, which can be applied to a distributed communication system. The distributed communication system includes a vehicle gateway, an OTA master controller deployed on a first device, and a middleware deployed on a second device.

[0055] The vehicle's gateway can communicate with each ECU. The OTA master controller can communicate with the OTA cloud platform. The OTA master controller is deployed on the vehicle's first device, which can be a VBOX (Vehicle Communication Box). The middleware can communicate with the vehicle's gateway. The middleware is deployed on the vehicle's second device, which can be a CDC (Cockpit Domain Controller).

[0056] Specifically, the middleware can be understood as the software layer between the OTA master control and the vehicle gateway. The middleware has built-in DoIP and UDS (Unified Diagnostic Services) protocol stacks, that is, the middleware relies on the DoIP and UDS protocol stacks to achieve communication.

[0057] For example, Figure 1 This is a vehicle architecture diagram provided by an embodiment of the present application. The vehicle ECU upgrade method provided by an embodiment of the present application mainly involves OTA master control, middleware and vehicle gateway, such as Figure 1As shown, the OTA master controller can be deployed in the vehicle communication terminal, and the middleware can be deployed in the audio and video entertainment controller (i.e., the cockpit domain controller). The vehicle dynamics controller in the figure is mainly used to control the vehicle body.

[0058] The vehicle communication terminal can communicate with the OTA cloud platform via 4G or 5G networks and with vehicle gateways 1 through 4 via 100M Ethernet. The audio and video entertainment controller can also communicate with vehicle gateways 1 through 4 via 100M Ethernet. Vehicle gateways 1 through 4 are each connected to one or more ECUs. For example, vehicle gateway 1 connects to ECUs 1-1 through ECUs 1-n, and vehicle gateway 2 connects to ECUs 2-1 through ECUs 2-n. Each vehicle gateway can communicate with each ECU via Ethernet or the CAN bus.

[0059] Figure 2 This is a flow chart of a vehicle ECU upgrade method provided by an embodiment of the present application. Figure 2 The vehicle ECU upgrade method specifically includes:

[0060] S110 , in response to detecting the upgrade instruction corresponding to the target ECU, the OTA master controller obtains the client identifier corresponding to the OTA upgrade program of the target ECU, and sends the data of the installation package to the client corresponding to the client identifier in the middleware through the OTA upgrade program.

[0061] Among them, the upgrade instruction can be actively issued by the OTA cloud platform after detecting the new version information; or, the upgrade instruction can be that the middleware detects that the user requests an upgrade query through the human-computer interaction interface, requests the latest version information from the OTA platform through the vehicle-cloud communication module in the vehicle communication terminal, and queries the current version information of the target ECU through the vehicle gateway, and then generates it when the latest version information does not match the current version information; the upgrade instruction can be confirmed to the user when the latest version information does not match the current version information, and is generated after the user confirms the upgrade.

[0062] In a specific embodiment, the method provided in the embodiment of the present application further includes the following steps:

[0063] Step 101: In response to detecting an upgrade query request for a target ECU, the middleware sends a current version read request to the vehicle gateway to obtain the current version information of the target ECU, and sends a latest version read request to the OTA master controller, so that the OTA master controller requests the latest version information of the target ECU from the OTA cloud platform.

[0064] Step 102: If the OTA master determines that the latest version information is different from the current version information, the upgrade confirmation information is displayed to the human-computer interaction interface through the middleware. In response to detecting that the user triggers the upgrade confirmation operation on the human-computer interaction interface, it is determined that the upgrade instruction is detected.

[0065] Among them, in step 101, the middleware in the second device (i.e., the audio and video entertainment controller) can detect the upgrade query request for the target ECU initiated by the user through the human-computer interaction interface, and then the middleware can send a current version read request to the vehicle gateway to enable the vehicle gateway to obtain the current version information of the target ECU and return it to the middleware. The middleware sends the current version information to the OTA master control; and the middleware can send a latest version read request to the OTA master control to enable the OTA master control to request the latest version information of the target ECU from the OTA cloud platform.

[0066] Furthermore, in step 102, the OTA master control can determine whether the latest version information of the target ECU is the same as the current version information. If different, it means that the target ECU needs to be upgraded. At this time, the upgrade confirmation information can be displayed to the human-computer interaction interface through the middleware, such as sending the upgrade confirmation information to the middleware so that the middleware forwards it to the human-computer interaction interface for display.

[0067] After the upgrade confirmation information is displayed, if it is detected that the user triggers the upgrade confirmation operation on the human-computer interaction interface, it can be determined that the upgrade instruction for the target ECU is detected.

[0068] Through the above steps 101-102, it is possible to implement an upgrade query for each ECU in the vehicle, thereby automatically determining each ECU that needs to be upgraded and generating corresponding upgrade instructions after user confirmation, facilitating the subsequent timely establishment of the corresponding OTA upgrade program.

[0069] In an embodiment of the present application, if the OTA master detects the upgrade instruction corresponding to the target ECU, the data of the installation package can be sent to the corresponding client connected to the OTA upgrade program through the OTA upgrade program of the target ECU.

[0070] Specifically, the OTA master is used to manage the upgrade of all ECUs in the vehicle. The OTA master can create a corresponding OTA upgrade program for each target ECU that needs to be upgraded, and use the OTA upgrade program to create a corresponding client (DoIP and UDS client) in the middleware to facilitate subsequent communication between the OTA upgrade program and the corresponding client to transmit the installation package data.

[0071] Among them, the OTA master control can create a corresponding OTA upgrade program for each ECU in the vehicle in advance. The OTA upgrade program creates a client in the middleware so that the client creates corresponding thread resources and assigns a client identifier to the OTA upgrade program. Subsequent OTA upgrade programs can transmit data through the client identifier.

[0072] Alternatively, in order to further improve the rationality of resource utilization, the OTA master control can create a corresponding OTA upgrade program for the target ECU in real time when it detects the upgrade instruction of the target ECU. The OTA upgrade program creates a client in the middleware so that the client creates corresponding thread resources and assigns a client identifier to the OTA upgrade program. Subsequent OTA upgrade programs can transmit data through the client identifier.

[0073] In a specific embodiment, before obtaining the client identifier corresponding to the OTA upgrade program of the target ECU and sending the data of the installation package to the client corresponding to the client identifier in the middleware through the OTA upgrade program, the following steps are also included:

[0074] Step 103: The OTA master controller creates an OTA upgrade program corresponding to the target ECU;

[0075] Step 104 : The OTA master creates a client corresponding to the OTA upgrade program in the middleware through the OTA upgrade program, and associates and stores the client identifier corresponding to the client with the upgrade communication information of the target ECU.

[0076] In step 103, the OTA master, in response to detecting the upgrade instruction of the target ECU, first creates an OTA upgrade program corresponding to the target ECU in the first device. The OTA upgrade program is used to create a client in the middleware to communicate with it and perform data transmission with the client.

[0077] Furthermore, in step 104, after the OTA master creates the OTA upgrade program for the target ECU, the OTA upgrade program can create a corresponding client in the middleware. The client can then create a corresponding thread resource in the second device, assign a client identifier (which can be understood as the identifier of the thread resource), and feed the client identifier back to the OTA upgrade program. After the OTA upgrade program obtains the client identifier, the OTA master can associate the client identifier with the upgrade communication information of the target ECU and store it on the first device.

[0078] In one example, the OTA master creates a client corresponding to the OTA upgrade program in the middleware through the OTA upgrade program, and associates and stores the client identifier corresponding to the client with the upgrade communication information of the target ECU, including the following steps:

[0079] Step 1041: The OTA upgrade program calls the middleware, and the middleware creates a client corresponding to the OTA upgrade program and obtains the corresponding client identifier.

[0080] Step 1042: The middleware obtains the upgrade communication information of the target ECU, associates the client identifier with the upgrade communication information and stores it, and synchronizes the client identifier and the upgrade communication information to the OTA master, so that the OTA master stores the client identifier and the upgrade communication information in an associated manner.

[0081] Among them, in step 1041, the OTA upgrade program can call the middleware, and the middleware establishes a client based on the DoIP and UDS protocol stack. The client will create corresponding thread resources and assign a client identifier to the OTA upgrade program.

[0082] Furthermore, in step 1042, the middleware may obtain the upgrade communication information of the target ECU, wherein the upgrade communication information may describe communication-related parameters such as the port and IP of the target ECU upgrade. For example, the upgrade communication information may include the source IP address, target IP address, source port, target port, ECU source logical address, and ECU target logical address.

[0083] Furthermore, the middleware can associate the client identifier with the upgrade communication information and store it in the second device, and synchronize the client identifier and the upgrade communication information to the OTA master, which then associates and stores the client identifier with the upgrade communication information in the first device. In this way, the middleware can associate and store the client identifier, and the OTA master can associate and store the client identifier, which facilitates the OTA master's subsequent data transmission based on the client identifier, and facilitates the middleware to recover from exceptions based on the client identifier.

[0084] In an embodiment of the present application, the OTA master responds to the upgrade instruction of the target ECU. After creating the corresponding OTA upgrade program and the OTA upgrade program creates the corresponding client, the OTA master can send the data of the installation package to the client corresponding to the client identifier through the OTA upgrade program through the client identifier corresponding to the OTA upgrade program.

[0085] It should be noted that in the embodiment of the present application, the OTA master can realize parallel upgrade and flashing of multiple ECUs. The OTA master can create one or more OTA upgrade programs, which correspond to one or more target ECUs for OTA upgrade and flashing.

[0086] S120 . During data transmission, the OTA master controller suspends data transmission in response to detecting abnormal operation of the client, and the middleware restarts the client in response to detecting abnormal operation of the client.

[0087] Specifically, while the OTA upgrade program is sending the upgrade package data to the corresponding client, the OTA master and middleware can perform anomaly detection on each client that is transmitting data. If the OTA master detects that the client is operating abnormally, it can suspend data transmission to wait for the middleware to restart the client. If the middleware detects that the client is operating abnormally, it can restart the client to attempt to restore normal operation of the client. Among them, the client identifier remains unchanged after the middleware restarts the client, and the OTA master can continue to use the client identifier for data transmission.

[0088] Considering that the middleware may fail to restart the client, in order to further ensure the reliability of data transmission, a new client can be recreated and the original client can be released when the middleware fails to restart.

[0089] In a specific embodiment, after the middleware restarts the client in response to detecting an abnormal operation of the client, the following steps are further included:

[0090] Step 121: If the middleware fails to restart the client, the middleware reclaims the memory resources occupied by the client, creates a new client, and obtains a client identifier corresponding to the new client;

[0091] Step 122: The middleware obtains the associated client identifier based on the upgrade communication information of the target ECU, and determines whether the client identifier associated with the upgrade communication information is the same as the new client identifier. If different, the client identifier associated with the upgrade communication information is used to update the new client identifier.

[0092] Among them, in step 121, after the middleware restarts the client, if the middleware detects that the restart of the client fails, the middleware can first reclaim the memory resources occupied by the client, that is, reclaim the thread resources of the client, release the client, and create a new client. The new client creates the corresponding thread resources and obtains the client identifier corresponding to the new client.

[0093] Furthermore, in step 122 , the middleware may query the client identifier associated with the upgrade communication information from pre-stored information through the upgrade communication information of the target ECU. The client identifier is the identifier of the released original client.

[0094] The middleware can determine whether the client identifier associated with the upgraded communication information is the same as the new client identifier. If they are not the same, the new client identifier can be modified to the client identifier associated with the upgraded communication information to make the new client consistent with the identifier of the released original client, so that the OTA master can continue data transmission based on the original client identifier.

[0095] Through the above implementation method, when the middleware fails to restart the client, a new client with the same identifier as the original client can be re-created. While ensuring the OTA master control's seamless transmission, the reliability of data transmission is further improved. In addition, the resource utilization of the device can be improved by promptly releasing the resources occupied by the original client.

[0096] It should be noted that in the above embodiment, the middleware can update the new client identifier based on the client identifier associated with the upgraded communication information to achieve the purpose of keeping the identifier of the new client consistent with that of the original client. However, considering the possibility of update failure, in order to avoid the subsequent OTA master using a client identifier different from the identifier of the new client for data transmission, thereby causing transmission failure, the middleware can also synchronize the updated client identifier to the OTA master update.

[0097] In one example, after the middleware uses the client identifier associated with the upgrade communication information to update the new client identifier, the method further includes:

[0098] The middleware stores the updated client identifier in association with the upgrade communication information, and synchronizes the updated client identifier and the upgrade communication information to the OTA master, so that the OTA master updates the content stored in association with the upgrade communication information.

[0099] Specifically, after the middleware updates the identifier of the new client, it can store the updated client identifier in association with the upgraded communication information, while deleting the client identifier originally stored in association with the upgraded communication information, and then synchronize the updated client identifier and the upgraded communication information to the OTA master.

[0100] Furthermore, the OTA master control may query the content stored in association with the upgrade communication information and replace the content with the updated client identifier to achieve the associated storage of the updated client identifier and the upgrade communication information, while deleting the client identifier originally stored in association with the upgrade communication information.

[0101] Through the above example, after the middleware updates the new client identifier, the content stored in association with the middleware and the OTA master can be updated, avoiding transmission failure caused by the OTA master using different client identifiers for data transmission, and further ensuring the reliability of data transmission.

[0102] S130. In response to detecting that the pause duration has reached a preset duration, the OTA master control continues to send the data of the installation package to the client corresponding to the client identifier through the OTA upgrade program, so that the vehicle gateway upgrades the target ECU based on the installation package.

[0103] Specifically, when the OTA master detects an abnormality in the client, it suspends data transmission and starts counting the pause duration. If it detects that the pause duration reaches the preset duration, it can continue to use the client identifier corresponding to the target ECU and continue to send the installation package data to the corresponding client through the OTA upgrade program.

[0104] The preset time length may be a preset time length for waiting for the middleware to restart the client, or the preset time length may be a preselected time length for waiting for the middleware to restart the client and rebuild the client.

[0105] In an embodiment of the present application, taking into account the possibility that the middleware fails to restart the client or rebuild the client within a preset time period due to high system load or other reasons, in this case, the OTA master control can promptly return a prompt message to prompt the user that the upgrade package download failed.

[0106] In some embodiments, the method provided in the embodiments of the present application further includes:

[0107] If the OTA master detects that the client fails to restart and recreate within the preset time, it generates an upgrade failure message and sends the upgrade failure message to the OTA cloud platform or the vehicle interface.

[0108] Specifically, if the OTA master detects that the pause time reaches the preset time, and the middleware fails to restart the client and fails to rebuild, the OTA master can determine that the protocol stack of the middle layer is unrecoverable, and can generate an upgrade failure message, and report the upgrade failure message to the OTA cloud platform or the vehicle interface to indicate that the upgrade package download failed, so as to facilitate subsequent attempts to download the upgrade package again.

[0109] Through the above implementation, when the middleware fails to restart the client or rebuild the client within the preset time period, prompts can be given in time to facilitate subsequent attempts to download the upgrade package.

[0110] After the client receives the complete data of the installation package, it can transmit it to the server of the vehicle gateway (DoIP and UDS server). The client and the server can be a many-to-one relationship, that is, multiple clients can connect to one server.

[0111] Specifically, after receiving the installation package, the server in the vehicle gateway can forward the message according to the address of the target ECU, transmitting the target ECU's installation package in the form of a message to the target ECU for upgrade and flashing. Since the OTA master and client are installed on the first and second devices respectively, the middleware on the second device needs to be synchronized with the OTA master; otherwise, the upgrade and flashing will fail due to a malfunction.

[0112] For example, Figure 3 This is a schematic diagram of a method of flashing multiple ECUs in parallel provided by an embodiment of the present application. Figure 3 As shown in the figure, the middleware in the audio and video entertainment controller and the server in the vehicle gateway can be considered OTA upgrade agents, and the ECUs 1-n to be flashed can be considered OTA upgrade slaves. The OTA master can create an OTA upgrade program for each ECU to be flashed (ECU 1-n), resulting in OTA upgrade programs 1-n. The OTA upgrade program then creates a corresponding client in the audio and video entertainment controller, resulting in clients 1-n.

[0113] OTA upgrade programs 1-n can connect to clients 1-n, transmitting the corresponding ECU upgrade packages to them. Clients 1-n can then connect to the server in the vehicle gateway via Ethernet and transmit the corresponding ECU upgrade packages to the server. Furthermore, the server can send the upgrade packages to the ECUs 1-n to be upgraded via Ethernet or a controller area network (CAN) for flashing.

[0114] In a specific implementation, the vehicle gateway upgrades the target ECU based on the installation package, including the following steps:

[0115] Step 131: The client stores the installation package on the second device;

[0116] Step 132: In response to detecting the flashing request corresponding to the target ECU, the client sends the data of the installation package to the server in the vehicle gateway;

[0117] Step 133: The server upgrades the target ECU based on the data in the installation package.

[0118] In step 131 , the client may first store the data of the installation package in the second device; and the user may initiate a flashing request to the target ECU through the human-computer interaction interface.

[0119] Specifically, in step 132 , the flashing request may be generated by the OTA upgrade program after the data transmission of the installation package is completed. That is, the OTA upgrade program detects that the data transmission of the installation package is completed and may send a flashing request corresponding to the target ECU to the client.

[0120] Furthermore, if the client detects a flashing request, it can send the data of the installation package to the server in the vehicle gateway, and then in step 133, the server can send the data of the installation package to the target ECU for upgrade flashing.

[0121] In an embodiment of the present application, during the process of flashing data to the target ECU at the server end of the vehicle gateway, considering that different ECUs support different communication protocols, the server end can also perform data conversion on the upgrade package.

[0122] In one example, the server upgrades the target ECU based on the data in the installation package, including:

[0123] The server obtains the protocol type supported by the target ECU and determines whether data conversion is required based on the protocol type; if so, the server converts the data in the installation package based on the protocol type and sends the converted data to the target ECU.

[0124] Before sending the data of the installation package to the target ECU, the server can first obtain the protocol type supported by the target ECU, and then determine whether data conversion is required based on the protocol type.

[0125] For example, for target ECUs that support Ethernet, the DoIP protocol can be used for OTA upgrades, while for target ECUs that do not support Ethernet, the UDS protocol can be used for OTA upgrades. Therefore, for target ECUs that do not support Ethernet, it can be determined that data conversion is required to convert the upgrade package data into a protocol type supported by the target ECU, such as UDS data.

[0126] Figure 4 This is a schematic diagram of converting DoIP data to UDS data provided by an embodiment of the present application. Figure 4 As shown in the figure, for target ECUs that do not support Ethernet, the upgrade package can be converted from the DoIP type to the UDS type. A DoIP data frame consists of an Ethernet header (EthHead), an IP header (IPHead), a transport layer header (TCP / UDP Head), a DoIP header (DoIPHead), a source address, a destination address, and DoIP data. A UDS data frame consists of a CAN identifier (CANID), a data length code (DLC), protocol control information (DoCAN PCI), and UDS data.

[0127] Specifically, converting DoIP data to UDS data involves converting the data format sent by the OTA master to a format supported by the OTA upgrade slave (i.e., ECU). This process primarily involves converting the field content corresponding to the target address in the DoIP data (i.e., the logical address) into the field content corresponding to the CAN identifier in the UDS data (i.e., the request ID).

[0128] In addition to converting DoIP data to UDS data when sending the upgrade package to the target ECU, considering that the target ECU may feedback data to the vehicle gateway, the server of the vehicle gateway can also convert the UDS data fed back by the target ECU to DoIP data for such situations, so that the DoIP data can be subsequently fed back to the OTA master control through the client.

[0129] Figure 5 This is a schematic diagram of converting UDS data to DoIP data provided by an embodiment of the present application. Figure 5 As shown in the figure, for a target ECU that does not support Ethernet, the UDS data it feeds back can be converted into DoIP data. The structures of the DoIP data frame and the UDS data frame can be referred to in the previous description.

[0130] Specifically, converting UDS data to DoIP data involves converting the data format supported by the OTA upgrade slave (i.e., ECU) to the data format supported by the OTA master. This process primarily involves converting the field content corresponding to the CAN identifier in the UDS data (i.e., the request ID) into the field content corresponding to the source address in the DoIP data (i.e., the logical address).

[0131] Through the above data conversion mechanism, both ECUs that support Ethernet functions and ECUs that do not support Ethernet functions can be successfully upgraded and flashed, ensuring the upgrade reliability of each ECU.

[0132] Figure 6 is a schematic diagram of a distributed communication upgrade provided by an embodiment of the present application, Figure 6 The OTA vehicle-cloud communication process, human-computer interaction process, upgrade file package signature verification process, timeout management process, file download process, and upgrade management process are described. VBOX can be equipped with an OTA master control, and CDC can be equipped with middleware.

[0133] like Figure 6As shown, the user can initiate an upgrade query through the human-computer interaction module, and then the human-computer interaction module forwards the upgrade query to the vehicle-cloud communication module of the vehicle-side VBOX, so that the vehicle-cloud communication module sends an upgrade query request to the OTA cloud platform. In addition, the human-computer interaction module can also send a version information reading request to the VIU (Vehicle Gateway) through the transceiver management module, and send the obtained current version information to the vehicle-cloud communication module. After determining that the target ECU needs to be upgraded, the vehicle-cloud communication module can obtain the upgrade package pushed by the OTA cloud platform and verify the signature of the upgrade package.

[0134] Furthermore, users can initiate installation instructions through the human-computer interaction module, which sends them to the VBOX upgrade management module. The upgrade management module, through the OTA master application management in the state machine management module, creates an OTA upgrade program corresponding to the target ECU. This program interacts with the communication protocol stack management module in the CDC, allowing the CDC to call the protocol stack to create a client corresponding to the OTA upgrade program. The vehicle-to-cloud communication module can then send the verified upgrade package to the client through the OTA upgrade program created by the OTA master. During the transmission process, the state machine management module can also perform timeout detection based on timing management to implement timeout management, that is, suspend transmission when a transmission anomaly is detected, and perform timeout detection during the waiting process.

[0135] After the upgrade package is sent, the client can store the upgrade package in the CDC, and then send the upgrade package to the MPU (Microprocessor Unit) or MCU (Microcontroller Unit) in the VIU through the transceiver management module to install the upgrade package. The MPU or MCU can forward the upgrade data to the target ECU and receive the upgrade result feedback from the target ECU, and forward the upgrade result to the transceiver management module. The client can send the upgrade result to the vehicle-cloud communication module, so that the vehicle-cloud communication module forwards the upgrade result to the OTA cloud platform.

[0136] An embodiment of the present application provides a vehicle ECU upgrade method, the method comprising: an OTA master controller deployed on a first device, in response to detecting an upgrade instruction corresponding to a target ECU, obtains a client identifier corresponding to an OTA upgrade program of the target ECU, and sends, through the OTA upgrade program, data of an installation package to a client corresponding to the client identifier in a middleware deployed on a second device; during data transmission, the OTA master controller, in response to detecting an abnormal operation of the client, suspends data transmission; the middleware, in response to detecting an abnormal operation of the client, restarts the client; and the OTA master controller, in response to detecting that the pause duration has reached a preset duration, continues to send data of the installation package through the OTA upgrade program, so that the vehicle gateway can subsequently upgrade the target ECU through the installation package; in this method, the OTA master controller and the middleware can detect abnormal operation of the client; when the client operates abnormally, the OTA master controller suspends data transmission, waits for the middleware to restart the client, and then resumes data transmission through the restarted client, so that the OTA master controller still performs data transmission according to the operation before the abnormal operation, thereby realizing senseless data transmission, avoiding the OTA master controller from reapplying for a handle ID when the data transmission is abnormal, and thereby avoiding the upgrade flash failure caused by the failure of the initial handle ID.

[0137] Based on the same purpose, an embodiment of the present application further provides a vehicle, which includes a distributed communication system, the distributed communication system including a vehicle gateway, an OTA master deployed on a first device, and middleware deployed on a second device, wherein:

[0138] In response to detecting the upgrade instruction corresponding to the target ECU, the OTA master controller obtains the client identifier corresponding to the OTA upgrade program of the target ECU, and sends the data of the installation package to the client corresponding to the client identifier in the middleware through the OTA upgrade program;

[0139] During the data transmission process, the OTA master controller suspends data transmission in response to detecting abnormal operation of the client, and the middleware restarts the client in response to detecting abnormal operation of the client;

[0140] In response to detecting that the pause duration has reached the preset duration, the OTA master control continues to send the installation package data to the client corresponding to the client identifier through the OTA upgrade program, so that the vehicle gateway upgrades the target ECU based on the installation package.

[0141] Figure 7 This is a schematic diagram of the internal modules of an OTA master control and middleware provided in an embodiment of the present application. Figure 7As shown in the figure, the OTA master controller deployed in VBOX can be composed of an OTA upgrade program, an address information storage module, a client process ID acquisition module, a client ID synchronization module, and a client process monitoring module. The middleware deployed in CDC can be composed of a client process generation module, a client process destruction module, a client process monitoring module, a client identification synchronization module, a client process ID replication module, a client memory module, and a client process restart module. The OTA master controller and the middleware communicate via Ethernet.

[0142] When the OTA master needs to upgrade one or more target ECUs, it can establish an OTA upgrade program corresponding to each target ECU. The OTA upgrade program calls the middleware's DoIP and UDS protocol stacks. The middleware uses the client process generation module to establish a client that communicates with the OTA upgrade program. The client creates corresponding thread resources and assigns a client identifier (CLIENTID) to the OTA upgrade program. The client connects to the server in the VIU, which can parse the destination address in the client message and forward the message to the target ECU for upgrade and flashing. The OTA upgrade program can operate on the CLIENTID for data communication. When the OTA master detects that the upgrade is complete, it can call the middleware to release the thread corresponding to the CLIENTID (i.e., destroy the client) and reclaim related resources.

[0143] Because the OTA controller and middleware (DOIP and UDS protocol stacks) are located on separate devices, if the middleware device (CDC) experiences an exception or restarts, causing the middleware thread to become abnormal or destroyed, the OTA controller on the VBOX will be unaware of these changes and will continue to use an invalid CLIENTID for communication message operations, resulting in communication failure. Furthermore, if the middleware device (CDC) experiences an exception, the OTA controller may not be able to actively release the thread, leading to memory leaks and, in severe cases, a CDC system crash.

[0144] Therefore, in order to solve this technical problem, after the middleware assigns a CLIENTID, the middleware can associate and store the upgraded communication information, such as the source IP address, target IP address, source port, and target port, with the CLIENTID through the client memory module, and send this information to the OTA master through the client identification synchronization module. The OTA master associates and stores the upgraded communication information with the CLIENTID through the internal address information storage module. At the same time, the OTA master can detect whether the client is running abnormally through the internal client process monitoring module, and the middleware can detect whether the client is running abnormally through the internal client process monitoring module.

[0145] If the OTA controller's client process monitoring module detects an abnormal middleware thread, the OTA controller can pause sending communication messages to wait for the client to restart (that is, wait for the thread to recover). If the middleware's client process monitoring module detects an abnormal middleware thread, the middleware can restart the client through the client process restart module. The OTA controller can wait for 15 seconds. If it exceeds 15 seconds, the thread is considered unrecoverable and an upgrade failure message may be reported. If it recovers, data transmission will resume.

[0146] During the middleware's thread restart process, the client's CLIENTID remains unchanged. After the restart, the OTA controller can continue to use the CLIENTID for communication message transmission. If the middleware fails to restart the thread (due to a crash or restart of the middleware protocol stack process), the middleware can destroy the module through the client process, reclaim the memory resources occupied by the thread, and recreate a new thread based on the information stored in the client memory module, and obtain the corresponding CLIENTID.

[0147] Furthermore, the middleware can determine whether the CLIENTID associated with the upgrade communication information stored in the client memory module is the same as the new CLIENTID. If different, the new CLIENTID is replaced with the previously stored CLIENTID through the client process ID copy module, and the replaced ID is synchronized to the OTA master through the client identification synchronization module. At the same time, the OTA master updates the saved information.

[0148] Since the CLIENTID of the process rebuilt by the middleware is the same as the CLIENTID before the exception, the OTA master control can still continue data transmission by operating the previous CLIENTID, realizing seamless operation without reapplying for the handle ID, avoiding the invalidation of the previous handle ID caused by reapplying for the handle ID, thereby avoiding upgrade and flashing failures, greatly improving the transmission efficiency of communication messages and the upgrade success rate.

[0149] The vehicle provided in the embodiment of the present application can be applied to the vehicle ECU upgrade method provided in the method embodiment of the present application, and the execution steps and beneficial effects are no longer repeated here.

[0150] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. Figure 8 As shown, the electronic device 400 includes one or more processors 401 and a memory 402 .

[0151] The processor 401 may be a central processing unit (CPU) or other forms of processing units having data processing capabilities and / or instruction execution capabilities, and may control other components in the electronic device 400 to perform desired functions.

[0152] Memory 402 may include one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may include, for example, random access memory (RAM) and / or cache memory. The non-volatile memory may include, for example, read-only memory (ROM), a hard disk, flash memory, etc. One or more computer program instructions may be stored on the computer-readable storage medium, and the processor 401 may execute the program instructions to implement the vehicle ECU upgrade method of any embodiment of the present application described above and / or other desired functions. Various contents such as initial external parameters and threshold values ​​may also be stored in the computer-readable storage medium.

[0153] In one example, electronic device 400 may further include an input device 403 and an output device 404, which are interconnected via a bus system and / or other connection mechanisms (not shown). Input device 403 may include, for example, a keyboard, a mouse, etc. Output device 404 may output various information to the outside, including warning information, braking force, etc. Output device 404 may include, for example, a display, a speaker, a printer, a communication network, and remote output devices connected thereto.

[0154] Of course, to simplify, Figure 8 Only some of the components related to the present application in the electronic device 400 are shown, and components such as buses, input / output interfaces, etc. are omitted. In addition, the electronic device 400 may further include any other appropriate components according to specific application scenarios.

[0155] In addition to the above-mentioned methods and devices, an embodiment of the present application may also be a computer program product, which includes computer program instructions, which, when executed by a processor, enable the processor to execute the steps of the vehicle ECU upgrade method provided in any embodiment of the present application.

[0156] The computer program product may be written in any combination of one or more programming languages ​​to implement the program code for performing the operations of the embodiments of the present application, including object-oriented programming languages ​​such as Java, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0157] In addition, an embodiment of the present application may also be a computer-readable storage medium having computer program instructions stored thereon. When the computer program instructions are executed by a processor, the processor executes the steps of the vehicle ECU upgrade method provided in any embodiment of the present application.

[0158] The computer-readable storage medium may be any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. The readable storage medium may include, for example, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or device, or any combination thereof. More specific examples (a non-exhaustive list) of readable storage media include: an electrical connection with one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof.

[0159] It should be noted that the terms used in this application are only for describing specific embodiments and are not intended to limit the scope of this application. As shown in the specification and claims of this application, unless the context clearly indicates an exception, the words "one", "an", "a kind of" and / or "the" do not specifically refer to the singular and may also include the plural. The terms "comprise", "include" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method or device. In the absence of further restrictions, the elements defined by the sentence "comprise a..." do not exclude the presence of other identical elements in the process, method or device comprising the elements.

[0160] It should also be noted that the terms "center", "up", "down", "left", "right", "vertical", "horizontal", "inside", "outside", etc., indicating orientations or positional relationships, are based on the orientations or positional relationships shown in the accompanying drawings, and are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be understood as a limitation on this application. Unless otherwise clearly specified and limited, the terms "installed", "connected", "connected", etc. should be understood in a broad sense, for example, it can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be a direct connection, or an indirect connection through an intermediate medium, or it can be a communication between the internal parts of two elements. For those of ordinary skill in the art, the specific meanings of the above terms in this application can be understood according to specific circumstances.

[0161] This article uses specific examples to illustrate the principles and implementation methods of this application. The description of the above embodiments is only used to help understand the method and core ideas of this application. The above is only the preferred implementation method of this application. It should be pointed out that due to the limitations of textual expression, there are objectively infinite specific structures. For ordinary technicians in this technical field, without departing from the principles of this application, they can also make several improvements, modifications or changes, and can also combine the above technical features in an appropriate manner; these improvements, modifications, changes or combinations, or the direct application of the inventive concept and technical solution to other occasions without improvement, should be regarded as the scope of protection of this application.

Claims

1. A method for upgrading a vehicle ECU, characterized in that: Applied to a distributed communication system, the distributed communication system includes a vehicle gateway, an OTA master deployed on a first device, and middleware deployed on a second device. The vehicle ECU upgrade method includes: The OTA master controller creates an OTA upgrade program corresponding to the target ECU in response to detecting an upgrade instruction corresponding to the target ECU; The OTA upgrade program calls the middleware, and the middleware creates a client corresponding to the OTA upgrade program and obtains a corresponding client identifier; The middleware obtains the upgrade communication information of the target ECU, associates the client identifier with the upgrade communication information and stores the associated information, and synchronizes the client identifier and the upgrade communication information to the OTA master, so that the OTA master stores the associated information. The OTA master controller obtains a client identifier corresponding to the OTA upgrade program of the target ECU, and sends the data of the installation package to the client corresponding to the client identifier in the middleware through the OTA upgrade program; During the data transmission process, the OTA master controller suspends data transmission in response to detecting that the client is operating abnormally, and the middleware restarts the client in response to detecting that the client is operating abnormally; In response to detecting that the pause duration has reached a preset duration, the OTA master control continues to send the data of the installation package to the client corresponding to the client identifier through the OTA upgrade program, so that the vehicle gateway upgrades the target ECU based on the installation package.

2. The vehicle ECU upgrade method according to claim 1, characterized in that: After the middleware restarts the client in response to detecting that the client is running abnormally, the method further includes: If the middleware fails to restart the client, the middleware reclaims the memory resources occupied by the client, creates a new client, and obtains the client identifier corresponding to the new client; The middleware obtains the associated client identifier based on the upgrade communication information of the target ECU, and determines whether the client identifier associated with the upgrade communication information is the same as the new client identifier. If different, the client identifier associated with the upgrade communication information is used to update the new client identifier.

3. The vehicle ECU upgrade method according to claim 2, characterized in that: After the middleware uses the client identifier associated with the upgrade communication information to update the new client identifier, the method further includes: The middleware stores the updated client identifier in association with the upgrade communication information, and synchronizes the updated client identifier and the upgrade communication information to the OTA master, so that the OTA master updates the content stored in association with the upgrade communication information.

4. The vehicle ECU upgrade method according to claim 1, characterized in that: The vehicle gateway upgrades the target ECU based on the installation package, including: The client stores the data of the installation package in the second device; In response to detecting the flashing request corresponding to the target ECU, the client sends the data of the installation package to the server in the vehicle gateway; The server upgrades the target ECU based on the data of the installation package.

5. The vehicle ECU upgrade method according to claim 4, characterized in that: The server upgrades the target ECU based on the data in the installation package, including: The server obtains the protocol type supported by the target ECU and determines whether data conversion is required based on the protocol type; If so, the server performs data conversion on the data of the installation package based on the protocol type, and sends the converted data to the target ECU.

6. The vehicle ECU upgrade method according to claim 1, characterized in that: The method further comprises: In response to detecting an upgrade query request for the target ECU, the middleware sends a current version read request to the vehicle gateway to obtain the current version information of the target ECU, and sends a latest version read request to the OTA master controller to enable the OTA master controller to request the latest version information of the target ECU from the OTA cloud platform; If the OTA master determines that the latest version information is different from the current version information, the upgrade confirmation information is displayed to the human-computer interaction interface through the middleware; In response to detecting that a user triggers a confirmation upgrade operation on the human-computer interaction interface, it is determined that the upgrade instruction is detected.

7. The vehicle ECU upgrade method according to claim 1, characterized in that: The method further comprises: If the OTA master detects that the client fails to restart and recreate within the preset time period, it generates an upgrade failure message and sends the upgrade failure message to the OTA cloud platform or the vehicle interface.

8. A vehicle, characterized in that: The vehicle includes a distributed communication system, which includes a vehicle gateway, an OTA master controller deployed on a first device, and middleware deployed on a second device, wherein: The OTA master controller creates an OTA upgrade program corresponding to the target ECU in response to detecting an upgrade instruction corresponding to the target ECU; The OTA upgrade program calls the middleware, and the middleware creates a client corresponding to the OTA upgrade program and obtains a corresponding client identifier; The middleware obtains the upgrade communication information of the target ECU, associates the client identifier with the upgrade communication information and stores the associated information, and synchronizes the client identifier and the upgrade communication information to the OTA master, so that the OTA master stores the associated information. The OTA master controller obtains a client identifier corresponding to the OTA upgrade program of the target ECU, and sends the data of the installation package to the client corresponding to the client identifier in the middleware through the OTA upgrade program; During the data transmission process, the OTA master controller suspends data transmission in response to detecting that the client is operating abnormally, and the middleware restarts the client in response to detecting that the client is operating abnormally; In response to detecting that the pause duration has reached a preset duration, the OTA master control continues to send the data of the installation package to the client corresponding to the client identifier through the OTA upgrade program, so that the vehicle gateway upgrades the target ECU based on the installation package.

Images