Battery device firmware upgrade method, battery device, and storage medium

Abstract

The application relates to the field of device control and provides a battery device firmware upgrading method, a battery device and a storage medium, the method comprising the following steps: monitoring alarm information of a battery device and acquiring device portrait data of at least one dimension of the battery device; in the case that the alarm information meets preset alarm conditions, determining weight information corresponding to each device portrait data according to the data integrity of the device portrait data, wherein the weight information is positively correlated with the integrity of the device portrait data; performing upgrading decision evaluation on the device portrait data to determine upgrading decision sub-scores corresponding to each device portrait data; fusing the upgrading decision sub-scores according to the weight information to obtain decision evaluation parameters of the battery device; and when the decision evaluation parameters meet first upgrading conditions, performing a firmware upgrading operation on the battery device, so that the automation degree and timeliness of the battery device firmware upgrading operation are improved.

Description

Technical Field

[0001] This application relates to the field of device control, and more particularly to a firmware upgrade method for a battery device, a battery device, and a storage medium. Background Technology

[0002] Device firmware upgrades refer to erasing the instruction set stored in the device hardware and writing a new version, thereby enabling the device to fix vulnerabilities, improve performance, or expand functionality. Taking batteries as an example, battery firmware upgrades refer to the operation of updating the embedded software in the Battery Management System (BMS). Existing battery device firmware upgrades typically rely on users manually confirming whether a firmware version upgrade is needed based on the alarm information output by the device. This approach has low intelligence and cannot automatically perform differentiated firmware upgrades based on the large amount of information collected during battery device operation. Summary of the Invention

[0003] The main objective of this application is to provide a firmware upgrade method for battery devices, a battery device, and a storage medium, with the aim of improving the automation and timeliness of firmware upgrade operations for battery devices.

[0004] In a first aspect, this application provides a firmware upgrade method for a battery device, the method comprising the following steps: Monitor alarm information of battery devices and obtain device profile data of at least one dimension of the battery devices; When the alarm information meets the preset alarm conditions, the weight information corresponding to each device profile data is determined according to the data completeness of the device profile data, and the weight information is positively correlated with the completeness of the device profile data; The device profile data is used to evaluate upgrade decisions and determine the upgrade decision sub-scores corresponding to each device profile data. The upgrade decision sub-scores are fused based on the weight information to obtain the decision evaluation parameters for the battery device; When the decision evaluation parameters meet the first upgrade condition, a firmware upgrade operation is performed on the battery device.

[0005] Secondly, this application also provides a battery device, the battery device including a processor, a memory, and a computer program stored in the memory and executable by the processor, wherein when the computer program is executed by the processor, it implements the firmware upgrade method as described above.

[0006] Thirdly, this application also provides a computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, it implements the firmware upgrade method described above.

[0007] This application provides a firmware upgrade method, device, and computer storage medium for battery devices. This application utilizes device profile data accumulated during the operation of the battery device. When an alarm occurs, an upgrade decision is evaluated based on the device profile data, and a decision evaluation parameter obtained from the upgrade decision evaluation is used to determine whether to perform a firmware upgrade operation. This allows for timely automatic firmware upgrades based on alarm information, improving the automation and timeliness of the battery device firmware upgrade operation. Attached Figure Description

[0008] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0009] Figure 1 A schematic flowchart illustrating a firmware upgrade method for a battery device according to an embodiment of this application; Figure 2 A flowchart illustrating a firmware upgrade method for a battery device according to another embodiment of this application; Figure 3 A flowchart illustrating a firmware upgrade method for a battery device according to another embodiment of this application; Figure 4 A flowchart illustrating a firmware upgrade method for a battery device according to another embodiment of this application; Figure 5 This is a schematic block diagram of the structure of a battery device according to an embodiment of this application. Detailed Implementation

[0010] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0011] The flowchart shown in the attached diagram is for illustrative purposes only and does not necessarily include all content and operations / steps, nor does it necessarily have to be performed in the order described. For example, some operations / steps can be broken down, combined, or partially merged, so the actual execution order may change depending on the actual situation.

[0012] It should be understood that, in order to clearly describe the technical solutions of the embodiments of the present invention, the terms "first" and "second" are used in the embodiments of the present invention to distinguish identical or similar items with essentially the same function and effect. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and the terms "first" and "second" are not necessarily different.

[0013] It should be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of the application. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0014] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0015] The following detailed description of some embodiments of this application is provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0016] In related technologies, the core control algorithm of a Battery Management System (BMS) is typically deployed as embedded firmware. This firmware samples parameters such as voltage, temperature, and current of each battery cell in real time, and uses mathematical models to calculate the battery pack's State of Charge (SOC) and State of Health (SOH). Based on this, it implements charge and discharge control strategies to prevent safety risks such as overcharging, over-discharging, and thermal runaway. Simultaneously, it optimizes cell consistency through equalization management to slow down aging. However, the firmware update mechanism for existing battery devices mainly relies on manual triggering by the user for any operational anomalies. If manual intervention is not timely, the anomalies will persist, affecting the normal use of the battery device.

[0017] Therefore, there is an urgent need for a firmware upgrade method for battery devices to solve at least one of the above problems.

[0018] To resolve the above issues, please refer to [link / reference]. Figure 1 , Figure 1This is a schematic flowchart illustrating a firmware upgrade method for a battery device according to an embodiment of this application. The method assesses the firmware upgrade needs of the battery device based on device profile data collected by the battery management system, obtains decision assessment parameters reflecting the firmware upgrade needs, and determines whether a firmware upgrade operation needs to be performed based on the decision assessment parameters, thereby achieving autonomous firmware upgrade of the battery device. This firmware upgrade method can be implemented by the battery device itself, deployed in the battery management system of the battery device; alternatively, it can be implemented by a server, whereby the battery device sends device profile data, alarm information, etc., to a single server or server cluster via a communication module. The single server or server cluster then determines the decision assessment parameters and performs the firmware upgrade operation on the battery device based on these parameters.

[0019] It should be noted that the acquisition of any information mentioned in the method provided in this application, such as device profile data, complies with relevant regulations and is carried out with the consent of the corresponding user, and will not infringe on the user's privacy or violate relevant laws and regulations.

[0020] To solve the above problem, please refer to Figure 1 , Figure 1 This is a flowchart illustrating a firmware upgrade method for a battery device according to an embodiment of this application. Specifically, as shown... Figure 1 As shown, the provided firmware upgrade method includes steps S101 to S105. Details are as follows: Step S101: Monitor the alarm information of the battery device and obtain device profile data of at least one dimension of the battery device.

[0021] A battery device includes at least a battery pack composed of multiple battery cells and a battery management system that communicates with the battery pack. During the operation of the battery device, the battery management system needs to continuously monitor the status parameters of the battery pack, such as the voltage parameters of each battery cell, as well as the temperature data, current data, and state of charge (SOC) of the battery pack as a whole, and output alarm information when there are abnormal status parameters.

[0022] The device profile data reflects the basic information of the battery device and the user's usage habits, such as device model, firmware version, charging time, discharging time, charging frequency, and discharging frequency. Understandably, there is a certain correlation between the firmware update needs of the battery device and the aforementioned device profile data; therefore, the firmware update needs can be effectively assessed based on the device profile data.

[0023] It is understandable that the acquisition of device profile data and the monitoring of alarm information can be performed simultaneously: for example, continuously acquiring device profile data while listening for alarm information; or they can be performed alternately: for example, acquiring device profile data after listening for alarm information, or listening for alarm information after acquiring device profile data, and so on.

[0024] Step S102: When the alarm information meets the preset alarm conditions, determine the weight information corresponding to each device profile data according to the data completeness of the device profile data. The weight information is positively correlated with the completeness of the device profile data.

[0025] For example, if the alarm information meets preset alarm conditions, such as detecting alarm information or the number of detected alarm information reaching a certain number, it indicates that there is an abnormality in the operation of the battery device. The abnormality may be caused by firmware incompatibility with the battery device, which can be resolved through firmware upgrade. Therefore, the alarm information meeting the preset alarm conditions is used as the condition for triggering the calculation of decision evaluation parameters.

[0026] Specifically, the device profile data includes multiple dimensions, and the weight information of the device profile data in each dimension is determined to facilitate the subsequent fusion of the upgrade decision sub-scores of the device profile information in each dimension to obtain decision evaluation parameters. Among them, the weight information is determined at least by the completeness of the device profile data in that dimension.

[0027] Understandably, different dimensions of device profile data may have varying degrees of data gaps. The more complete the device profile data, the more valuable it is for that dimension, and the higher the weight can be assigned to it. Conversely, the less complete the device profile data, the lower the weight should be assigned to it. Therefore, the weight information for each dimension is positively correlated with the completeness of that dimension.

[0028] Step S103: Perform upgrade decision evaluation on the device profile data and determine the upgrade decision sub-score corresponding to each device profile data.

[0029] Understandably, device profile data reflects firmware upgrade needs to some extent. Therefore, upgrade needs are evaluated based on device profile data for each dimension, and upgrade decision sub-scores are obtained for each dimension of device profile data.

[0030] The dimensions of the device profile data include at least one of the following: device information dimension, alarm history dimension, device status dimension, and usage characteristic dimension.

[0031] Step S104: The upgrade decision sub-scores are fused according to the weight information to obtain the decision evaluation parameters of the battery device.

[0032] Understandably, each dimension of the device profile information has corresponding weight information and upgrade decision sub-scores. Furthermore, the greater the weight information, the greater the impact of the upgrade decision sub-score for that dimension on the decision evaluation parameters; conversely, the smaller the weight information, the smaller the impact of the upgrade decision sub-score for that dimension on the decision evaluation parameters.

[0033] Specifically, multiple upgrade decision self-scoring scores can be weighted and fused based on weight information to obtain upgrade evaluation parameters. Of course, this is not the only option, and no limitation is made here.

[0034] Step S105: When the decision evaluation parameters meet the first upgrade conditions, perform a firmware upgrade operation on the battery device.

[0035] Understandably, the level of the decision evaluation parameter reflects the level of firmware upgrade demand. Therefore, the first upgrade condition can be, for example, greater than a first preset value. When the decision evaluation parameter is greater than the first preset threshold, the battery device is controlled to perform a firmware upgrade operation.

[0036] Specifically, the battery device can be upgraded via FOTA (Firmware-Over-The-Air) to the latest available version or the target version corresponding to the alarm information, in order to fix the operational problems of the battery device.

[0037] In some embodiments, the method further includes: if the alarm identifier in the alarm information belongs to a preset identifier, taking the preset firmware version corresponding to the preset identifier as the target version of the upgrade operation, and controlling the battery device to perform a firmware upgrade operation based on the target version.

[0038] For example, the alarm identifier is used to reflect the type of alarm information. The alarm identifier can be a pre-set string, such as E2002 indicating AFE (Analog Front End) abnormality, E2012 indicating voltage difference abnormality, and E2006 indicating power surge.

[0039] Specifically, a mapping table between different alarm identifiers and firmware versions can be pre-set to determine the target firmware used to resolve different abnormal situations. For example, if the alarm identifier is E2002 or E2012, and it needs to be upgraded to the total voltage protection version, then the corresponding target version is the total voltage protection version; if the alarm message is E2006, and it needs to be upgraded to the latest version, then the corresponding target version is the latest version.

[0040] Understandably, when the alarm flag belongs to the aforementioned preset flag, the battery device can be directly controlled to upgrade the firmware to the target version corresponding to the preset flag, thus avoiding the computational burden caused by calculating decision evaluation parameters.

[0041] Please refer to Figure 2 , Figure 2 This is a flowchart illustrating a firmware upgrade method for a battery device, provided as another embodiment of this application.

[0042] In some embodiments, if the calculation of decision evaluation parameters is triggered as soon as an alarm is detected, the calculation of decision evaluation parameters will be deemed triggered, resulting in a significant increase in the computational load of the battery management system. To avoid this situation, such as... Figure 2 As shown, step S101 monitors the alarm information of the battery device, including: step S1011, determining at least one of alarm frequency, alarm severity, and alarm duration based on the alarm information; step S1012, if at least one of the alarm frequency, alarm severity, and alarm duration meets a preset triggering condition, determining that the alarm information meets the preset alarm condition.

[0043] Specifically, alarm information is determined to meet preset alarm conditions only when the alarm frequency is high (e.g., alarm frequency exceeds a preset frequency); or, alarm information is determined to meet preset alarm conditions only when the alarm severity is high (e.g., alarm priority exceeds a preset priority); or, alarm information is determined to meet preset alarm conditions only when the alarm duration is long (e.g., alarm duration exceeds a preset duration). This ensures the authenticity of alarm information and the necessity of calculating decision evaluation parameters, avoiding unnecessary triggering of decision evaluation parameter calculations and reducing the computational burden on the battery management system.

[0044] Please refer to Figure 3 , Figure 3 This is a flowchart illustrating a firmware upgrade method for a battery device, provided as another embodiment of this application.

[0045] like Figure 3 As shown, in some embodiments, step S102 determines the weight information corresponding to each device profile data based on the completeness of the device profile data, including: step S1021, evaluating the completeness of the device profile data to obtain the data completeness corresponding to each device profile data; step S1022, determining the decision completeness of the device profile data based on the data completeness corresponding to each device profile data; when the decision completeness is greater than or equal to a first preset threshold, determining the weight information based on the data completeness and the decision completeness.

[0046] Specifically, data completeness reflects the completeness of the device profile data for each dimension individually, while decision completeness reflects the overall completeness of all device profile data. Understandably, a low decision completeness indicates low data completeness for each dimension, meaning the device profile data as a whole has significant gaps. In this case, it's difficult to accurately quantify decision evaluation parameters based on the device profile data. Therefore, weight information and upgrade decision sub-scores are only calculated when the decision completeness is greater than or equal to a first preset threshold; otherwise, if the decision completeness is less than the first preset threshold, no further calculations are performed, thereby improving the accuracy and objectivity of the decision evaluation parameters.

[0047] Decision completeness can be obtained by adding the completeness of each data point together.

[0048] In some embodiments, the completeness assessment of the device profile data to obtain the data completeness corresponding to each device profile data includes: obtaining target field information corresponding to the device profile data; and determining the data completeness based on the field score and field weight of the target field information.

[0049] For example, each dimension of device profile data includes multiple fields. Each field under the same dimension can be traversed, and the field score can be determined based on whether each field is complete. Combined with the field weight corresponding to the field, the data completeness of the device profile data for that dimension can be determined.

[0050] Specifically, the weight of each field can be pre-set based on its importance. For example, fields can be categorized into key fields, important fields, and general fields, with the weight decreasing sequentially for each type. For instance, a key field could have a weight of 1.0, an important field 0.7, and a general field 0.5. Field scores can be determined based on whether a field is missing; a missing field can have a score of 0, while a complete field can have a score of 1. However, this is not a limitation; field weights and scores can also be other values, which are not restricted here.

[0051] For example, key fields are those necessary for performing upgrade decision evaluation, such as firmware version, device model, alarm identifier, alarm time, battery level, total voltage, and battery usage time; important fields are important bases for performing upgrade decision evaluation, such as production date, alarm priority, battery temperature, number of charging cycles, and usage frequency; general fields are other fields used as auxiliary basis for judgment, which will not be elaborated here.

[0052] In some embodiments, determining the data completeness based on the field scores and field weights of the target field information includes: summing the products of each field score and field weight to obtain a field score; summing the field weights to obtain a total weight; and determining the data completeness based on the ratio of the field score to the total weight.

[0053] Specifically, each field in the device profile information is traversed, and the sum of the product of the field score and the field weight for each field, as well as the sum of the weights of all fields, is calculated. The ratio of the two is taken as the data completeness of the device profile data for that dimension, i.e.: Data completeness = Σ(field weight × field score) / Σ(field weight). This is used to quantify the data completeness of the device profile data for each dimension, so as to dynamically adjust the weight information of the device profile data using data completeness, and make the magnitude of the decision evaluation parameters more objective and reasonable in reflecting the size of firmware upgrade needs in different dimensions.

[0054] In some embodiments, determining the weight information based on the data completeness and the decision completeness includes: determining the weight information according to the ratio of the data completeness to the decision completeness.

[0055] For example, suppose the data completeness of the device profile data in each dimension is γ1, γ2, ..., γ... N Therefore, the decision completeness γ = γ1 + γ2 + ... + γ N The weights of the device profile data for each dimension are: γ1 / γ, γ2 / γ, ..., γ N / γ. This ensures that the weight information for each dimension reflects the completeness of the device profile data for that dimension, making the impact of the device profile data on decision evaluation parameters correspond to the degree of data completeness.

[0056] Optionally, if the sum of the weight information calculated by the above method is not 1, or the difference from 1 is large, such as greater than 0.001, the calculated weight information is normalized so that the sum is 1, thereby improving the rationality of the weight information.

[0057] The weight information is calculated using the above method, so that the equipment profile data of each dimension has dynamically changing weights, thereby improving the rationality and objectivity of decision evaluation parameters.

[0058] In some embodiments, the method further includes setting the weight information to a preset value when the decision completeness is less than the first preset threshold.

[0059] For example, if the decision completeness is a very small value, such as close to 0, it will lead to an unreasonable increase in the calculated weight information. In this case, to avoid inaccurate weight information, the weight information is abandoned and the weight information of the user profile data is directly set to a preset value. For example, the weight information of the user profile data for each dimension is set to the same preset value. Assuming that the user profile information has a total of 4 dimensions, the weight information of each dimension is 1 / 4 = 0.25. Of course, this is not limited to this; the preset value of each weight can also be different.

[0060] In some embodiments, the method further includes: if the decision completeness is less than a second preset threshold, then abandoning the calculation of the decision evaluation parameters, wherein the second preset threshold is greater than the first preset threshold.

[0061] For example, if the completeness of the decision is low, then the upgrade decision evaluation based on incomplete user profile data lacks objectivity. Therefore, the upgrade evaluation based on the decision evaluation parameters should be abandoned directly, that is, other judgment criteria should be used for upgrade decision evaluation, or the firmware upgrade operation should be abandoned.

[0062] The second preset threshold for determining whether to abandon the calculation of decision evaluation parameters is lower than the first preset threshold for determining whether to abandon the calculation of weight information. For example, if the decision completeness is less than 1, the calculation of weight information is abandoned and the weight information is directly set to a preset value; while if the decision completeness is less than 0.1, the calculation of decision evaluation parameters is abandoned.

[0063] For example, the decision evaluation parameters can be abandoned from being calculated, such as by setting the decision evaluation parameters to 0.

[0064] In some embodiments, obtaining device profile data for a battery device includes: obtaining raw battery data; if the raw battery data is numerical data, normalizing it based on the maximum and minimum values ​​to obtain normalized values ​​for each numerical data; if the raw battery data is date data, converting it into timestamp information and normalizing it based on the earliest time in the timestamp information to obtain normalized dates for each date data; if the raw battery data is sequence data, converting it into encoded information and normalizing it based on the encoded information to obtain normalized sequences for each sequence data; and determining the device profile data based on the normalized values, the normalized dates, and the normalized sequences.

[0065] Understandably, raw battery data from different dimensions may have different formats or units. In order to integrate raw battery data from various dimensions, it is necessary to normalize the raw battery data to obtain device profile data with the same format and units. For example, the raw battery data can be normalized into device profile data with values ​​between 0 and 1, and then the device profile data can be integrated.

[0066] For example, for numerical data such as voltage, power consumption, temperature, usage duration, number of charging cycles, usage frequency, and alarm frequency, Min-Max normalization is used. The normalized value is calculated as: normalized_value = (x - min) / (max - min), where min and max represent the minimum and maximum values ​​within the same data category, respectively. For date-based data, such as production dates, the data is first converted to a timestamp and then normalized relative to the earliest timestamp. For sequential data, such as device model, alarm priority, and firmware version, one-hot encoding can be used to encode the sequential data, so that each sequential data item corresponds to a binary vector; for example, each device model corresponds to a binary vector.

[0067] In some embodiments, the device profile data includes device information data. The step of evaluating the device profile data to determine the upgrade decision sub-score corresponding to each device profile data includes: obtaining the device information data of the battery device, the device information data including device model data and current version data; if the device model data is compatible with the latest version, then determining the first upgrade sub-score based on the version difference information between the current version data and the target version data, wherein the first upgrade sub-score is positively correlated with the version difference information.

[0068] Specifically, the evaluation dimensions of device profile data include device information; that is, device profile data includes device information data. This device information data includes device model data, current version data, etc., and the firmware upgrade requirements of the battery device are evaluated based on this device information data.

[0069] The target version can be the latest firmware version or the target version corresponding to the alarm information. A mapping table between device models and compatible firmware versions is pre-set. Based on the device model data, the mapping table is looked up to determine whether the firmware version compatible with the device model data includes the target version, thereby determining whether the device model data and the target version are compatible.

[0070] Specifically, firmware upgrades for battery devices require that the device model be compatible with the target firmware version; otherwise, the upgraded firmware will not run on the device. Therefore, only when the device model data is compatible with the target version is the first upgrade sub-score determined based on the current version data; otherwise, the firmware upgrade operation is abandoned. Alternatively, if the device model data is incompatible with the target version, the device model sub-score `model_support_score` corresponding to the device model data is set to a smaller value, such as 0, while if the device model data is compatible with the target version, the device model sub-score is set to 1, thus providing a comparison.

[0071] Version difference information reflects the age of the current version, that is, the degree of difference between the current version and the latest version. The older the current version is relative to the latest version, the greater the version difference information, the stronger the need for firmware upgrade, and therefore the higher the first upgrade sub-score. Conversely, the newer the current version is relative to the latest version, the smaller the version difference information, the weaker the need for firmware upgrade, and the lower the first upgrade sub-score. Therefore, the first upgrade sub-score is positively correlated with version difference information.

[0072] Specifically, version differences can be quantified based on factors such as the number of version iterations and release intervals between the current and target versions, resulting in a current version sub-score. For example, the current version sub-score, version_score = 1 - normalized_version, where the latest version data is 1, and the current version data is the normalized version number.

[0073] In some embodiments, the device model sub-score (model_support_score) corresponding to the device model data and the current version sub-score (version_score) corresponding to the current version data are weighted and fused to obtain the first upgrade sub-score (deviceInfoScore) corresponding to the device information data. The weights of the device model sub-score and the current version sub-score can be set according to actual needs, for example, 0.4 and 0.6 respectively. Therefore, the first upgrade sub-score (deviceInfoScore) = 0.6 * version_score + 0.4 * model_support_score. However, this is not the only possibility; the first upgrade sub-score can also be calculated using other methods, which are not limited here.

[0074] In some embodiments, the method further includes: if the device model data is incompatible with the target version, then abandoning the firmware upgrade operation.

[0075] Understandably, if the device model itself is incompatible with the target version—for example, if the device model is older or the firmware of the target version cannot run on that battery model—upgrading to the target version may actually cause more serious problems. Therefore, in such cases, it is best to abandon the firmware upgrade operation.

[0076] In some embodiments, the device profile data includes historical alarm data. The step of evaluating upgrade decisions based on the device profile data and determining upgrade decision sub-scores corresponding to each device profile data includes: acquiring historical alarm data of the battery device within a preset period; determining the alarm frequency, alarm severity, and alarm quantity within the preset period based on the historical alarm data; and determining a second upgrade sub-score for the historical alarm data based on the alarm frequency, alarm severity, and alarm quantity. The second upgrade sub-score is positively correlated with the alarm frequency and alarm severity, and positively correlated with the alarm quantity when the alarm quantity is less than a preset quantity.

[0077] Understandably, firmware upgrades are ultimately designed to resolve detected alarms and improve the operational stability of battery devices. Therefore, device profile data includes historical alarm data.

[0078] The preset period can be a certain time window before the start of calculating the decision evaluation parameters. For example, one hour before the start of calculating the decision evaluation parameters can be used as the preset period. Based on the alarm information monitored in the preset period, the alarm frequency, alarm severity, alarm quantity, etc. are determined, and the second upgrade sub-score is determined based on the alarm frequency, alarm severity, and alarm quantity.

[0079] Specifically, the alarm frequency sub-score is equal to the normalized alarm frequency, i.e., frequency_score = normalized_frequency; the alarm severity sub-score is equal to the normalized alarm severity, i.e., severity_score = normalized_severity. The alarm severity can be determined based on the priority of the alarm information. If the number of alarms is large, in order to avoid the second escalation self-score increasing indefinitely, the second escalation sub-score is positively correlated with the number of alarms when the number of alarms is less than the preset number, and the second escalation sub-score is directly set to the preset score when the number of alarms is greater than the preset number. For example, the alarm number sub-score is proportional to the number of alarms when it is less than 1, i.e., anomaly_score = min(1.0, anomaly_count / 5.0).

[0080] Furthermore, the second escalation sub-score is equal to the weighted sum of the alarm frequency sub-score (frequency_score), alarm severity sub-score (severity_score), and alarm quantity sub-score (anomaly_score). The weights can be set according to actual needs, for example, 0.4, 0.4, and 0.2 respectively, i.e., alarmHistoryScore = 0.4 * frequency_score + 0.4 * severity_score + 0.2 * anomaly_score. Of course, it is not limited to this; the second escalation sub-score can also be calculated by other methods, which are not limited here.

[0081] In some embodiments, the device profile data includes device status data. The step of evaluating upgrade decisions based on the device profile data and determining upgrade decision sub-scores corresponding to each device profile data includes: acquiring device status data of the battery device, the device status data including battery status, voltage status, and temperature status; determining the number of status anomalies of the battery device based on the battery status, voltage status, and temperature status; and determining a third upgrade sub-score for the device status data based on the number of status anomalies; wherein the third upgrade sub-score is positively correlated with the number of status anomalies.

[0082] Understandably, the battery management system of a battery device accumulates a large amount of status data, which reflects the operating status of the battery device to a certain extent. Therefore, the dimensions of device profile data include the device status dimension, that is, device profile data includes device status data.

[0083] Specifically, device status data includes power status, voltage status, and temperature status, each of which can be normal or abnormal. For example, if the power status fluctuates, shows a falsely high value, or freezes, then the power status is abnormal; if the voltage remains excessively high or low, then the voltage status is abnormal; if the temperature remains excessively high, then the temperature status is abnormal. The number of abnormal device status data is called the status abnormality number, which can be, for example, 0, 1, 2, or 3.

[0084] Specifically, the third upgrade sub-score, deviceStatusScore, is calculated as: 0.4 * battery_anomaly + 0.3 * voltage_anomaly + 0.3 * temp_anomaly. Here, battery_anomaly is set to 1 if the battery status is abnormal, and 0 otherwise; voltage_anomaly is set to 1 if the voltage status is abnormal, and 0 otherwise; and temp_anomaly is set to 1 if the temperature status is abnormal, and 0 otherwise. However, this is not a limitation; the third upgrade sub-score can also be calculated using other methods, which are not specified here.

[0085] In some embodiments, the device profile data includes usage characteristic data. The step of evaluating the device profile data to determine the upgrade decision sub-score corresponding to each device profile data includes: obtaining the usage characteristic data of the battery device, the usage characteristic data including usage duration, number of charging times, and usage frequency; determining a fourth upgrade sub-score based on the usage duration, the number of charging times, and the usage frequency, wherein the fourth upgrade sub-score is positively correlated with the usage duration, the number of charging times, and the usage frequency.

[0086] Understandably, the firmware upgrade requirements for battery devices are also related to user habits. Therefore, the dimensions of device profile data include usage feature dimensions; in other words, device profile data includes usage feature data.

[0087] Specifically, the feature data used includes usage duration, number of charges, and usage frequency. The fourth upgrade sub-score, usagePatternScore, is calculated as: usage_time_score = 0.4 * usage_time_score + 0.3 * charge_count_score + 0.3 * usage_freq_score, where usage_time_score = normalized_usage_time (normalized usage duration), charge_count_score = normalized_charge_count (normalized number of charges), and usage_freq_score = normalized_usage_frequency (normalized usage frequency). However, this is not a limitation; the fourth upgrade sub-score can also be calculated using other methods, which are not specified here.

[0088] Understandably, the higher the usage time, number of charging cycles, and usage frequency, the more serious the aging of the battery device, and the more necessary it is to use the new firmware version for protection. Therefore, the fourth upgrade sub-score is positively correlated with usage time, number of charging cycles, and usage frequency within a certain range.

[0089] Please refer to Figure 4 , Figure 4 This is a flowchart illustrating a firmware upgrade method for a battery device, provided as another embodiment of this application.

[0090] In some embodiments, after performing a firmware upgrade operation on the battery device in step S105, the method further includes: step S106, obtaining a first alarm list within a first preset time period before performing the firmware upgrade operation, and a second alarm list within a second preset time period after performing the firmware upgrade operation; step S107, determining the alarm resolution rate of the firmware upgrade operation based on the first alarm list and the second alarm list, and storing the upgrade effect score of the firmware upgrade operation based on the alarm resolution rate.

[0091] Specifically, after the firmware upgrade is completed, the upgrade effect is quantified by comparing the first alarm list before the upgrade and the second alarm list after the upgrade. The alarm resolution rate can be determined by comparing the number of first alarms in the first alarm list with the number of second alarms in the second alarm list; it can also be determined by comparing the number of first alarm types in the first alarm list with the number of second alarm types in the second alarm list; or it can be determined by comparing the duration of the first alarm before the upgrade with the duration of the second alarm after the upgrade.

[0092] The first preset duration and the second preset duration can be the same or different, and can be set according to actual needs. No restrictions are imposed here.

[0093] Understandably, alarm resolution rate is positively correlated with upgrade effectiveness score. Upgrade effectiveness score can be used to quantify upgrade effectiveness, which can be displayed intuitively to users or sent to a remote server to facilitate R&D personnel in evaluating the effectiveness of firmware upgrades.

[0094] In some embodiments, the first upgrade condition includes the decision evaluation parameter being within a first preset parameter range, and the step of performing a firmware upgrade operation on the battery device when the decision evaluation parameter meets the first upgrade condition includes: performing a firmware upgrade operation on the battery device when the decision evaluation parameter is within the first preset parameter range.

[0095] Specifically, when the decision evaluation parameters are within a first preset parameter range, it indicates that the battery device has a high demand for firmware upgrades. At this time, the battery device is controlled to perform a firmware upgrade operation, upgrading the firmware version of the battery device to the target version, thereby achieving automated firmware upgrades. The first preset parameter range can be defined as the decision evaluation parameters being greater than a certain parameter threshold.

[0096] In some embodiments, the method further includes: if the decision evaluation parameter is within a second preset parameter range, obtaining auxiliary decision information, and performing a firmware upgrade operation on the battery device if the auxiliary decision information meets a second upgrade condition; wherein any value within the first preset parameter range is greater than any value within the second preset parameter range.

[0097] Specifically, even if the decision evaluation parameters do not reach the first preset parameter range, they may still be at a relatively high level, such as within the second preset parameter range. In this case, more comprehensive judgment criteria can be obtained, and combined with auxiliary decision information, it can be further determined whether a firmware upgrade operation needs to be performed. If the decision evaluation parameters are within the second preset parameter range, and the auxiliary decision information meets the second upgrade condition, then the battery device is controlled to perform a firmware upgrade operation.

[0098] Understandably, any value within the first preset parameter range is greater than any value within the second preset parameter range. For example, assuming the decision evaluation parameter is between 0 and 1, the first preset parameter range could be (0.70, 1.00], and the second preset parameter range could be (0.50, 0.70).

[0099] Understandably, if the decision evaluation parameter is less than 0.50 compared to the first preset parameter range and the second preset parameter range, it means that there is no need for a firmware upgrade for the battery device.

[0100] The firmware upgrade method for battery devices provided in this application utilizes device profile data accumulated during the operation of the battery device. When an alarm occurs, an upgrade decision is evaluated based on the device profile data, and the decision evaluation parameters obtained from the upgrade decision evaluation determine whether to perform the firmware upgrade operation. This method makes full use of the large amount of device profile data accumulated during the operation of the battery device, achieving a balance between the accuracy and recall rate of the upgrade decision, and improving the automation and timeliness of the firmware upgrade operation of the battery device.

[0101] For example, the above method can be implemented as a computer program, which can be used in, for example... Figure 5 It runs on the battery device shown.

[0102] Please see Figure 5 , Figure 5This is a schematic block diagram of a battery device provided in an embodiment of this application.

[0103] like Figure 5 As shown, the battery device includes a processor, a memory, and a network interface connected via a system bus, wherein the memory may include a storage medium and internal memory.

[0104] The storage medium may store an operating system and a computer program. The computer program includes program instructions that, when executed, cause the processor to perform any firmware upgrade method.

[0105] The processor provides computing and control capabilities to support the operation of the entire battery device.

[0106] Internal memory provides an environment for the execution of computer programs stored in the storage medium. When these computer programs are executed by the processor, the processor can perform any firmware upgrade method.

[0107] This network interface is used for network communication, such as sending assigned tasks. Those skilled in the art will understand that... Figure 5 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the battery device to which the present application is applied. A specific battery device may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0108] It should be understood that the processor can be a Central Processing Unit (CPU), but it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Among these, a general-purpose processor can be a microprocessor or any conventional processor.

[0109] In one embodiment, the processor is configured to run a computer program stored in memory to perform the following steps: Monitor alarm information of battery devices and obtain device profile data of at least one dimension of the battery devices; When the alarm information meets the preset alarm conditions, the weight information corresponding to each device profile data is determined according to the data completeness of the device profile data, and the weight information is positively correlated with the completeness of the device profile data; The device profile data is used to evaluate upgrade decisions and determine the upgrade decision sub-scores corresponding to each device profile data. The upgrade decision sub-scores are fused based on the weight information to obtain the decision evaluation parameters for the battery device; When the decision evaluation parameters meet the first upgrade condition, a firmware upgrade operation is performed on the battery device.

[0110] It should be noted that those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process of the battery device described above can be referred to the corresponding process in the aforementioned firmware upgrade method embodiment, and will not be repeated here.

[0111] This application also provides a computer-readable storage medium storing a computer program, the computer program including program instructions, and the method implemented when the program instructions are executed can be referred to various embodiments of the firmware upgrade method of this application.

[0112] The computer-readable storage medium can be an internal storage unit of the battery device described in the foregoing embodiments, such as the hard disk or memory of the battery device. Alternatively, the computer-readable storage medium can be an external storage device of the battery device, such as a plug-in hard disk, smart media card (SMC), secure digital card (SD), flash card, etc., provided on the battery device.

[0113] It should be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of the application. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0114] It should also be understood that the term "and / or" as used in this specification and the appended claims refers to any combination and all possible combinations of one or more of the associated listed items, and includes such combinations. It should be noted that, herein, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.

[0115] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments. The above descriptions are merely specific implementations of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A firmware upgrade method for a battery device, characterized in that, The method includes: Monitor alarm information of battery devices and obtain device profile data of at least one dimension of the battery devices; When the alarm information meets the preset alarm conditions, the weight information corresponding to each device profile data is determined according to the data completeness of the device profile data, and the weight information is positively correlated with the completeness of the device profile data; The device profile data is used to evaluate upgrade decisions and determine the upgrade decision sub-scores corresponding to each device profile data. The upgrade decision sub-scores are fused based on the weight information to obtain the decision evaluation parameters for the battery device; When the decision evaluation parameters meet the first upgrade condition, a firmware upgrade operation is performed on the battery device.

2. The firmware upgrade method for battery devices according to claim 1, characterized in that, The step of determining the weight information corresponding to each device profile data based on the completeness of the device profile data includes: The completeness of the device profile data is evaluated to obtain the data completeness of each device profile data. The decision completeness of the device profile data is determined based on the data completeness corresponding to each device profile data. When the decision completeness is greater than or equal to a first preset threshold, the weight information is determined based on the data completeness and the decision completeness.

3. The firmware upgrade method for battery devices according to claim 2, characterized in that, The method further includes: When the decision completeness is less than the first preset threshold, the weight information is set to a preset value.

4. The firmware upgrade method for battery devices according to claim 2, characterized in that, The method further includes: If the decision completeness is less than a second preset threshold, then the calculation of the decision evaluation parameters is abandoned, wherein the second preset threshold is greater than the first preset threshold.

5. The firmware upgrade method for a battery device according to claim 2, characterized in that, The determination of the weight information based on the data completeness and the decision completeness includes: The weight information is determined based on the ratio of the data completeness to the decision completeness.

6. The firmware upgrade method for a battery device according to claim 1, characterized in that, The device profile data includes device information data. The upgrade decision evaluation of the device profile data, determining the upgrade decision sub-score corresponding to each device profile data, includes: Obtain device information data for the battery device, including device model data and current version data; If the device model data is compatible with the target version, the first upgrade sub-score is determined based on the version difference information between the current version data and the latest version data, wherein the first upgrade sub-score is positively correlated with the version difference information.

7. The firmware upgrade method for a battery device according to claim 6, characterized in that, The method further includes: If the device model data is incompatible with the target version, the firmware upgrade operation will be abandoned.

8. The firmware upgrade method for a battery device according to claim 1, characterized in that, The device profile data includes historical alarm data. The upgrade decision evaluation of the device profile data, determining the upgrade decision sub-score corresponding to each device profile data, includes: Obtain historical alarm data of the battery device within a preset period; Based on the historical alarm data, determine the alarm frequency, alarm severity, and number of alarms for the preset period; A second escalation sub-score is determined based on the alarm frequency, the alarm severity, and the number of alarms; wherein the second escalation sub-score is positively correlated with the alarm frequency and the alarm severity, and positively correlated with the number of alarms when the number of alarms is less than a preset number.

9. The firmware upgrade method for a battery device according to claim 1, characterized in that, The device profile data includes device status data. The upgrade decision evaluation of the device profile data, determining the upgrade decision sub-score corresponding to each device profile data, includes: Acquire device status data of the battery device, including power status, voltage status, and temperature status; Based on the state of charge, the state of voltage, and the state of temperature, determine the number of abnormal states of the battery device; Based on the number of state anomalies, a third upgrade sub-score for the device state data is determined; wherein the third upgrade sub-score is positively correlated with the number of state anomalies.

10. The firmware upgrade method for a battery device according to claim 1, characterized in that, The device profile data includes usage feature data. The upgrade decision evaluation of the device profile data, determining the upgrade decision sub-score corresponding to each device profile data, includes: The usage characteristic data of the battery device is obtained, including usage duration, number of charging cycles, and usage frequency. A fourth upgrade sub-score is determined based on the usage duration, the number of charging cycles, and the usage frequency, wherein the fourth upgrade sub-score is positively correlated with the usage duration, the number of charging cycles, and the usage frequency.

11. The firmware upgrade method for a battery device according to claim 2, characterized in that, The process of evaluating the completeness of the device profile data to obtain the data completeness corresponding to each device profile data includes: Obtain the target field information corresponding to the device profile data; The data completeness is determined based on the field scores and field weights of the target field information.

12. The firmware upgrade method for a battery device according to claim 11, characterized in that, Determining the data completeness based on the field score and field weight of the target field information includes: The field score is obtained by summing the products of the scores of each field and the field weights. The total weight is obtained by summing the weights of each field. The data completeness is determined by the ratio of the field score to the sum of the weights.

13. The firmware upgrade method for a battery device according to any one of claims 1-12, characterized in that, The acquisition of device profile data for battery devices includes: Obtain raw battery data; If the original battery data is numerical data, then normalization is performed based on the maximum and minimum values ​​in the numerical data to obtain the normalized values ​​of each numerical data. If the original battery data is date data, then the date data is converted into timestamp information and normalized based on the earliest time in the timestamp information to obtain the normalized date of each date data. If the original battery data is sequential data, then the sequential data is converted into encoded information and normalized based on the encoded information to obtain a normalized sequence of each sequential data. The device profile data is determined based on the normalized value, the normalized date, and the normalized sequence.

14. The firmware upgrade method for a battery device according to any one of claims 1-12, characterized in that, The method further includes: If the alarm identifier in the alarm information is a preset identifier, the preset firmware version corresponding to the preset identifier is used as the target version of the upgrade operation, and the battery device is controlled to perform a firmware upgrade operation based on the target version.

15. The firmware upgrade method for a battery device according to any one of claims 1-12, characterized in that, The monitoring of alarm information from battery devices includes: Based on the alarm information, determine at least one of the following: alarm frequency, alarm severity, and alarm duration; If at least one of the alarm frequency, the alarm severity, and the alarm duration meets a preset triggering condition, the alarm information is determined to meet the preset alarm condition.

16. The firmware upgrade method for a battery device according to any one of claims 1-12, characterized in that, After performing a firmware upgrade on the battery device, the method further includes: Obtain a first alarm list within a first preset time period before performing the firmware upgrade operation, and a second alarm list within a second preset time period after performing the firmware upgrade operation; The alarm resolution rate of the firmware upgrade operation is determined based on the first alarm list and the second alarm list, and the upgrade effect score of the firmware upgrade operation is stored based on the alarm resolution rate.

17. The firmware upgrade method for a battery device according to any one of claims 1-12, characterized in that, The first upgrade condition includes that the decision evaluation parameters are within a first preset parameter range. When the decision evaluation parameters meet the first upgrade condition, performing a firmware upgrade operation on the battery device includes: When the decision evaluation parameters are within the first preset parameter range, a firmware upgrade operation is performed on the battery device.

18. The firmware upgrade method for a battery device according to claim 17, characterized in that, The method further includes: If the decision evaluation parameters are within the second preset parameter range, auxiliary decision information is obtained, and if the auxiliary decision information meets the second upgrade conditions, a firmware upgrade operation is performed on the battery device. Wherein, any value within the first preset parameter range is greater than any value within the second preset parameter range.

19. A battery device, characterized in that, The battery device includes a processor, a memory, and a computer program stored in the memory and executable by the processor, wherein when the computer program is executed by the processor, it implements the steps of the firmware upgrade method as described in any one of claims 1 to 18.

20. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, it implements the steps of the firmware upgrade method as described in any one of claims 1 to 18.

Images