OTA cache list generation method and system, ECU version detection method and system and vehicle

Abstract

The invention relates to an OTA cache list generation method and system, an ECU version detection method and system and a vehicle, and the method comprises the steps that a central gateway continuously monitors and forwards all passing messages, analyzes each frame of message needing to be forwarded, and extracts a source logic address; comparing the source logic address with a preset ECU (Electronic Control Unit) list of which the vehicle type fully supports OTA; if the source logic address exists in the ECU list, which supports OTA in the whole amount, of the vehicle type and is not recorded in a local OTA-ECU cache list, the source logic address is written into the local OTA-ECU cache list; if any one of the following conditions is met, the cache operation is skipped: the first condition is that a source logic address exists in an ECU list of which the vehicle type fully supports OTA, but a local OTA-ECU cache list is recorded; and the second condition is that the source logic address does not exist in an ECU list of which the vehicle type fully supports the OTA. According to the method and the device, the OTA upgrading efficiency is improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of OTA upgrade, and particularly relates to an OTA cache list generation method and system, an ECU version detection method and system, and a vehicle. BACKGROUND

[0002] Under the strong impetus of the electrification trend in the automotive industry, new energy vehicles are developing rapidly. To meet the growing functional requirements such as intelligent driving assistance and efficient energy management, the number of electronic control units (ECUs) in a vehicle continues to rise. The coordinated work of a large number of ECUs makes a vehicle a highly complex and intelligent electronic system.

[0003] To improve vehicle development efficiency and enhance product competitiveness, vehicle manufacturers introduce remote software upgrade functions for new energy vehicles. With the help of OTA (over-the-air) technology, manufacturers can quickly iterate the software version of ECUs on new energy vehicles, timely repair vehicle faults caused by software vulnerabilities, and significantly improve after-sales maintenance efficiency, providing users with a more convenient and intelligent vehicle experience.

[0004] In the vehicle OTA upgrade process, detecting ECU version information is a key link. Since there are a large number of ECUs in new energy vehicles, and current vehicle manufacturers mostly use platform solutions to develop new vehicle models, the programs carried by the vehicle-mounted OTA controller are also based on platform design. In the detection stage, the OTA controller needs to read the version information of each OTA-upgradable ECU on the vehicle through the controller area network (CAN) network one by one. To ensure that all possible ECUs are covered, the OTA controller adopts a full-quantity reading strategy and maintains a list of OTA-upgradable ECUs present in the vehicle locally.

[0005] However, this solution has obvious drawbacks. When the OTA controller attempts to read the ECU information not carried by the vehicle, due to the characteristics of CAN communication, there is no corresponding CAN node to receive the reading message, and the OTA controller will activate the timeout waiting mechanism, wasting time. To alleviate this problem, the mainstream approach of vehicle manufacturers is to configure an OTA upgrade ECU list for individual vehicles in advance. However, even so, due to the flexibility of vehicle options, different vehicles of the same vehicle model may still have individual differences in ECUs. This leads to the possibility of triggering a timeout waiting condition due to an uncarried ECU during the OTA version detection stage.

[0006] In summary, the existing vehicle OTA upgrade detection ECU version stage has the problem of low detection efficiency. When a certain ECU is not configured, an additional timeout waiting time is generated; if the number of unconfigured ECUs is large, the waiting time of the whole vehicle OTA upgrade will be greatly prolonged, which greatly reduces the user's upgrade experience.

[0007] Therefore, it is necessary to develop a new OTA cache list generation, ECU version detection method, system and vehicle. SUMMARY

[0008] The purpose of the present application is to provide an OTA cache list generation, ECU version detection method, system and vehicle to improve the efficiency and user experience of the vehicle OTA upgrade detection stage.

[0009] In order to achieve the above purpose, the technical scheme adopted by the present application is as follows: In a first aspect, the present application provides an OTA cache list generation method, comprising the following steps: The central gateway continuously monitors and forwards all passing messages, analyzes the messages to be forwarded, and extracts the source logical address of the messages; The source logical address is compared with the preset ECU list of the vehicle model supporting OTA in full amount; If the source logical address exists in the ECU list of the vehicle model supporting OTA in full amount, and the source logical address is not recorded in the local OTA-ECU cache list, the source logical address is written into the local OTA-ECU cache list; If any of the following conditions is met, the cache operation is skipped: Condition one: the source logical address exists in the ECU list of the vehicle model supporting OTA in full amount, but the source logical address is recorded in the local OTA-ECU cache list; Condition two: the source logical address does not exist in the ECU list of the vehicle model supporting OTA in full amount.

[0010] Optionally, in the vehicle off-line electrical detection stage, the initial local OTA-ECU cache list is constructed and verified by sequentially waking up each ECU and triggering CAN message sending. This method can ensure that the actual ECU information supporting OTA upgrade carried by the vehicle is accurately obtained before the vehicle is delivered for use, and the initialization of the local OTA-ECU cache list is completed in advance.

[0011] Optionally, the ECU list of the vehicle model supporting OTA in full is a list of all ECU logical addresses supporting OTA upgrade preset when the vehicle model is shipped. The ECU list of the vehicle model supporting OTA in full is a list of all ECU logical addresses supporting OTA upgrade preset when the vehicle model is shipped. This provides a clear and unified standard for subsequent message source logical address comparison, so that the comparison process has rules to follow, reduces errors that may be caused by unclear standards, and improves the accuracy and efficiency of the local OTA-ECU cache list generation.

[0012] Optionally, the local OTA-ECU list is a list of all ECU logical addresses supporting OTA upgrade actually carried by the current vehicle. This helps to accurately identify the ECU in the vehicle that really needs to participate in OTA upgrade, avoids including ECU that does not support OTA upgrade in the cache list, thereby optimizing the content of the local OTA-ECU cache list and improving the pertinence and effectiveness of OTA upgrade.

[0013] In a second aspect, an ECU version detection method is provided, which includes the following steps: When the vehicle end triggers an OTA upgrade detection task, a current local OTA-ECU cache list is requested from a central gateway; According to the local OTA-ECU cache list, the version information of the corresponding ECU is read; The local OTA-ECU cache list uses the steps of the OTA cache list generation method.

[0014] In a third aspect, an OTA cache list generation system is provided, which includes: A central gateway for continuously listening to and forwarding all passing messages, analyzing the messages to be forwarded, and extracting the source logical address of the messages; A comparison module connected to the central gateway for comparing the source logical address with a preset ECU list of the vehicle model supporting OTA in full; A cache writing module connected to the comparison module for writing the source logical address into the local OTA-ECU cache list when the source logical address exists in the ECU list of the vehicle model supporting OTA in full and is not recorded in the local OTA-ECU cache list; A skip cache judgment module connected to the comparison module and the cache writing module for controlling the skip cache operation when any of the following conditions is met: Condition one: the source logical address exists in the ECU list of the vehicle model supporting OTA in full, but the local OTA-ECU cache list has recorded the source logical address; Condition 2: The source logical address does not exist in the list of ECUs that fully support OTA for this model.

[0015] Optionally, an initial cache construction and verification module is also included, connected to the verification module and cache writing module. This module is used to complete the construction and verification of the initial local OTA-ECU cache list by waking up each ECU in sequence and triggering the transmission of CAN messages during the vehicle's offline electrical inspection phase. This approach ensures that the information of the ECUs actually equipped with OTA upgrades is accurately obtained before the vehicle is delivered for use, and the local OTA-ECU cache list is initialized in advance.

[0016] In a fourth aspect, the present invention provides an ECU version detection system, comprising: The task trigger module is used to send a trigger signal when the vehicle triggers the OTA upgrade detection task; A request acquisition module, connected to the task trigger module, is used to request the central gateway to obtain the current local OTA-ECU cache list according to the trigger signal; A version reading module, connected to the request acquisition module, for reading the version information of the corresponding ECU according to the local OTA-ECU cache list; The local OTA-ECU cache list is generated by the OTA cache list generation system according to the present invention.

[0017] In a fifth aspect, a vehicle according to the present invention is equipped with an OTA cache list generation system according to the present invention, which is used to generate a local OTA-ECU cache list.

[0018] In a sixth aspect, a vehicle described in the present invention is equipped with an ECU version detection system as described in the present invention, which is used to detect ECU version information that supports OTA upgrades.

[0019] The present invention has the following beneficial effects: 1. Accurately build and dynamically update cache lists to improve detection accuracy Accurately constructing the initial list: During the vehicle's offline electrical inspection phase, the initial local OTA ECU cache list is constructed by sequentially waking up each ECU and triggering CAN message transmission. This process accurately identifies the vehicle's actual ECUs that support OTA upgrades, avoiding the issue of reading information about ECUs not installed in the vehicle during a full read strategy due to platform-based vehicle design. This ensures the accuracy of the cache list from the source and provides a reliable foundation for subsequent version detection.

[0020] Dynamic updates to adapt to changes: The central gateway continuously monitors and forwards all passing messages, parses each frame of messages to be forwarded, extracts the source logical address and compares it with the preset list of ECUs that fully support OTA for this model. When there are maintenance operations such as replacing ECU hardware or modifying and adding new ECU configurations, the message sent by the new ECU will be captured by the central gateway. If its source logical address meets the conditions, it will be written into the local OTA - ECU cache list in a timely manner; for ECUs that have been removed or are no longer supported, since they no longer send related messages, they will not appear in the updated content of the cache list. This dynamic update mechanism ensures that the local OTA - ECU cache list is always consistent with the current ECU configuration of the vehicle, effectively preventing the occurrence of missed upgrades.

[0021] 2. Effectively avoid timeouts and significantly improve detection efficiency Precisely screen detection targets: The local OTA ECU cache list clearly records the logical addresses of all ECUs currently installed in the vehicle that support OTA updates. During the OTA update version detection phase, the OTA update control module retrieves the corresponding ECU version information from this cache list and only operates on existing ECUs, avoiding sending read messages to ECUs not installed in the vehicle. Since there will be no corresponding CAN node receiving the read message, the timeout mechanism will not be activated, fundamentally solving the timeout problem caused by reading information from non-installed ECUs in existing solutions.

[0022] Significantly shortened upgrade time: In existing technologies, a large number of unconfigured ECUs significantly prolongs the waiting time for vehicle-wide OTA upgrades. This solution avoids this unnecessary waiting time through a precise cache list, making the OTA upgrade version detection process more efficient and smoother. Whether it's a single ECU upgrade or a large-scale OTA upgrade of the entire vehicle, the version detection process can be completed in a shorter time, significantly shortening the total vehicle OTA upgrade time and greatly improving the user's upgrade experience.

[0023] 3. Enhance system adaptability and flexibility, and improve user satisfaction Accommodating the flexibility of vehicle configurations: Given the flexibility of vehicle configurations, individual ECUs may differ across vehicles of the same model. This technical solution adapts to these variations by updating the local OTA ECU cache list in real time. Regardless of the personalized options selected at the factory or the subsequent replacement or installation of ECUs during use, the system can promptly adjust the cache list to ensure accurate and efficient version detection, providing users with a more flexible and personalized OTA upgrade service.

[0024] Improve the overall user experience: fast and accurate OTA upgrade version detection and smooth upgrade process to avoid long waiting time, so that users can enjoy new features and performance improvements brought by vehicle software upgrade in a timely manner. At the same time, it reduces the user's waiting time for upgrading, reduces the anxiety and dissatisfaction caused by the long upgrade process, thereby significantly improving the user's satisfaction and trust in the vehicle OTA upgrade function, and enhancing the user's loyalty to the brand. BRIEF DESCRIPTION OF DRAWINGS

[0025] Figure 1 is a flowchart of the OTA cache list generation method described in the embodiments of the present application; Figure 2 is a flowchart of the ECU version detection method described in the embodiments of the present application; Figure 3 is a principle block diagram of the OTA cache list generation system described in the embodiments of the present application; Figure 4 is a principle block diagram of the ECU version detection system described in the embodiments of the present application; Figure 5 is the hardware architecture in the embodiments of the present application; In the figure: 1, central gateway, 2, comparison module, 3, cache writing module, 4, skip cache judgment module, 5, initial cache construction and verification module, 6, task triggering module, 7, request acquisition module, 8, version reading module, 9, OTA upgrade master module. DETAILED DESCRIPTION

[0026] The embodiments of the present application will be described below with reference to the accompanying drawings and preferred embodiments, and those skilled in the art can understand other advantages and effects of the present application from the disclosure in the specification. The present application can also be implemented or applied by means of other different specific embodiments, and the details in the specification can be modified or changed based on different views and applications without departing from the spirit of the present application. It should be understood that the preferred embodiments are only for illustrating the present application, but not for limiting the protection scope of the present application.

[0027] In the embodiments of the present application, the words such as "exemplary" or "for example" are used to represent an example, illustration or description. Any embodiment or design scheme described as "exemplary" or "for example" in the embodiments of the present application should not be interpreted as more preferred or more advantageous than other embodiments or design schemes. Rather, the words such as "exemplary" or "for example" are intended to present the relevant concept in a specific manner for understanding.

[0028] As shown in Figure 1 In the embodiments of the present application, an OTA cache list generation method includes the following steps: The central gateway 1 continuously monitors and forwards all passing messages, analyzes each frame of the message to be forwarded, and extracts the source logical address of the message.

[0029] The source logical address is compared with a preset ECU list of the vehicle model that supports OTA in full.

[0030] If the source logical address exists in the ECU list of the vehicle model that supports OTA in full and is not recorded in the local OTA-ECU cache list, the source logical address is written into the local OTA-ECU cache list.

[0031] If any of the following conditions is met, the cache operation is skipped: Condition one: the source logical address exists in the ECU list of the vehicle model that supports OTA in full, but the source logical address is already recorded in the local OTA-ECU cache list.

[0032] Condition two: the source logical address does not exist in the ECU list of the vehicle model that supports OTA in full.

[0033] In a possible embodiment, during the electrical inspection stage of the vehicle off-line, the initial local OTA-ECU cache list is constructed and verified by sequentially waking up each ECU and triggering CAN message sending. This method can ensure that the information of the ECU supporting OTA upgrade actually carried by the vehicle is accurately obtained before the vehicle is delivered for use, and the initialization of the local OTA-ECU cache list is completed in advance.

[0034] In a possible embodiment, the ECU list of the vehicle model that supports OTA in full is a list of all ECU logical addresses that support OTA upgrade preset when the vehicle model is shipped. This provides a clear and unified standard for subsequent comparison of the source logical address of the message, so that the comparison process has rules to follow, reduces errors that may be caused by unclear standards, and improves the accuracy and efficiency of the generation of the local OTA-ECU cache list.

[0035] In a possible embodiment, the local OTA-ECU list is a list of all ECU logical addresses that support OTA upgrade actually carried by the current vehicle. This helps to accurately identify the ECU in the vehicle that really needs to participate in OTA upgrade, avoids including ECU that does not support OTA upgrade in the cache list, and thus optimizes the content of the local OTA-ECU cache list and improves the pertinence and effectiveness of OTA upgrade.

[0036] As shown in FIG. 1, Figure 2 An ECU version detection method in an embodiment of the present application includes the following steps: When the vehicle end triggers the OTA upgrade detection task, the central gateway 1 is requested to obtain the current local OTA-ECU cache list. The version information of the corresponding ECU is read according to the local OTA-ECU cache list. The local OTA-ECU cache list adopts the steps of the OTA cache list generation method in the embodiments of the present application.

[0037] As shown in Figure 3 In the embodiments of the present application, an OTA cache list generation system includes a central gateway 1, a comparison module 2, a cache writing module 3, and a skip cache judgment module 4. The central gateway 1 is used to continuously listen to and forward all passing messages, analyze each frame of the message to be forwarded, and extract the source logical address of the message. The comparison module 2 is connected with the central gateway 1 and is used to compare the source logical address with a preset full-amount OTA-supported ECU list of the vehicle model. The cache writing module 3 is connected with the comparison module 2, and when the source logical address exists in the full-amount OTA-supported ECU list of the vehicle model and is not recorded in the local OTA-ECU cache list, the source logical address is written into the local OTA-ECU cache list. The skip cache judgment module 4 is connected with the comparison module 2 and the cache writing module 3, and when any of the following conditions is met, the skip cache operation is controlled: Condition one: the source logical address exists in the full-amount OTA-supported ECU list of the vehicle model, but the local OTA-ECU cache list has recorded the source logical address.

[0038] Condition two: the source logical address does not exist in the full-amount OTA-supported ECU list of the vehicle model.

[0039] In a possible embodiment, an OTA cache list generation system further includes an initial cache construction and verification module 5, which is connected with the cache writing module 3 and is used to construct and verify the initial local OTA-ECU cache list by sequentially waking up each ECU and triggering CAN message sending during the vehicle off-line electrical inspection stage. This method can ensure that the actual OTA upgrade-supported ECU information of the vehicle is accurately obtained before the vehicle is delivered for use, and the initialization of the local OTA-ECU cache list is completed in advance.

[0040] As shown in Figure 4As shown, in an embodiment of the present application, an ECU version detection system includes a task triggering module 6, a request acquisition module 7 and a version reading module 8. The task triggering module 6 is used to send a trigger signal when the vehicle side triggers the OTA upgrade detection task. The request acquisition module 7 is connected to the task triggering module 6, and is used to request the central gateway 1 to obtain the current local OTA-ECU cache list according to the trigger signal. The version reading module 8 is connected to the request acquisition module 7, and is used to read the version information of the corresponding ECU according to the local OTA-ECU cache list. Among them, the local OTA-ECU cache list is generated by the OTA cache list generation system in the embodiment of the present application.

[0041] In an embodiment of the present application, a vehicle is equipped with an OTA cache list generation system as in the embodiment of the present application, which is used to generate a local OTA-ECU cache list.

[0042] In an embodiment of the present application, a vehicle is equipped with an ECU version detection system as in the embodiment of the present application, which is used to detect ECU version information that supports OTA upgrades.

[0043] like Figure 5 As shown, in this embodiment of the present application, the hardware involved in performing an OTA upgrade includes a central gateway 1 and an OTA upgrade master control module 9. The central gateway 1 is responsible for monitoring and forwarding data on the vehicle's various CAN buses. The central gateway 1 is equipped with an OTA upgrade node detection submodule, which can record and deduplicate the transmitting and receiving ECUs in all messages passing through the central gateway 1. The OTA upgrade master control module 9 is responsible for controlling the OTA upgrade process.

[0044] From the moment the vehicle rolls off the production line and the central gateway 1 is activated, the OTA upgrade node detection submodule deployed in the central gateway 1 starts to work continuously, continuously detecting the sending and receiving ECUs of messages passing through the central gateway 1, and comparing the source logical address of the ECU with the locally stored list of ECUs that fully support OTA for all vehicle models. If the source logical address of this ECU exists in the list of ECUs that fully support OTA for all vehicle models, this source logical address will be stored in the local OTA-ECU cache list.

[0045] When the vehicle triggers an OTA upgrade detection task, the OTA upgrade master control module 9 directly requests the local OTA-ECU cache list from the central gateway 1. Based on this local OTA-ECU cache list, it directly reads the corresponding ECU version information via the CAN bus, reports it to the cloud for version comparison, and executes the remaining OTA process. Through this OTA upgrade ECU detection method, as long as a frame of data corresponding to the ECU exists on the vehicle's CAN network within the set validity period, the central gateway 1 can effectively detect the presence of the ECU, avoiding the timeout problem caused by detecting ECUs not configured in the vehicle.

[0046] As shown in FIG. 5, the central gateway 1 is responsible for signal forwarding between three different CAN buses, and is connected with the OTA upgrade master module 9. The OTA upgrade master module refers to a multi-application intelligent terminal where the OTA upgrade master is located, and is mainly responsible for coordinating and controlling the OTA upgrade process, and undertaking the management and scheduling tasks of the entire OTA upgrade system.

[0047] The central gateway 1 updates the local OTA-ECU cache list of the vehicle in real time, and when there is a maintenance operation such as replacing the ECU hardware or adding a new ECU configuration, the local OTA-ECU cache list can be updated in time, which can effectively prevent the upgrade from being missed. When the version is detected, the OTA upgrade master module 9 obtains the accurate local OTA-ECU cache list that can be OTA, which effectively avoids the problem of timeout waiting, and significantly improves the user experience of OTA.

[0048] In the embodiments of the present application, the vehicle can be, but is not limited to, a pure electric vehicle (PEV / BEV), a hybrid electric vehicle (HEV), a range extended electric vehicle (REEV), a plug-in hybrid electric vehicle (PHEV), a new energy vehicle, etc.

[0049] Through the description of the above embodiments, those skilled in the art can clearly understand that, for the convenience and brevity of description, only the division of the above functional modules is taken as an example for illustration, and in actual application, the above functions can be completed by different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules to complete the full classification part or part of the functions described above.

[0050] The above embodiments are the preferred embodiments of the present application, but the embodiments of the present application are not limited to the above embodiments, and any changes, modifications, substitutions, combinations, simplifications made without departing from the spirit and principles of the present application should be equivalent replacement methods, and all are included in the protection scope of the present application.

Claims

1. A method for generating an OTA cache list, characterized in that: The following steps are involved: The central gateway (1) continuously monitors and forwards all messages passing through, parses the messages to be forwarded, and extracts the source logical address of the messages; Compare the source logical address with the preset list of ECUs that fully support OTA for this vehicle model; If the source logical address exists in the list of ECUs that fully support OTA for the vehicle model and the source logical address is not recorded in the local OTA-ECU cache list, then write the source logical address to the local OTA-ECU cache list; If any of the following conditions are met, the cache operation is skipped: Condition 1: The source logical address exists in the list of ECUs that fully support OTA for this vehicle model, but the source logical address is already recorded in the local OTA-ECU cache list; Condition 2: The source logical address does not exist in the list of ECUs that fully support OTA for this model.

2. The OTA cache list generation method according to claim 1, characterized in that: During the vehicle offline electrical inspection phase, the initial local OTA-ECU cache list is constructed and verified by waking up each ECU in turn and triggering the sending of CAN messages.

3. The OTA cache list generation method according to claim 1, characterized in that: The list of ECUs that fully support OTA for this model is a list of logical addresses of all ECUs that are preset when the model leaves the factory and support OTA upgrades.

4. The OTA cache list generation method according to claim 1, characterized in that: The local OTA-ECU list is a list of all ECU logical addresses that are actually installed in the current vehicle and support OTA upgrades.

5. A method for detecting an ECU version, characterized in that: The following steps are involved: When the vehicle triggers the OTA upgrade detection task, it requests the central gateway (1) to obtain the current local OTA-ECU cache list; Read the version information of the corresponding ECU according to the local OTA-ECU cache list; The local OTA-ECU cache list adopts the steps of the OTA cache list generation method according to any one of claims 1 to 4.

6. An OTA cache list generation system, characterized in that: include: The central gateway (1) is used to continuously monitor and forward all messages passing through, parse the messages to be forwarded, and extract the source logical address of the messages; A comparison module (2), connected to the central gateway (1), is used to compare the source logical address with a preset list of ECUs of the vehicle model that fully support OTA; A cache writing module (3) is connected to the comparison module (2), and when the source logical address exists in the list of ECUs that fully support OTA for the vehicle model and the source logical address is not recorded in the local OTA-ECU cache list, the source logical address is written into the local OTA-ECU cache list; The skip cache judgment module (4) is connected to the comparison module (2) and the cache writing module (3), and controls the skip cache operation when any of the following conditions is met: Condition 1: The source logical address exists in the list of ECUs that fully support OTA for this vehicle model, but the source logical address is already recorded in the local OTA-ECU cache list; Condition 2: The source logical address does not exist in the list of ECUs that fully support OTA for this model.

7. The OTA cache list generation system according to claim 6, characterized in that: Also includes: The initial cache construction and verification module (5) is connected to the cache writing module (3) and is used to complete the construction and verification of the initial local OTA-ECU cache list by waking up each ECU in turn and triggering the sending of CAN messages during the vehicle offline electrical inspection stage.

8. An ECU version detection system, characterized in that: include: A task trigger module (6) is used to send a trigger signal when the vehicle triggers the OTA upgrade detection task; A request acquisition module (7), connected to the task trigger module (6), is used to request the central gateway to obtain the current local OTA-ECU cache list according to the trigger signal; A version reading module (8), connected to the request acquisition module (7), is used to read the version information of the corresponding ECU according to the local OTA-ECU cache list; The local OTA-ECU cache list is generated by the OTA cache list generation system according to claim 6 or claim 7.

9. A vehicle, characterized in that: An OTA cache list generation system as claimed in claim 6 or claim 7 is installed to generate a local OTA-ECU cache list.

10. A vehicle, characterized in that: The ECU version detection system as claimed in claim 8 is installed to detect the version information of the ECU that supports OTA upgrade.

Images