Software maintenance method and device of vehicle controller, medium and electronic equipment

Abstract

The invention belongs to the technical field of electric vehicles, and relates to a software maintenance method and device of a vehicle controller, a medium and electronic equipment. The method comprises the steps that when a first version of target software of the vehicle controller runs in a first partition, a second version of the target software is flashed to a second partition, and the first partition and the second partition are obtained by dividing the storage space of the vehicle controller; the first identification information of the first partition and the second identification information of the second partition are used for conducting integrity verification to obtain a verification result, the target software continues to be operated in the first partition according to the first version or the target software continues to be operated in the second partition according to the second version according to the verification result, and the second version is different from the first version. According to the method, the advantages of a software double-partition mechanism are brought into play, the reliability and safety of software flashing are improved, the mistake-proofing flashing method achieved by the target software is provided, additional equipment, procedures or manual participation is not needed, and the stability and production efficiency of software flashing are guaranteed.

Description

Technical Field

[0001] The present disclosure belongs to the technical field of electric vehicles, and in particular, relates to a software maintenance method for a vehicle controller, a software maintenance device for a vehicle controller, a computer-readable storage medium, and an electronic device. Background Art

[0002] With the rapid iterative development of new energy vehicles and the popularization of electronics, the reliability and safety of vehicle controller software upgrades are becoming increasingly important.

[0003] However, when the same model has different configurations and uses the same controller hardware, in order to control development costs, the same hardware and underlying software can be used, and only the configuration in the application layer software can be changed to match different model projects. In this scenario, since the hardware and underlying software are the same, software errors are prone to occur, which may cause the vehicle to be unable to be used normally. When additional equipment is used for verification and identification, various costs and management requirements will also be added. Summary of the invention

[0004] In order to overcome the problems existing in the related art, the present disclosure provides a software maintenance method for a vehicle controller, a software maintenance device for a vehicle controller, a computer-readable storage medium and an electronic device.

[0005] According to a first aspect of an embodiment of the present disclosure, a software maintenance method for a vehicle controller is provided, comprising: When a first version of the target software of the vehicle controller is running in the first partition, flashing the second version of the target software to the second partition, wherein the first partition and the second partition are obtained by dividing the storage space of the vehicle controller; An integrity check is performed using the first identification information of the first partition and the second identification information of the second partition to obtain a check result, and based on the check result, the target software continues to run according to the first version in the first partition or runs the target software according to the second version in the second partition, where the second version is different from the first version.

[0006] Optionally, the first identification information includes: a first project identification code, and the first project identification code is stored in the storage space of the first partition; the second identification information includes: a second project identification code, and the second project identification code is stored in the storage space of the second partition.

[0007] Optionally, before performing integrity verification using the first identification information of the first partition and the second identification information of the second partition to obtain a verification result, the method further includes: A first project identification code of the first partition and a second project identification code of the second partition are obtained, and the second project identification code is used to update the historical project identification code currently stored in the storage space of the second partition.

[0008] Optionally, the performing integrity check using the first identification information of the first partition and the second identification information of the second partition to obtain a check result includes: Comparing the first project identification code with the second project identification code to obtain a comparison result; When the comparison result is that the first project identification code and the second project identification code are the same, determining the verification result is verification passed; or When the comparison result is that the first project identification code and the second project identification code are different, it is determined that the verification result is verification failure.

[0009] Optionally, continuing to run the target software according to the first version in the first partition or running the target software according to the second version in the second partition according to the verification result includes: When the verification result is that the verification passes, running the target software according to the second version in the second partition; or When the verification result is that the verification fails, the target software continues to be run according to the first version in the first partition.

[0010] Optionally, flashing the target software to the second partition includes: When the flashing instruction is received, the target software is flashed to the second partition according to a program flashing process.

[0011] Optionally, the method further comprises: When the verification result is that the verification fails, a notification of the verification result is sent through the program flashing process.

[0012] Optionally, the method further comprises: When the flash instruction is received again, the target software is flashed to a third version in the first partition according to the program flash process, so that the target software is run according to the third version in the first partition, and the third version is different from the first version and the second version.

[0013] According to a second aspect of an embodiment of the present disclosure, there is provided a software maintenance device for a vehicle controller, comprising: a software flashing module configured to flash the target software of the vehicle controller to the second partition when the target software of the vehicle controller is running in the first partition according to the first version, wherein the first partition and the second partition are obtained by dividing the storage space of the vehicle controller; The software running module is configured to perform an integrity check using the first identification information of the first partition and the second identification information of the second partition to obtain a check result, and continue to run the target software according to the first version in the first partition or run the target software according to the second version in the second partition according to the check result, where the second version is different from the first version.

[0014] According to a third aspect of an embodiment of the present disclosure, a computer-readable storage medium is provided, on which computer program instructions are stored. When the program instructions are executed by a processor, the steps of the software maintenance method for a vehicle controller provided in any one of the first aspects of the present disclosure are implemented.

[0015] According to a fourth aspect of an embodiment of the present disclosure, there is provided an electronic device, including: processor; a memory for storing processor-executable instructions; The processor is configured to: execute the executable instructions to implement any one of the steps of the vehicle controller software maintenance method provided in the first aspect of the present disclosure.

[0016] The technical solution provided by the embodiments of the present disclosure may have the following beneficial effects: In the method and apparatus provided by the exemplary embodiments of the present disclosure, the target software is run and flashed in a dual-partition manner, which takes advantage of the software dual-partition mechanism and effectively improves the reliability and security of software flashing. Furthermore, integrity verification is performed through the identification information of different partitions, providing a method for error-proof flashing implemented by the target software itself, without the need for additional equipment, processes or manual participation, further ensuring the stability and production efficiency of software flashing.

[0017] It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present disclosure and, together with the description, serve to explain the principles of the present disclosure.

[0019] Figure 1 A schematic diagram of a process flow of a software maintenance method for a vehicle controller in an exemplary embodiment of the present disclosure is schematically shown; Figure 2 A schematic diagram of a flow chart of a method for integrity verification in an exemplary embodiment of the present disclosure is schematically shown; Figure 3 A schematic diagram schematically shows a flow chart of a method for running target software in an exemplary embodiment of the present disclosure; Figure 4 A schematic diagram schematically shows a flow chart of a software maintenance method for a vehicle controller in an application scenario in an exemplary embodiment of the present disclosure; Figure 5 A schematic structural diagram of a software maintenance device for a vehicle controller in an exemplary embodiment of the present disclosure is schematically shown; Figure 6 A schematic diagram schematically shows the structure of another software maintenance device for a vehicle controller in an exemplary embodiment of the present disclosure; Figure 7 A schematic structural diagram of a software maintenance device for a vehicle controller in an exemplary embodiment of the present disclosure is schematically shown. DETAILED DESCRIPTION

[0020] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present disclosure. Instead, they are merely examples of devices and methods consistent with some aspects of the present disclosure as detailed in the appended claims.

[0021] It should be noted that all actions of acquiring signals, information or data in the present disclosure are carried out in compliance with the relevant data protection laws and policies of the country where the device is located and with the authorization given by the owner of the corresponding device.

[0022] With the rapid iterative development of new energy vehicles and the popularization of electronics, the reliability and safety of vehicle controller software upgrades are becoming increasingly important.

[0023] Among them, the dual-partition-based software upgrade solution is a mechanism that can significantly improve the reliability and security of vehicle controller upgrades. This mechanism divides the code storage space in the vehicle controller into two independent partitions, A and B, and the two partitions are updated in a rolling manner.

[0024] For example, when the current software is running in partition A, after receiving the flash command, the software to be upgraded is first flashed to partition B. After the flash process is completed and the verification is passed, the upgraded software is switched to partition B. If the upgrade fails or the verification fails, the program before the upgrade is still run in partition A.

[0025] Compared with the traditional non-partitioned mechanism, it can effectively prevent abnormal situations in the flashing process that may cause abnormal operation of the controller software, thereby improving the reliability and security of software upgrades.

[0026] In the related technology, a remote upgrade method, device, electronic device and storage medium and a dual-partition upgrade method and system based on the UDS (Unified Diagnostic Services) protocol are provided, which explains the dual-partition upgrade solution but does not mention the technical solution for software flashing and error prevention.

[0027] If the same model has different configurations but uses the same controller hardware, for example, for the vehicle battery management system (BMS), the high-end model has a 100-degree battery and the low-end model has a 90-degree battery, in order to control development costs, the same hardware and underlying software can be used, and different model projects can be matched only by changing the configuration in the application layer software. Obviously, in this scenario, because the hardware and underlying software are the same, how to prevent software errors is also an important issue.

[0028] Currently, manual identification is widely used through software file names to ensure that the software is not incorrectly flashed.

[0029] In the related art, a method and system for preventing software errors in the aftermarket is provided, which requires an additional detection device to match the vehicle VIN (Vehicle Identification Number) code and the software in the production management system. If the software submitted in the production management system is wrong, only the VIN code match will cause the wrong software to be flashed into the controller.

[0030] In the related art, another ECU (Electronic Control Unit) software anti-error test burning device is provided, which requires an additional detection device and only performs anti-error identification through the software model. It cannot prevent software flashing error when the erroneous software is configured as the correct software model.

[0031] In the related art, another vehicle motor controller software error-proof flashing method and vehicle motor controller are provided, which requires the configuration information to be written into the controller in advance. Different configurations of software need to be flashed into the controller in advance for different vehicle models, which brings additional processes and only performs error prevention by identifying the part number. In addition, there is no dual-partition software flashing mechanism, which is insufficient in reliability and security for software flashing.

[0032] In view of the problems existing in the related art, the present disclosure provides a software maintenance method for a vehicle controller. Figure 1 is a flow chart of a software maintenance method for a vehicle controller according to an exemplary embodiment. Figure 1As shown, the method may at least include the following steps: Step S110. When the first version of the target software of the vehicle controller is running in the first partition, the second version of the target software is flashed to the second partition. The first partition and the second partition are obtained by dividing the storage space of the vehicle controller.

[0033] Step S120. Perform integrity check using the first identification information of the first partition and the second identification information of the second partition to obtain a check result, and continue to run the target software in the first partition according to the first version or run the target software in the second partition according to the check result, the second version is different from the first version.

[0034] In the exemplary embodiment of the present disclosure, the target software is run and flashed in a dual-partition manner, which takes advantage of the software dual-partition mechanism and effectively improves the reliability and security of software flashing. Furthermore, integrity verification is performed through the identification information of different partitions, providing a method for error-proof flashing implemented by the target software itself, without the need for additional equipment, processes or manual participation, further ensuring the stability and production efficiency of software flashing.

[0035] The following is a detailed description of each step of the vehicle controller software maintenance method.

[0036] In step S110, when the first version of the target software of the vehicle controller is running in the first partition, the second version of the target software is flashed to the second partition, and the first partition and the second partition are obtained by dividing the storage space of the vehicle controller.

[0037] In the exemplary embodiment of the present disclosure, the vehicle controller of the electric vehicle is the core control component, which is responsible for vehicle driving control, network management, brake energy recovery, energy management, status monitoring and display, fault diagnosis and processing, external charging management and other functions to ensure the safe and stable operation of the vehicle.

[0038] The upgrade strategy for the target software of the vehicle controller may be a dual-partition based software upgrade solution. Specifically, the software upgrade solution may divide the storage space of the vehicle controller into two independent partitions A and B as the first partition and the second partition, so as to perform rolling updates in the two partitions.

[0039] In an optional embodiment, when a flashing instruction is received, the target software is flashed to the second partition according to a program flashing process.

[0040] For example, when the target software runs in the first partition according to the first version and receives a flash instruction, the target software to be upgraded will flash the second version to the second partition through the standard UDS program flash process. Other program flash processes can also be used to flash the target software to the second partition. This exemplary embodiment does not make any special limitations on this.

[0041] Among them, the standard UDS program flashing process includes a pre-programming step, a programming step and a post-programming step.

[0042] Specifically, the pre-programming step is to ensure that the programming (10 02) session can be entered normally.

[0043] (1) If there are no special requirements and you only want to ensure that the flashing can proceed normally, you can directly enter 1002 (Programming Session) from 1003 (Extended Session) without adding other diagnostic services.

[0044] (2) If you need to ensure that other ECUs are not affected during the flashing process, you need to add services 28, 85, and 31. Service 28 prohibits the output of messages on the bus, reduces the bus load, and ensures that the flashing process proceeds normally (when the bus load is high, the flashing may not run normally, and the diagnostic ID (Identity document) has a low priority and may not be sent). Service 85 prohibits the update of the DTC (Diagnostic Trouble Code) status bit. During the flashing process, the APP (application) message cannot be sent, which may trigger a communication DTC. This situation is not expected during the flashing process. Using service 85 can prohibit the update of the DTC status bit and do not introduce new DTCs. Service 31 is mainly to ensure that the flashing operation cannot be performed under abnormal circumstances.

[0045] The programming step is to ensure that the S19 / Bin / Hex file can be correctly downloaded into the ECU.

[0046] (1) During the flashing process, fingerprint information can be written to record the version flashing log.

[0047] (2) The main process of flashing is divided into: erasing memory, requesting download, software downloading, requesting flashing exit, and checking version verification.

[0048] (3) After the software download is complete, you need to use service 11 to reset (from 10 02 (programming session) to 10 01 (default session)) The post-programming step is to ensure that after the software is downloaded, the functions that were previously closed by the 85, 28 services can be turned on (for the ECU being flashed, this function is immediately restored after the programming step is completed; for other ECUs, the post-programming step is used to restore the previously disabled functions).

[0049] In step S120, an integrity check is performed using the first identification information of the first partition and the second identification information of the second partition to obtain a check result, and based on the check result, the target software continues to run according to the first version in the first partition or runs the target software according to the second version in the second partition, where the second version is different from the first version.

[0050] In an exemplary embodiment of the present disclosure, after the second version of the target software is flashed to the second partition, the first identification information of the first partition and the second identification information of the second partition may be acquired.

[0051] In an optional embodiment, the first identification information includes: a first project identification code, and the first project identification code is stored in the storage space of the first partition; the second identification information includes: a second project identification code, and the second project identification code is stored in the storage space of the second partition.

[0052] The project identification code may be an identification code that uniquely represents different projects. Each project identification code corresponds to a project and may be represented by Project_ID.

[0053] It is worth noting that the first project identification code is a project configuration identification code written at a fixed address in the first partition, and the second project identification code is a project configuration identification code written at a fixed address in the second partition, and no external transmission is required.

[0054] In an optional embodiment, a first project identification code of the first partition and a second project identification code of the second partition are obtained, and the second project identification code is used to update the historical project identification code currently stored in the storage space of the second partition.

[0055] The second project identification code of the second partition may be obtained after the target software is flashed to the second partition. However, the second partition originally stores the historical project identification code. Therefore, after obtaining the new second project identification code after flashing the target software, the historical project identification code may be overwritten with the second project identification code to update the project identification code of the second partition.

[0056] In an alternative embodiment, Figure 2 A flow chart of the integrity verification method is shown as follows: Figure 2 As shown, the method may at least include the following steps: In step S210, the first project identification code is compared with the second project identification code to obtain a comparison result.

[0057] After the first project identification code and the second project identification code are obtained, the first project identification code and the second project identification code may be compared to obtain a comparison result, so as to determine whether the first project identification code is identical to the second project identification code.

[0058] In step S220, when the comparison result is that the first project identification code and the second project identification code are the same, it is determined that the verification result is verification passed.

[0059] When the comparison result is that the first project identification code and the second project identification code are the same, it indicates that the verification result is that the target software passes the integrity verification after being flashed to the second partition.

[0060] In step S230, when the comparison result is that the first project identification code and the second project identification code are different, it is determined that the verification result is verification failure.

[0061] When the comparison result is that the first project identification code and the second project identification code are different, it indicates that the verification result is that the target software fails the integrity verification after being flashed to the second partition.

[0062] In an alternative embodiment, Figure 3 A flow chart of a method for running target software is shown, such as Figure 3 As shown, the method may at least include the following steps: in step S310, when the verification result is that the verification passes, the target software is run in the second partition according to the second version.

[0063] When an integrity check is performed based on the first identification information of the first partition and the second identification information of the second partition and the check result is passed, the flashed second version of the target software can be run in the second partition after restarting the vehicle controller.

[0064] In step S320, when the verification result is that the verification fails, the target software continues to run according to the first version in the first partition.

[0065] When an integrity check is performed based on the first identification information of the first partition and the second identification information of the second partition, and the check result is a check failure, it can be considered that the software of different configuration items was incorrectly flashed. Therefore, the first version of the target software before flashing continues to run in the first partition.

[0066] In an optional embodiment, when the verification result is that the verification fails, a notification of the verification result is sent through a program flashing process.

[0067] In addition, when the verification result is verification failure, a negative response of verification failure can be replied through the standard UDS program flashing process, and the flashing process can be ended.

[0068] In an optional embodiment, when a flash instruction is received again, the target software is flashed to a third version in the first partition according to the program flash process, so that the target software can be run according to the third version in the first partition, and the third version is different from the first version and the second version.

[0069] When there is a need for another upgrade, the third version of the target software to be upgraded can be re-written to the first partition using the program flashing process, so as to perform an integrity check of the upgrade using the second identification information of the current second partition and the identification information of the updated first partition, so that if the verification result is a pass, the target software can be run in the first partition according to the third version. In addition, if the verification result is a fail, the target software can continue to be run in the second partition according to the second version.

[0070] That is to say, when there is a need for upgrading again, the target software can be flashed alternately between the first partition and the second partition in sequence, or flashed alternately between more than two partitions, and this exemplary embodiment does not make any special limitation to this.

[0071] It is worth noting that the third version of the target software can be obtained by directly updating the first version of the first partition, or by updating the first version of the software of the first partition to the second version along with the second partition, and then updating from the second version to the third version. This exemplary embodiment does not make any special limitations on this.

[0072] The software maintenance method of the vehicle controller in the embodiment of the present disclosure is described in detail below in conjunction with an application scenario.

[0073] Figure 4 A flow chart of a software maintenance method for a vehicle controller in an application scenario is shown, such as Figure 4 As shown, in step S401, the program runs in partition A.

[0074] The target software of the vehicle controller runs in partition A.

[0075] In step S402, a software flashing request is received.

[0076] The flashing requirement may be issued via an OTA (Over-The-Air) command.

[0077] The dual-partition software for vehicle controllers of new energy vehicles refers to a software architecture design that aims to solve the problem of failed over-the-air (OTA) upgrades. The dual-partition software architecture design solves the problem of being unable to roll back when an OTA upgrade fails by dividing the software into two separate parts.

[0078] In step S403, the program to be upgraded is flashed to the B partition.

[0079] The target software to be upgraded will be flashed to the B partition through the standard UDS program flashing process.

[0080] In step S404, the program to be upgraded has been written to partition B.

[0081] In step S405 , the A_Project_ID of the A partition is read.

[0082] The project configuration identification code is written into the software and integrity check is performed by comparing the two partitions. That is, the project configuration code of the currently running software is compared with the project configuration code flashed into another partition.

[0083] In step S406 , the B_Project_ID of the B partition is read.

[0084] After the flashing is completed, the Project_ID of the new software has been written to the corresponding fixed address of the B partition, so the new B_Project_ID of the B partition can be read.

[0085] In step S407, whether A_Project_ID and B_Project_ID are equal.

[0086] After the first project identification code and the second project identification code are obtained, the Project_ID of the B partition and the existing Project_ID of the A partition may be compared to determine whether they are consistent, so as to determine whether the first project identification code and the second project identification code are the same.

[0087] In step S408, the integrity check passes.

[0088] When the comparison result is that the first project identification code and the second project identification code are the same, it indicates that the verification result is that after the target software is flashed to the second partition, the integrity check passes, and the flashing process ends.

[0089] In step S409, the partition operation is switched.

[0090] After the reboot is complete, the vehicle controller will start running the new program from partition B.

[0091] In step S410, the integrity check fails.

[0092] When the comparison result is that the first project identification code and the second project identification code are different, it indicates that the verification result is that the target software fails the integrity verification after being flashed to the second partition.

[0093] In step S411, a negative response is given, and the flashing is ended.

[0094] Furthermore, if the integrity check fails, it is considered that the software of different configuration items has been incorrectly flashed, and a negative response of verification failure is returned through the standard UDS program flashing process, and the flashing process is terminated.

[0095] In step S412, the current partition is kept running.

[0096] In addition, continue to run the target software before flashing in partition A.

[0097] It is worth mentioning that when there is a need for upgrading again, the software to be upgraded will be flashed to partition A, and flashed alternately in sequence.

[0098] In an exemplary embodiment of the present disclosure, based on the mechanism of software dual partitions, the software of partition A and partition B is rolled when flashing the software. Even if the flashing process is abnormally interrupted or the verification fails, the currently running partition software is still complete and can run normally, which effectively improves the reliability and security of software flashing.

[0099] Furthermore, the software is flashed to prevent errors by comparing the project configuration identification codes in the software of the two partitions. The software itself performs anti-error flashing identification, which does not require additional equipment, additional processes, or manual verification. This is more in line with the current OTA software upgrade scenario and further improves the reliability and production efficiency of software flashing.

[0100] In addition, in an exemplary embodiment of the present disclosure, a software maintenance device for a vehicle controller is also provided. Figure 5 A schematic diagram of the structure of the software maintenance device of the vehicle controller is shown, Figure 5 As shown, the vehicle controller software maintenance device 500 may include: a software flashing module 510 and a software running module 520. Among them: The software flashing module 510 is configured to flash the target software of the vehicle controller to the second partition when the target software of the vehicle controller is running in the first partition according to the first version, wherein the first partition and the second partition are obtained by dividing the storage space of the vehicle controller; The software running module 520 is configured to perform an integrity check using the first identification information of the first partition and the second identification information of the second partition to obtain a check result, and continue to run the target software according to the first version in the first partition or run the target software according to the second version in the second partition based on the check result, where the second version is different from the first version.

[0101] In some embodiments of the present disclosure, the first identification information includes: a first project identification code, and the first project identification code is stored in the storage space of the first partition; the second identification information includes: a second project identification code, and the second project identification code is stored in the storage space of the second partition.

[0102] In some embodiments of the present disclosure, the software maintenance device 500 of the vehicle controller is further configured to: A first project identification code of the first partition and a second project identification code of the second partition are obtained, and the second project identification code is used to update the historical project identification code currently stored in the storage space of the second partition.

[0103] In some embodiments of the present disclosure, the software execution module 520 is configured to: Comparing the first project identification code with the second project identification code to obtain a comparison result; When the comparison result is that the first project identification code and the second project identification code are the same, determining the verification result is verification passed; or When the comparison result is that the first project identification code and the second project identification code are different, it is determined that the verification result is verification failure.

[0104] In some embodiments of the present disclosure, the software execution module 520 is configured to: When the verification result is that the verification passes, running the target software according to the second version in the second partition; or When the verification result is that the verification fails, the target software continues to be run according to the first version in the first partition.

[0105] In some embodiments of the present disclosure, the software flashing module 510 is configured to: When the flashing instruction is received, the target software is flashed to the second partition according to a program flashing process.

[0106] In some embodiments of the present disclosure, the software maintenance device 500 of the vehicle controller is further configured to: When the verification result is that the verification fails, a notification of the verification result is sent through the program flashing process.

[0107] In some embodiments of the present disclosure, the software maintenance device 500 of the vehicle controller is further configured to: When the flash instruction is received again, the target software is flashed to a third version in the first partition according to the program flash process, so that the target software is run according to the third version in the first partition, and the third version is different from the first version and the second version.

[0108] Regarding the device in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the method, and will not be elaborated here.

[0109] The present disclosure also provides a computer-readable storage medium having computer program instructions stored thereon. When the program instructions are executed by a processor, the steps of the vehicle controller software maintenance method provided by the present disclosure are implemented.

[0110] Figure 6 is a block diagram of another software maintenance device 600 for a vehicle controller according to an exemplary embodiment. For example, the device 600 may be a mobile phone, a computer, a digital broadcast terminal, a messaging device, a game console, a tablet device, a medical device, a fitness device, a personal digital assistant, etc.

[0111] Reference Figure 6 , the device 600 may include one or more of the following components: a processing component 602 , a memory 604 , a power component 606 , a multimedia component 608 , an audio component 610 , an input / output interface 612 , a sensor component 614 , and a communication component 616 .

[0112] The processing component 602 generally controls the overall operation of the device 600, such as operations associated with display, phone calls, data communications, camera operations, and recording operations. The processing component 602 may include one or more processors 620 to execute instructions to complete all or part of the steps of the above method. In addition, the processing component 602 may include one or more modules to facilitate the interaction between the processing component 602 and other components. For example, the processing component 602 may include a multimedia module to facilitate the interaction between the multimedia component 608 and the processing component 602.

[0113] The memory 604 is configured to store various types of data to support operations on the device 600. Examples of such data include instructions for any application or method operating on the device 600, contact data, phone book data, messages, pictures, videos, etc. The memory 604 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk.

[0114] The power supply component 606 provides power to the various components of the device 600. The power supply component 606 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power for the device 600.

[0115] The multimedia component 608 includes a screen that provides an output interface between the device 600 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touch screen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touch, slide, and gestures on the touch panel. The touch sensor may not only sense the boundaries of the touch or slide action, but also detect the duration and pressure associated with the touch or slide operation. In some embodiments, the multimedia component 608 includes a front camera and / or a rear camera. When the device 600 is in an operating mode, such as a shooting mode or a video mode, the front camera and / or the rear camera may receive external multimedia data. Each front camera and rear camera may be a fixed optical lens system or have a focal length and optical zoom capability.

[0116] The audio component 610 is configured to output and / or input audio signals. For example, the audio component 610 includes a microphone (MIC), and when the device 600 is in an operation mode, such as a call mode, a recording mode, and a speech recognition mode, the microphone is configured to receive an external audio signal. The received audio signal can be further stored in the memory 604 or sent via the communication component 616. In some embodiments, the audio component 610 also includes a speaker for outputting audio signals.

[0117] The input / output interface 612 provides an interface between the processing component 602 and the peripheral interface modules, which may be keyboards, click wheels, buttons, etc. These buttons may include but are not limited to: a home button, a volume button, a start button, and a lock button.

[0118] The sensor assembly 614 includes one or more sensors for providing various aspects of status assessment for the device 600. For example, the sensor assembly 614 can detect the open / closed state of the device 600, the relative positioning of components, such as the display and keypad of the device 600, and the sensor assembly 614 can also detect the position change of the device 600 or a component of the device 600, the presence or absence of user contact with the device 600, the orientation or acceleration / deceleration of the device 600, and the temperature change of the device 600. The sensor assembly 614 may include a proximity sensor configured to detect the presence of a nearby object without any physical contact. The sensor assembly 614 may also include an optical sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, the sensor assembly 614 may also include an accelerometer, a gyroscope sensor, a magnetic sensor, a pressure sensor, or a temperature sensor.

[0119] The communication component 616 is configured to facilitate wired or wireless communication between the device 600 and other devices. The device 600 can access a wireless network based on a communication standard, such as WiFi, 2G or 3G, or a combination thereof. In an exemplary embodiment, the communication component 616 receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component 616 also includes a near field communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology and other technologies.

[0120] In an exemplary embodiment, the apparatus 600 may be implemented by one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the above methods.

[0121] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 604 including instructions, and the instructions can be executed by a processor 620 of the device 600 to perform the above method. For example, the non-transitory computer-readable storage medium can be a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, etc.

[0122] In addition to being an independent electronic device, the above-mentioned device can also be a part of an independent electronic device. For example, in one embodiment, the device can be an integrated circuit (IC) or a chip, wherein the integrated circuit can be an IC or a collection of multiple ICs; the chip can include but is not limited to the following types: GPU (Graphics Processing Unit), CPU (Central Processing Unit), FPGA (Field Programmable Gate Array), DSP (Digital Signal Processor), ASIC (Application Specific Integrated Circuit), SOC (System on Chip, SoC), etc. The above-mentioned integrated circuit or chip can be used to execute executable instructions (or codes) to implement the above-mentioned vehicle controller software maintenance method. The executable instructions can be stored in the integrated circuit or chip, or can be obtained from other devices or equipment, such as the integrated circuit or chip includes a processor, a memory, and an interface for communicating with other devices. The executable instruction can be stored in the memory, and when the executable instruction is executed by the processor, the above-mentioned software maintenance method of the vehicle controller can be implemented; alternatively, the integrated circuit or chip can receive the executable instruction through the interface and transmit it to the processor for execution, so as to implement the above-mentioned method.

[0123] In another exemplary embodiment, a computer program product is also provided. The computer program product includes a computer program executable by a programmable device. The computer program has a code portion for executing the software maintenance method of the vehicle controller described above when executed by the programmable device.

[0124] Figure 7 is a block diagram of another software maintenance device 700 for a vehicle controller according to an exemplary embodiment. For example, the device 700 may be provided as a server. Figure 7 The apparatus 700 includes a processing component 722, which further includes one or more processors, and a memory resource represented by a memory 732 for storing instructions executable by the processing component 722, such as an application. The application stored in the memory 732 may include one or more modules, each corresponding to a set of instructions. In addition, the processing component 722 is configured to execute instructions to perform the software maintenance method of the vehicle controller described above.

[0125] The device 700 may also include a power supply component 726 configured to perform power management of the device 700, a wired or wireless network interface 750 configured to connect the device 700 to a network, and an input / output interface 758. The device 700 may operate based on an operating system stored in the memory 732.

[0126] Those skilled in the art will readily appreciate other embodiments of the present disclosure after considering the specification and practicing the present disclosure. The present disclosure is intended to cover any variations, uses or adaptations of the present disclosure that follow the general principles of the present disclosure and include common knowledge or customary techniques in the art that are not disclosed in the present disclosure. The description and examples are to be considered as exemplary only, and the true scope and spirit of the present disclosure are indicated by the following claims.

[0127] It should be understood that the present disclosure is not limited to the exact structures that have been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present disclosure is limited only by the appended claims.

Claims

1. A software maintenance method for a vehicle controller, characterized in that: include: When a first version of the target software of the vehicle controller is running in the first partition, flashing the second version of the target software to the second partition, wherein the first partition and the second partition are obtained by dividing the storage space of the vehicle controller; An integrity check is performed using the first identification information of the first partition and the second identification information of the second partition to obtain a check result, and based on the check result, the target software continues to run according to the first version in the first partition or runs the target software according to the second version in the second partition, where the second version is different from the first version.

2. The software maintenance method of a vehicle controller according to claim 1, characterized in that: The first identification information includes: a first project identification code, and the first project identification code is stored in the storage space of the first partition; the second identification information includes: a second project identification code, and the second project identification code is stored in the storage space of the second partition.

3. The software maintenance method of a vehicle controller according to claim 2, characterized in that: Before performing integrity verification using the first identification information of the first partition and the second identification information of the second partition to obtain a verification result, the method further includes: A first project identification code of the first partition and a second project identification code of the second partition are obtained, and the second project identification code is used to update the historical project identification code currently stored in the storage space of the second partition.

4. The software maintenance method of a vehicle controller according to claim 2, characterized in that: The performing integrity check using the first identification information of the first partition and the second identification information of the second partition to obtain a check result includes: Comparing the first project identification code with the second project identification code to obtain a comparison result; When the comparison result is that the first project identification code and the second project identification code are the same, determining the verification result is verification passed; or When the comparison result is that the first project identification code and the second project identification code are different, it is determined that the verification result is verification failure.

5. The software maintenance method of a vehicle controller according to claim 1, characterized in that: The step of continuing to run the target software according to the first version in the first partition or running the target software according to the second version in the second partition according to the verification result comprises: When the verification result is that the verification passes, running the target software according to the second version in the second partition; or When the verification result is that the verification fails, the target software continues to be run according to the first version in the first partition.

6. The software maintenance method of a vehicle controller according to claim 1, characterized in that: Flashing the target software to the second partition includes: When the flashing instruction is received, the target software is flashed to the second partition according to a program flashing process.

7. The software maintenance method of a vehicle controller according to claim 6, characterized in that: The method further comprises: When the verification result is that the verification fails, a notification of the verification result is sent through the program flashing process.

8. The vehicle controller software maintenance method according to claim 6, characterized in that: The method further comprises: When the flash instruction is received again, the target software is flashed to a third version in the first partition according to the program flash process, so that the target software is run according to the third version in the first partition, and the third version is different from the first version and the second version.

9. A software maintenance device for a vehicle controller, characterized in that: include: a software flashing module configured to flash the target software of the vehicle controller to the second partition when the target software of the vehicle controller is running in the first partition according to the first version, wherein the first partition and the second partition are obtained by dividing the storage space of the vehicle controller; The software running module is configured to perform an integrity check using the first identification information of the first partition and the second identification information of the second partition to obtain a check result, and continue to run the target software according to the first version in the first partition or run the target software according to the second version in the second partition according to the check result, where the second version is different from the first version.

10. A computer-readable storage medium having computer program instructions stored thereon, characterized in that: When the program instructions are executed by a processor, the steps of the method described in any one of claims 1 to 8 are implemented.

11. An electronic device, characterized in that: include: a memory having a computer program stored thereon; A processor, configured to execute the computer program in the memory to implement the steps of the method according to any one of claims 1 to 8.

Images