Upgrading method of vehicle ECU (Electronic Control Unit) and vehicle

Abstract

The invention provides a vehicle ECU upgrading method and a vehicle, and the method comprises the steps: obtaining a client identifier corresponding to an OTA upgrading program of a target ECU in response to a detected upgrading instruction corresponding to the target ECU by an OTA master controller deployed on a first device, and sending data of the installation package to a client corresponding to the client identifier in middleware deployed in the second equipment through the OTA upgrade program, in a data sending process, pausing data sending in response to detection of abnormal operation of the client by the OTA master control, and restarting the client in response to detection of abnormal operation of the client by the middleware. Further, the OTA master control continues to send data through the OTA upgrading program when the pause duration reaches the preset duration, non-inductive data transmission of the OTA master control in the abnormal state is achieved, it is avoided that the OTA master control applies for the handle ID again when the data transmission is abnormal, and then upgrading and flashing failures caused by failure of the initial handle ID are avoided.

Description

Technical Field

[0001] This application relates to the technical field of OTA upgrades, and particularly to a method for upgrading a vehicle ECU and a vehicle. Background Art

[0002] Automobile OTA (Over-The-Air Technology) upgrade refers to using over-the-air technology for firmware upgrade and software upgrade. OTA not only brings a more convenient vehicle upgrade path but also allows users to experience a more intelligent and convenient driving experience. It upgrades its own system by downloading software update packages from a remote server through the network.

[0003] Currently, when flashing an ECU (Electronic Control Unit) based on OTA upgrade, usually the OTA master application downloads the upgrade file of the ECU to the vehicle side and divides the upgrade file into multiple data packets to be flashed 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 malfunctions, the OTA master will not be able to detect this failure, resulting in communication failure and thus flash failure. Summary of the Invention

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

[0006] An embodiment of this application provides a method for upgrading a vehicle ECU, which is applied to a distributed communication system. The distributed communication system includes a vehicle gateway, an OTA master deployed on a first device, and a middleware deployed on a second device. The method for upgrading the vehicle ECU includes: In response to detecting an upgrade instruction corresponding to a target ECU, the OTA master 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 sending process, the OTA master responds to detecting that the client runs abnormally, pauses data sending, and the middleware responds to detecting that the client runs abnormally and restarts the client; When the OTA master responds to detecting that the pause duration reaches the preset duration, it 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.

[0007] 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, it further includes: The OTA master creates an OTA upgrade program corresponding to the target ECU; The OTA master creates a client corresponding to the OTA upgrade program in the middleware through the OTA upgrade program, and associatively stores the client identifier corresponding to the client with the upgrade communication information of the target ECU.

[0008] Optionally, the OTA master creates a client corresponding to the OTA upgrade program in the middleware through the OTA upgrade program, and associatively stores the client identifier corresponding to the client with the upgrade communication information of the target ECU, including: The OTA upgrade program calls the middleware, and the middleware creates a client corresponding to the OTA upgrade program to obtain the corresponding client identifier; The middleware obtains the upgrade communication information of the target ECU, associatively stores the client identifier with the upgrade communication information, and synchronizes the client identifier and the upgrade communication information to the OTA master, so that the OTA master associatively stores the client identifier and the upgrade communication information.

[0009] Optionally, after the middleware responds to detecting that the client runs abnormally and restarts the client, it further includes: If the middleware fails to restart the client, the middleware reclaims the memory resources occupied by the client and creates a new client to obtain 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 judges whether the client identifier associated with the upgrade communication information is the same as the new client identifier. If they are different, the client identifier associated with the upgrade communication information is used to update the new client identifier.

[0010] Optionally, after the middleware updates the new client identifier by using the client identifier associated with the upgrade communication information, the following steps are further included: 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 control, so that the OTA master control updates the content stored in association with the upgrade communication information.

[0011] Optionally, the vehicle gateway upgrades the target ECU based on the installation package, including: The client stores the installation package in the second device; In response to detecting a 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.

[0012] Optionally, the server upgrades the target ECU based on the data of 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.

[0013] Optionally, the method further includes: In response to detecting an upgrade query request for the target ECU, the middleware sends a current version reading request to the vehicle gateway to obtain the current version information of the target ECU, and sends a latest version reading request to the OTA master control, so that the OTA master control requests the latest version information of the target ECU from the OTA cloud platform; If the OTA master control determines that the latest version information is different from the current version information, it displays an upgrade confirmation message to the human-machine interface through the middleware; In response to detecting that the user triggers a confirmation upgrade operation on the human-machine interface, it is determined that the upgrade instruction is detected.

[0014] Optionally, the method further includes: If the OTA master control detects that the client fails to restart and fails to be recreated within the preset time period, it generates an upgrade failure message and sends the upgrade failure message to the OTA cloud platform or the in-vehicle interface.

[0015] An embodiment of the present application further provides a vehicle, which includes a distributed communication system. The distributed communication system includes a vehicle gateway, an OTA master deployed on a first device, and a middleware deployed on a second device, where: In response to detecting an upgrade instruction corresponding to a target ECU, the OTA master 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 sending process, when the OTA master detects that the client is running abnormally, it pauses the data sending. When the middleware detects that the client is running abnormally, it restarts the client; When the OTA master detects that the pause duration reaches a preset duration, it 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.

[0016] An embodiment of the present application further provides an electronic device, which includes: a processor and a memory; The processor is configured to execute the steps of the method for upgrading a vehicle ECU provided in any embodiment of the present application by calling a program or instruction stored in the memory.

[0017] An embodiment of the present application further provides a computer-readable storage medium, which stores a program or instruction, and the program or instruction causes a computer to execute the steps of the method for upgrading a vehicle ECU provided in any embodiment of the present application.

[0018] In summary, the present application proposes an upgrade method for a vehicle ECU. The method includes: the OTA master deployed on the first device responds to detecting an upgrade instruction corresponding to the target ECU, 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 deployed on the second device through the OTA upgrade program. During the data sending process, the OTA master responds to detecting that the client runs abnormally and pauses the data sending. The middleware responds to detecting that the client runs abnormally and restarts the client. Then, the OTA master responds to detecting that the pause duration reaches a preset duration and 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 and the middleware can detect the abnormality of the client. When the client runs abnormally, the OTA master pauses the data sending and waits for the middleware to restart the client, and then resumes the data sending through the restarted client, so that the OTA master still performs data transmission with the operations before the abnormality, realizing seamless data transmission, avoiding the OTA master re-applying for a handle ID when the data transmission is abnormal, and further avoiding the upgrade and flashing failure caused by the invalidation of the initial handle ID. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] In order to more clearly illustrate the specific embodiments of the present application or the technical solutions in the prior art, the following will briefly introduce the drawings required for use in the description of the specific embodiments or the prior art. Obviously, the drawings in the following description are some embodiments of the present application. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0020] Figure 1 is an overall vehicle architecture diagram provided by an embodiment of the present application; Figure 2 is a flowchart of an upgrade method for a vehicle ECU provided by an embodiment of the present application; Figure 3 is a schematic diagram of parallel flashing of multiple ECUs provided by an embodiment of the present application; Figure 4 is a schematic diagram of converting DoIP data to UDS data provided by an embodiment of the present application; Figure 5 is a schematic diagram of converting UDS data to DoIP data provided by an embodiment of the present application; Figure 6 is a schematic diagram of distributed communication upgrade provided by an embodiment of the present application; Figure 7 is a schematic diagram of internal modules of the OTA master and the middleware provided by an embodiment of the present application; Figure 8 It is a schematic structural diagram of an electronic device provided by an embodiment of the present application. Detailed implementation manners

[0021] The present application will be further described in detail below in conjunction with the accompanying drawings and embodiments. It can be understood that the specific embodiments described herein are only used to explain the related invention, rather than limiting the invention. Additionally, it should be noted that for the convenience of description, only the parts related to the invention are shown in the drawings.

[0022] It should be noted that, without conflict, the embodiments in the present application and the features in the embodiments can be combined with each other. The present application will be described in detail below with reference to the drawings and embodiments.

[0023] As mentioned in the background art, in view of the problems in the prior art, the present application proposes an upgrading method for a vehicle ECU. This method can be applied to a distributed communication system, which includes a vehicle gateway, an OTA master deployed on a first device, and a middleware deployed on a second device.

[0024] Among them, the vehicle gateway of the vehicle can be communicatively connected to each ECU. The OTA master can be communicatively connected to an OTA cloud platform. The OTA master is deployed on a first device of the vehicle, and the first device can be a VBOX (Vehicle Communication Box, vehicle communication terminal). The middleware can be communicatively connected to the vehicle gateway of the vehicle. The middleware is deployed on a second device of the vehicle, and the second device can be a CDC (Cockpit Domain Controller, cockpit domain controller or audio-visual entertainment controller).

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

[0026] Exemplarily, Figure 1 It is an overall vehicle architecture diagram provided by an embodiment of the present application. The upgrading method for the vehicle ECU provided by the embodiment of the present application mainly involves an OTA master, a middleware, and a vehicle gateway. As Figure 1 shown, the OTA master can be deployed in the vehicle communication terminal, and the middleware can be deployed in the audio-visual entertainment controller (i.e., the cockpit domain controller). The vehicle dynamic controller in the figure is mainly used for body control.

[0027] Among them, the vehicle communication terminal can communicate with the OTA cloud platform through a 4G or 5G network and communicate with vehicle gateways 1 to 4 through a 100M Ethernet; the audio and video entertainment controller can communicate with vehicle gateways 1 to 4 through a 100M Ethernet. Each of vehicle gateways 1 to 4 is connected to one or more ECUs. For example, vehicle gateway 1 is connected to ECUs 1-1 to 1-n, and vehicle gateway 2 is connected to ECUs 2-1 to 2-n. The vehicle gateway can communicate with each of the underlying ECUs through Ethernet or a CAN bus respectively.

[0028] Figure 2 is a flowchart of a method for upgrading a vehicle ECU provided by an embodiment of the present application. Refer to Figure 2 , the method for upgrading the vehicle ECU specifically includes: S110. In response to detecting an upgrade instruction corresponding to a target ECU, the OTA master 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.

[0029] Among them, the upgrade instruction can be actively sent by the OTA cloud platform after detecting new version information; or, the upgrade instruction can be that when the middleware detects that the user requests an upgrade query through the human-machine interface, it 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 to confirm with the user when the latest version information does not match the current version information, and generate it after the user confirms the upgrade.

[0030] In a specific implementation manner, the method provided by the embodiment of the present application further includes the following steps: Step 101. In response to detecting an upgrade query request for a target ECU, the middleware sends a current version reading request to the vehicle gateway to obtain the current version information of the target ECU, and sends a latest version reading request to the OTA master, so that the OTA master requests the latest version information of the target ECU from the OTA cloud platform; Step 102. If the OTA master determines that the latest version information is different from the current version information, it displays an upgrade confirmation message to the human-machine interface through the middleware, and in response to detecting that the user triggers a confirmation upgrade operation on the human-machine interface, determines that an upgrade instruction is detected.

[0031] 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 initiated by the user for the target ECU through the human-machine interface. Then, the middleware can send a current version reading request to the vehicle gateway, so that the vehicle gateway can obtain the current version information of the target ECU and return it to the middleware, and the middleware sends the current version information to the OTA master control; moreover, the middleware can send a latest version reading request to the OTA master control, so that the OTA master control requests the latest version information of the target ECU from the OTA cloud platform.

[0032] 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 they are different, it means that the target ECU needs to be upgraded. At this time, the upgrade confirmation information can be displayed on the human-machine interface through the middleware. For example, the upgrade confirmation information is sent to the middleware, so that the middleware forwards it to the human-machine interface for display.

[0033] After the upgrade confirmation information is displayed, if it is detected that the user triggers the confirm upgrade operation on the human-machine interface, an upgrade instruction for the target ECU can be determined to be detected.

[0034] Through the above steps 101 - step 102, the upgrade query of each ECU in the vehicle can be realized, so that each ECU that needs to be upgraded can be automatically judged and, after being confirmed by the user, the corresponding upgrade instruction can be generated, which is convenient for establishing the corresponding OTA upgrade program in a timely manner subsequently.

[0035] In the embodiment of the present application, if the OTA master control detects the upgrade instruction corresponding to the target ECU, it can first send the data of the installation package to the corresponding client connected to the OTA upgrade program through the OTA upgrade program of the target ECU.

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

[0037] Among them, the OTA master control can pre-create corresponding OTA upgrade programs for each ECU in the vehicle. 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. Subsequently, the OTA upgrade program can perform data transmission through the client identifier.

[0038] Alternatively, to further improve the rationality of resource utilization, when the OTA master detects an upgrade instruction for the target ECU, it can create a corresponding OTA upgrade program for the target ECU in real time. The OTA upgrade program creates a client in the middleware, enabling the client to create corresponding thread resources and allocate a client identifier to the OTA upgrade program. Subsequently, the OTA upgrade program can perform data transmission through this client identifier.

[0039] In a specific implementation, before obtaining the client identifier corresponding to the OTA upgrade program for 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 further included: Step 103: The OTA master creates an OTA upgrade program corresponding to the target ECU; 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.

[0040] Among them, in Step 103, in response to detecting an upgrade instruction for the target ECU, the OTA master first creates an OTA upgrade program corresponding to the target ECU in the first device. This OTA upgrade program is used to create a client for communicating with it in the middleware and perform data transmission with the client.

[0041] Furthermore, in Step 104, after the OTA master creates the OTA upgrade program corresponding to the target ECU, the OTA upgrade program can create a client corresponding to the OTA upgrade program in the middleware. Then, the client can create corresponding thread resources in the second device and allocate a client identifier (which can be understood as the identifier of the thread resource), and feedback the client identifier to the OTA upgrade program. After the OTA upgrade program obtains the client identifier, the OTA master can associate and store the client identifier with the upgrade communication information of the target ECU in the first device.

[0042] In an 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: Step 1041: The OTA upgrade program calls the middleware, and the middleware creates a client corresponding to the OTA upgrade program to obtain the corresponding client identifier; Step 1042: The middleware obtains the upgrade communication information of the target ECU, associates and stores the client identifier with the upgrade communication information, and synchronizes the client identifier and the upgrade communication information to the OTA master, so that the OTA master associates and stores the client identifier and the upgrade communication information.

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

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

[0045] Furthermore, the middleware can associate and store the client identifier and the upgrade communication information in the second device, and synchronize the client identifier and the upgrade communication information to the OTA master control. The OTA master control associates and stores the client identifier and the upgrade communication information in the first device. In this way, the middleware can realize the associated storage of the client identifier, and the OTA master control can realize the associated storage of the client identifier, which is convenient for the OTA master control to perform data transmission based on the client identifier in the future, and is convenient for the middleware to perform exception recovery based on the client identifier.

[0046] In the embodiment of the present application, in response to the upgrade instruction of the target ECU, after the OTA master control creates the corresponding OTA upgrade program and the OTA upgrade program creates the corresponding client, the OTA master control can send the data of the installation package to the client corresponding to the client identifier through the client identifier corresponding to the OTA upgrade program.

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

[0048] S120. During the data sending process, when the OTA master control detects that the client is running abnormally, it pauses the data sending. When the middleware detects that the client is running abnormally, it restarts the client.

[0049] Specifically, during the process of the OTA upgrade program sending the upgrade package data to the corresponding client, the OTA master control and middleware can perform anomaly detection on each client where data transmission is in progress. If the OTA master control detects that the client is running abnormally, it can pause data transmission to wait for the middleware to restart the client. If the middleware detects that the client is running abnormally, it can restart the client to attempt to restore the normal operation of the client. Among them, after the middleware restarts the client, the client identifier remains unchanged, and the OTA master control can continue to use this client identifier for data transmission later.

[0050] Considering that there may be a situation where the middleware fails to restart the client, to further ensure the reliability of data transmission, when the middleware fails to restart, a new client can also be re-created and the original client can be released.

[0051] In a specific implementation manner, after the middleware restarts the client in response to detecting that the client is running abnormally, the following steps are further included: 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 the client identifier corresponding to the new client. 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 they are different, the new client identifier is updated using the client identifier associated with the upgrade communication information.

[0052] 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 to obtain the client identifier corresponding to the new client.

[0053] Further, in Step 122, the middleware can query the client identifier associated with the upgrade communication information in the pre-stored information through the upgrade communication information of the target ECU. This client identifier is the identifier of the original client that has been released.

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

[0055] Through the above implementation, in the case where the middleware fails to restart the client, a new client consistent with the original client identifier can be re-created, while ensuring the seamless transmission of the OTA master control, further improving the reliability of data transmission. Moreover, by promptly releasing the resources occupied by the original client, the resource utilization rate of the device can be increased.

[0056] It should be noted that in the above implementation, the middleware can update the new client identifier based on the client identifier associated with the upgrade communication information, so that the identifier of the new client is consistent with that of the original client. However, considering the possible failure of the update, to prevent the OTA master control from using a client identifier different from that of the new client for data transmission, which may lead to transmission failure, the middleware can also synchronize the updated client identifier to the OTA master control for update.

[0057] In one example, after the middleware updates the new client identifier using the client identifier associated with the upgrade communication information, it 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 control, so that the OTA master control updates the content stored in association with the upgrade communication information.

[0058] Specifically, after the middleware updates the identifier of the new client, it can store the updated client identifier in association with the upgrade communication information, and at the same time delete the client identifier originally associated with the upgrade communication information stored, and then synchronize the updated client identifier and the upgrade communication information to the OTA master control.

[0059] Furthermore, the OTA master control can 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, and at the same time delete the client identifier originally associated with the upgrade communication information stored.

[0060] Through the above example, after the middleware updates the new client identifier, the content stored in association between the middleware and the OTA master control can be updated, preventing the OTA master control from using different client identifiers for data transmission, which may lead to transmission failure, and further ensuring the reliability of data transmission.

[0061] S130. In response to detecting that the pause duration reaches the 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.

[0062] Specifically, when the OTA master detects an abnormality in the client, it pauses data transmission and starts timing 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 data of the installation package to the corresponding client through the OTA upgrade program.

[0063] Among them, the preset duration can be the duration set in advance for waiting for the middleware to restart the client, or the preset duration can be the duration set in advance for waiting for the middleware to restart the client and reconstruct the client.

[0064] In the embodiment of the present application, considering that there may be a situation where the middleware fails to restart the client or fails to reconstruct the client within the preset duration due to reasons such as high system load, in this case, the OTA master can promptly return a prompt message to prompt the user that the upgrade package download fails.

[0065] In some embodiments, the method provided by the embodiment of the present application further includes: If the OTA master detects that the client fails to restart and fails to recreate within the preset duration, it generates an upgrade failure message and sends the upgrade failure message to the OTA cloud platform or the in-vehicle unit interface.

[0066] Specifically, if the OTA master detects that the pause duration reaches the preset duration, and the middleware fails to restart the client and fails to reconstruct, the OTA master can determine that the protocol stack of the middle layer is irrecoverable, generate an upgrade failure message, and report the upgrade failure message to the OTA cloud platform or the in-vehicle unit interface to prompt that the upgrade package download fails, facilitating subsequent re-attempts to download the upgrade package.

[0067] Through the above implementation, in the case where the middleware fails to restart the client or fails to reconstruct the client within the preset duration, a prompt can be made in a timely manner to facilitate subsequent continued attempts to download the upgrade package.

[0068] After the client receives the complete data of the installation package, the client can transfer it to the server side of the vehicle gateway (DoIP and UDS server side). Among them, the relationship between the client and the server can be one-to-many, that is, multiple clients can connect to one server.

[0069] Specifically, after receiving the installation package, the server in the vehicle gateway can forward the message according to the address of the target ECU, and transmit the installation package of the target ECU to the target ECU in the form of a message for upgrade and flashing. Among them, since the OTA master and the client are installed on the first device and the second device respectively, the middleware of the second device needs to be synchronized with the OTA master, otherwise the upgrade and flashing will fail due to a fault.

[0070] Exemplarily, Figure 3It is a schematic diagram of parallel flashing of multiple ECUs provided by an embodiment of the present application. As Figure 3 shown, the middleware in the audio-visual entertainment controller and the server in the vehicle gateway can be regarded as OTA upgrade agents, and the ECUs 1~n to be flashed can be regarded as OTA upgrade slaves. The OTA master can create OTA upgrade programs for each ECU to be flashed, that is, ECUs 1~n, respectively, to obtain OTA upgrade programs 1~n. The OTA upgrade programs can create corresponding clients in the audio-visual entertainment controller to obtain clients 1~n.

[0071] Among them, the OTA upgrade programs 1~n can be respectively connected to the clients 1~n to transmit the upgrade packages of the corresponding ECUs to the clients 1~n. The clients 1~n can be connected to the server in the vehicle gateway through Ethernet to transmit the upgrade packages of the corresponding ECUs to the server. Further, the server can send the upgrade package to the ECUs 1~n to be upgraded through Ethernet or Controller Area Network (CAN) for upgrade flashing.

[0072] In a specific embodiment, the vehicle gateway upgrades the target ECU based on the installation package, including the following steps: Step 131: The client stores the installation package in the second device; Step 132: The client responds to the detected flashing request corresponding to the target ECU and sends the data of the installation package to the server in the vehicle gateway; Step 133: The server upgrades the target ECU based on the data of the installation package.

[0073] Among them, in step 131, the client can first store the data of the installation package in the second device; the user can initiate a flashing request for the target ECU through the human-machine interface.

[0074] Specifically, in step 132, the flashing request can be generated by the OTA upgrade program after the data transmission of the installation package is completed, that is, when the OTA upgrade program detects that the data transmission of the installation package is completed, it can send the flashing request corresponding to the target ECU to the client.

[0075] Further, if the client detects the flashing request, it can send the data of the installation package to the server in the vehicle gateway. Then, in step 133, the server can send the data of the installation package to the target ECU for upgrade flashing.

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

[0077] In one example, the server upgrades the target ECU based on the data of 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.

[0078] Among them, 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 according to the protocol type.

[0079] Exemplarily, for a target ECU that supports the Ethernet function, the DoIP protocol can be used for OTA upgrade flashing, and for a target ECU that does not support the Ethernet function, the UDS protocol can be used for OTA upgrade flashing. Therefore, for a target ECU that does not support the Ethernet function, it can be determined that data conversion is required to convert the data of the upgrade package into the protocol type supported by the target ECU, such as UDS data.

[0080] Figure 4 FIG. is a schematic diagram of converting DoIP data to UDS data provided by an embodiment of the present application. As Figure 4 shown, for a target ECU that does not support the Ethernet function, the upgrade package can be converted from the DoIP type to the UDS type. Among them, the DoIP data frame can be composed of an Ethernet header (EthHead), an IP header (IPHead), a transport layer header (TCP / UDP Head), a DoIP header (DoIPHead), a source address, a target address, and DoIP data. The UDS data frame can be composed of a CAN identifier (CANID), a data length code (DLC), a protocol control information (DoCAN PCI), and UDS data, etc.

[0081] Specifically, converting DoIP data to UDS data is mainly to convert the data format sent by the OTA master control to the data format supported by the OTA upgrade slave control (i.e., the ECU). In this process, mainly the content filled in the field corresponding to the target address in the DoIP data (i.e., the logical address) is converted into the content filled in the field corresponding to the CAN identifier in the UDS data (i.e., the request ID).

[0082] In addition to converting from DoIP data to UDS data during the process of sending the upgrade package to the target ECU, considering that there may be a situation where the target ECU feeds back data to the vehicle gateway, for such a situation, the server of the vehicle gateway can also convert the UDS data fed back by the target ECU to DoIP data, so as to facilitate subsequent feedback of the DoIP data to the OTA master control through the client.

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

[0084] Specifically, converting UDS data into DoIP data is mainly a conversion from the data format supported by the OTA slave (i.e., the ECU) to the data format supported by the OTA master. In this process, mainly the content filled in the field corresponding to the CAN identifier in the UDS data (i.e., the request ID) is converted into the content filled in the field corresponding to the source address in the DoIP data (i.e., the logical address).

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

[0086] Figure 6 It is a schematic diagram of distributed communication upgrade provided by an embodiment of the present application, Figure 6 describing the OTA vehicle-cloud communication process, human-machine interaction process, upgrade file package signature verification process, timeout management process, file download process, and upgrade management process, etc. Among them, VBOX can carry the OTA master, and CDC can carry the middleware.

[0087] As Figure 6 shown, among them, the user can initiate an upgrade query through the human-machine interaction module. Then, the human-machine 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 a request for the upgrade query to the OTA cloud platform. And, the human-machine interaction module can also send a request for reading the version information 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.

[0088] Further, the user can initiate an installation instruction through the human-machine interaction module, and the human-machine interaction module sends it to the upgrade management module of VBOX. The upgrade management module creates an OTA upgrade program corresponding to the target ECU through the OTA master control application management in the state machine management module, so as to interact with the communication protocol stack management module in the CDC through the OTA upgrade program, enabling the CDC to call the protocol stack to create a client corresponding to the OTA upgrade program. Furthermore, the vehicle-cloud communication module can send the verified upgrade package to the client through the OTA upgrade program created by the OTA master control. During the sending process, the state machine management module can also perform timeout detection according to the timing management to implement timeout management, that is, pause the transmission when a transmission exception is detected, and perform timeout detection during the waiting process.

[0089] 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 can forward the upgrade result to the OTA cloud platform.

[0090] The method for upgrading a vehicle ECU provided by an embodiment of the present application includes: the OTA master deployed on the first device, in response to detecting an upgrade instruction corresponding to the target ECU, 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 deployed on the second device through the OTA upgrade program. During the data sending process, the OTA master, in response to detecting that the client runs abnormally, pauses the data sending. The middleware, in response to detecting that the client runs abnormally, restarts the client. Furthermore, the OTA master, in response to detecting that the pause duration reaches a preset duration, 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 and the middleware can detect the abnormality of the client. When the client runs abnormally, the OTA master pauses the data sending and waits for the middleware to restart the client, and then resumes the data sending through the restarted client, enabling the OTA master to still perform data transmission with the same operation as before the abnormality, realizing seamless data transmission, avoiding the OTA master from re-applying for the handle ID when the data transmission is abnormal, and thus avoiding the upgrade flashing failure caused by the invalidation of the initial handle ID.

[0091] For the same purpose, an embodiment of the present application further provides a vehicle, which includes a distributed communication system. The distributed communication system includes a vehicle gateway, an OTA master deployed on a first device, and a middleware deployed on a second device, where: In response to detecting an upgrade instruction corresponding to a target ECU, the OTA master 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 sending process, in response to detecting that the client is running abnormally, the OTA master pauses the data sending, and in response to detecting that the client is running abnormally, the middleware restarts the client; In response to detecting that the pause duration reaches a preset duration, the OTA master 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.

[0092] Figure 7 It is a schematic diagram of internal modules of an OTA master and a middleware provided by an embodiment of the present application. As Figure 7 shown, the OTA master deployed in the 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 the CDC can be composed of a client process generation module, a client process destruction module, a client process monitoring module, a client identifier synchronization module, a client process ID replication module, a client memory module, and a client process restart module. The OTA master and the middleware communicate through Ethernet.

[0093] Among them, when the OTA master needs to upgrade one or more target ECUs, it can establish OTA upgrade programs corresponding to the target ECUs. The OTA upgrade program calls the DoIP and UDS protocol stacks of the middleware. The middleware establishes a client for communicating with the OTA upgrade program through the client process generation module. The client creates corresponding thread resources and assigns a client identifier (CLIENTID) to the OTA upgrade program. The client is connected to the server in the VIU. The server 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 the CLIENTID for data communication transmission. When the OTA master detects that the upgrade is completed, it can call the middleware to release the thread corresponding to the CLIENTID (i.e., destroy the client) and recycle relevant resources.

[0094] Since the OTA master control and the middleware (DOIP and UDS protocol stacks) are placed on two different devices respectively, when an exception occurs in the middleware device (CDC) or the middleware thread is abnormal or destroyed due to a restart, the OTA master control in VBOX will not be able to perceive these changes at this time and still use the invalid CLIENTID to operate communication messages, which will lead to communication transmission failure at this time. And the abnormal situation of the middleware device (CDC) may cause the thread not to be actively released by the OTA master control, resulting in memory leakage, and in severe cases, it will cause the CDC system to crash.

[0095] Therefore, to solve this technical problem, after the middleware obtains the CLIENTID, the middleware can associate and store the upgraded communication information such as the source IP address, destination IP address, source port, and destination port with the CLIENTID through the client memory module, and send this information to the OTA master control through the client identifier synchronization module. The OTA master control associates and stores the upgraded communication information with the CLIENTID through the internal address information storage module. At the same time, the OTA master control can detect whether the client is running abnormally through the internal client process monitoring module, and the middleware can also detect whether the client is running abnormally through the internal client process monitoring module.

[0096] When the client process monitoring module of the OTA master control detects that the thread running state of the middleware is abnormal, the OTA master control can pause sending communication messages to wait for the restart of the client (i.e., wait for the recovery of the thread). When the client process monitoring module of the middleware detects that the thread running state of the middleware is abnormal, the middleware can restart the client through the client process restart module. The waiting time of the OTA master control can be 15 seconds. If it exceeds 15 seconds, it is considered that the thread cannot be recovered, and a prompt message of upgrade failure can be reported. If it is recovered, the data will be transmitted continuously.

[0097] During the process of the middleware restarting the thread, the CLIENTID of the client will remain unchanged. After restarting, the OTA master control can continue to use this CLIENTID for communication message transmission. If the middleware fails to restart the thread (the middleware protocol stack process crashes or restarts), the middleware can recycle the memory resources occupied by the thread through the client process destruction module, and recreate a new thread according to the information saved in the client memory module and obtain the corresponding CLIENTID.

[0098] Further, 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 they are different, the new CLIENTID is replaced with the originally stored CLIENTID through the client process ID replication module, and the replaced ID is synchronized to the OTA master through the client identifier synchronization module. Meanwhile, the OTA master updates the stored information.

[0099] Since the CLIENTID of the middleware reconstruction process is the same as the CLIENTID before the anomaly, the OTA master can still perform data transmission by operating the previous CLIENTID, achieving a seamless operation without the need to reapply for a handle ID, thus avoiding the invalidation of the previous handle ID caused by reapplying for a handle ID, and further avoiding the failure of the upgrade flashing, greatly improving the transmission efficiency of communication messages and the upgrade success rate.

[0100] The vehicle provided by the embodiment of the present application is applicable to the vehicle ECU upgrade method provided by the method embodiment of the present application, and the implementation steps and beneficial effects are not elaborated here.

[0101] Figure 8 It is a schematic structural diagram of an electronic device provided by an embodiment of the present application. As Figure 8 shown, the electronic device 400 includes one or more processors 401 and a memory 402.

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

[0103] The memory 402 may include one or more computer program products, and the computer program products 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, etc. The non-volatile memory may include, for example, read-only memory (ROM), 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 run 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 thresholds may also be stored in the computer-readable storage medium.

[0104] In one example, the electronic device 400 may further include: an input device 403 and an output device 404, and these components are interconnected through a bus system and / or other forms of connection mechanisms (not shown). The input device 403 may include, for example, a keyboard, a mouse, and so on. The output device 404 may output various information to the outside, including warning prompt information, braking force, and so on. The output device 404 may include, for example, a display, a speaker, a printer, and a communication network and its connected remote output devices, and so on.

[0105] Of course, for simplicity, Figure 8 only some of the components related to the present application in the electronic device 400 are shown, and components such as a bus, an input / output interface, and so on are omitted. In addition, according to specific application scenarios, the electronic device 400 may further include any other appropriate components.

[0106] In addition to the above methods and devices, an embodiment of the present application may also be a computer program product, which includes computer program instructions, and when the computer program instructions are run by a processor, the processor is caused to execute the steps of the vehicle ECU upgrade method provided in any embodiment of the present application.

[0107] The computer program product may be written in any combination of one or more programming languages for programming code to perform the operations of the embodiments of the present application. The programming languages include object-oriented programming languages, such as Java, C++, etc., and also include conventional procedural programming languages, such as the "C" language or similar programming languages. The programming code may be executed entirely on a user computing device, partially on the user device, executed as an independent software package, partially on the user computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0108] Furthermore, an embodiment of the present application may also be a computer-readable storage medium, on which computer program instructions are stored, and when the computer program instructions are run by a processor, the processor is caused to execute the steps of the vehicle ECU upgrade method provided in any embodiment of the present application.

[0109] The computer-readable storage medium may adopt any combination of one or more readable media. The readable media 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, apparatus, or device, or any combination of the above. More specific examples (non-exhaustive list) of the readable storage medium 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 disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above.

[0110] It should be noted that the terms used in this application are only for describing specific embodiments and do not limit the scope of this application. As shown in the specification and claims of this application, unless the context clearly indicates otherwise, words such as "a", "an", "one", and / or "the" are not specifically singular and may also include the plural. The term "comprising", "including", or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, or device including a series of elements not only includes those elements but also includes other elements not explicitly listed, or further includes elements inherent to such a process, method, or device. Without further limitation, an element defined by the statement "including one..." does not exclude the existence of additional identical elements in the process, method, or device including the said element.

[0111] It should also be noted that the orientation or positional relationship indicated by terms such as "center", "upper", "lower", "left", "right", "vertical", "horizontal", "inner", "outer", etc. is based on the orientation or positional relationship shown in the drawings, and is only for the convenience of describing this application and simplifying the description, rather than indicating or implying 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 of this application. Unless otherwise clearly specified and defined, terms such as "installed", "connected", "coupled" should be understood in a broad sense. For example, it may be a fixed connection, a detachable connection, or an integral connection; it may be a mechanical connection or an electrical connection; it may be directly connected or indirectly connected through an intermediate medium, and it may be the internal communication 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.

[0112] In this article, specific examples are used to elaborate on the principles and implementation manners of the present application. The description of the above embodiments is only for helping to understand the method and its core idea of the present application. The above is only the preferred implementation manner of the present application. It should be noted that due to the limited nature of literal expression and objectively infinite specific structures, for those of ordinary skill in the art, without departing from the principles of the present application, several improvements, embellishments or changes can also be made, or the above technical features can be combined in an appropriate manner; these improvements, embellishments, changes or combinations, or directly applying the inventive concept and technical solution to other occasions without improvement, shall all be regarded as the protection scope of the present 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 a middleware deployed on a second device. The method for upgrading a vehicle ECU includes: In response to detecting an upgrade instruction corresponding to a target ECU, the OTA master 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 sending process, in response to detecting that the client is running abnormally, the OTA master suspends the data sending, and in response to detecting that the client is running abnormally, the middleware restarts the client; In response to detecting that the suspension duration reaches a preset duration, the OTA master 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 upgrading method of the vehicle ECU according to claim 1, characterized in that 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, it further includes: The OTA master creates an OTA upgrade program corresponding to the target ECU; 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.

3. The vehicle ECU upgrade method according to claim 2, wherein, 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 OTA upgrade program calls the middleware, and the middleware creates a client corresponding to the OTA upgrade program to obtain a corresponding client identifier; The middleware obtains the upgrade communication information of the target ECU, associates and stores the client identifier with the upgrade communication information, and synchronizes the client identifier and the upgrade communication information to the OTA master, so that the OTA master associates and stores the client identifier with the upgrade communication information.

4. The upgrading method of the vehicle ECU according to claim 1, wherein, After the middleware restarts the client in response to detecting that the client is running abnormally, it further includes: If the middleware fails to restart the client, the middleware reclaims the memory resources occupied by the client and creates a new client to obtain a 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 client identifier of the new client. If they are different, the middleware uses the client identifier associated with the upgrade communication information to update the client identifier of the new client.

5. The upgrading method of the vehicle ECU according to claim 4, characterized in that, After the middleware uses the client identifier associated with the upgrade communication information to update the client identifier of the new client, it further includes: The middleware associates and stores the updated client identifier with the upgrade communication information, and synchronizes the updated client identifier and the upgrade communication information to the OTA master control, so that the OTA master control updates the content associated and stored with the upgrade communication information.

6. The method for upgrading a vehicle ECU according to claim 1, wherein 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 a 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.

7. The upgrade method of the vehicle ECU according to claim 6, wherein, The server upgrades the target ECU based on the data of 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.

8. The method for upgrading a vehicle ECU according to claim 1, wherein, The method further includes: In response to detecting an upgrade query request for the target ECU, the middleware sends a current version reading request to the vehicle gateway to obtain the current version information of the target ECU, and sends a latest version reading request to the OTA master control, so that the OTA master control requests the latest version information of the target ECU from the OTA cloud platform; If the OTA master control determines that the latest version information is different from the current version information, it displays an upgrade confirmation message to the human-machine interface through the middleware; In response to detecting that the user triggers a confirmation upgrade operation on the human-machine interface, it is determined that the upgrade instruction is detected.

9. The method for upgrading a vehicle ECU according to claim 1, wherein The method further includes: If the OTA master control detects that the client fails to restart and fails to be recreated within the preset duration, it generates an upgrade failure message and sends the upgrade failure message to the OTA cloud platform or the in-vehicle interface.

10. A vehicle, characterized in that, The vehicle includes a distributed communication system, and the distributed communication system includes a vehicle gateway, an OTA master control deployed on a first device, and a middleware deployed on a second device, wherein: In response to detecting an upgrade instruction corresponding to the target ECU, the OTA master control 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; During the data sending process, in response to detecting that the client runs abnormally, the OTA master control pauses the data sending, and in response to detecting that the client runs abnormally, the middleware restarts the client; In response to detecting that the pause duration reaches the 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