Charging pile software updating method and device, computer equipment and storage medium

Abstract

The invention provides a charging pile software updating method and device, computer equipment and a storage medium, local software version information of each module in a charging pile and cloud software version information of each module in a file server are obtained, and the software version information comprises updating file information and updating file state; performing version self-checking on local software version information of each module based on a hash table in which latest software version information of each module is stored, and updating the hash table based on a version self-checking result; performing version check on the cloud software version information of each module based on the hash table, and updating the hash table based on a version check result; and in response to a software updating signal, performing software updating on each module in the charging pile based on the hash table. By adopting the method, the deployment, operation and maintenance cost of the system during software updating is reduced, and meanwhile, the universality and success rate of software updating are improved.

Description

Technical Field

[0001] The present invention relates to the field of software technology, and in particular to a charging pile software updating method, device, computer equipment and storage medium. Background Art

[0002] There are basically two existing software update solutions for DC charging piles. One is to not differentiate between the modules in the device and update all modules in the DC charging pile uniformly when there is a need for software update. The second is to allocate different update files to different modules of the DC charging pile and update them by module. In order to meet the software update function and software version management, most of the above software update methods require the construction of a network platform to complete the version management of each module in the DC charging pile.

[0003] However, the research found that the above software update solutions require a customized software management platform for software version management, which results in high system deployment and operation and maintenance costs during software updates. In addition, the device cannot be updated offline without an Internet connection, or the update files for offline updates cannot be version managed, which reduces the versatility and success rate of software updates. Summary of the invention

[0004] In view of this, the object of the present invention is to provide a charging pile software update method, device, computer equipment and storage medium to reduce the deployment and operation and maintenance costs of the system during software updates, while improving the versatility and success rate of software updates.

[0005] In a first aspect, an embodiment of the present application provides a charging pile software update method, the method comprising:

[0006] Obtain the local software version information of each module in the charging pile and the cloud software version information of each module in the file server, wherein the software version information includes update file information and update file status;

[0007] Performing a version self-check on the local software version information of each module based on a hash table storing the latest software version information of each module, and updating the hash table based on the version self-check result;

[0008] Performing version checking on the cloud software version information of each module based on the hash table, and updating the hash table based on the version checking result;

[0009] In response to the software update signal, software of each module in the charging pile is updated based on the hash table.

[0010] Optionally, performing version self-check on the local software version information of each module based on the hash table storing the latest software version information of each module includes:

[0011] Performing a version self-check on the local software version information of each module based on the latest update file information of each module to obtain a first self-check result, wherein the first self-check result is a self-check success or a self-check failure;

[0012] When the first self-check result is a self-check success, determining the first self-check result as a version self-check result;

[0013] When the first self-check result is self-check failure, a second self-check result is obtained by performing a version self-check based on the latest update file status of each module and the local software version information of each module, and the second self-check result is determined as the version self-check result.

[0014] Optionally, updating the hash table based on the version self-check result includes:

[0015] When the first self-check result is that the self-check is successful, the latest updated file status in the hash table is updated based on the local software version information of each module.

[0016] Optionally, performing version checking on the cloud software version information of each module based on the hash table includes:

[0017] Perform file name format verification on the cloud software version information of each module to determine the module that has successfully been verified;

[0018] Based on the cloud software version information of the successfully verified module and its corresponding latest software version information in the hash table, it is determined whether the successfully verified module meets the update requirements to implement version checking.

[0019] Optionally, updating the hash table based on version checking includes:

[0020] When the module that has been successfully verified meets the update requirements, the hash table is updated based on the cloud software version information of the module that has been successfully verified.

[0021] Optionally, performing software update on each module in the charging pile based on the hash table includes:

[0022] Determine a target update module based on the update file status of each module in the hash table;

[0023] Obtaining a target update package of the target update module from the file server;

[0024] The target update module is software updated based on the target update package.

[0025] Optionally, the modules in the charging pile also include a power control module, a switch control module, and a charging control module.

[0026] In a second aspect, an embodiment of the present application provides a charging pile software update device, the device comprising:

[0027] A software version information acquisition module is used to acquire the local software version information of each module in the charging pile and the cloud software version information of each module in the file server, wherein the software version information includes update file information and update file status;

[0028] A first hash table update module, configured to perform a version self-check on the local software version information of each module based on a hash table storing the latest software version information of each module, and update the hash table based on the version self-check result;

[0029] A second hash table update module, configured to perform a version check on the cloud software version information of each module based on the hash table, and update the hash table based on the version check result;

[0030] A software update module is used to respond to a software update signal and perform software update on each module in the charging pile based on the hash table.

[0031] Optionally, performing version self-check on the local software version information of each module based on the hash table storing the latest software version information of each module includes:

[0032] Performing a version self-check on the local software version information of each module based on the latest update file information of each module to obtain a first self-check result, wherein the first self-check result is a self-check success or a self-check failure;

[0033] When the first self-check result is a self-check success, determining the first self-check result as a version self-check result;

[0034] When the first self-check result is self-check failure, a second self-check result is obtained by performing a version self-check based on the latest update file status of each module and the local software version information of each module, and the second self-check result is determined as the version self-check result.

[0035] Optionally, updating the hash table based on the version self-check result includes:

[0036] When the first self-check result is that the self-check is successful, the latest updated file status in the hash table is updated based on the local software version information of each module.

[0037] Optionally, performing version checking on the cloud software version information of each module based on the hash table includes:

[0038] Perform file name format verification on the cloud software version information of each module to determine the module that has successfully been verified;

[0039] Based on the cloud software version information of the successfully verified module and its corresponding latest software version information in the hash table, it is determined whether the successfully verified module meets the update requirements to implement version checking.

[0040] Optionally, updating the hash table based on version checking includes:

[0041] When the module that has been successfully verified meets the update requirements, the hash table is updated based on the cloud software version information of the module that has been successfully verified.

[0042] Optionally, performing software update on each module in the charging pile based on the hash table includes:

[0043] Determine a target update module based on the update file status of each module in the hash table;

[0044] Obtaining a target update package of the target update module from the file server;

[0045] The target update module is software updated based on the target update package.

[0046] Optionally, the modules in the charging pile also include a power control module, a switch control module, and a charging control module.

[0047] In a third aspect, an embodiment of the present application provides a computer device, comprising: a processor, a memory and a bus, the memory storing machine-readable instructions executable by the processor, and when the computer device is running, the processor communicates with the memory through the bus, and when the machine-readable instructions are executed by the processor, the steps of the charging pile software update method described in any optional implementation manner of the first aspect are performed.

[0048] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium having a computer program stored thereon, and when the computer program is executed by a processor, the steps of the charging pile software update method described in any optional implementation manner in the above-mentioned first aspect are executed.

[0049] The technical solution provided by this application includes but is not limited to the following beneficial effects:

[0050] The present application obtains the local software version information of each module in the charging pile and the cloud software version information of each module in the file server; performs a version self-check on the local software version information of each module based on a hash table storing the latest software version information of each module, and updates the hash table based on the version self-check result; performs a version check on the cloud software version information of each module based on the hash table, and updates the hash table based on the version check result; in response to a software update signal, performs a software update on each module in the charging pile based on the hash table, simplifies the process of version management and maintenance, extracts important features such as version information, file acquisition records, and error version cleaning in version management, integrates version management into the device side, and only needs to provide a file server for remote upgrade, which reduces the cost of platform construction. By decoupling the file acquisition method from the version management module, remote upgrade and offline upgrade are uniformly managed on the device side, thereby reducing the deployment and operation and maintenance costs of the system during software updates, while improving the versatility and success rate of software updates.

[0051] In order to make the above-mentioned objects, features and advantages of the present invention more obvious and easy to understand, preferred embodiments are given below and described in detail with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings required for use in the embodiments are briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present invention and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without creative work.

[0053] Figure 1 A flowchart of a charging pile software update method provided by the first embodiment of the present invention is shown;

[0054] Figure 2 A flow chart of a version self-checking method provided in Embodiment 1 of the present invention is shown;

[0055] Figure 3 A schematic diagram of a version of a local self-check process provided by Embodiment 1 of the present invention is shown;

[0056] Figure 4 A flow chart of a version checking method provided in Embodiment 1 of the present invention is shown;

[0057] Figure 5 A flowchart of a naming format verification method provided by Embodiment 1 of the present invention is shown;

[0058] Figure 6 A flowchart of a software updating method provided by the first embodiment of the present invention is shown;

[0059] Figure 7 A schematic diagram showing a system module relationship provided by the first embodiment of the present invention;

[0060] Figure 8 A schematic diagram showing the structure of a charging pile software update device provided in the second embodiment of the present invention is shown;

[0061] Fig. 9 A schematic diagram of the structure of a computer device provided in Embodiment 3 of the present invention is shown. DETAILED DESCRIPTION

[0062] In order to make the purpose, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. The components of the embodiments of the present invention generally described and shown in the drawings here can be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present invention provided in the drawings is not intended to limit the scope of the claimed invention, but merely represents selected embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without making creative work belong to the scope of protection of the present invention.

[0063] Embodiment 1

[0064] To facilitate understanding of this application, Figure 1 The contents described in the flowchart of a charging pile software update method provided in the first embodiment of the present invention are described in detail in the first embodiment of the present application.

[0065] See also Figure 1 As shown, Figure 1 A flowchart of a charging pile software update method provided in the first embodiment of the present invention is shown, wherein the method comprises steps S101 to S104:

[0066] S101: Obtain local software version information of each module in the charging pile and cloud software version information of each module in the file server, wherein the software version information includes update file information and update file status.

[0067] Specifically, the TCU billing control module in the charging pile collects the local software version information of other modules in the charging pile, including the TCU billing control module, PCU power control module, PSU switch control module and CCU charging control module. At the same time, the TCU billing control module obtains the cloud software version information of each module from the server.

[0068] S102: Performing a version self-check on the local software version information of each module based on a hash table storing the latest software version information of each module, and updating the hash table based on the version self-check result.

[0069] Specifically, the latest software version information of each module stored in the hash table includes version number, file name, update status, download status, download count, file summary, and uses the module type corresponding to the file as the index value.

[0070] For each module, the TCU module determines which is higher, the latest software version of the module stored in the hash table or the local software version of the module, based on the latest software version information of the module stored in the hash table and the local software version information of the module; if the one in the hash table is higher, the local software version update file is deleted; if the local software version of the module is higher, the latest software version information of the module stored in the hash table is deleted. Furthermore, after the TCU module is started, it performs a self-check on the local version management status, loads the hash table file based on the version management submodule in the TCU module, parses out the current version of each module, available update files, available update file summaries, module update status, update file download times, and update file download status, performs a version self-check on the local software version information of each module based on the above information, and updates the corresponding field content in the hash table according to the self-check results.

[0071] S103: performing a version check on the cloud software version information of each module based on the hash table, and updating the hash table based on the version check result.

[0072] Specifically, for each module, the TCU module determines which of the latest software version of the module stored in the hash table and the cloud software version information of the module is higher based on the latest software version information of the module stored in the hash table and the cloud software version information of the module; if the one in the hash table is higher, the hash table is not updated; if the cloud software version of the module is higher, the cloud software version information of the module is recorded in the hash table. Furthermore, after the TCU completes the self-check of the local version management status, it periodically initiates HTTP requests to the file server to obtain the file names of the update files of all modules that already exist in the file server, and then verifies the naming format and version number of the file names.

[0073] S104: In response to the software update signal, perform software update on each module in the charging pile based on the hash table.

[0074] Specifically, the software update signal is triggered automatically periodically or manually by the charging pile manager, and the TCU module responds to the software update signal and performs software updates on each module in the charging pile using the latest software version information recorded in the hash table as the update target.

[0075] In an alternative embodiment, see Figure 2 As shown, Figure 2 A flowchart of a version self-checking method provided by the first embodiment of the present invention is shown, wherein the version self-checking of the local software version information of each module based on the hash table storing the latest software version information of each module comprises steps S201 to S203:

[0076] S201: Performing a version self-check on the local software version information of each module based on the latest update file information of each module to obtain a first self-check result, wherein the first self-check result is a self-check success or a self-check failure.

[0077] S202: When the first self-check result is a self-check success, determine the first self-check result as a version self-check result.

[0078] S203: When the first self-check result is self-check failure, a second self-check result is obtained by performing a version self-check based on the latest update file status of each module and the local software version information of each module, and the second self-check result is determined as the version self-check result.

[0079] Specifically, the first version self-check is performed to determine whether the latest update file of each module in the hash table exists. If not, the information is deleted. If the file exists, the summary of the file is obtained through the MD5 algorithm and compared with the summary in the hash table. If the comparison is successful, it means that the first version self-check of the module is successful. At this time, the latest update file status in the hash table is updated based on the local software version information of each module. If the comparison fails, it means that the first version self-check of the module has failed, then the download status and download count of the file are read. If the download has been completed or the download count has reached the limit value, the file and the information in the hash table are deleted. If the download is not completed and the download count has not reached the limit value, it means that the second self-check is successful, and the module update status is changed from updating to not updating, the download status is changed from downloading to not downloading, and the download count is changed to 0.

[0080] See also Figure 3 As shown, Figure 3A schematic diagram of a local self-check process of a version provided by the first embodiment of the present invention is shown, wherein the self-check is started, and it is determined whether a hash table file exists. If not, a hash table is created. If so, the hash table is read, and then all data in the hash table is traversed, a Linux command is executed to obtain a file summary, and then a Linux command is executed to traverse the files in the specified directory, and then a Linux command is executed to obtain the update package file summary and then determine whether the download is completed; if so, it is determined whether the summary comparison is correct, and if not, the hash table is updated; if it is determined whether the summary comparison is correct, the update package file is deleted and the hash table is updated; if it is determined whether the summary comparison is correct, the hash table is directly updated, and finally the self-check ends.

[0081] In an optional implementation, the updating of the hash table based on the version self-check result includes:

[0082] When the first self-check result is that the self-check is successful, the latest updated file status in the hash table is updated based on the local software version information of each module.

[0083] Specifically, when the first self-check result is a self-check success, there is no need to perform a second self-check, and the first self-check result is directly used as the version self-check result to update the hash table.

[0084] In an alternative embodiment, see Figure 4 As shown, Figure 4 A flow chart of a version checking method provided in the first embodiment of the present invention is shown, wherein the version checking of the cloud software version information of each module based on the hash table includes steps S401 to S402:

[0085] S401: Perform file name format verification on the cloud software version information of each module to determine the module that has successfully been verified.

[0086] S402: Determine whether the successfully verified module meets the update requirements based on the cloud software version information of the successfully verified module and its corresponding latest software version information in the hash table to implement version checking.

[0087] Specifically, the file names of all the update files of the modules that already exist in the file server are obtained, and then the naming format of the file names is checked, and the file names that have successfully been checked are cached in a list, and the file name and the file server address are combined into a file download address in the format of [file server address] / [file name], and cached in the name list, and the file names that have failed the check are skipped. The TCU traverses the name list, first obtains the version number according to the file name, and compares it with the current version number of the module to which the file applies. If it does not meet the update requirements, the file is ignored. If it meets the update requirements, it is further determined whether the file has been downloaded. If not, the download address of the file is removed from the file download address list, and the file is started to be downloaded. If it has been downloaded or not downloaded, the summary of the file is obtained from the file hit and compared with the summary of the corresponding file in the hash table. If the summary matches, the download continues. If the summary does not match, the downloaded part is deleted, the download is restarted, and the download status of the module in the hash table is updated to downloading, and the number of downloads is accumulated by 1. After the download is successful, the download status is updated to downloaded.

[0088] See also Figure 5 As shown, Figure 5 A flowchart of a naming format verification method provided by Embodiment 1 of the present invention is shown, wherein the file naming format is: [module type]_[version number]_[date]_[MD5 summary].SREC or [module type]_[version number]_[date]_[MD5 summary].update. After starting the naming format verification, the suffix of the file name is taken to determine whether it is the same as update. If so, the summary information part of the name is taken to determine whether it is a local file; if not, it is determined whether it is the same as SREC. If so, the summary information part of the name is taken to determine whether it is a local file, otherwise the verification fails. If it is a local file, the file digest is calculated by MD5 to determine whether the digest comparison is successful. If so, the module type in the name is taken, otherwise the verification fails; if it is not a local file, the module type in the name is directly taken to determine whether it is the same as TCU, if otherwise, it is determined whether it is the same as CCU, if otherwise, it is determined whether it is the same as PSU, if otherwise, it is determined whether it is the same as PCU; in the above module type judgment process, if it is the same as any model, the version number in the name is taken to determine whether it is greater than the current version. If so, the verification is successful, otherwise the verification fails, and finally the verification is ended.

[0089] In an optional implementation, the updating of the hash table based on the version check includes:

[0090] When the module that has been successfully verified meets the update requirements, the hash table is updated based on the cloud software version information of the module that has been successfully verified.

[0091] Specifically, when the verified module meets the update requirements, the download status and summary information in the local software version information are compared with the download status and summary information in the cloud software version information, and the update is performed based on the comparison result, and the hash table is updated based on the update status.

[0092] In an alternative embodiment, see Figure 6 As shown, Figure 6 A flowchart of a software update method provided in the first embodiment of the present invention is shown, wherein the software update of each module in the charging pile based on the hash table includes steps S601 to S603:

[0093] S601: Determine a target update module based on the update file status of each module in the hash table.

[0094] S602: Acquire a target update package of the target update module from the file server.

[0095] S603: Perform software update on the target update module based on the target update package.

[0096] Specifically, the TCU module periodically displays the update files and applicable modules that have been downloaded in the remote update interface, and cyclically checks whether the upgrade command has been received. If a local upgrade is required, the USB flash drive containing the update file needs to be connected to the USB interface of the TCU module, and the local upgrade is triggered by clicking the screen button. After the trigger, the TCU module will scan the files in the USB flash drive to determine whether the file name meets the naming format applicable to this method. Unsatisfactory files will be ignored, and satisfactory files will be classified according to the module type in the file name and displayed on the screen. The TCU module copies the file selected by the user to be updated from the USB flash drive to the update directory of the module according to the user's selection, triggering the update command. If a remote upgrade is required, select the module that can be updated in the software update interface of the TCU module to trigger the update command. After the TCU module receives the triggered update instruction, the version management module modifies the update status of the module in the hash table to updating, and monitors the update status of the module in real time. Then, according to the updated target module, the update file required for the update target is read from the file directory where the target module is stored, and the version number and data summary of the update file are parsed through the file name. Then, according to the type of the updated target module, the corresponding CAN data communication interface is called to transfer the data to the target module for the software update of the module. If the TCU module itself is updated, the file is directly replaced in the TCU file system. If the update fails, the version status of the module in the hash table is changed to not updated. If the update is successful, the status is modified to updated. The TCU module needs to be restarted after upgrading the target module for the update to take effect.

[0097] In an optional embodiment, the modules in the charging pile also include a power control module, a switch control module, and a charging control module.

[0098] For details, see Figure 7 As shown, Figure 7 A schematic diagram of a system module relationship provided by the first embodiment of the present invention is shown, wherein the update file source is U judgment or server, the TCU module is responsible for version management, downloads the update file from the update file source, and performs PSU update data and update feedback with the PSU switch control module, and performs CCU update data and update feedback with the CCU charging control module, and performs PCU update data and update feedback with the PCU power control module. For a DC charging pile, when the software version of each module in the DC charging pile is remotely updated based on the above modules, the following steps are included:

[0099] Step 1: Get the PCU power control module program to be updated, rename the file according to the naming format of the update file, and then upload the file to the server. The file naming format referred to in this step is: [module type]_[version number]_[date]_[MD5 summary].SREC or [module type]_[version number]_[date]_[MD5 summary].update.

[0100] Step 2: After TCU is started, the version management module is called to perform a local update status self-check. After the self-check is completed, the update status of the modules contained in the hash table is changed from "Updating" to "Not Updated", and the download status is changed from "Downloading" to "Not Downloaded". Modules with an update status of "Not Updated" and a download status of "Downloaded" are pushed to the interface as updateable modules. The status of the modules in the version management module included in this step is divided into: Not Updated, Updating, Updated. The download status of the update file in the version management module included in this step is divided into: Not Downloaded, Downloading, Downloaded.

[0101] Step 3: After verifying the information in the local hash table, the TCU uses the http protocol to initiate a file list query request to the specified file server. The response from the file server should include all update files in the server that are applicable to this method and support downloading.

[0102] Step 4: parse the names of all received files through the version management module, obtain the module type, version number, date, and MD5 summary of each file, and then compare it with the hash table loaded by the version management module. If the file has not been downloaded and the version number is greater than the current version number of the device, update the above information of the file to the hash table of the version management module. The hash table generated by the version management module included in this step contains: version number, file name, update status, download status, number of downloads, file summary, and uses the module type corresponding to the file as the index value.

[0103] Step 5: During the operation of TCU, the update status is not updated, the download status is not downloaded, and the download times are less than the maximum limit. The module download address, then download the corresponding update package to the specified update directory, and change the download status of the module to downloading. The download times limit value of the update file in the version management module included in this step is specified by the TCU software, and the default value is 3.

[0104] Step 6: When the TCU software update interface shows a prompt that the PCU is available for update, the operator chooses whether to perform the software update based on the on-site situation. If the on-site situation allows the update, click the button to trigger the update signal.

[0105] Step 7: After receiving the signal to start updating the PCU, the TCU splits and assembles the PCU data and sends all the data to the PCU module via the CAN bus. After receiving all the data, the PCU module assembles the data again, starts the software update, and feeds back the update status to the TCU via the CAN bus.

[0106] Step 8: TCU obtains the update status feedback of PCU and displays the feedback information on the interface. After receiving the successful update of PCU module, the update status of PCU module is modified to updated, and the interface prompts whether to restart TCU and PCU immediately to make the update effective. If the update fails, the update status of PCU module is modified to not updated, and prompts the update failure.

[0107] For a DC charging pile, when the software version of each module in the DC charging pile is locally updated, the following steps are included: Step 1, obtain the PCU program to be updated, rename the file according to the naming format of the update file of this method, and then save the file to a USB flash drive. Steps 3, 4, and 5 follow the corresponding steps in the aforementioned remote update. Step 6, connect the USB flash drive that stores the update file of the PCU module to the TCU through the USB interface, click the local update button in the TCU software update interface, and the version management module in the TCU will traverse the files in the USB flash drive, and calculate the file summary information of the files in the USB flash drive that conform to the naming format through the MD5 summary algorithm, and then compare it with the summary information in the file name. If the comparison is wrong, the file is ignored. If the comparison is correct, the file is displayed in the list of updateable files. Other files that do not conform to the naming format will be ignored. Steps 7 and 8 follow the corresponding steps in the aforementioned remote update.

[0108] Embodiment 2

[0109] See also Figure 8 As shown, Figure 8 A schematic diagram of the structure of a charging pile software update device provided in the second embodiment of the present invention is shown, wherein the device comprises:

[0110] The software version information acquisition module 801 is used to acquire the local software version information of each module in the charging pile and the cloud software version information of each module in the file server, wherein the software version information includes update file information and update file status;

[0111] A first hash table updating module 802, configured to perform a version self-check on the local software version information of each module based on a hash table storing the latest software version information of each module, and update the hash table based on the version self-check result;

[0112] A second hash table updating module 803, configured to perform a version check on the cloud software version information of each module based on the hash table, and update the hash table based on the version check result;

[0113] The software update module 804 is used to respond to the software update signal and perform software update on each module in the charging pile based on the hash table.

[0114] In an optional implementation, the performing version self-check on the local software version information of each module based on the hash table storing the latest software version information of each module includes:

[0115] Performing a version self-check on the local software version information of each module based on the latest update file information of each module to obtain a first self-check result, wherein the first self-check result is a self-check success or a self-check failure;

[0116] When the first self-check result is a self-check success, determining the first self-check result as a version self-check result;

[0117] When the first self-check result is self-check failure, a second self-check result is obtained by performing a version self-check based on the latest update file status of each module and the local software version information of each module, and the second self-check result is determined as the version self-check result.

[0118] In an optional implementation, the updating of the hash table based on the version self-check result includes:

[0119] When the first self-check result is that the self-check is successful, the latest updated file status in the hash table is updated based on the local software version information of each module.

[0120] In an optional implementation, the performing version check on the cloud software version information of each module based on the hash table includes:

[0121] Perform file name format verification on the cloud software version information of each module to determine the module that has successfully been verified;

[0122] Based on the cloud software version information of the successfully verified module and its corresponding latest software version information in the hash table, it is determined whether the successfully verified module meets the update requirements to implement version checking.

[0123] In an optional implementation, the updating of the hash table based on the version check includes:

[0124] When the module that has been successfully verified meets the update requirements, the hash table is updated based on the cloud software version information of the module that has been successfully verified.

[0125] In an optional implementation, the software update of each module in the charging pile based on the hash table includes:

[0126] Determine a target update module based on the update file status of each module in the hash table;

[0127] Obtaining a target update package of the target update module from the file server;

[0128] The target update module is software updated based on the target update package.

[0129] In an optional embodiment, the modules in the charging pile also include a power control module, a switch control module, and a charging control module.

[0130] Embodiment 3

[0131] Based on the same application concept, see Fig. 9 As shown, Fig. 9 FIG. 4 shows a schematic diagram of the structure of a computer device provided by Embodiment 3 of the present invention, wherein: Fig. 9 As shown, a computer device 900 provided in Embodiment 3 of the present application includes:

[0132] A processor 901, a memory 902 and a bus 903, wherein the memory 902 stores machine-readable instructions executable by the processor 901. When the computer device 900 is running, the processor 901 communicates with the memory 902 via the bus 903. When the processor 901 is running, the machine-readable instructions execute the steps of the charging pile software update method shown in the above-mentioned embodiment 1.

[0133] Embodiment 4

[0134] Based on the same application concept, an embodiment of the present application further provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the charging pile software update method described in any one of the above embodiments are executed.

[0135] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working process of the system and device described above can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here.

[0136] The computer program product for updating the charging pile software provided in the embodiment of the present invention includes a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the method described in the previous method embodiment. The specific implementation can be found in the method embodiment, which will not be repeated here.

[0137] The charging pile software update device provided in the embodiment of the present invention can be specific hardware on the device or software or firmware installed on the device. The implementation principle and technical effects of the device provided in the embodiment of the present invention are the same as those of the aforementioned method embodiment. For the sake of brief description, the parts not mentioned in the device embodiment can refer to the corresponding contents in the aforementioned method embodiment. Those skilled in the art can clearly understand that for the convenience and simplicity of description, the specific working processes of the systems, devices and units described above can all refer to the corresponding processes in the aforementioned method embodiment, and will not be repeated here.

[0138] In the embodiments provided by the present invention, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some communication interfaces, and the indirect coupling or communication connection of devices or units can be electrical, mechanical or other forms.

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

[0140] In addition, each functional unit in the embodiment provided by the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0141] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk, etc., which can store program codes.

[0142] It should be noted that similar numbers and letters represent similar items in the following figures. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. In addition, the terms "first", "second", "third", etc. are only used to distinguish the description and are not to be understood as indicating or implying relative importance.

[0143] Finally, it should be noted that the above-described embodiments are only specific implementations of the present invention, which are used to illustrate the technical solutions of the present invention, rather than to limit them. The protection scope of the present invention is not limited thereto. Although the present invention is described in detail with reference to the above-described embodiments, those skilled in the art should understand that any person skilled in the art can still modify the technical solutions described in the above-described embodiments within the technical scope disclosed by the present invention, or can easily think of changes, or make equivalent replacements for some of the technical features therein; and these modifications, changes or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present invention. They should all be covered within the protection scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the claims.

Claims

1. A charging pile software update method, characterized in that: The method comprises: Obtain the local software version information of each module in the charging pile and the cloud software version information of each module in the file server, wherein the software version information includes update file information and update file status; Performing a version self-check on the local software version information of each module based on a hash table storing the latest software version information of each module, and updating the hash table based on the version self-check result; Performing version checking on the cloud software version information of each module based on the hash table, and updating the hash table based on the version checking result; In response to the software update signal, software of each module in the charging pile is updated based on the hash table.

2. The method according to claim 1, characterized in that: The performing version self-check on the local software version information of each module based on the hash table storing the latest software version information of each module includes: Performing a version self-check on the local software version information of each module based on the latest update file information of each module to obtain a first self-check result, wherein the first self-check result is a self-check success or a self-check failure; When the first self-check result is a self-check success, determining the first self-check result as a version self-check result; When the first self-check result is self-check failure, a second self-check result is obtained by performing a version self-check based on the latest update file status of each module and the local software version information of each module, and the second self-check result is determined as the version self-check result.

3. The method according to claim 2, characterized in that The updating of the hash table based on the version self-check result includes: When the first self-check result is that the self-check is successful, the latest updated file status in the hash table is updated based on the local software version information of each module.

4. The method according to claim 1, characterized in that The performing version checking on the cloud software version information of each module based on the hash table includes: Perform file name format verification on the cloud software version information of each module to determine the module that has successfully been verified; Based on the cloud software version information of the successfully verified module and its corresponding latest software version information in the hash table, it is determined whether the successfully verified module meets the update requirements to implement version checking.

5. The method according to claim 4, characterized in that The updating of the hash table based on the version check includes: When the module that has been successfully verified meets the update requirements, the hash table is updated based on the cloud software version information of the module that has been successfully verified.

6. The method according to claim 1, characterized in that The performing software updating on each module in the charging pile based on the hash table includes: Determine a target update module based on the update file status of each module in the hash table; Acquire the target update package of the target update module from the file server; The target update module is software updated based on the target update package.

7. The method according to claim 1, characterized in that The modules in the charging pile also include a power control module, a switch control module, and a charging control module.

8. A charging pile software update device, characterized in that: The device comprises: A software version information acquisition module is used to acquire the local software version information of each module in the charging pile and the cloud software version information of each module in the file server, wherein the software version information includes update file information and update file status; A first hash table update module, configured to perform a version self-check on the local software version information of each module based on a hash table storing the latest software version information of each module, and update the hash table based on the version self-check result; A second hash table update module, configured to perform a version check on the cloud software version information of each module based on the hash table, and update the hash table based on the version check result; A software update module is used to respond to a software update signal and perform software update on each module in the charging pile based on the hash table.

9. A computer device, characterized in that: include: A processor, a memory and a bus, wherein the memory stores machine-readable instructions executable by the processor, and when the computer device is running, the processor and the memory communicate via the bus, and when the machine-readable instructions are executed by the processor, the steps of the charging pile software update method as described in any one of claims 1 to 7 are performed.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the charging pile software update method as described in any one of claims 1 to 7 are executed.

Images