Method for updating an electronic control unit, ecu, and terminal

Abstract

Provided are an electronic control unit (ECU) updating method and an ECU. The method comprises: a second ECU acquiring a first file from a first ECU (S320), the first file being a file stored locally by the first ECU; and the second ECU updating according to the first file (S330). The first ECU and the second ECU are located in the same terminal. The first file stored locally by the first ECU is transmitted to the second ECU through communication between the ECUs in the terminal, so that the second ECU can be updated, and the flexibility and updating efficiency of the ECU are improved.

Description

[0001] This application is a divisional application. The original application has the application number 202180001811.1 and the original application date is June 30, 2021. The entire contents of the original application are incorporated herein by reference. Technical Field

[0002] This application relates to the field of vehicles, specifically to a method for ECU updating, an ECU, and a terminal. Background Technology

[0003] With social development, intelligent transportation equipment, smart home devices, robots, and other intelligent terminals are gradually entering people's daily lives.

[0004] In intelligent vehicles, the electronic control unit (ECU) executes programs to process data. It can be understood as a microcomputer controller in the field of autonomous driving, or a vehicle-specific microcontroller. Each ECU includes a processor and memory. The processor executes programs stored in the memory to perform specific functions. Updates to the ECU's applications can be achieved through hardware replacement, near-end upgrades, and over-the-air (OTA) updates, thereby upgrading or fixing the applications. Summary of the Invention

[0005] This application provides an ECU update method, an ECU, and a terminal, which improves the flexibility and efficiency of ECU updates and reduces costs.

[0006] In a first aspect, a method for updating an ECU is provided, the method comprising: a second ECU obtaining a first file from a first ECU, the first file being a file locally stored in the first ECU; the second ECU updating according to the first file; and the first ECU and the second ECU being located in the same terminal.

[0007] The documents described in this application may also be referred to as version files, programs, program files, software, or software versions, etc., indicating programs or software that can be used or run on an ECU. For example, the first file may be an application program (APP) file, specifically a version file of an APP that has not been updated for the first ECU. The first file can be understood as an object file or object program, and the second file described below can be understood as the source file or source program.

[0008] By utilizing the communication between the first ECU and the second ECU in the terminal, the second ECU can be updated to the first file stored locally by the first ECU, eliminating the need for each ECU to retrieve the first file from the external network, thus improving the flexibility of file updates in the ECU.

[0009] In conjunction with the first aspect, in some possible implementations, the second ECU obtaining the first file from the first ECU includes: if an update requirement is met, the second ECU obtaining the first file from the first ECU, wherein the update requirement includes the first file having a version higher than the second file, and the second file being a file used by the second ECU when it is not updated. For example, the second file is a version file of an app that the second ECU can update.

[0010] By setting update requirements, the first ECU sends a first file to the second ECU when the update requirements are met. This allows the file versions in the first and second ECUs to match and be compatible, thereby enhancing the compatibility between ECUs and improving the functional coordination between them.

[0011] Newer versions of the file offer better performance. Using the newer version of the first file to process data improves processing performance. Furthermore, using the same version of the file across all ECUs ensures consistent processing results.

[0012] In conjunction with the first aspect, in some possible implementations, the method further includes: the second ECU sending version information to the first ECU, the version information being used to indicate the version of the second file; the second ECU obtaining the first file from the first ECU, including: receiving the first file, the first file being sent by the first ECU after determining, based on the version information, that it meets the update requirements.

[0013] The first ECU can determine whether the second file needs to be updated based on the version information sent by the second ECU. The first ECU can also determine whether to send the first file to the second ECU without requiring additional equipment, making implementation simpler and reducing costs. For example, the first ECU can periodically check whether other ECUs on the terminal are working properly or whether their versions are too low, allowing the first ECU to decide whether to send the first file to other ECUs based on the actual situation.

[0014] In conjunction with the first aspect, in some possible implementations, the second ECU obtains the first file from the first ECU, including: when the second file is abnormal, the second ECU obtains the first file from the first ECU, wherein the second file is the file used by the second ECU when it has not been updated.

[0015] If there is an anomaly in the second file in the second ECU, the first ECU sends the target program to the second ECU, which can update the abnormal file in the second ECU in a timely manner.

[0016] In conjunction with the first aspect, in some possible implementations, before the second ECU updates according to the first file, the method further includes: the second ECU detecting whether the second file is normal. Optionally, before the second ECU updates according to the first file, the second ECU may also detect whether the first file is normal.

[0017] The second ECU checks whether the second file in the second ECU is normal, and the detection method is relatively simple.

[0018] For example, the second ECU can also detect whether the updated file is abnormal. Optionally, the second ECU can periodically detect whether the updated file is abnormal, so as to detect in a timely manner whether the second ECU can be updated normally, and if it can be updated normally, whether it can work normally, thereby ensuring the normal operation of the ECU and improving the reliability of the ECU.

[0019] In addition, the second ECU detects whether there are any anomalies in the updated files. If there are anomalies in the updated files, the files can be retrieved again, thereby ensuring that the ECU works normally and improving the reliability of the ECU.

[0020] In conjunction with the first aspect, in some possible implementations, the second ECU detects whether the first file is normal, including: the second ECU performs an integrity check on the first file.

[0021] Integrity checks can be used to verify whether the first file is normal, providing an effective method for determining whether a file is normal.

[0022] In conjunction with the first aspect, in some possible implementations, the first file is obtained by the first ECU from the terminal's communication box (TBOX). That is, the first file can be obtained by the first ECU periodically or irregularly from the external network (internet connection) via OTA.

[0023] For example, when the programs in the first ECU and the second ECU of a terminal need to be upgraded, the terminal obtains the first file from the external network via OTA (Over-The-Air) updates. Then, through the terminal's TBOX and / or gateway, it sends the first file to the first ECU, thus updating the program in the first ECU. When sending the first file to the second ECU via the first ECU, the TBOX does not need to send the same file to each ECU. In other words, the TBOX does not need to repeatedly obtain and forward the first file, thereby saving transmission resources for ECU updates.

[0024] In conjunction with the first aspect, in some possible implementations, the method further includes: before the second ECU obtains the first file from the first ECU, determining whether the second ECU needs to obtain the first file.

[0025] The first ECU or the second ECU can determine whether the second ECU needs to obtain the first file.

[0026] In conjunction with the first aspect, in some possible implementations, the second ECU obtains first version information, which is used to represent the version of the first file; based on the first version information, the second ECU compares the version of the first file with the version of the second file; the second ECU obtaining the first file from the first ECU includes: when the version of the second file is lower than the version of the first file, the second ECU obtains the first file from the first ECU.

[0027] In conjunction with the first aspect, in some possible implementations, the method further includes: before the second ECU obtains the first file from the first ECU, the second ECU detects whether the second file is abnormal; the second ECU obtaining the first file from the first ECU includes: when the second file is abnormal, the second ECU obtains the first file from the first ECU.

[0028] The second ECU detects whether the second file is abnormal, and if the second file is abnormal, it retrieves the first file and can update the second file in a timely manner.

[0029] Secondly, a method for updating an ECU is provided, the method comprising: a first ECU reading a first file stored locally on the first ECU; the first ECU sending the first file to a second ECU, such that the second ECU updates a second file to the first file, wherein the first ECU and the second ECU are located in the same terminal.

[0030] The first ECU sends a first file stored in its corresponding storage area to a second ECU, updating the second file in the second ECU. The second ECU updates the file using communication with the first ECU in the terminal, eliminating the need to retrieve the first file from outside the terminal, thus improving the flexibility of ECU updates. Compared to over-the-air or near-end updates for updating individual ECUs in a terminal, the ECU method provided in this application improves efficiency and reduces costs.

[0031] In conjunction with the second aspect, in some possible implementations, the first ECU sending the first file to the second ECU includes: if an update requirement is met, the first ECU sending the first file to the second ECU, wherein the update requirement includes the first file having a version higher than the second file, and the second file being a file used by the second ECU when it is not updated.

[0032] By setting update requirements, the first ECU sends the first file to the second ECU when the update requirements are met. This ensures that the file versions in the first and second ECUs are matched and compatible, avoiding functional inconsistencies or even conflicts.

[0033] Newer versions of the file offer better performance. Using the newer version of the first file to process data improves processing performance. Furthermore, using the same version of the file across all ECUs ensures consistent processing results.

[0034] In conjunction with the second aspect, in some possible implementations, the method further includes: the first ECU receiving version information sent by the second ECU, the version information being used to represent the version of the second file, and the first ECU determining whether it meets the update requirements based on the version information.

[0035] Therefore, the first ECU can determine whether the second file needs to be updated based on the version information sent by the second ECU. The first ECU can determine whether to send the first file to the second ECU without the need for additional equipment, making the implementation relatively simple.

[0036] In conjunction with the second aspect, in some possible implementations, the method further includes: the first ECU receiving the first file sent by the communication box T-BOX.

[0037] When the programs in the first ECU and the second ECU of the terminal need to be upgraded, the program in the first ECU can be updated by sending the first file to the first ECU via the TBOX. When sending the first file to the second ECU via the first ECU, the TBOX does not need to send the same file to each ECU. In other words, the TBOX does not need to repeatedly obtain the first file, thereby reducing the consumption of transmission resources.

[0038] In conjunction with the second aspect, in some possible implementations, the terminal includes a communication box T-BOX, and the method further includes: the first ECU receiving measurement information sent by the T-BOX; the first ECU sending a first response message to the T-BOX, wherein among the multiple response messages received by the T-BOX, the response time corresponding to the first response message is less than the response time corresponding to the second response message, and the second response message is sent by the second ECU to the T-BOX after receiving the measurement information; the first file is forwarded by the T-BOX and transmitted to the first ECU.

[0039] T-BOX identifies the ECU with the shortest response time among multiple ECUs and forwards the first file to that ECU, thereby reducing transmission latency and improving transmission efficiency. T-BOX can also be used to forward the first file sent by a server.

[0040] In conjunction with the second aspect, in some possible implementations, the first ECU sending the target program to the second ECU includes: in the event that the second file is abnormal, the first ECU sending the first file to the second ECU, wherein the second file is the file used by the second ECU when it has not been updated.

[0041] If there is an anomaly in the second file in the second ECU, the first ECU sends the target program to the second ECU, which can update the abnormal file in the second ECU in a timely manner.

[0042] In conjunction with the second aspect, in some possible implementations, the method further includes: the first ECU sending version query information to the second ECU; the first ECU sending the target program to the second ECU, including: if the first ECU does not receive version information sent by the second ECU within a preset time period after the version query information is sent, the first ECU determines that the original program is abnormal, and the version information is used to indicate the version of the original program.

[0043] If the second ECU fails to respond to the version query information sent by the first ECU within a preset time period, it can be determined that the second ECU is abnormal, and the abnormal program in the second ECU can be updated in a timely manner.

[0044] In conjunction with the second aspect, in some possible implementations, the method further includes: the first ECU detecting whether the first file is normal; the first ECU sending the first file to the second ECU, including: if the first file is normal, the first ECU sending the first file to the second ECU.

[0045] If the first file is normal, it is sent to the second ECU so that the second ECU updates the second file to the first file, thereby increasing the probability that the updated first file in the second ECU is normal, avoiding the transmission of abnormal files, and reducing resource consumption.

[0046] In conjunction with the second aspect, in some possible implementations, the first ECU detects whether the first file is normal, including: the first ECU performs an integrity check on the first file.

[0047] Integrity checks can be used to verify whether the first file is normal, providing an effective method for determining whether a file is normal.

[0048] In conjunction with the second aspect, in some possible implementations, the first file is an application file (APP).

[0049] Thirdly, an ECU is provided, including various functional modules for implementing the ECU update method described in the first or second aspect.

[0050] Fourthly, an ECU is provided, including a communication interface and a processor. The communication interface is used for the ECU to interact with other devices. When program instructions are executed in the processor, the ECU causes the ECU to execute the ECU update method described in the first or second aspect.

[0051] Fifthly, a computer program storage medium is provided, characterized in that the computer program storage medium has program instructions that, when executed, cause the method described in the first aspect or the second aspect to be executed.

[0052] In a sixth aspect, a chip is provided, the chip system including at least one processor, wherein when program instructions are executed in the at least one processor, the method described in the first aspect or the second aspect is performed.

[0053] Optionally, as one implementation, the chip may further include a memory storing instructions, and the processor is used to execute the instructions stored in the memory. When the instructions are executed, the processor is used to execute the method in either the first aspect or the second aspect.

[0054] The aforementioned chip can be a field-programmable gate array (FPGA) or an application-specific integrated circuit (ASIC).

[0055] A seventh aspect provides a terminal including a first ECU and a second ECU, the second ECU being configured to execute the method described in the first aspect, and the first ECU being configured to execute the method described in the second aspect. For example, the terminal is a vehicle. Attached Figure Description

[0056] Figure 1 This is a functional block diagram of a vehicle to which this application embodiment applies.

[0057] Figure 2 This is a schematic structural diagram of a communication method.

[0058] Figure 3This is a schematic flowchart of an ECU update method provided in an embodiment of this application.

[0059] Figure 4 This is a schematic flowchart of another ECU update method provided in the embodiments of this application.

[0060] Figure 5 This is a schematic flowchart of an ECU program upgrade method provided in an embodiment of this application.

[0061] Figure 6 This is a schematic structural diagram of an ECU provided in an embodiment of this application.

[0062] Figure 7 This is a schematic structural diagram of another ECU provided in the embodiments of this application.

[0063] Figure 8 This is a schematic structural diagram of another ECU provided in the embodiments of this application. Detailed Implementation

[0064] The technical solutions in this application will now be described with reference to the accompanying drawings.

[0065] The ECU update method provided in this application can be applied to intelligent driving vehicles. The technical solutions of this application embodiment will be described below with reference to the accompanying drawings.

[0066] Figure 1 This is a functional block diagram of a vehicle to which this application embodiment applies. The vehicle 100 can be an intelligent driving vehicle, and the vehicle 100 can be configured for fully or partially automated driving modes.

[0067] In one example, vehicle 100 can control itself while in autonomous driving mode, and can determine the current state of the vehicle and its surrounding environment through human intervention, determine the possible behaviors of at least one other vehicle in the surrounding environment, and determine the confidence level corresponding to the probability of the other vehicle performing the possible behavior, and control vehicle 100 based on the determined information. When vehicle 100 is in autonomous driving mode, vehicle 100 can be configured to operate without human interaction.

[0068] The vehicle 100 may include various subsystems, such as a driving system 110, a sensing system 120, a control system 130, etc.

[0069] Optionally, vehicle 100 may include more or fewer subsystems, and each subsystem may include multiple components. Furthermore, each subsystem and component of vehicle 100 may be interconnected via wired or wireless means.

[0070] The propulsion system 110 may include components for providing powered motion to the vehicle 100. The sensing system 120 may include several sensors for sensing information about the environment surrounding the vehicle 100. The control system 130 controls the operation of the vehicle 100 and its components.

[0071] Optionally, the components described above are merely examples. In actual applications, components in each of the above modules may be added or removed as needed. Figure 1 This should not be construed as a limitation on the embodiments of this application.

[0072] Optionally, vehicle 100 may be an autonomous vehicle traveling on a road, capable of identifying objects in its surrounding environment to determine adjustments to its current speed. These objects may be other vehicles, traffic control equipment, or other types of objects. In some examples, each identified object may be considered independently, and based on the object's individual characteristics, such as its current speed, acceleration, and distance from the vehicle, the speed adjustment to be made by the autonomous vehicle can be determined.

[0073] Optionally, the vehicle 100 or a computing device associated with the vehicle 100 may predict the behavior of the identified object based on the characteristics of the identified object and the state of the surrounding environment (e.g., traffic, rain, ice on the road, etc.).

[0074] The aforementioned vehicle 100 can be a car, truck, motorcycle, bus, ship, airplane, helicopter, lawnmower, recreational vehicle, amusement park vehicle, construction equipment, tram, golf cart, train, handcart, etc., and this application embodiment does not impose any special limitations.

[0075] Based on the function of the electronic components in the vehicle's onboard system, these electronic components can be divided into multiple domains such as the powertrain domain, intelligent driving domain, and intelligent cockpit domain. Each domain may include at least one electronic control unit (ECU).

[0076] The electronic components in the propulsion system 110 belong to the power domain, while the electronic components in the sensing system 120 and control system 130 belong to the intelligent driving domain. The electronic components in the intelligent cockpit domain are used to support office, leisure, and entertainment activities in dynamic commuting scenarios.

[0077] ECUs within the same domain can communicate via a communication bus. An ECU includes a processor (such as a microcontroller unit (MCU)), memory, and input / output (I / O) interfaces. An ECU may also include one or more of the following: an analog-to-digital converter (A / D), a shaping integrated circuit, and a driver integrated circuit.

[0078] With the increasing number of vehicle ECUs and their growing complexity and intelligence, the upgrade frequency of applications (APPs) running on these ECUs is constantly increasing. Errors such as abnormally triggering the erasure of the application's storage area or malfunctions during the upgrade process may lead to defects in the application itself, necessitating its repair.

[0079] The applications in the vehicle's ECU can be upgraded or repaired through over-the-air (OTA) updates, local updates, or hardware replacement. The applications in the ECU are those stored in memory.

[0080] Replacing the hardware involves removing the ECU from the vehicle and installing a new hardware module with a new application. Replacing the hardware module is costly. It requires a trip to a professional vehicle repair shop or on-site service, which is time-consuming. Furthermore, the application stored in the ECU's memory in the replaced hardware module may be incompatible with applications stored in the memory of other onboard ECUs in the vehicle, causing the vehicle system to malfunction.

[0081] Near-end upgrades connect the vehicle's system to a diagnostic tool or a specific upgrade device from the original equipment manufacturer (OEM) via a communication cable. This allows the transfer of new applications stored on the diagnostic tool to the memory of the ECU being upgraded or repaired, enabling application upgrades or repairs. However, near-end upgrades require connecting the vehicle's system to the diagnostic tool or specific upgrade device via a communication cable, meaning a trip to a professional vehicle repair shop or on-site service is necessary, which is time-consuming.

[0082] Through OTA, such as Figure 2 As shown, applications stored on the OEM's cloud server can be transmitted to a specific ECU via a wireless network through devices such as a telematics box (T-Box) and a gateway in the vehicle system, thereby enabling application upgrades and repairs for the ECU.

[0083] The gateway is the central node for in-vehicle communication, connecting most of the electronic control units inside the vehicle. It supports various bus systems and can realize cross-domain function integration, basic routing communication and protocol translation, extraction and integration of in-vehicle data, security deployment, and provide diagnostic communication services and network services, making vehicle interconnection services a reality.

[0084] A telematics box (T-Box), also known as an in-vehicle information box, is primarily used to facilitate interaction between the gateway and the internet. A T-Box can belong to the communications domain.

[0085] An in-vehicle system may include multiple ECUs of the same type. These ECUs have identical hardware components, and the applications stored in the memory of each ECU are the same.

[0086] The application upgrades and repairs of each ECU in the vehicle system are performed via OTA (Over-The-Air) updates, which are costly.

[0087] To address the aforementioned issues, this application provides an ECU update method and apparatus. The update software stored locally in the first ECU is forwarded to the second ECU, enabling the second ECU to perform an update. Therefore, when a second ECU with a lower software version or whose update software is corrupted, requiring an update, can directly obtain the update software from other ECUs in the terminal, such as the first ECU with a higher software version or one with intact software. As can be seen, the method described in this application allows for direct forwarding of available update software to the ECU requiring an update when available, eliminating the need for real-time OTA updates, significantly saving network resources and update time, and improving update efficiency. Furthermore, the update software stored locally in the first ECU can not only be used by the first ECU itself but also shared with other ECUs within the terminal, improving the reuse efficiency of the update software.

[0088] The software mentioned above can also be referred to as software version, file, installation file, update file, program, or program file, etc., indicating a program or software that can be used or run on the ECU.

[0089] The ECU described in this application is a type of controller for a terminal. This application does not limit the name of the controller. The functions of the ECU described in this application include controlling the operating status of the terminal and / or acquiring environmental data. For example, when the ECU is used in a vehicle, the ECU can control the vehicle's driving status.

[0090] Figure 3 This is a schematic flowchart of an ECU update method provided in an embodiment of this application.

[0091] The terminal includes a first ECU and a second ECU.

[0092] The terminal can be one or more of the following devices: vehicle, vehicle-mounted device, vehicle-mounted chip, etc.

[0093] ECU update method 300 includes S320-S330.

[0094] In S320, the second ECU obtains the first file from the first ECU.

[0095] The first file is a file stored locally by the first ECU. The first file is stored in the storage area corresponding to the first ECU.

[0096] The first file can be an application file. An application file can also be called a version file. The first ECU can execute this first file to implement the application's functionality.

[0097] In S330, the second ECU is updated based on the first file.

[0098] The second file is a file stored locally by the second ECU.

[0099] By using S320 to S330 and utilizing the communication between the first ECU and the second ECU in the terminal, the second ECU can be updated to the first file stored locally by the first ECU. This eliminates the need for each ECU to retrieve the first file from the external network, thus improving the flexibility of file updates in the ECU.

[0100] The first file can be understood as the target program, and the second file can be understood as the source program.

[0101] In some embodiments, the second ECU may access a first file stored locally by the first ECU.

[0102] The second ECU can retrieve the first file stored locally by the first ECU if the second file is abnormal.

[0103] Optionally, the second ECU can perform integrity verification on the second file. Integrity verification can be based on methods such as cyclic redundancy check (CRC) or cipher-based message authentication code (CMAM). Integrity verification can determine whether the second file is abnormal.

[0104] The second ECU can also retrieve the first file stored locally by the first ECU if the version of the second file is lower than the version of the first file.

[0105] Optionally, the second ECU can obtain first version information from the first ECU. This first version information indicates the version of the first file. The second ECU can compare the version of the first file with the version of the second file based on the first version information. If it is determined that the version of the first file is higher than the version of the second file, the second ECU can obtain the first file stored locally by the first ECU. Alternatively, the second ECU can send its own second version information of the second file to the first ECU, which will then make a judgment based on the first version information and the second version information of the second ECU. If the first ECU determines that the version of the first file is higher than the version of the second file, the second ECU can obtain the first file stored locally by the first ECU.

[0106] Before S320, S310 can be performed. In S310, the first ECU reads the first file stored locally in the first ECU. In S320, the first ECU can send the first file to the second ECU.

[0107] Therefore, since each ECU does not need to have the ability to read the local storage of other ECUs, the second ECU can update the second file by receiving the first file from the first ECU.

[0108] In S320, the first ECU can also send a file identifier to the second ECU. The second ECU can then update the second file to the first file based on the file identifier. The first and second files can be of the same type and have the same identifier.

[0109] If the update requirements are met, the second ECU can obtain the first file.

[0110] The update requirement can be that the version of the first file is higher than the version of the second file. Therefore, the files used in each ECU to achieve the same or similar functions are all the latest versions.

[0111] Generally, newer versions of the file have better performance. Using the latest version of the file to process data improves processing performance. Furthermore, using the same version of the file to process data ensures high consistency in the processing results.

[0112] Optionally, the second ECU may send version information to the first ECU periodically or irregularly.

[0113] Alternatively, the first ECU can send a version query message to the second ECU. The version query message indicates that the second ECU is sending version information to the first ECU. After receiving the version query message, the second ECU can send the version information to the first ECU.

[0114] Alternatively, the first ECU can periodically or irregularly send version query information to the second ECU.

[0115] In other embodiments, the terminal includes a processing system and a control device. The processing system includes a first ECU and a second ECU. The control device can be a device independent of each ECU in the processing system. Before performing S320, the first ECU can send first version information to the control device, and the second ECU can send second version information to the control device. The first version information is used to indicate the version of a first file, and the second version information is used to indicate the version of a second file. The control device can control the processing system to perform S320 to S330.

[0116] The control device can send version query information to each ECU in the processing system. Each ECU, upon receiving the version query information, can send version information to the control device, indicating the version of the file stored locally by that ECU. Alternatively, each ECU can periodically or irregularly send its version information to the control device. Based on the received version information from each ECU, the control device can control the processing system to perform steps S310 to S330. For example, the control device can control the processing system to perform steps S310 to S330 in at least one of the following situations: if version information from the second ECU is not received, it is determined that the second file stored locally by the second ECU is abnormal, and it is determined that updating the second file is necessary.

[0117] Setting up a separate control device increases the number of terminal devices and occupies more space.

[0118] Optionally, if the second file is abnormal, the first ECU sends the first file to the second ECU.

[0119] As can be seen, if there is an anomaly in the second file stored locally in the second ECU, the first ECU can send the first file to the second ECU to update the abnormal file in the second ECU in a timely manner.

[0120] In some embodiments, if the second ECU determines that the second file is abnormal, the second ECU can send an abnormality indication message to the first ECU. The abnormality indication message indicates that the second file is abnormal. The first ECU can determine that the second file needs to be updated based on the received abnormality indication message and send the first file to the second ECU.

[0121] In other embodiments, the first ECU may send version query information to the second ECU. The version query information instructs the second ECU to send version information to the first ECU, whereby the version information sent by the second ECU represents the version of the second file stored locally by the second ECU. If the second file is abnormal, the second ECU may choose not to send version information to the first ECU. If the first ECU does not receive version information from the second ECU within a preset time period after the version query information is sent, the first ECU determines that the second file is abnormal and sends the first file to the second ECU.

[0122] Therefore, by querying the version of the second file in the second ECU, the first ECU can determine whether the second file is abnormal, and thus update the abnormal second file in the second ECU in a timely manner.

[0123] The first ECU can receive the first file sent by the TBOX. The TBOX is located in the same terminal as the first ECU and the second ECU. That is, the first file can be obtained by the first ECU from the external network periodically or irregularly via OTA. Moreover, the first ECU can not only use the first file to update itself, but also forward the first file to other ECUs on the terminal that need to be updated, thereby improving the update efficiency of the terminal's ECUs and saving network transmission resources.

[0124] TBOX can forward information, files, etc., sent by the server to various ECUs. The server can be one or more of different types of servers, such as physical servers or virtual servers, and can have processing and sending / receiving functions. For example, the server could be an OEM cloud server.

[0125] When files in the first ECU and second ECU of the terminal need to be upgraded, the new file can be forwarded to the first ECU via TBOX to update the file in the first ECU; then the new file is sent from the first ECU to the second ECU, reducing the number of times the server repeatedly sends new files to the terminal, thereby reducing the occupation of transmission resources and improving file update efficiency.

[0126] The first ECU can be any one of multiple similar ECUs, receiving the first file sent by the server. Multiple similar ECUs can store files used to perform the same function. For example, the first ECU could be the ECU that responds fastest to measurement information sent by the T-BOX.

[0127] The terminal includes a T-BOX. The T-BOX can send measurement information to various similar ECUs within the terminal.

[0128] After receiving the measurement information sent by the T-BOX, each ECU sends a response message to the T-BOX. Among the multiple response messages received by the T-BOX, the T-BOX can determine the ECU with the shortest response time as the first ECU and forward the first file sent by the server to the first ECU. For example, this first ECU can be the master ECU.

[0129] In other words, the first ECU can receive measurement information sent by the T-BOX. The first ECU can send a first response message to the T-BOX. Among the multiple response messages received by the T-BOX, the response time corresponding to the first response message is shorter than the response time corresponding to the second response message. The second response message is sent to the T-BOX by the second ECU after receiving the measurement information. Afterwards, the first ECU receives the first file sent by the T-BOX.

[0130] When T-BOX forwards the first file sent by the server, T-BOX determines the first ECU with the shorter response time among multiple ECUs, and forwards the first file sent by the server to the first ECU. This can reduce transmission latency and improve transmission efficiency.

[0131] Figure 4 This is a schematic flowchart of an ECU update method provided in an embodiment of this application.

[0132] An ECU application program (APP) refers to the ECU program used to perform one or more specific tasks. The following explanation uses updating the ECU application program (APP) as an example.

[0133] The terminal includes multiple ECUs of the same type.

[0134] These multiple ECUs of the same type include ECU 1 and ECU 2.

[0135] Each ECU can perform S411 upon power-up.

[0136] In S411, the ECU performs an integrity check on the APP file stored in its storage area. Each ECU can run a bootloader upon power-up. The bootloader is used to initialize the ECU and guide the execution of the APP file. The APP file stored in each ECU's storage area can also be understood as the APP file for that ECU, that is, the APP file currently used by that ECU.

[0137] When the BootLoader is running, the ECU can perform integrity checks on the APP files stored in the storage area corresponding to that ECU. Integrity checks can also be called integrity verification.

[0138] Normally, the BootLoader is stored in a protected storage area. The data stored in this protected storage area remains unchanged after the product leaves the factory. Therefore, the BootLoader is not easily damaged and will not be upgraded after leaving the factory.

[0139] When the S411 detection result is abnormal, the APP file will no longer be run, but the BootLoader will continue to run.

[0140] If the test result is normal, proceed with S412.

[0141] In S412, the ECU runs the APP file. That is, after the APP file passes the integrity check and the ECU completes the bootloader's startup process, it jumps to the APP file, and the ECU begins to execute the APP file to implement its business functions.

[0142] In S421, the ECU sends version query information to other similar ECUs.

[0143] Version query information is used to request version information of the APP file in other similar ECUs.

[0144] The following example illustrates how ECU 1 sends version query information to ECU 2.

[0145] When ECU 2 runs APP file 2, if it receives version query information sent by ECU 1, it will proceed to S422.

[0146] In other words, when ECU 2 runs APP file 2, if it receives version query information sent by ECU 1, it will proceed to S422.

[0147] In S422, ECU 2 sends version response information to ECU 1.

[0148] The version response information sent by ECU 2 is used to indicate the version information of APP file 2 in ECU 2.

[0149] If ECU 2's detection result in S411 is abnormal and APP file 2 is not executed, then ECU 2 can send an exception message to ECU 1 when it receives the version query information sent by ECU 1. The exception message indicates that there is an error in the complete new check of APP file 2 in ECU 2.

[0150] Alternatively, if ECU 2 detects an anomaly in S411 and does not run APP file 2, ECU 2 may not send version response information to ECU 1.

[0151] In S423, ECU 1 determines whether APP file 2 in ECU 2 needs to be updated.

[0152] ECU 1 can determine that the APP file 2 in ECU 2 needs to be updated when at least one of the following conditions occurs: ECU 1 receives an abnormal message sent by ECU 2; ECU 1 does not receive a version response message sent by ECU 2 after a preset time following S421; or the version response message sent by ECU 2 meets the update conditions.

[0153] For example, when receiving version response information from ECU 2, ECU 1 can determine whether APP file 2 in ECU 2 needs to be updated, i.e., whether the update requirement is met, based on the version information carried in the version response information. For instance, the update requirement could be that the version of APP file 2 indicated by the version information carried in the version response information is lower than the version of APP file 1 in ECU 1. If the version information carried in the version response information meets the update requirement, ECU 1 determines that APP file 2 in ECU 2 needs to be updated.

[0154] When ECU 1 determines that APP file 2 in ECU 2 does not need to be updated, ECU 1 can periodically or irregularly perform S421 again. In other words, ECU 1 can periodically or irregularly check whether the APP file in other similar ECUs needs to be updated.

[0155] When ECU 1 determines that APP file 2 in ECU 2 needs to be updated, it performs S424.

[0156] In S424, ECU 1 determines whether the update conditions are met.

[0157] If the update conditions are met, ECU 1 can determine to update APP file 2 in ECU 2.

[0158] The update conditions may include at least one of the following: a preset voltage range for ECU 2, a preset maximum terminal speed, etc. ECU 1 or ECU 2 can determine whether ECU 2 meets the update conditions. When the terminal is a vehicle, the preset maximum terminal speed can be the vehicle's travel speed.

[0159] Updating APP file 2 in ECU 2 when the voltage of ECU 2 meets the preset voltage range can reduce the possibility of errors in ECU 2's storage of the received APP file 2. Updating APP file 2 in ECU 2 when the terminal speed is less than the preset maximum terminal speed can reduce the impact of ECU 2 updates on vehicle driving safety. In some cases, the preset maximum vehicle speed can be 0, meaning the ECU update can be performed when the vehicle is not moving.

[0160] ECU 1 can send an update condition check request to ECU 2, instructing ECU 2 to obtain update detection information such as its operating voltage and the vehicle speed. ECU 2 can perform the check to obtain the update detection information and send it to ECU 1. ECU 1 can then determine whether the update conditions are met based on the update detection information. Alternatively, ECU 2 can determine whether the update conditions are met based on the update detection information and send its result to ECU 1.

[0161] Alternatively, ECU 1 can perform detection to obtain update detection information and determine whether the update conditions are met. Or, some information in the update detection information can be detected by ECU 1, while other information can be detected by ECU 2. For example, ECU 1 can send an update condition check request to ECU 2, instructing ECU 2 to check its operating voltage. ECU 1 can also detect the vehicle speed. Afterwards, ECU 1 can determine whether the update conditions are met based on the detected vehicle speed and the operating voltage of ECU 2 sent by ECU 2.

[0162] If the update conditions are not met, or ECU 1 does not receive update detection information or a judgment result regarding whether the update conditions are met from ECU 2, then ECU 1 determines that the update conditions are not met. When ECU 1 determines that it will not perform the update, ECU 1 can continue running the APP file 1. When ECU 1 determines that the update conditions are not met, the update process ends. In some embodiments, when ECU 1 determines that the update conditions are not met, after a preset time period, ECU 1 can repeat step S424.

[0163] If ECU 1 receives update detection information from ECU 2 and determines that the update detection information meets the update conditions, or if ECU 1 receives a judgment result from ECU 2 indicating that the update conditions are met, then ECU 1 determines to update APP file 2 in ECU 2. When ECU 1 determines that the update conditions are met, it can proceed to S431.

[0164] In S431, ECU 1 sends an update instruction to ECU 2.

[0165] When ECU 1 determines that the update conditions are met, ECU 1 can stop running APP file 1 and run BootLoader.

[0166] If the detection result of ECU 2 in S411 is abnormal, proceed to S433.

[0167] If the detection result of ECU 2 in S411 is normal, that is, ECU 2 is running the APP file 2, then ECU 2 will proceed to S432 after receiving the update instruction.

[0168] In S432, ECU 2 stops running APP file 2. ECU 2 can also run the BootLoader.

[0169] After S432, S433 can be performed.

[0170] In S433, ECU 1 authenticates with ECU 2.

[0171] Specifically, ECU 1 can send an authentication request to ECU 2. Based on the authentication request, ECU 2 determines whether ECU 1 is legitimate and sends the result of its authentication to ECU 1.

[0172] If authentication is successful, proceed with S434.

[0173] In S434, ECU 1 sends the APP file 1 to ECU 2.

[0174] ECU 1 reads the APP file 1 in its storage area and sends the read APP file 1 to ECU 2.

[0175] ECU 2 can write the APP file 1 sent by ECU 1 into the storage area of ​​ECU 2, thereby enabling ECU 2 to be updated according to the APP file 1.

[0176] After S434, ECU 1 can continue running APP file 1, and ECU 2 can read and run APP file 1 from its storage area. For example, ECU 1 and ECU 2 can run a BootLoader to bootstrap APP file 1.

[0177] Specifically, after ECU 1 completes the transmission of APP file 1 via S434, it can send a reset request to ECU 2. Upon receiving the reset request, ECU 2 can run the BootLoader, read APP file 1 from the storage area, and run it.

[0178] During the BootLoader process, ECU 2 can perform an integrity check on APP file 1 in the storage area. Therefore, ECU 2 can determine whether the updated APP file 1 is normal.

[0179] In other words, after S434, S411 to S434 can be performed again.

[0180] Using S411 to S434, ECU 2 can be updated if its APP file 2 is incomplete or of an outdated version.

[0181] In some embodiments, when the detection result of S411 by ECU 2 is abnormal, ECU 2 can send abnormal indication information to other ECUs, such as ECU 1.

[0182] If the detection result of ECU 1 in S411 is abnormal, ECU 1 can ignore the abnormal indication information sent by ECU 2 after receiving the abnormal indication information. If the detection result of ECU 1 in S411 is normal, ECU 1 can proceed to S424 and subsequent steps after receiving the abnormal indication information.

[0183] For example, after receiving the abnormal indication information, ECU 1 determines to perform an update in S424, and S431 can be skipped, meaning that the update instruction can be stopped from being sent to ECU 2. In other words, after S424, S433 can be performed, where ECU 1 and ECU 2 perform identity authentication. If the authentication is successful, S434 is performed, where ECU 1 sends the APP file 1 to ECU 2.

[0184] Similarly, as with the update of ECU 2, ECU 1 can also determine whether it needs an update. In some embodiments, in S423, ECU 1 can also determine whether APP file 1 in ECU 1 needs an update based on the version information carried in the version response information. For example, when the version of APP file 1 in ECU 1 is lower than the version of APP file 2 indicated by the version information carried in the version response information, ECU 1 determines that APP file 1 in ECU 1 needs to be updated. When ECU 1 determines that APP file 1 in ECU 1 needs to be updated, ECU 1 can send APP file 1 update request information to ECU 2 to request ECU 2 to send APP file 2 in ECU 2 to ECU 1. Afterwards, ECU 2 can perform the various steps performed by ECU 1 in S423-S434 to update APP file 1 in ECU 1.

[0185] Through steps S411 to S434, the ECU verifies the integrity of its own APP file and compares the versions of the APP files among various ECUs. ECUs with abnormal APP file integrity detection results or ECUs with outdated APP file versions are updated. Through internal vehicle processing, the APP files in each ECU are troubleshooted and upgraded. Therefore, the ECU update method provided in this application embodiment does not require a trip to a professional repair shop or on-site service from a professional, and the terminal does not need to be connected to the internet to update the APP files in the ECU, reducing the requirements for external environmental conditions.

[0186] In existing OTA upgrade technologies, the APP file is stored on the OEM's cloud server. Downloading it to the ECU requires wireless transmission, T-BOX forwarding, and gateway forwarding. The ECU update method provided in this application allows for APP file transmission between ECUs within the terminal, and between ECUs in the same domain via a communication bus. Transmission between ECUs in different domains is achieved through communication bus transmission and gateway forwarding, eliminating the need for wireless transmission and T-BOX forwarding, reducing transmission latency, and improving update efficiency.

[0187] Furthermore, regardless of whether a local upgrade or OTA technology is used, the APP file in the updated ECU is newly downloaded from outside the vehicle, and its version may differ from the APP files in other similar ECUs within the terminal, potentially leading to incompatibility issues. The ECU update method provided in this application embodiment can utilize the latest version of the APP file stored in one of the similar ECUs to update the APP files in other ECUs, thereby avoiding version discrepancies between APP files in different similar ECUs and resolving the incompatibility problem.

[0188] Figure 5 This is a schematic flowchart of an ECU program upgrade method provided in an embodiment of this application.

[0189] use Figure 4 The ECU update method shown allows the cloud server to send new application files to some of the similar ECUs in a terminal when software upgrades are required. Afterwards, the multiple similar ECUs execute... Figure 4 The ECU update method shown completes the upgrade of each ECU. That is, when an ECU update is needed for this terminal, only the APP file needs to be downloaded to a specific ECU via OTA, such as... Figure 5The example shown is ECU 1, which saves network transmission resources by eliminating the need to download the update file to each ECU. Furthermore, ECU 1 itself can use the APP file for updates, and ECU 1 can also forward the updated APP file to other ECUs for updates, such as... Figure 5 The ECU 2 shown allows it to be updated based on the APP file.

[0190] As can be seen, the update method provided in this application embodiment eliminates the need for multiple ECUs in the terminal to obtain APP files via the external network (internet) for each update. Instead, the APP files can be obtained from the external network periodically or irregularly and stored locally in the ECU. When an ECU needs to be updated, or when other ECUs need to be updated, the ECU performs the update or forwards the update to other ECUs. This significantly improves update efficiency, and some ECUs can be updated without an internet connection, reducing the ECU's dependence on the network for updates.

[0191] Specifically, it can be done through Figure 5 The ECU program upgrade method first upgrades this part of the ECU. For example, this ECU is used in a vehicle.

[0192] The terminal includes a T-BOX and multiple identical ECUs. These multiple identical ECUs include ECU 1 and ECU 2. The T-BOX is used to communicate with devices outside the terminal.

[0193] When the T-BOX is triggered by an external source, the terminal begins execution. Figure 5 The ECU program upgrade method shown refers to initiating the APP file upgrade process. The T-BOX is triggered by external factors, such as receiving a new APP file or an APP file upgrade request from a cloud server or other devices.

[0194] In the S511, the T-BOX sends measurement information to multiple similar ECUs.

[0195] In S512, each of the multiple similar ECUs sends measurement response information to T-BOX.

[0196] In the S513, T-BOX identified the fastest transmitting ECU among multiple similar ECUs.

[0197] T-BOX determines the time interval for each ECU based on the difference between the time it takes to send measurement information to each ECU and the time it takes to receive the measurement response information sent by each ECU. The ECU with the shortest corresponding time interval is the ECU with the shortest transmission time, which can also be understood as the ECU with the fastest transmission.

[0198] The ECU with the fastest transmission speed may include, for example, ECU 1. ECU 1 may be the master ECU.

[0199] Before performing the S520 update, the ECU, T-BOX, or other onboard electronic devices can determine whether the update conditions are met. Update conditions may include maximum vehicle speed, the preset voltage range of the ECU's operating voltage, etc.

[0200] If the update conditions are determined before proceeding to S513, it can also be determined whether the operating voltage of each ECU meets the preset voltage range. In S513, the T-BOX can identify the ECU with the fastest transmission speed among multiple ECUs whose operating voltage meets the preset voltage range.

[0201] Alternatively, in the S511, the T-BOX can send measurement information to multiple ECUs whose operating voltages meet a preset voltage range.

[0202] In the S520, the T-BOX sends a new APP file, namely APP file 1, to one or more ECUs that have the fastest transmission speed.

[0203] Taking ECU 1 as the fastest ECU in terms of transmission, and the T-BOX sending APP file 1 to ECU 1 as an example, ECU 1 may be running the BootLoader or APP file at the end of S513.

[0204] Before performing the S520, the T-BOX can send an upgrade request to ECU 1.

[0205] If ECU 1 is running the original APP file when S513 ends, after receiving the upgrade request, ECU 1 can stop running the original APP file and run the BootLoader.

[0206] If ECU 1 is running the BootLoader when S513 ends, then ECU 1 will keep the BootLoader running.

[0207] Therefore, when performing S520, the program running by ECU 1 is the BootLoader, which reduces the possibility of errors occurring when ECU 1 receives and stores APP file 1.

[0208] Following S520, T-BOX can also send a reset request to ECU 1. Upon receiving the reset request, ECU 1 can read and run APP file 1.

[0209] Following the S520, these multiple similar ECUs can perform... Figure 4S421 to S434, as shown, perform program upgrades on each ECU in the terminal.

[0210] In some embodiments, one or more steps in S421-S431 may be omitted after S520.

[0211] For example, in S511-S520, T-BOX only upgrades one of the multiple ECUs of the same type, namely ECU 1. After S520, S421-S423 can be omitted. ECU 1 no longer needs to request and obtain the version of the APP file in other ECUs, saving communication between ECUs and reducing waste of resources.

[0212] Compared to the method of downloading new APP files from the cloud for each ECU for upgrade, the ECU program upgrade method of this application embodiment upgrades multiple similar ECUs by obtaining new APP files from other ECUs, reducing the number of times new APP files are downloaded from the cloud server, saving wireless transmission resources, and eliminating the time-consuming wireless transmission of repeatedly downloading the same APP files from the cloud server.

[0213] The above text combined Figures 1 to 5 The present application describes interactive systems and methods, which are described below in conjunction with embodiments of the present application. Figures 6 to 8 This section describes apparatus embodiments of the present application. It should be understood that the descriptions of the various embodiments correspond to each other; therefore, any parts not described in detail can be referred to the foregoing descriptions of the interactive system and method embodiments.

[0214] Figure 6 This is a schematic structural diagram of an ECU provided in an embodiment of this application.

[0215] The ECU 2000 includes a read module 2010 and a transceiver module 2020.

[0216] The Read module 2010 is used to read the first file stored locally.

[0217] The transceiver module 2020 is used to send the first file to the second ECU so that the second ECU can be updated, wherein the first ECU and the second ECU are located in the same terminal.

[0218] Optionally, if the update requirement is met, the first ECU sends the first file to the second ECU, wherein the update requirement includes that the version of the first file is higher than the version of the second file, and the second file is the file used by the second ECU when it is not updated.

[0219] Optionally, the transceiver module 2020 is further configured to receive version information sent by the second ECU, the version information being used to indicate the version of the second file.

[0220] The ECU 2000 also includes a processing module, which is used to determine whether the update requirements are met based on the version information.

[0221] Optionally, the transceiver module 2020 is also used to receive the first file sent by the communication box T-BOX.

[0222] Optionally, the transceiver module 2020 is used to send the first file to the second ECU in the event that the second file is abnormal, wherein the second file is the file used by the second ECU when it has not been updated.

[0223] Optionally, the transceiver module 2020 is also used to send version query information to the second ECU.

[0224] ECU 2000 may further include a processing module, used to determine that the second file is abnormal if ECU 2000 does not receive version information from the second ECU within a preset time period after the version query information is sent, wherein the version information is used to indicate the version of the second file.

[0225] Optionally, the ECU 2000 may also include a processing module for detecting whether the first file is normal.

[0226] The transceiver module 2020 is also used to send the first file to the second ECU when the first file is normal.

[0227] Optionally, the processing module is used to perform integrity verification on the first file.

[0228] Optionally, the first file is an application file (APP).

[0229] Figure 7 This is a schematic structural diagram of an ECU provided in an embodiment of this application.

[0230] ECU 4000 includes acquisition module 4010 and update module 4020.

[0231] The acquisition module 4010 is used to acquire a first file from the first ECU, wherein the first file is a file stored locally by the first ECU; The update module 4020 is used to update according to the first file.

[0232] Optionally, the acquisition module 4010 is configured to, when an update requirement is met, have the second ECU acquire the first file from the first ECU, wherein the update requirement includes the first file having a version higher than the second file, and the second file being a file used by the second ECU when it is not updated.

[0233] Optionally, the ECU 4000 also includes a transceiver module for sending version information to the first ECU, the version information being used to indicate the version of the second file.

[0234] The acquisition module 4010 is used to receive the first file, which is sent by the first ECU after determining that it meets the update requirements based on the version information.

[0235] Optionally, the acquisition module 4010 is used to acquire the first file from the first ECU when the second file is abnormal, wherein the second file is the file used by the second ECU when it is not updated.

[0236] Optionally, the ECU 4000 also includes a processing module for determining whether the second file is abnormal.

[0237] Optionally, the ECU 4000 also includes a processing module for detecting whether the acquired first file is normal.

[0238] Optionally, the processing module is used to perform integrity verification on the acquired second file.

[0239] Optionally, the first file is obtained by the first ECU from the communication box TBOX.

[0240] Optionally, the first file is an application file (APP).

[0241] Figure 8 This is a schematic structural diagram of an ECU provided in an embodiment of this application.

[0242] The ECU 3000 includes a processor 3010 and a communication interface 3020.

[0243] The communication interface 3020 is used for information exchange between the ECU 3000 and other devices. When program instructions are executed in the processor 3010, the ECU 3000 performs the ECU update method described above.

[0244] Specifically, ECU 3000 can be used to execute Figure 3 First ECU and second ECU Figure 4 , Figure 5 The steps executed by either ECU 1 or ECU 2.

[0245] This application also provides a terminal, including ECU 2000 and ECU 4000.

[0246] This application also provides a computer program storage medium, characterized in that the computer program storage medium has program instructions, which, when executed, cause the method described above to be executed.

[0247] This application also provides a chip system, characterized in that the chip system includes at least one processor, and when program instructions are executed in the at least one processor, the method described above is executed.

[0248] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0249] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0250] In this application embodiment, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent the existence of A alone, the simultaneous existence of A and B, or the existence of B alone. A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" and similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, and c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0251] It should be understood that in the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0252] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0253] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0254] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0255] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0256] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0257] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for updating an electronic control unit (ECU), characterized in that, The method includes: The second ECU obtains a first file from the first ECU. The first file is a file stored locally by the first ECU. The second ECU and the first ECU are of the same type. The hardware composition of the ECUs of the same type is the same and the application programs stored in the memory of each ECU of the same type are the same. If the update conditions are met, the second ECU updates according to the first file. The update conditions include at least one of the second ECU's preset voltage range and preset maximum terminal speed. The first ECU and the second ECU are located in the same terminal; The first ECU is configured to: periodically send version query information to the second ECU, the version query information being used to instruct the second ECU to send version information to the first ECU, the version information being used to indicate the version of a second file stored locally by the second ECU, the first file and the second file corresponding to the same application; and determine that the second ECU needs to update the version of the second file if it receives an error indication information sent by the second ECU indicating that the second file is abnormal or if it does not receive version information sent by the second ECU within a preset time after the version query information is sent.

2. The method according to claim 1, characterized in that, The second ECU obtains the first file from the first ECU, including: If the update requirement is met, the second ECU obtains the first file from the first ECU. The update requirement includes that the version of the first file is higher than the version of the second file, and the second file is the file used by the second ECU when it is not updated.

3. The method according to claim 2, characterized in that, The method further includes: The second ECU sends the version information to the first ECU; The second ECU obtains the first file from the first ECU, including: receiving the first file, which is sent by the first ECU after determining that it meets the update requirements based on the version information.

4. The method according to claim 2 or 3, characterized in that, Before the second ECU updates according to the first file, the method further includes: the second ECU detecting whether the second file is normal.

5. The method according to claim 4, characterized in that, The second ECU detects whether the second file is normal, including: the second ECU performs an integrity check on the second file.

6. The method according to any one of claims 1-3, characterized in that, The first file was obtained by the first ECU from the communication box TBOX of the terminal.

7. The method according to any one of claims 1-3, characterized in that, The first file is the application program (APP) file.

8. A method for updating an electronic control unit (ECU), characterized in that, The method includes: The first ECU reads the first file stored locally on the first ECU; When the update conditions are met, the first ECU sends the first file to the second ECU so that the second ECU can be updated. The update conditions include at least one of the second ECU's preset voltage range and preset maximum terminal speed. The first ECU and the second ECU are located in the same terminal. The second ECU and the first ECU are of the same type. The hardware composition of the same type of ECU is the same and the application programs stored in the memory of each type of ECU are the same. The first ECU is configured to: periodically send version query information to the second ECU, the version query information being used to instruct the second ECU to send version information to the first ECU, the version information being used to indicate the version of a second file stored locally by the second ECU, the first file and the second file corresponding to the same application; and determine that the second ECU needs to update the version of the second file if it receives an error indication information sent by the second ECU indicating that the second file is abnormal or if it does not receive version information sent by the second ECU within a preset time after the version query information is sent.

9. The method according to claim 8, characterized in that, The first ECU sends the first file to the second ECU, including: when an update requirement is met, the first ECU sends the first file to the second ECU, wherein the update requirement includes the first file having a version higher than the second file, and the second file being the file used by the second ECU when it is not updated.

10. The method according to claim 9, characterized in that, The method further includes: The first ECU receives the version information sent by the second ECU; The first ECU determines whether it meets the update requirements based on the version information.

11. The method according to any one of claims 8-10, characterized in that, The method further includes: The first ECU receives the first file sent by the communication box T-BOX.

12. The method according to claim 11, characterized in that, The method further includes: the first ECU sending version query information to the second ECU; The first ECU sends the first file to the second ECU, including: if the first ECU does not receive version information from the second ECU within a preset time period after the version query information is sent, the first ECU determines that the second file is abnormal, and the version information is used to indicate the version of the second file.

13. The method according to any one of claims 8-10, characterized in that, The method further includes: the first ECU detecting whether the first file is normal; The first ECU sends the first file to the second ECU, including: when the first file is normal, the first ECU sends the first file to the second ECU.

14. The method according to claim 13, characterized in that, The first ECU detects whether the first file is normal, including: the first ECU performs an integrity check on the first file.

15. The method according to any one of claims 8-10, characterized in that, The first file is the application program (APP) file.

16. An electronic control unit (ECU), characterized in that, It includes a communication interface and a processor. The communication interface is used for the ECU to interact with other devices. When program instructions are executed in the processor, the ECU performs the ECU update method according to any one of claims 1-15.

17. A computer program storage medium, characterized in that, The computer program storage medium has program instructions that, when executed, cause the method as described in any one of claims 1-15 to be performed.

18. A chip, characterized in that, The chip includes at least one processor, which, when program instructions are executed in the at least one processor, causes the method as described in any one of claims 1-15 to be performed.

19. A terminal, characterized in that, It includes a first electronic control unit (ECU) and a second ECU, wherein the second ECU is used to perform the method of any one of claims 1-7, and the first ECU is used to perform the method of any one of claims 8-15.

20. The terminal according to claim 19, characterized in that, The terminal is a vehicle.

Images