Non-parking vehicle OTA upgrading method, device and equipment and storage medium

Abstract

The invention provides a non-parked vehicle OTA upgrading method, device and equipment and a storage medium, task cycle polling in the prior art is changed into event notification, that is, when a cloud end has a new upgrading task, firstly, an OTA vehicle end program is started through a resident program deployed at a vehicle end in a network wake-up mode, and then the OTA vehicle end program is started through the resident program deployed at the vehicle end; at the moment, communication is established between the OTA vehicle end program and the cloud end, query and synchronization of an upgrading task are completed, if the ECU versions of the vehicle are all latest versions, the OTA vehicle end program automatically quits and releases resources, and when version updating needs to be executed indeed, the follow-up process is started to be executed until upgrading succeeds / fails, the OTA vehicle end program quits, and the OTA vehicle end program returns to the cloud end. Therefore, the network load and the system overhead caused by frequent version query and report are avoided fundamentally, the real-time performance of the OTA task is improved, and the system overhead and the flow consumption when no task exists are reduced to the maximum extent.

Description

Technical Field

[0001] The present invention belongs to the technical field of vehicle OTA upgrade, and in particular relates to a non-resident vehicle OTA upgrade method, device, equipment and storage medium. Background Art

[0002] In the industry context of software-defined cars, with the update and upgrade of the vehicle's electronic and electrical architecture, OTA (Over-the-Air Technology) as the main technical means for OEMs to iteratively upgrade automotive software functions has become a standard feature when domestic and foreign OEMs deliver new cars.

[0003] The traditional solution starts the OTA vehicle-side program as a standard application with the vehicle-side system. The program will periodically establish communication with the cloud in the background to perform query and synchronization of upgrade tasks. Each time the OTA vehicle-side program is queried, it will obtain the software version number of all ECUs in the vehicle and report it to the cloud. The cloud will perform a version check and determine whether to push the upgrade task for the corresponding vehicle. Such frequent version queries are bound to cause the CAN channel to be busy. When the number of ECUs in the vehicle is large, the consumption of a single version query will cause a huge burden on the CAN bus. At the same time, reporting this information to the cloud through the vehicle body wireless network will be an expense. When an abnormality occurs in the OTA vehicle-side program, frequent version reports may also cause the CAN bus to be unable to idle, which in turn causes a serious malfunction in which the vehicle cannot be started due to lack of power because it cannot sleep. Summary of the invention

[0004] Based on this, in order to solve the above technical problems, a non-resident vehicle OTA upgrade method, device, equipment and storage medium are provided.

[0005] The technical solution adopted by the present invention is as follows:

[0006] As a first aspect of the present invention, a non-resident vehicle OTA upgrade method is provided, which is applied in the cloud and is characterized by comprising:

[0007] When there is a new upgrade task in the cloud, a wake-up signal is sent to the resident program deployed on the vehicle side, so that the resident program starts the OTA vehicle side program after receiving the wake-up signal sent by the cloud;

[0008] Establish communication with the OTA vehicle-side program to complete the query and synchronization of the upgrade task.

[0009] As a second aspect of the present invention, a non-resident vehicle OTA upgrade method is provided, which is applied to a vehicle side, characterized in that a resident program is deployed on the vehicle side, and the method comprises:

[0010] When the resident program receives a wake-up signal sent by the cloud, the OTA vehicle-side program is started;

[0011] The OTA vehicle-side program establishes communication with the cloud to complete the query and synchronization of the upgrade task;

[0012] If no upgrade is required or the upgrade process is completed, the OTA vehicle-side program is terminated.

[0013] As a third aspect of the present invention, a non-resident vehicle OTA upgrade device is provided, characterized by being used to implement any of the methods described above.

[0014] As a fourth aspect of the present invention, an electronic device is provided, comprising a storage module, wherein the storage module comprises instructions loaded and executed by a processor, wherein the instructions, when executed, cause the processor to execute any of the above methods.

[0015] As a fifth aspect of the present invention, a computer-readable storage medium is provided, which stores one or more programs, and when the one or more programs are executed by a processor, implements the method of any of the above aspects.

[0016] The present invention changes the task periodic polling in the prior art into event notification, that is, when there is a new upgrade task on the cloud, the OTA vehicle-side program is first started through the network wake-up method through the resident program deployed on the vehicle-side. At this time, the OTA vehicle-side program establishes communication with the cloud to complete the query and synchronization of the upgrade task. If the ECU version of the vehicle is already the latest version, the OTA vehicle-side program automatically exits to release resources. When it is really necessary to perform a version update, the subsequent process is started until the upgrade succeeds / fails, and the OTA vehicle-side program exits, fundamentally avoiding the network load and system overhead caused by frequent version queries and reports, which not only improves the real-time performance of OTA tasks, but also minimizes the system overhead and traffic consumption when there is no task. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The present invention is described in detail below with reference to the accompanying drawings and specific embodiments:

[0018] Figure 1 A flowchart of a non-resident vehicle OTA upgrade method provided by an embodiment of the present invention;

[0019] Figure 2 A schematic diagram of an electronic device is provided for an embodiment of the present invention;

[0020] Figure 3 A schematic diagram of an environment in which an embodiment of the present invention is applied. DETAILED DESCRIPTION

[0021] The following will illustrate the implementation methods of the present invention in conjunction with the drawings in the specification. It should be noted that the implementation methods involved in this specification are not exhaustive and do not represent the only implementation methods of the present invention. The following corresponding embodiments are only for the purpose of clearly illustrating the invention content of the patent of the present invention, and are not intended to limit its implementation methods. For ordinary technicians in this field, different forms of changes and modifications can be made on the basis of the description of this embodiment. All obvious changes or modifications that belong to the technical concept and invention content of the present invention are also within the scope of protection of the present invention.

[0022] Figure 3 The environment in which the embodiments of the present application are applied is shown, including a cloud 110 and a vehicle side 120, which are connected via a mobile communication network (such as 2G / 3G / 4G or Wi fi, etc.), wherein a resident program is deployed in the vehicle side 120 in the form of a process, and the resident program is started with the vehicle side 120, and even if the vehicle side 120 is in a sleep state, the resident program remains active.

[0023] like Figure 1 As shown, the embodiment of the present application provides a non-resident vehicle OTA upgrade method, and its specific process is as follows:

[0024] S101. When there is a new upgrade task in the cloud, a wake-up signal is sent to the resident program on the vehicle side.

[0025] In this embodiment, the cloud pushes a wake-up signal to the resident program via MQTT.

[0026] S102: After the resident program on the vehicle side receives the wake-up signal sent from the cloud, it starts the OTA vehicle side program.

[0027] Among them, after the resident program starts the OTA vehicle-side program, it sends a response signal to the cloud. After the cloud sends the wake-up signal, if it does not receive the response signal within the preset response time period, or the received response signal is wrong, it will resend the wake-up signal to the resident program.

[0028] S103, the OTA vehicle-side program of the vehicle-side establishes communication with the cloud to complete the query and synchronization of the upgrade task. The specific process of the query and synchronization of the upgrade task is as follows:

[0029] S31. The vehicle-side OTA vehicle-side program obtains the software version information and reports the software version information to the cloud. At the same time, the software version information is cached in the vehicle-side memory to avoid repeated queries when the version number is needed in the subsequent upgrade process, thereby reducing the frequency of version queries.

[0030] Among them, the software version information includes the software version numbers of all ECUs of the vehicle.

[0031] S32. The cloud receives the software version information reported by the vehicle.

[0032] S33. The cloud determines whether the vehicle needs to be upgraded based on the software version information. If so (it means that the version of the vehicle ECU is not the latest version), the upgrade task is pushed to the vehicle. Otherwise (it means that the version of the vehicle ECU is already the latest version), the vehicle is notified that no upgrade is needed.

[0033] S34. The vehicle receives the upgrade task pushed by the cloud and executes the upgrade task.

[0034] S104: If the vehicle side does not need to be upgraded or the upgrade process is completed, the OTA vehicle side program is terminated.

[0035] The end of the upgrade process refers to whether the upgrade is successful or failed.

[0036] From the above, it can be seen that a non-resident vehicle OTA upgrade method provided by an embodiment of the present application changes the task periodic polling in the prior art into event notification. That is, when there is a new upgrade task on the cloud, the OTA vehicle-side program is first started through the network wake-up method through the resident program deployed on the vehicle-side. At this time, the OTA vehicle-side program establishes communication with the cloud to complete the query and synchronization of the upgrade task. If the ECU version of the vehicle is already the latest version, the OTA vehicle-side program automatically exits to release resources. When it is really necessary to perform a version update, the subsequent process is started until the upgrade succeeds / fails, and the OTA vehicle-side program exits, fundamentally avoiding the network load and system overhead caused by frequent version queries and reports, which not only improves the real-time performance of OTA tasks, but also minimizes the system overhead and traffic consumption when there is no task.

[0037] Similar to the above concept, the embodiment of the present invention also provides a non-resident vehicle OTA upgrade device, which is used to implement the functions of the cloud 110 or the vehicle end 120 in the above embodiment method. Those skilled in the art can understand that these devices can be configured using commercially available hardware components through the steps taught in this solution.

[0038] Same as above idea, Figure 2 A schematic block diagram of the structure of an electronic device provided by an embodiment of the present invention is shown.

[0039] like Figure 2 As shown, the electronic device may include a storage module 21 , a processor 22 and a communication interface 23 .

[0040] In one example, the storage module 21 of the electronic device includes instructions loaded and executed by the processor 22, and when the instructions are executed, the processor 22 implements the functions of the cloud 110 in the above-mentioned embodiment method.

[0041] In one example, the storage module 21 of the electronic device includes instructions loaded and executed by the processor 22, and when the instructions are executed, the processor 22 implements the functions of the vehicle end 120 in the above-mentioned embodiment method.

[0042] It should be understood that the processor 22 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Among them, the general-purpose processor may be a microprocessor or the processor may be any conventional processor, etc.

[0043] The communication interface 23 is used to communicate with other devices through a transmission medium, so that the electronic device can communicate with other devices. Exemplarily, the communication interface 23 can be a transceiver, a circuit, a bus, a module or other types of communication interfaces, and the other device can be a terminal device. The processor 22 uses the communication interface 23 to send and receive data and is used to implement the above-mentioned embodiment method.

[0044] A computer-readable storage medium is also provided in an embodiment of the present invention. The computer-readable storage medium stores one or more programs. When the one or more programs are executed by a processor, the functions of the cloud 110 or the vehicle end 120 in the above-mentioned embodiment method are implemented.

[0045] It will be appreciated by those skilled in the art that all or some of the steps, systems, and functional modules / units in the methods disclosed above may be implemented as software, firmware, hardware, and appropriate combinations thereof. In a hardware implementation, the division between the functional modules / units mentioned in the above description does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed by several physical components in cooperation. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, a digital signal processor, or a microprocessor, or may be implemented as hardware, or may be implemented as an integrated circuit, such as an application-specific integrated circuit. Such software may be distributed on a computer-readable storage medium, which may include a computer-readable storage medium (or a non-transitory medium) and a communication medium (or a temporary medium).

[0046] As is known to those of ordinary skill in the art, the term computer-readable storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules or other data). Computer-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and can be accessed by a computer. In addition, it is known to those of ordinary skill in the art that communication media typically contain computer-readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transmission mechanism, and may include any information delivery medium.

[0047] Exemplarily, the computer-readable storage medium may be an internal storage module of the electronic device of the aforementioned embodiment, such as a hard disk or memory of the electronic device. The computer-readable storage medium may also be an external storage device of the electronic device, such as a plug-in hard disk, a smart memory card (SmartMediaCard, SMC), a secure digital (SecureDigital, SD) card, a flash card (FlashCard), etc. equipped on the electronic device.

[0048] The electronic device and computer-readable storage medium provided in the aforementioned embodiments change the task periodic polling in the prior art into event notification, that is, when there is a new upgrade task on the cloud, the OTA vehicle-side program is first started through the network wake-up method through the resident program deployed on the vehicle-side. At this time, the OTA vehicle-side program establishes communication with the cloud to complete the query and synchronization of the upgrade task. If the ECU version of the vehicle is already the latest version, the OTA vehicle-side program automatically exits to release resources. When it is really necessary to perform a version update, the subsequent process is started until the upgrade succeeds / fails, and the OTA vehicle-side program exits, fundamentally avoiding the network load and system overhead caused by frequent version queries and reports, which not only improves the real-time performance of OTA tasks, but also minimizes the system overhead and traffic consumption when there is no task.

[0049] Obviously, those skilled in the art can make various changes and modifications to the present application without departing from the scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is also intended to include these modifications and variations.

Claims

1. A non-resident vehicle OTA upgrade method, applied to the cloud, characterized in that: include: When there is a new upgrade task in the cloud, a wake-up signal is sent to the resident program deployed on the vehicle side, so that the resident program starts the OTA vehicle side program after receiving the wake-up signal sent by the cloud; Establish communication with the OTA vehicle-side program to complete the query and synchronization of the upgrade task.

2. A non-resident vehicle OTA upgrade method according to claim 1, characterized in that: Also includes: If after sending the wake-up signal, no response signal is received within the preset response time period, or the received response signal is erroneous, the wake-up signal is resent to the resident program deployed on the vehicle side, wherein the response signal is sent to the cloud after the resident program starts the OTA vehicle-side program.

3. The non-resident vehicle OTA upgrade method according to claim 1, characterized in that: The query and synchronization of completing the upgrade task further includes: Receive software version information reported by the vehicle end, wherein the software version information includes software version numbers of all ECUs of the vehicle; Determine whether the vehicle needs to be upgraded based on the software version information. If so, push the upgrade task to the vehicle end. Otherwise, notify the vehicle end that no upgrade is required.

4. A non-resident vehicle OTA upgrade method, applied to the vehicle side, characterized in that: The vehicle end is deployed with a resident program, and the method includes: When the resident program receives a wake-up signal sent by the cloud, the OTA vehicle-side program is started; The OTA vehicle-side program establishes communication with the cloud to complete the query and synchronization of the upgrade task; If no upgrade is required or the upgrade process is completed, the OTA vehicle-side program is terminated.

5. A non-resident vehicle OTA upgrade method according to claim 4, characterized in that: Also includes: After the resident program starts the OTA vehicle-side program, it sends a response signal to the cloud.

6. A non-resident vehicle OTA upgrade method according to claim 4, characterized in that: The query and synchronization of completing the upgrade task further includes: Obtain software version information and report the software version information to the cloud, where the software version information includes the software version numbers of all ECUs of the vehicle; Receive the upgrade task pushed by the cloud, and execute the upgrade task.

7. A non-resident vehicle OTA upgrade method according to claim 6, characterized in that: The obtaining of software version information further includes: After obtaining the software version information, the information is cached in the memory.

8. A non-resident vehicle OTA upgrade device, characterized in that: A non-resident vehicle OTA upgrade method for implementing any one of claims 1-7.

9. An electronic device, characterized in that: It comprises a storage module, which comprises instructions loaded and executed by a processor, and when the instructions are executed, the processor executes a non-resident vehicle OTA upgrade method according to any one of claims 1-7.

10. A computer-readable storage medium storing one or more programs, characterized in that: When the one or more programs are executed by the processor, a non-resident vehicle OTA upgrade method as described in any one of claims 1-7 is implemented.

Images