CN112256285A - OTA (over the air) upgrading method of vehicle, computer-readable storage medium and electronic equipment - Google Patents
OTA (over the air) upgrading method of vehicle, computer-readable storage medium and electronic equipment Download PDFInfo
- Publication number
- CN112256285A CN112256285A CN202011108262.1A CN202011108262A CN112256285A CN 112256285 A CN112256285 A CN 112256285A CN 202011108262 A CN202011108262 A CN 202011108262A CN 112256285 A CN112256285 A CN 112256285A
- Authority
- CN
- China
- Prior art keywords
- system software
- vehicle
- started
- state data
- software
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 47
- 230000008569 process Effects 0.000 abstract description 8
- 238000005192 partition Methods 0.000 description 8
- 230000006870 function Effects 0.000 description 5
- 238000010586 diagram Methods 0.000 description 2
- 239000000463 material Substances 0.000 description 2
- 230000008439 repair process Effects 0.000 description 2
- 230000002159 abnormal effect Effects 0.000 description 1
- 230000004075 alteration Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 239000013307 optical fiber Substances 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/61—Installation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/71—Version control; Configuration management
Abstract
The invention discloses an OTA (over the air) upgrading method of a vehicle, a computer readable storage medium and electronic equipment, wherein first system software and second system software are stored in an ECU (electronic control Unit) of the vehicle, and the method comprises the following steps: determining that one of the first system software and the second system software is started; when the first system software is determined to be started, an upgrading task is established through the first system software to upgrade the second system software, after the second system software is upgraded, and when the vehicle is started again, the second system software is determined to be started, and the upgrading task is established through the second system software to upgrade the first system software. In the system upgrading process, at least one system software is in a starting operation state, so that the vehicle can normally run through the system, and the vehicle can normally run during upgrading without influencing the use of the vehicle by a user.
Description
Technical Field
The present invention relates to the field of vehicle technologies, and in particular, to an OTA upgrading method for a vehicle, a computer-readable storage medium, and an electronic device.
Background
With the advent of the software-defined automotive age, software updates for modern automobiles are more and more frequent. When the software of the automobile is upgraded and updated, an Electronic Control Unit (ECU) of the automobile is in an upgrading mode, and the ECU cannot work at the moment, so that the automobile is limited to run during upgrading.
Disclosure of Invention
The present invention is directed to solving, at least to some extent, one of the technical problems in the related art. To this end, a first object of the invention is to propose an OTA upgrade method for a vehicle, which enables the vehicle to run normally during the upgrade.
A second object of the invention is to propose a computer-readable storage medium.
A third object of the invention is to propose an electronic device.
In order to achieve the above object, an embodiment of a first aspect of the present invention provides an OTA upgrading method for a vehicle, where an ECU of the vehicle stores first system software and second system software, where the method includes the following steps: determining that one of the first system software and the second system software is started; when the first system software is determined to be started, an upgrading task is established through the first system software to upgrade the second system software, after the second system software is upgraded, and when the vehicle is started again, the second system software is determined to be started, and the upgrading task is established through the second system software to upgrade the first system software.
According to the OTA upgrading method of the vehicle, the first system software and the second system software are stored in the ECU of the vehicle, one of the first system software and the second system software is determined to be started, when the first system software is determined to be started, the upgrading task is established through the first system software to upgrade the second system software, and after the second system software is upgraded and the vehicle is restarted, the second system software is determined to be started, and the upgrading task is established through the second system software to upgrade the first system software. In the system upgrading process, at least one system software is in a starting operation state, so that the vehicle can normally run through the system, and the vehicle can normally run during upgrading without influencing the use of the vehicle by a user.
According to one embodiment of the invention, determining that one of the first system software and the second system software is started comprises: respectively acquiring state data of first system software and state data of second system software; determining whether one of the first system software and the second system software is started according to the state data of the first system software and the state data of the second system software.
According to one embodiment of the present invention, determining that one of the first system software and the second system software is started based on the status data of the first system software and the status data of the second system software includes: determining that the second system software is started when the first system software is determined to be damaged according to the state data of the first system software; and determining that the first system software is started when the second system software is determined to be damaged according to the state data of the second system software.
According to an embodiment of the present invention, determining that one of the first system software and the second system software is started based on the status data of the first system software and the status data of the second system software further includes: when the first system software and the second system software are determined to be intact according to the state data of the first system software and the state data of the second system software, determining whether the version number of the first system software is consistent with the version number of the second system software according to the state data of the first system software and the state data of the second system software; and when the version number of the first system software is inconsistent with the version number of the second system software, determining that the system software with the high version number is started.
According to an embodiment of the present invention, determining that one of the first system software and the second system software is started based on the status data of the first system software and the status data of the second system software further includes: and when the version number of the first system software is consistent with the version number of the second system software, determining that the first system software is started.
According to one embodiment of the invention, after the first system software is started, if the second system software is determined to be damaged, the second system software is repaired.
According to one embodiment of the invention, after the second system software is started, if the first system software is determined to be damaged, the first system software is repaired.
According to one embodiment of the invention, after the first system software or the second system software is started, if the version number of the first system software is consistent with the version number of the second system software, the first system software or the second system software is kept to normally run.
In order to achieve the above object, a second embodiment of the present invention provides a computer-readable storage medium, on which an OTA upgrade program of a vehicle is stored, which, when executed by a processor, implements the OTA upgrade method of the vehicle.
According to the computer-readable storage medium of the embodiment of the invention, by the OTA upgrading method of the vehicle, in the system upgrading process, as at least one system software is in the starting running state, the vehicle can run normally through the system, and thus the vehicle can run normally during upgrading without influencing the use of the vehicle by a user.
In order to achieve the above object, an electronic device according to a third aspect of the present invention includes a memory, a processor, and an OTA upgrading program of a vehicle stored in the memory and operable on the processor, where the OTA upgrading method of the vehicle is implemented when the processor executes the OTA upgrading program.
According to the electronic equipment of the embodiment of the invention, through the OTA upgrading method of the vehicle, in the system upgrading process, at least one system software is in the starting operation state, so that the vehicle can normally run through the system, and the vehicle can normally run during upgrading without influencing the use of the vehicle by a user.
Additional aspects and advantages of the invention will be set forth in part in the description which follows and, in part, will be obvious from the description, or may be learned by practice of the invention.
Drawings
FIG. 1 is a diagram of an OAT upgrade ECU software architecture for a vehicle according to one embodiment of the present invention;
FIG. 2 is a flow diagram of a method for OTA upgrade of a vehicle according to one embodiment of the present invention;
fig. 3 a-3 b are flow charts of OTA upgrade methods for vehicles according to one specific example of the present invention.
Detailed Description
Reference will now be made in detail to embodiments of the present invention, examples of which are illustrated in the accompanying drawings, wherein like or similar reference numerals refer to the same or similar elements or elements having the same or similar function throughout. The embodiments described below with reference to the drawings are illustrative and intended to be illustrative of the invention and are not to be construed as limiting the invention.
An OTA upgrade method of a vehicle, a computer-readable storage medium, and an electronic device according to embodiments of the present invention are described below with reference to the accompanying drawings.
In the present application, referring to fig. 1, first system software and second system software are stored in an ECU of a vehicle, and both the first system software and the second system software can operate system functions of the ECU, so that the ECU controls the vehicle to normally operate through the first system software or the second system software.
Fig. 2 is a flowchart of an OTA upgrading method of a vehicle according to an embodiment of the present invention, and referring to fig. 2, the OTA upgrading method of the vehicle may include the following steps:
step S102, determining whether the first system software or the second system software is started.
In one embodiment, determining that one of the first system software and the second system software is launched may include: respectively acquiring state data of first system software and state data of second system software; determining whether one of the first system software and the second system software is started according to the state data of the first system software and the state data of the second system software. The state data may include system version numbers of the first system software and the second system software, system states (which may include both good and bad states), and the like.
As an embodiment, determining that one of the first system software and the second system software is started based on the state data of the first system software and the state data of the second system software includes: determining that the second system software is started when the first system software is determined to be damaged according to the state data of the first system software; and determining that the first system software is started when the second system software is determined to be damaged according to the state data of the second system software. That is, when one of the first system software and the second system software is in a damaged state, the other system software with a good system state is started.
As another embodiment, determining that one of the first system software and the second system software is started based on the state data of the first system software and the state data of the second system software further comprises: when the first system software and the second system software are determined to be intact according to the state data of the first system software and the state data of the second system software, determining whether the version number of the first system software is consistent with the version number of the second system software according to the state data of the first system software and the state data of the second system software; when the version number of the first system software is inconsistent with the version number of the second system software, determining the system software with a high version number to start; and when the version number of the first system software is consistent with the version number of the second system software, determining that the first system software is started.
That is, when the system states of the first system software and the second system software are both intact, determining one of the system software to be started according to the version number of the first system software and the version number of the second system software, wherein when the version number of the first system software is inconsistent with the version number of the second system software, determining the system software with a high version number to be started; when the version number of the first system software is consistent with the version number of the second system software, the first system software can be determined to be started, and certainly, the second system software can also be determined to be started.
And step S104, when the first system software is determined to be started, establishing an upgrading task through the first system software to upgrade the second system software, after the second system software is upgraded and when the vehicle is restarted, determining that the second system software is started, and establishing the upgrading task through the second system software to upgrade the first system software.
Specifically, when the first system software is determined to be started, the first system software can be started and operated firstly, an upgrading task is created through the first system software to upgrade the second system software, then when the vehicle is started again, the second system software can be started and operated, and the upgrading task is created through the second system software to upgrade the first system software, so that the ECU software is upgraded and updated without influencing the use of the vehicle, and the problem that the vehicle cannot run during upgrading is effectively solved.
Similarly, if it is determined that the second system software is started, an upgrade task is created through the second system software to upgrade the first system software, and after the first system software is upgraded and the vehicle is restarted, it is determined that the first system software is started, and an upgrade task is created through the first system software to upgrade the second system software.
In the OTA upgrading method for the vehicle provided by the embodiment, because two system software are arranged in the ECU of the vehicle, when the vehicle is started, one system software is selected to be started to ensure the normal operation of the vehicle, and meanwhile, the running system software is used for creating an upgrading task for the other system software, so that the other system software can be upgraded when the vehicle is running, when the vehicle is started again, the system software which is already upgraded is started preferentially to control the operation of the vehicle, and the system software which is already upgraded is used for creating an upgrading task for the other system software, so that the other system software is upgraded, thereby realizing the normal operation of the vehicle in the upgrading process of the system software, and not influencing the normal use of the vehicle by a user. In addition, even if the software of the system fails to be upgraded or an error occurs, the normal use of the vehicle is not influenced because the other system can normally operate.
In one embodiment of the invention, after the first system software is started, if the second system software is determined to be damaged, the second system software is repaired; and after the second system software is started, if the first system software is determined to be damaged, repairing the first system software.
That is, after the first system software or the second system software is started, it may be determined whether the other system needs to be repaired or upgraded according to the system status and the version number of the first system software and the second system software, for example, when it is determined that the other system is damaged according to the system status, the other system may be repaired; when the version number of the other system is determined to be lower, the other system can be upgraded; and if the version number of the first system software is consistent with that of the second system software, the first system software or the second system software is kept to normally run, and the upgrading operation is not carried out.
Further, in order to make the present application more clear to those skilled in the art, the present application will be described in further detail below with reference to specific examples shown in fig. 3 a-3 b.
After the vehicle is started, a system boot program in the vehicle ECU starts to run first, and then the system boot program reads status data stored in the ECU, where the status data may include version numbers of the first system software (i.e., system a) and the second system software (i.e., system B), system statuses of the first system software and the second system software, a current starting partition, starting times of the first system software and the second system software, and the number of times of loading failures of the first system software and the second system software, and then determines whether the first system software is started or the second system software is started according to the flow shown in fig. 3 a.
Specifically, referring to fig. 3a, in a normal situation, after the vehicle is started, the system boot program starts to operate, and determines whether the loading failure times of the first system software and the second system software in the status data are less than the preset times, such as 3 times, and it is obvious that the loading failure times of the system software are less than the preset times due to the initial operation of the system boot program, that is, the system fails to be loaded for the non-consecutive preset times. At this time, the system bootstrap program reads the system state and the version number of the first system software and the second system software in the state data, and determines whether the first system software and the second system software are intact according to the system state, if the first system software and the second system software are both intact, then further judges whether the version numbers of the first system software and the second system software are consistent, if so, the first system software can be started first. Referring to fig. 3b, after the first system software is successfully started, the first system software reads the system states and version numbers of the first system software and the second system software in the state data, and determines whether the first system software and the second system software are both intact according to the system states, and obviously, both are intact, and at this time, the first system software further determines whether the version numbers of the first system software and the second system software are consistent, and obviously, both are consistent, and at this time, the first system software normally operates.
Referring to fig. 3a, if the system boot program determines that the first system software is intact and the second system software is damaged according to the system status (e.g., the first system software is not successfully upgraded during the previous upgrade, etc.), the first system software is determined to be started, and referring to fig. 3b, after the first system software is successfully started, the first system software reads the system status and the version number of the first system software and the second system software in the status data, and determines whether the first system software and the second system software are intact according to the system status, which is obvious that the second system software is damaged, and then the first system software repairs the second system software. On the contrary, if the system boot program determines that the second system software is intact and the first system software is damaged according to the system status (e.g. the first system software is not successfully upgraded during the previous upgrade, etc.), the second system software is determined to be started, and referring to fig. 3b, after the second system software is successfully started, the second system software reads the system status and the version number of the first system software and the second system software in the status data, and determines whether the first system software and the second system software are both intact according to the system status, obviously, the first system software is damaged, and then the second system software repairs the first system software.
Referring to fig. 3a, if the system boot program determines that the first system software and the second system software are both in good condition according to the system status, but determines that the version of the first system software is higher than the version of the second system software according to the version number, the first system software is determined to be started, referring to fig. 3b, after the first system software is started successfully, the first system software reads the system status and the version number of the first system software and the second system software in the status data, and determines whether the first system software and the second system software are both in good condition according to the system status, obviously, both of them are in good condition, at this time, the first system software further determines whether the version numbers of the first system software and the second system software are consistent, obviously, the version of the first system software is higher than the version of the second system software, and at this time, the first system software upgrades the second system software. In contrast, referring to FIG. 3a, if the system boot determines that both the first system software and the second system software are intact according to the system status, but determines that the version of the second system software is higher than the version of the first system software according to the version number, it is determined to start the second system software, as shown with reference to fig. 3b, when the second system software is successfully started, the system state and version number of the first system software and the second system software in the state data are read by the second system software, and determining whether the first system software and the second system software are both intact according to the system state, obviously, the second system software further determines whether the version numbers of the first system software and the second system software are consistent, obviously, the version of the second system software is higher than that of the first system software, and at the moment, the second system software upgrades the first system software.
It should be noted that, when the system boot determines that the first system software or the second system software needs to be started according to the system state and the version number, the system boot loads and runs the first system software or the second system software, but the first system software or the second system software may not be successfully loaded due to some reasons, such as damage to a starting partition where the first system software or the second system software is located (it should be noted that, in order to avoid mutual influence between the first system software and the second system software, during the storage, the first system software and the second system software may be stored in different starting partitions, so as to ensure that damage to one partition does not affect another partition, and improve the reliability of the system), so a WDT (Watch Dog Timer) and a RTC (Real Time Clock) may be set in the ECU, the method has the function of providing a basis for the system boot program to judge whether the system software is started successfully or not, so that the system boot program can determine whether the first system software or the second system software is started successfully or not according to the basis after the first system software or the second system software is started.
On this basis, in an abnormal situation, as shown in fig. 3a, it is assumed that when the system boot determines that the first system software needs to be started currently according to the state data, the system boot loads and runs the first system software, if the first system software is not loaded and runs successfully, the WDT is inevitably reset, at this time, the ECU reruns the system boot, when the system boot runs again, the system boot reads the current time from the RTC and reads the recorded start time of the first system software from the ECU, and if the current time minus the recorded start time of the first system software is smaller than the normal time for starting the ECU, it is determined that the first system software is loaded and runs unsuccessfully for the first time. If the current failure times are less than the preset times, for example, 3 times, the system boot program determines that the first system software and the second system software are to be started again according to the state data, and obviously, the first system software is finally determined to be required to be started. And then, the system bootstrap program loads and runs the first system software again, and so on until the first system software is successfully loaded and run or the number of times of loading and running failure of the first system software is equal to the preset number of times, such as 3 times. If the number of times of loading and running failure of the first system software is equal to the preset number of times, for example, 3 times, the current starting partition, namely the starting partition where the first system software is located, is marked to be in a damaged state, and at the moment, the system boot program directly starts the system software of the other starting partition, namely the second system software. It should be noted that, for the start judgment of the second system software, reference may be made to the foregoing description, and details are not described here.
In brief, it may be determined by the system boot program according to the steps shown in fig. 3a that the first system software or the second system software is to be started, and then the system software to be started is loaded and run, and if the system software is successfully started, it is determined by the system boot program according to the steps shown in fig. 3b that another system software needs to be repaired or upgraded; if the system software is not successfully started, another system software is directly started, and if the other system software is successfully started, the other system software is determined to be required to be repaired or upgraded according to the steps shown in FIG. 3 b.
According to the OTA upgrading method for the vehicle, when vehicle ECU software is upgraded, two system software are set, when the vehicle is started, one system software is selected to be started to ensure normal operation of the vehicle, meanwhile, the other system software is upgraded or repaired through the system software, when the vehicle is started again, the other system software is started, normal operation of the vehicle is controlled through the other system software, meanwhile, the other system software is used for upgrading or repairing the system software which is operated before, and therefore the vehicle can be ensured to operate normally in the upgrading process of the system software, and normal vehicle use of a user is not affected. Moreover, if the system software fails to be upgraded or has errors, the system which fails to be upgraded can be repaired or upgraded again under the condition that the normal operation of the vehicle is ensured by the mode.
In addition, another embodiment of the present application provides a computer-readable storage medium, on which an OTA upgrade program of a vehicle is stored, where the OTA upgrade program of the vehicle, when executed by a processor, implements the foregoing OTA upgrade method of the vehicle, and for a description of operation of the OTA upgrade program in the present application, please refer to the description of the OTA upgrade method of the vehicle in the present application, which is not repeated herein.
According to the computer-readable storage medium of the embodiment of the invention, by the OTA upgrading method of the vehicle, in the system upgrading process, as at least one system software is in the starting running state, the vehicle can run normally through the system, and thus the vehicle can run normally during upgrading without influencing the use of the vehicle by a user.
In addition, another embodiment of the present application provides an electronic device, which includes a memory, a processor, and an OTA upgrade program of a vehicle stored in the memory and executable on the processor, where the OTA upgrade program is executed by the processor to implement the foregoing OTA upgrade method of the vehicle, and details are not repeated herein.
According to the electronic equipment of the embodiment of the invention, through the OTA upgrading method of the vehicle, in the system upgrading process, at least one system software is in the starting operation state, so that the vehicle can normally run through the system, and the vehicle can normally run during upgrading without influencing the use of the vehicle by a user.
It should be noted that the logic and/or steps represented in the flowcharts or otherwise described herein, such as an ordered listing of executable instructions that can be considered to implement logical functions, can be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor-containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions. For the purposes of this description, a "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of the computer-readable medium would include the following: an electrical connection (electronic device) having one or more wires, a portable computer diskette (magnetic device), a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber device, and a portable compact disc read-only memory (CDROM). Additionally, the computer-readable medium could even be paper or another suitable medium upon which the program is printed, as the program can be electronically captured, via for instance optical scanning of the paper or other medium, then compiled, interpreted or otherwise processed in a suitable manner if necessary, and then stored in a computer memory.
It should be understood that portions of the present invention may be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, the various steps or methods may be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, any one or combination of the following techniques, which are known in the art, may be used: a discrete logic circuit having a logic gate circuit for implementing a logic function on a data signal, an application specific integrated circuit having an appropriate combinational logic gate circuit, a Programmable Gate Array (PGA), a Field Programmable Gate Array (FPGA), or the like.
In the description herein, references to the description of the term "one embodiment," "some embodiments," "an example," "a specific example," or "some examples," etc., mean that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the invention. In this specification, the schematic representations of the terms used above do not necessarily refer to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples.
Furthermore, the terms "first", "second" and "first" are used for descriptive purposes only and are not to be construed as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one such feature. In the description of the present invention, "a plurality" means at least two, e.g., two, three, etc., unless specifically limited otherwise.
Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention, and that variations, modifications, substitutions and alterations can be made to the above embodiments by those of ordinary skill in the art within the scope of the present invention.
Claims (10)
1. An OTA upgrade method for a vehicle, wherein a first system software and a second system software are stored in an ECU of the vehicle, wherein the method comprises the following steps:
determining that one of the first system software and the second system software is launched;
when the first system software is determined to be started, establishing an upgrading task through the first system software to upgrade the second system software, after the second system software is upgraded and when the vehicle is restarted, determining that the second system software is started, and establishing the upgrading task through the second system software to upgrade the first system software.
2. The OTA upgrade method for a vehicle of claim 1, wherein determining that one of the first system software and the second system software is initiated comprises:
respectively acquiring state data of the first system software and state data of the second system software;
and determining that one of the first system software and the second system software is started according to the state data of the first system software and the state data of the second system software.
3. The OTA upgrade method for a vehicle of claim 2, wherein determining that one of the first system software and the second system software is initiated based on the state data of the first system software and the state data of the second system software comprises:
determining that the second system software is started when the first system software is determined to be damaged according to the state data of the first system software;
and determining the first system software to start when the second system software is determined to be damaged according to the state data of the second system software.
4. The OTA upgrade method for a vehicle of claim 2, wherein determining that one of the first system software and the second system software is activated based on the state data of the first system software and the state data of the second system software, further comprising:
when the first system software and the second system software are determined to be intact according to the state data of the first system software and the state data of the second system software, determining whether the version number of the first system software is consistent with the version number of the second system software according to the state data of the first system software and the state data of the second system software;
and when the version number of the first system software is inconsistent with the version number of the second system software, determining the system software with a high version number to start.
5. The OTA upgrade method for a vehicle of claim 4, wherein determining that one of the first system software and the second system software is initiated based on the state data for the first system software and the state data for the second system software, further comprises:
and when the version number of the first system software is consistent with the version number of the second system software, determining that the first system software is started.
6. The OTA upgrade method for a vehicle according to any one of claims 1-5, wherein after the first system software is started, if it is determined that the second system software is damaged, the second system software is repaired.
7. The OTA upgrade method for a vehicle according to any one of claims 1-5, wherein after the second system software is started, the first system software is repaired if it is determined that the first system software is damaged.
8. The OTA upgrade method for a vehicle according to any one of claims 1-5, wherein after the first system software or the second system software is started, if a version number of the first system software coincides with a version number of the second system software, the first system software or the second system software is kept operating normally.
9. A computer-readable storage medium, having stored thereon an OTA upgrade program of a vehicle which, when executed by a processor, implements an OTA upgrade method of a vehicle as claimed in any one of claims 1 to 8.
10. An electronic device comprising a memory, a processor, and an OTA upgrade program for a vehicle stored on the memory and executable on the processor, when executing the OTA upgrade program, implementing an OTA upgrade method for a vehicle as claimed in any one of claims 1 to 8.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011108262.1A CN112256285A (en) | 2020-10-16 | 2020-10-16 | OTA (over the air) upgrading method of vehicle, computer-readable storage medium and electronic equipment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011108262.1A CN112256285A (en) | 2020-10-16 | 2020-10-16 | OTA (over the air) upgrading method of vehicle, computer-readable storage medium and electronic equipment |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN112256285A true CN112256285A (en) | 2021-01-22 |
Family
ID=74244242
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011108262.1A Pending CN112256285A (en) | 2020-10-16 | 2020-10-16 | OTA (over the air) upgrading method of vehicle, computer-readable storage medium and electronic equipment |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112256285A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2022165711A1 (en) * | 2021-02-04 | 2022-08-11 | 华为技术有限公司 | Upgrading method and apparatus based on over-the-air (ota) technology |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20120331454A1 (en) * | 2011-06-24 | 2012-12-27 | International Business Machines Corporation | Image Delta-Based Upgrade Of Complex Stack In Software Appliance |
| CN109408153A (en) * | 2018-11-01 | 2019-03-01 | 百度在线网络技术（北京）有限公司 | Software start-up method and method for upgrading software |
| CN110727450A (en) * | 2019-10-11 | 2020-01-24 | 上海元城汽车技术有限公司 | Method and device for updating boot loader |
| CN111475194A (en) * | 2020-03-20 | 2020-07-31 | 创驱（上海）新能源科技有限公司 | Software upgrading method for new energy automobile controller |
-
2020
- 2020-10-16 CN CN202011108262.1A patent/CN112256285A/en active Pending
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20120331454A1 (en) * | 2011-06-24 | 2012-12-27 | International Business Machines Corporation | Image Delta-Based Upgrade Of Complex Stack In Software Appliance |
| CN109408153A (en) * | 2018-11-01 | 2019-03-01 | 百度在线网络技术（北京）有限公司 | Software start-up method and method for upgrading software |
| CN110727450A (en) * | 2019-10-11 | 2020-01-24 | 上海元城汽车技术有限公司 | Method and device for updating boot loader |
| CN111475194A (en) * | 2020-03-20 | 2020-07-31 | 创驱（上海）新能源科技有限公司 | Software upgrading method for new energy automobile controller |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2022165711A1 (en) * | 2021-02-04 | 2022-08-11 | 华为技术有限公司 | Upgrading method and apparatus based on over-the-air (ota) technology |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110809755B (en) | electronic control system | |
| CN110659038B (en) | Vehicle-mounted millimeter wave radar upgrading method and device, computer equipment and storage medium | |
| CN108241498B (en) | Vehicle-mounted equipment upgrading method and device and vehicle | |
| CN109634781B (en) | Double-area backup image system based on embedded program and starting method | |
| KR20080023841A (en) | The method of firmware upgrade and automatic firmware recovery system | |
| US20230297368A1 (en) | Software update apparatus, software update method, non-transitory storage medium storing program, vehicle, and ota master | |
| US20060218340A1 (en) | Data validity determining method for flash EEPROM and electronic control system | |
| CN114625400A (en) | Finished automobile OTA upgrading method and system, storage medium and automobile end upgrading device | |
| CN112256285A (en) | OTA (over the air) upgrading method of vehicle, computer-readable storage medium and electronic equipment | |
| US20160323416A1 (en) | Method and device for updating software in a means of transportation | |
| CN110333882B (en) | System upgrading method, device, equipment and computer readable medium | |
| CN111273928B (en) | Bootloader design method for self-upgrading | |
| CN110196730B (en) | Hot patch management method, device and storage medium of application program | |
| CN112612642A (en) | Software starting and upgrading failure backspacing method and device and terminal equipment | |
| CN116795423A (en) | Firmware version compatibility management method and device, computer equipment and storage medium | |
| CN116302005A (en) | Chip, chip upgrading method and device, electronic equipment and readable storage medium | |
| CN116795408A (en) | ECU software upgrading method and system and vehicle | |
| JP2005284902A (en) | Terminal device, control method and control program thereof, host device, control method and control program thereof, and method, system, and program for remote updating | |
| CN106444730B (en) | Diagnosis method of electronic control unit for preventing software from being dead | |
| CN114895947A (en) | Software upgrading method, device, equipment and storage medium of vehicle-mounted controller | |
| US11768669B2 (en) | Installing application program code on a vehicle control system | |
| CN112732301A (en) | Vehicle upgrading method and device | |
| EP3399411A1 (en) | Method and system for fault handling during remote installation of software in a vehicle | |
| CN116909609B (en) | Software upgrading method and device of vehicle-mounted intelligent equipment and vehicle-mounted intelligent equipment | |
| WO2022215402A1 (en) | Vehicle electronic control device and program rewriting method |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| TA01 | Transfer of patent application right |
Effective date of registration: 20231129 Address after: 518000 Baoneng Center, No. 3008 Baoneng North Road, Luohu District, Shenzhen, Guangdong Province Applicant after: Shenzhen Shengbo Hairui Management Co.,Ltd. Address before: 510700 Baoneng Cultural Plaza, 59 lichui street, Huangpu District, Guangzhou City, Guangdong Province Applicant before: Baoneng (Guangzhou) Automobile Research Institute Co.,Ltd. |
|
| TA01 | Transfer of patent application right |