Battery data management method and device, computer equipment and storage medium

Abstract

The invention discloses a battery data management method and device, computer equipment and a storage medium, and relates to the technical field of digital energy. In the present application, battery metadata is stored by a first device, and battery feature data is generated based on the battery metadata. On the basis, battery characteristic data sent by the first device is received and stored. Thus, services can be provided to the outside based on the battery feature data in the subsequent process without contacting the battery metadata, the privacy of the user is protected, and the data security is improved.

Description

Technical Field

[0001] The present application belongs to the field of digital energy technology, and in particular, relates to a battery data management method, device, computer equipment and storage medium. Background Art

[0002] A large amount of battery metadata is generated at each stage of the battery's life cycle. Relying on these battery metadata, the battery's full life cycle management and services can be achieved. However, since the battery metadata at each stage of the battery's life cycle is often collected by the service provider at the corresponding stage in the process of providing services to users, these battery metadata involve user privacy. Based on this, how to protect user privacy and improve the security of battery metadata in the process of using these battery metadata is a huge challenge. Summary of the invention

[0003] The present application provides a battery data management method, apparatus, computer equipment and storage medium, aiming to protect user privacy and improve the security of battery metadata.

[0004] A first aspect of the present application provides a battery data management method, the method comprising: receiving battery characteristic data sent by a first device, the first device storing battery metadata, the battery characteristic data being generated based on the battery metadata; and storing the battery characteristic data.

[0005] In this application, the first device stores the battery metadata and generates the battery characteristic data based on the battery metadata. On this basis, the battery characteristic data sent by the first device is received and stored, so that services can be provided to the outside based on the battery characteristic data in the future without contacting the battery metadata, thus protecting the user's privacy and improving the data security.

[0006] Optionally, the method further includes: receiving a characteristic data request from a second device, the characteristic data request being used to request target characteristic data; and sending the target characteristic data to the second device based on the battery characteristic data.

[0007] In the present application, after receiving a characteristic data request, the target characteristic data can be returned to the second device based on the battery characteristic data. It can be seen that the present application can provide relevant services of battery characteristic data to the outside without contacting the battery metadata, thereby protecting user privacy and meeting user data needs.

[0008] Optionally, the implementation process of sending the target characteristic data to the second device based on the battery characteristic data may include: if the target characteristic data is non-sensitive data, acquiring the target characteristic data based on the battery characteristic data; and sending the target characteristic data to the second device.

[0009] In the present application, if the target characteristic data requested by the second device is non-sensitive data, the target characteristic data can be directly returned to the second device, thereby providing services to the outside without contacting the battery metadata.

[0010] Optionally, the implementation process of sending target characteristic data to the second device based on the battery characteristic data may include: if the target characteristic data is sensitive data, verifying the key information of the second device; if the verification of the key information of the second device is successful, obtaining the target characteristic data based on the battery characteristic data; and sending the target characteristic data to the second device.

[0011] If the target feature data requested by the second device is sensitive data, the key information of the second device can be verified to verify the identity of the second device. If the verification is successful, the target feature data is returned to the second device, thereby improving the security of sensitive data.

[0012] Optionally, the method further includes: receiving a metadata request sent by the second device, and sending the metadata request to the first device.

[0013] In the present application, if the second device requests battery metadata, the metadata request can be forwarded to the first device, and the first device directly returns the target metadata to the second device. In this way, the battery metadata is still not contacted, thereby improving the security of the battery metadata.

[0014] Optionally, before sending the metadata request to the first device, the method further includes: verifying the key information of the second device; if the key information of the second device is verified successfully, executing the step of sending the metadata request to the first device.

[0015] In this application, before forwarding the metadata request of the second device to the first device, the identity of the second device can be verified by verifying the key information of the second device. After the verification is passed, the metadata request is sent to the first device, so that the security of the battery metadata can be further improved.

[0016] Optionally, the method further includes: receiving device information of the second device; and sending key information of the second device to the second device based on the device information of the second device.

[0017] In this application, corresponding key information can be generated for the second device based on the device information of the second device, so that the key information can be used to indicate the identity of the second device. On this basis, the second device can carry the key information when accessing sensitive feature data or metadata to indicate the legitimacy of its own identity.

[0018] Optionally, the method further includes: sending a standardization operator to the first device, wherein the standardization operator includes a rule for standardizing a data format of the battery metadata and a corresponding mapping rule.

[0019] In the present application, a standardized operator is sent to the first device, so that the first device can standardize the data format of the battery metadata and the corresponding mapping rules based on the standardized operator, so as to unify the data format of the battery metadata provided by different service providers, and unify the mapping rules corresponding to the battery metadata of different service providers, thereby facilitating the subsequent management and application of the battery data.

[0020] Optionally, the battery characteristic data includes at least one of battery status data and data characteristic values ​​of the battery metadata.

[0021] In the present application, the battery characteristic data may include at least one of the data characteristic values ​​of the battery status data and the battery metadata. The battery status data may indicate the status of the battery at different stages in its life cycle, and the data characteristic values ​​of the battery metadata may indicate the statistical characteristics of the battery metadata. On this basis, the battery characteristic data may be used to realize data analysis and status prediction at different stages in the battery life cycle, and to provide users with services at different stages in the battery life cycle.

[0022] The second aspect of the present application provides a battery data management device, which includes: a receiving module for receiving battery characteristic data sent by a first device, wherein the first device stores battery metadata, and the battery characteristic data is generated based on the battery metadata; and a storage module for storing the battery characteristic data.

[0023] Optionally, the device further includes: a receiving module for receiving a characteristic data request from a second device, wherein the characteristic data request is used to request target characteristic data; and a sending module for sending the target characteristic data to the second device based on the battery characteristic data.

[0024] Optionally, the sending module is specifically used to: if the target characteristic data is non-sensitive data, obtain the target characteristic data based on the battery characteristic data; and send the target characteristic data to the second device.

[0025] Optionally, the sending module is specifically used to: if the target characteristic data is sensitive data, verify the key information of the second device; if the verification of the key information of the second device is successful, obtain the target characteristic data based on the battery characteristic data; and send the target characteristic data to the second device.

[0026] Optionally, the receiving module is further used to: receive a metadata request from the second device; and the sending module is further used to: send the metadata request to the first device.

[0027] Optionally, the sending module is further used to: verify the key information of the second device; if the key information of the second device is verified, execute the step of sending the metadata request to the first device.

[0028] Optionally, the receiving module is further used to receive device information of the second device; and the sending module is further used to send key information of the second device to the second device based on the device information of the second device.

[0029] Optionally, the sending module is further used to: send a standardization operator to the multiple first devices, where the standardization operator includes a rule for standardizing a data format of the battery metadata and a corresponding mapping rule.

[0030] Optionally, the battery characteristic data includes at least one of battery status data and data characteristic values ​​of the battery metadata.

[0031] The third aspect of the present application further provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a computer device, the battery data management method of the first aspect is implemented.

[0032] The fourth aspect of the present application further provides a computer device, the computer device comprising a processor, the processor being used to execute a computer program in a memory to implement the battery data management method of the first aspect above.

[0033] A fifth aspect of the present application provides a computer program product, which includes instructions, and when the instructions are executed by a processor, the battery data management method as described in the first aspect above is implemented.

[0034] Compared with the prior art, the embodiments of the present application have at least the following beneficial effects:

[0035] In the embodiment of the present application, the first device stores the battery metadata and generates the battery characteristic data based on the battery metadata. On this basis, the battery characteristic data sent by the first device is received and stored, so that services can be provided to the outside based on the battery characteristic data in the future without contacting the battery metadata, thus protecting the user's privacy and improving the data security. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] Figure 1 It is a structural diagram of a battery data management system provided in an embodiment of the present application;

[0037] Figure 2 is a flow chart of a battery data management method provided in an embodiment of the present application;

[0038] Figure 3 This is a flow chart of providing feature data to a terminal device provided by an embodiment of the present application;

[0039] Figure 4 This is a flow chart of providing battery metadata to a terminal device provided by an embodiment of the present application;

[0040] Figure 5 It is a storage flow chart of battery metadata and battery characteristic data provided by an embodiment of the present application;

[0041] Figure 6 This is a flow chart of a terminal device requesting non-sensitive feature data from a first server provided by an embodiment of the present application;

[0042] Figure 7 This is a flow chart of a terminal device requesting sensitive feature data from a first server provided by an embodiment of the present application;

[0043] Figure 8 This is a flow chart of a terminal device requesting battery metadata from a first server provided by an embodiment of the present application;

[0044] Fig. 9 is a structural schematic diagram of a battery data management device provided in an embodiment of the present application;

[0045] Fig.10 is a structural schematic diagram of another battery data management device provided in an embodiment of the present application;

[0046] Fig.11 It is a structural diagram of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0047] The following embodiments of the technical solution of the present application are described in detail in conjunction with the accompanying drawings. The following embodiments are only used to more clearly illustrate the technical solution of the present application, and are therefore only used as examples, and cannot be used to limit the scope of protection of the present application.

[0048] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by technicians in the technical field to which this application belongs; the terms used herein are only for the purpose of describing specific embodiments and are not intended to limit this application; the terms "including" and "having" in the specification and claims of this application and the above-mentioned figure descriptions and any variations thereof are intended to cover non-exclusive inclusions.

[0049] In the description of the embodiments of the present application, the technical terms "first", "second", etc. are only used to distinguish different objects, and cannot be understood as indicating or implying relative importance or implicitly indicating the number, specific order, or primary and secondary relationship of the indicated technical features. In the description of the embodiments of the present application, "at least one" means one or more, and "more than one" means two or more, unless otherwise clearly and specifically defined.

[0050] Reference to "embodiments" herein means that a particular feature, structure, or characteristic described in conjunction with the embodiments may be included in at least one embodiment of the present application. The appearance of the phrase in various locations in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment that is mutually exclusive with other embodiments. It is explicitly and implicitly understood by those skilled in the art that the embodiments described herein may be combined with other embodiments.

[0051] In the description of the embodiments of the present application, the term "and / or" is only a description of the association relationship of the associated objects, indicating that there may be three relationships. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. In addition, the character " / " in this article generally indicates that the associated objects before and after are in an "or" relationship.

[0052] As the world pays more and more attention to sustainable development, digital energy technology with new energy as the core has attracted more and more attention. The so-called digital energy technology refers to the connection of energy facilities to the Internet of Things, relying on emerging technologies such as big data and artificial intelligence to connect the physical world and the digital world, and guide the energy flow through the information flow to achieve efficient use and intelligent management of energy. For example, in the field of new energy, digital energy technology can achieve the management of the entire life cycle of batteries in new energy vehicles.

[0053] The full life cycle of a battery may include multiple stages, for example, the multiple stages may include the production stage, the use stage, the recycling stage, etc. of the battery. Among them, different stages of the full life cycle of the battery may correspond to service providers that provide services to users at the corresponding stages. For example, the service provider corresponding to the production stage is a battery manufacturer, the service provider corresponding to the use stage may be a charging pile operator, a battery maintenance service provider, and the service provider corresponding to the recycling stage may be a battery recycler. Service providers at each stage may collect battery metadata in the process of providing services to users. For example, in the use stage of the battery, the charging pile operated by the charging pile operator may collect metadata such as the capacity, voltage, and charging current of the battery when charging the battery. On this basis, by accessing the battery metadata throughout the life cycle, the state of the battery throughout the life cycle can be managed, and corresponding services can be provided to the outside based on the state of the battery throughout the life cycle. However, since the battery metadata involves user privacy, there will be data security issues when accessing the battery metadata. Based on this, an embodiment of the present application provides a battery data management method, in which the battery metadata is stored by a first device, and battery feature data is generated based on the battery metadata. On this basis, the battery feature data sent by the first device is received and stored. In this way, services can be provided to the outside world based on battery characteristic data without accessing battery metadata, thus protecting user privacy and improving data security.

[0054] The battery data management method provided in the embodiment of the present application can be applied to a battery data management system, which may include a first device, a second device, and a third device. Among them, the first device can be used to store battery metadata, and generate battery characteristic data based on the battery metadata, and then send the battery characteristic data to the third device. The third device can be used to receive and store the battery characteristic data, on this basis, the second device can request a service from the third device, and accordingly, the third device can provide a service to the second device based on the stored battery characteristic data.

[0055] It should be noted that the second device may be a physical device or a software device deployed on a physical device. For example, the second device may be a terminal device or an application client deployed on a terminal device. Optionally, in some possible cases, the second device may also be used to collect battery metadata and send the collected battery metadata to the first device for storage.

[0056] In addition, in a possible implementation, the first device and the third device may be two independent devices deployed in the same physical device. For example, the first device and the third device are deployed in the same server or terminal device. In this case, although the third device is deployed in the same physical device as the first device, the third device cannot access the battery metadata stored in the first device. Among them, the third device may be a device combining software and hardware. The first device may also be a device combining software and hardware.

[0057] In another possible implementation, the first device and the third device may also be two devices deployed on different physical devices. For example, the first device and the third device may be deployed on different servers, or the first device is deployed in a server and the third device is deployed in a terminal device.

[0058] Alternatively, the first device and the third device are two different physical devices. For example, the first device is a server for storing battery metadata, and the third device is a server or terminal device for providing services to the outside.

[0059] Next, taking the first device and the third device as different servers and the second device as a terminal device as an example, a battery data management system provided in an embodiment of the present application is introduced. Figure 1 The battery data management system may include a first server 101, a second server 102 and a plurality of terminal devices 103. The second server 102 may be one or more. Figure 1 A plurality of second servers are shown in FIG.

[0060] In the embodiment of the present application, the multiple terminal devices 103 may include terminal devices operated or maintained by different service providers. For example, the multiple terminal devices 103 may include test equipment of battery manufacturers, industrial sensors, charging piles of charging pile operators, terminal devices used to collect and record data during vehicle maintenance operated by automobile manufacturers, and battery testing equipment of battery recyclers, etc. In addition, the multiple terminal devices 103 may also include terminal devices held by users who use batteries.

[0061] The second server 102 can be used to store battery metadata. In addition, the second server 102 can be a server operated or maintained by a service provider. For example, the second server 102 can be a local server of the service provider, or a cloud server rented by the service provider. When there are multiple second servers 102, a second server 102 and a terminal device 103 operated or maintained by the same service provider among multiple second servers 102 and multiple terminal devices 103 can establish a communication connection. In this way, the terminal device 103 can collect battery metadata and send the collected battery metadata to the second server 102 belonging to the same service provider for storage.

[0062] It should be noted that each second server 102 can store the battery metadata sent by the terminal device 103 belonging to the same service provider locally. Optionally, multiple second servers 102 can also form a blockchain system. In this case, a blockchain can be deployed on each second server 102, and accordingly, the second server 102 can store the received battery metadata in the blockchain.

[0063] When there is only one second server 102, terminal devices 103 operated or maintained by different service providers can all access the second server 102 and send their collected battery metadata to the second server 102. In this case, the second server 102 can store battery metadata of different service providers, that is, it can store battery metadata of different stages in the whole life cycle of the battery.

[0064] The second server 102 and multiple terminal devices 103 can communicate with the first server 101. Among them, the second server 102 can generate battery characteristic data based on the battery metadata stored in itself, and send the battery characteristic data to the first server 101. The first server 101 can store the battery characteristic data sent by the second server 102. On this basis, any terminal device 103 among the multiple terminal devices 103 can send a characteristic data request to the first server 101 to request the target characteristic data. After receiving the characteristic data request, the first server 101 can return the target characteristic data to the terminal device 103 based on the characteristic data request and the battery characteristic data stored in itself. In this way, the first server 101 provides services to users through the battery characteristic data throughout the battery life cycle provided by the second server 102, without contacting the battery metadata, protecting user privacy, and improving the security of the battery metadata.

[0065] In addition, in the embodiment of the present application, a behavior model of the battery's entire life cycle may be deployed on the first server 101. On this basis, the first server 101 may use digital twin technology to perform data analysis and prediction through the behavior model and the battery characteristic data stored in itself, so as to enhance the intelligence and accuracy of the battery's entire life cycle management.

[0066] Optionally, the terminal device 103 may also send a metadata request to the first server 101 to request target metadata. The first server 101 may forward the metadata request to the second server 102, and the second server 102 returns the requested target metadata to the terminal device 103. In this way, the first server still does not have access to the battery metadata, thereby improving the security of the battery metadata.

[0067] It should be noted that, in the embodiment of the present application, the first server 101 can be a local server or a cloud server.

[0068] Based on the battery data management system introduced above, the battery data management method provided in the embodiment of the present application is applied to the above Figure 1 The battery data management system shown in the figure is taken as an example to introduce the detailed implementation process of the battery data management method. That is, taking the first device as the second server, the third device as the first server, and the second device as any one of the multiple terminal devices as an example, the battery data management method provided in the embodiment of the present application is introduced as an example, see Figure 2 , the method comprises the following steps:

[0069] Step 201: The second server receives and stores battery metadata.

[0070] In an embodiment of the present application, the second server may receive and store battery metadata collected by the second terminal device.

[0071] Among them, the second terminal device may be a terminal device operated or maintained by a service provider, and the second server may be a server for storing the battery metadata of the service provider. Exemplarily, the second server and the second terminal device may both be operated or maintained by the service provider. The second terminal device first accesses the second server. Afterwards, the second terminal device may collect battery metadata when providing battery services to the user, and report the collected battery metadata to the second server in real time. Alternatively, the second terminal device may also report to the second server after the battery metadata collected by itself reaches a certain amount of data, or the second terminal device may send the battery metadata collected within the preset interval to the second server at every preset interval. Among them, the battery metadata may include unprocessed battery data.

[0072] In a possible implementation, when the second terminal device first accesses the second server, the device information of the second terminal device may be sent to the second server. After receiving the device information of the second terminal device, the second server may send the device information of the second terminal device to the first server. The first server may send the key information of the second terminal device to the second terminal device based on the device information of the second terminal device. The key information is used for identity authentication when the second terminal device subsequently requests data from the first server.

[0073] The device information of the second terminal device may include the network address, device type, service type, etc. of the second terminal device. The first server may generate key information based on the device information of the second terminal device, and send the key information to the second terminal device based on the network address of the second terminal device.

[0074] It should be noted that the service type of the second terminal device can be used to indicate the service provided by the second terminal device. For example, when the second terminal device is a charging pile, the corresponding service type can be a charging service. In the case where there are multiple second servers and each second server is used to store battery metadata of a stage in the full life cycle of the battery, the first server can determine which stage of the battery life cycle the second terminal device belongs to through the service type of the second terminal device, so as to determine which stage of the battery life cycle metadata the second server connected to the second terminal device stores. Based on this, in an embodiment of the present application, the first server can store the service type of the second terminal device in correspondence with the identifier of the second server to which the second terminal device is connected. Among them, the identifier of the second server can be the network address of the second server or other information that can be used to uniquely identify the second server. Of course, in some possible cases, the first server can also obtain the service type corresponding to the second server by other means, for example, it can be reported by the second server itself.

[0075] In addition, when the second terminal device is a terminal device of a battery manufacturer, the second terminal device can collect battery metadata during the battery production process. For example, the second terminal device can read the battery identification and collect the battery capacity, voltage, current, and physical parameters of each battery cell in the battery.

[0076] When the second terminal device is a terminal device of a service provider in the battery use stage, the second terminal device can collect battery metadata when providing services to users. For example, when the second terminal device is a charging pile operated by a charging pile operator, when charging the user's battery, the second terminal device can read the battery identification and collect battery metadata such as battery capacity, charging current, voltage, temperature, etc.

[0077] When the second terminal device is a terminal device of a battery recycler, the second terminal device can collect metadata of the battery to be recycled. For example, the second terminal device can read the battery identification and collect the capacity of the battery to be recycled, the physical parameters of each battery cell in the battery, etc.

[0078] After receiving the battery metadata sent by the second terminal device, the second server can store the battery metadata and the corresponding battery identification locally. Alternatively, a blockchain can also be deployed on the second server, so that the second server can store the battery metadata and the corresponding battery identification in the blockchain.

[0079] Optionally, the second server may also store corresponding collection time information and corresponding service type for the battery metadata.

[0080] Optionally, since the types of battery metadata collected by the terminal devices of service providers at different stages of the battery life cycle may be different, and the data formats and corresponding mapping rules of the same type of battery metadata collected by the terminal devices of each service provider may also be different, in an embodiment of the present application, in order to facilitate the comprehensive management of the entire life cycle of the battery, the first server may pre-send a standardization operator to the second server. Among them, the standardization operator includes rules for standardizing battery metadata. Based on this, the second server can standardize the data format and corresponding mapping rules of the received battery metadata based on the standardization operator.

[0081] Among them, standardizing the data format of the battery metadata may include standardizing one or more of the data fields, data structures, and measurement units of the battery metadata.

[0082] Exemplarily, standardizing the data fields of battery metadata may mean: for a certain type of data, if the standardization operator includes conversion rules corresponding to the parameter fields of this type of data, the second server may convert the parameter fields in the data it receives according to the corresponding conversion rules provided in the standardization operator. For example, the temperature data of the battery reported by the second terminal device is: Temperature 30°C, where the parameter field used to identify the temperature parameter is Temperature. The conversion rule corresponding to Temperature in the standardization operator is: (Temperature, T)→(Temp), that is, when the parameter field of the temperature data is Temperature or T, it is converted to Temp. Based on this, the second server can replace Temperature in the received temperature data with Temp according to the conversion rule.

[0083] Standardizing the data structure of battery metadata may mean that: for a certain type of data, the standardization operator includes a data structure corresponding to the data, and the second server may convert the data structure of the data received by itself according to the data structure corresponding to the data in the standardization operator. For example, the temperature data of the battery reported by the second terminal device may be: T = 30 ° C, and the data structure corresponding to the temperature data in the standardization operator is: battery temperature [T = xx ° C]. Based on this, the second server may change the data structure of the temperature data received by itself to: battery temperature [T = 30 ° C] according to the data structure of the temperature data in the standardization operator.

[0084] Standardizing the measurement unit of battery metadata may mean that for a certain type of data, the standardization operator includes a preset measurement unit for the data and a conversion rule for converting other measurement units into the preset measurement unit. Based on this, the second server may convert the received battery metadata according to the conversion rule for converting the first measurement unit into the preset measurement unit in the standardization operator when the first measurement unit of the data received by itself is not the preset measurement unit. For example, the temperature data of the battery reported by the second terminal device is: T = 30°C, that is, the measurement unit is Celsius, and the measurement unit of the battery temperature data in the standardization operator is K, that is, Kelvin temperature. Based on this, the second server may convert the temperature data it receives to T = 303K according to the conversion rule for converting Celsius into Kelvin temperature provided in the standardization operator.

[0085] In addition, in an embodiment of the present application, since the second server may be a server operated or maintained by a service provider at a certain stage of the battery's life cycle, the second server may also provide services to users through the terminal device based on the battery metadata collected by the terminal device. For example, the second server may provide users with services such as safety warnings and battery status diagnosis based on the battery metadata. Based on this, the second server may also store mapping rules corresponding to the battery metadata, which may include safety warning rules, battery status diagnosis rules, etc. corresponding to the battery metadata. Considering that the same type of mapping rules corresponding to the same type of battery metadata in the second servers corresponding to different service providers may be different, the standardization operator sent by the first server to the second server may also include rules for standardizing the mapping rules corresponding to the battery metadata, so as to unify the same mapping rules corresponding to the same type of battery metadata in the second servers corresponding to different service providers. Based on this, the second server may also standardize the mapping rules corresponding to the battery metadata stored in itself based on the standardization operator.

[0086] Exemplarily, for a certain type of battery metadata, the standardization operator may include a standard safety warning rule and a warning rule conversion algorithm corresponding to the battery metadata, wherein the standard safety warning rule may include a standard warning condition and a corresponding standard warning description information. The second server may detect whether the first warning condition in the safety warning rule corresponding to the battery metadata stored in itself is the same as the standard warning condition, and whether the first warning description information corresponding to the first warning condition is the same as the standard warning description information by executing the warning rule conversion algorithm in the standardization operator. If the first warning condition is different from the standard warning condition, but the first warning description information is the same as the standard warning description information, the first warning condition may be modified to the standard warning condition. If the first warning condition is the same as the standard warning condition, but the first warning description information is different from the standard warning description information, the first warning description information may be modified to the standard warning description information. If both are different, it may be further determined whether the condition range of the first warning condition contains the condition range of the standard warning condition, or it may be determined whether the condition range of the standard warning condition contains the condition range of the first warning condition. If so, the warning rule of the battery metadata stored in the second server may be directly modified to the standard safety warning rule.

[0087] For example, the standard warning condition in the standard safety warning rule corresponding to the battery temperature data in the standardized operator is Temp>38℃, that is, when the battery temperature is greater than 38℃, a warning is issued, and the corresponding standard warning description information can be that the battery temperature is too high. The first warning condition in the safety warning rule corresponding to the battery temperature data in the second server is Temp>40℃, that is, when the battery temperature is greater than 40℃, a warning is issued, and the corresponding first warning description information is that the battery temperature is too high. In this case, the second server can modify the first warning condition to Temp>38℃ based on the standardized operator.

[0088] In some embodiments of the present application, the standardization operator may also include at least one standard state diagnosis rule. Among them, the standard state diagnosis rule may refer to a rule for determining a certain battery state based on battery metadata. Based on this, the second server can also detect whether any state diagnosis rule stored in itself is the same as the standard state diagnosis rule for determining the same battery state based on the standardization operator. If they are not the same, corresponding modifications can be made based on the standard state diagnosis rule.

[0089] For example, the standardized operator includes a standard state diagnosis rule for estimating the remaining battery life based on the battery capacity. If the state diagnosis rule for estimating the remaining battery life based on the battery capacity in the second server is different from the standard state diagnosis rule, the second server can modify its own stored state diagnosis rule based on the standard state diagnosis rule. For another example, the standardized operator may include a standard state diagnosis rule for diagnosing battery faults based on the battery charging current. If the state diagnosis rule for diagnosing battery faults based on the battery charging current in the second server is different from the standard state diagnosis rule, the second server can modify its own state diagnosis rule accordingly based on the standard state diagnosis rule.

[0090] Step 202: The second server generates battery characteristic data based on the battery metadata.

[0091] After receiving the battery metadata sent by the second terminal device, the second server may generate battery characteristic data based on the battery metadata, wherein the battery characteristic data may include at least one of battery status data and data characteristic values ​​of the battery metadata.

[0092] Exemplarily, from the above introduction, it can be seen that the second server can provide corresponding services to users based on the mapping rules corresponding to the battery metadata. Based on this, in an embodiment of the present application, the second server can generate battery status data based on the received battery metadata and the corresponding mapping rules. Among them, the battery status data may include safety warning data generated based on safety warning rules corresponding to the battery metadata, fault diagnosis data generated based on status diagnosis rules, battery health status data, etc.

[0093] Optionally, the second server may also perform statistics based on the received battery metadata to obtain data characteristic values ​​of the battery metadata, wherein the data characteristic values ​​may include statistical data corresponding to statistical quantities such as standard deviation, mean value, median, etc. of the battery metadata.

[0094] For example, for the data of a certain parameter of a certain battery, the second server can count the standard deviation, average value, etc. of the data of the parameter of the battery currently received, or it can also count the standard deviation, average value, etc. of the data of the parameter of the battery currently received and the data of the parameter of the battery within a period of time before the current moment.

[0095] Step 203: The second server sends battery characteristic data to the first server.

[0096] After obtaining the battery characteristic data, the second server may send the battery characteristic data to the first server so that the first server can provide services to the user based on the battery characteristic data without accessing the battery metadata, thereby protecting user privacy and improving data security.

[0097] It should be noted that, when sending the battery characteristic data, the second server may send the battery identifier corresponding to the battery characteristic data to the first server together, so that the first server can store and manage the battery characteristic data.

[0098] Optionally, the second server may also send the service type corresponding to the battery characteristic data to the first server, and the service type may be used to indicate to which stage of the battery life cycle the battery characteristic data belongs.

[0099] Optionally, the second server may also send time information corresponding to the battery characteristic data, and the time information may include collection time information of battery metadata used to generate the battery characteristic data.

[0100] When there are multiple second servers, each of the multiple second servers can refer to the method introduced in the above embodiment to process the battery metadata received and stored by itself, so as to obtain battery characteristic data, and feed back the battery characteristic data to the first server.

[0101] Step 204: The first server receives and stores the battery characteristic data sent by the second server.

[0102] As can be seen from the introduction in the above embodiments, when there are multiple second servers, each second server can send the battery characteristic data and the corresponding battery identification obtained after processing the battery metadata to the first server. Based on this, the first server can receive the battery characteristic data sent by multiple second servers, and store the battery characteristic data, the corresponding battery identification and the identification of the second server that sent the battery characteristic data accordingly.

[0103] Optionally, when there is only one second server, the first server may store the received battery characteristic data and the corresponding battery identification in correspondence with each other, without storing the identification of the second server.

[0104] Optionally, in the case where the second server also sends the service type corresponding to the battery characteristic data, the first server may also store the service type in correspondence with the battery characteristic data.

[0105] Optionally, in the case where the second server also sends the time information corresponding to the battery characteristic data, the first server may also store the time information corresponding to the battery characteristic data in correspondence with the battery characteristic data.

[0106] When the first server receives and stores the battery characteristic data sent by the second server, the terminal device can request a service from the first server. Next, the process of the first server providing a service to the terminal device is introduced. Figure 3When the terminal device requests related services related to battery characteristic data, the first server can execute the following steps 301 and 302.

[0107] Step 301: The first server receives a feature data request sent by a first terminal device.

[0108] In the embodiment of the present application, when the first terminal device wants to request a service related to battery characteristic data, the first terminal device may send a characteristic data request to the first server. Correspondingly, the first server may receive the characteristic data request sent by the first terminal device.

[0109] Wherein, the characteristic data request is used to request other battery data other than non-battery metadata. Exemplarily, the characteristic data request includes indication information of the target characteristic data to be requested. For example, the characteristic data request may include a target battery identifier and a target data type to indicate which type of characteristic data of which battery is requested. Wherein, the target data type may include at least one of a state class and a data feature class, the state class is used to indicate that the target characteristic data is battery state data, and the data feature class is used to indicate that the target characteristic data is a data feature value. In addition, the indication information of the target characteristic data may also include a target service type to indicate which stage of the entire life cycle of the battery the characteristic data is requested for. Optionally, the indication information of the target characteristic data may also include target time information to indicate which time period of the battery the characteristic data is requested for.

[0110] In addition, in an embodiment of the present application, the first terminal device may be a terminal device maintained by a service provider and connected to the second server of the service provider. For example, the first terminal device may be the same terminal device as the second terminal device in the aforementioned embodiment, or the first terminal device and the aforementioned second terminal device are different terminal devices connected to the same second server, or the first terminal device and the aforementioned second terminal device are connected to different second servers. As can be seen from the introduction in step 201, when the terminal device first accesses the second server, the first server can allocate key information to the terminal device based on the device information of the terminal device. Therefore, in this case, the feature data request may also include the key information of the first terminal device.

[0111] Optionally, in some possible situations, the first terminal device may also carry its own key information in the feature data request when the requested target feature data is sensitive data, and not carry its own key information in the feature data request when the requested target feature data is non-sensitive data. Sensitive data includes data feature values ​​and battery metadata of battery metadata, and non-sensitive data includes battery status data.

[0112] Optionally, in some embodiments of the present application, the first terminal device may also be a terminal device held by a user. In this case, the feature data request may not include key information.

[0113] Step 302: The first server sends target characteristic data to the first terminal device based on the battery characteristic data.

[0114] After receiving the characteristic data request, the first server may return target characteristic data to the first terminal device based on the characteristic data request and the battery characteristic data stored in the first server.

[0115] Exemplarily, if the target characteristic data requested by the characteristic data request is sensitive data, the first server can verify the key information of the first terminal device. If the verification of the key information of the first terminal device is successful, the target characteristic data is obtained based on the battery characteristic data stored in itself; and the target characteristic data is sent to the first terminal device.

[0116] Optionally, if the target characteristic data requested by the characteristic data request is non-sensitive data, the first server may directly obtain the target characteristic data based on the stored battery characteristic data, and send the target characteristic data to the first terminal device.

[0117] It should be noted that if the terminal device carries its own key information in the feature data request when the data type of the requested feature data is a data feature type, but does not carry its own key information when the data type is a status type, then when the feature data request contains the key information of the first terminal device, it means that the target feature data requested by the first terminal device is sensitive data. In this case, the first server can directly verify the key information in the feature data request of the first terminal device.

[0118] Optionally, if the terminal device carries its own key information in the feature data request when the data type of the requested feature data is a status type or a data feature type, the first server may determine whether the requested target feature data is sensitive data based on the target data type in the feature data request of the first terminal device. If the target data type is a data feature type, the target feature data is determined to be sensitive data. In this case, the key information of the first terminal device is verified. Optionally, if the target data type is a status type, the target feature data is determined to be non-sensitive data. In this case, the first server may not verify the key information of the first terminal device, but directly obtain the target feature data based on the feature data request and the stored battery feature data. Of course, in this case, the first server may not determine the target data type, but directly verify the key information of the first terminal device.

[0119] After the first server verifies the key information of the first terminal device, or determines that the target characteristic data is non-sensitive data, the first server can obtain at least one characteristic data from the battery characteristic data stored in itself based on the indication information of the target characteristic data included in the characteristic data request, and then obtain the target characteristic data based on the at least one characteristic data. The target characteristic data includes the at least one characteristic data, or the target characteristic data is generated by the at least one characteristic data.

[0120] Exemplarily, when the target data type in the indication information of the requested target characteristic data is a status type, the first server can obtain the battery status data that corresponds to the target battery identification and conforms to the target service type and / or target time information from the battery characteristic data stored in itself, and use the obtained battery status data as the target characteristic data.

[0121] Among them, it can be known from the introduction in the above-mentioned embodiment that when there are multiple second servers and each second server is used to store battery metadata of a stage of the battery life cycle, the first server can store the mapping relationship between the identifier of the second server and the service type, and when storing the battery characteristic data, the first server correspondingly stores the identifier of the second server that sends the battery characteristic data. Based on this, the first server can first obtain the identifier of the target second server corresponding to the target service type, and then obtain the battery status data corresponding to the target battery identifier and the identifier of the target second server from the battery characteristic data stored in itself. At this time, the obtained battery status data is the target characteristic data corresponding to the target battery identifier that conforms to the target service type. Alternatively, the first server stores the service type correspondingly when storing the battery characteristic data. In this case, the first server can directly obtain the battery status data corresponding to the target battery identifier and the target server type, and the obtained battery status data is the target characteristic data.

[0122] Alternatively, if the indication information of the target characteristic data includes target time information, the first server may obtain the battery status data that conforms to the target time information and corresponds to the target battery identifier from the battery characteristic data stored in the first server.

[0123] Optionally, if the indication information of the target characteristic data does not include target time information and target service type, the first server may obtain battery status data of each stage in the entire life cycle corresponding to the target battery identifier, and use the obtained battery status data as the target characteristic data.

[0124] Optionally, the first server may also generate a battery status report based on the acquired battery status data, and use the battery status report as the target characteristic data.

[0125] Specifically, a behavior model of the battery's entire life cycle may be deployed on the first server. The behavior model includes but is not limited to the battery's data model, algorithm model, geometric model, and control feedback model. On this basis, the first server may use the acquired battery status data as input to the behavior model, use the behavior model to analyze the battery status data of the battery, and make predictions, thereby generating a status report of the battery's entire life cycle.

[0126] As another example, when the target data type in the indication information of the requested target characteristic data is a data characteristic class, the first server can obtain the data characteristic value corresponding to the target battery identification that conforms to the target service type and / or target time information from the battery characteristic data stored in itself, and use the obtained data characteristic value as the target characteristic data.

[0127] After acquiring the target characteristic data, the first server may send the target characteristic data to the first terminal device.

[0128] Optionally, if the target characteristic data is sensitive data and the first server fails to verify the key information of the first terminal device, the first server may send a request failure message to the first terminal device.

[0129] From the above, it can be seen that in the embodiment of the present application, the first server can store the battery characteristic data provided by the second server. On this basis, the first server can provide services to the outside based on the battery characteristic data. In this way, the first server does not contact the battery metadata of each service provider, which protects user privacy and improves data security. Moreover, when the battery metadata of the entire life cycle of the battery is stored in one or more second servers, the first server can obtain the battery characteristic data of the entire life cycle of the battery, thereby realizing the aggregation and management of the characteristic data of the entire life cycle of the battery, and then providing users with battery status management services for each stage of the entire life cycle.

[0130] The above steps 301 and 302 mainly introduce the implementation process when the terminal device requests the first server for services related to battery characteristic data. In some possible situations, the terminal device may also need to request battery metadata from the first server. For example, a terminal device may need to request battery metadata collected by a terminal device that does not belong to the same service provider. In this case, Figure 4 The process shown provides the requested battery metadata to the end device, see Figure 4 , the process may include:

[0131] Step 401: A first terminal device sends a metadata request to a first server.

[0132] In the embodiment of the present application, when the first terminal device needs to request battery metadata, it sends a metadata request to the first server. Correspondingly, the first server receives the metadata request sent by the first terminal device.

[0133] The metadata request includes indication information of the target metadata to be requested. The indication information of the target metadata includes a target battery identifier to indicate which battery metadata is requested. Optionally, the indication information may also include a target service type and / or target time information to indicate which stage and / or time in the battery life cycle metadata is requested.

[0134] Optionally, since battery metadata involves user privacy and is sensitive data, in order to improve data security, in an embodiment of the present application, the metadata request carries the key information of the first terminal device. Since the key information of the terminal device is allocated by the first server, the first server can verify the key information of the first terminal device when receiving the metadata request, thereby verifying the identity of the first terminal device.

[0135] If the first server successfully verifies the key information of the first terminal device, the first server may perform the following step 402. Alternatively, if the first server fails to verify the key information of the first terminal device, the first server may return a request failure message to the first terminal device, or do not respond and directly terminate the operation.

[0136] Optionally, the metadata request may also carry a network address of the first terminal device.

[0137] Step 402: The first server sends the metadata request to the second server.

[0138] In the case where there are multiple second servers, the first server can determine the target second server storing the target metadata from the multiple second servers according to the indication information of the target metadata carried in the metadata request. Then, the metadata request is sent to the corresponding target second server. The target second server and the first terminal device may be operated or maintained by the same service provider, or may be operated or maintained by different service providers.

[0139] Exemplarily, as described in the aforementioned step 204, the first server can store the battery identifier, the identifier of the second server that sends the battery characteristic data, and the time information in correspondence with the battery characteristic data. Furthermore, as described in the aforementioned step 201, the first server can also store a mapping relationship between the identifier of the second server and the service type. Based on this, in this step, the first server can search for the identifier of the second server corresponding to the target battery identifier. If the indication information of the target metadata does not include the target time information and / or the target service type, the identifier of the second server found is the identifier of the target second server. Among them, there may be one or more identifiers of the second server found, that is, there may be one or more target second servers.

[0140] Optionally, if the indication information of the target metadata includes the target service type and / or target time information, the first server can search for the identifier of the second server that matches the target service type and corresponds to the target battery identifier, and / or search for the identifier of the second server that matches the battery characteristic data that matches the target time information and corresponds to the target battery identifier. The identifier of the second server found is the identifier of the target second server.

[0141] After finding the identifier of the target second server, the first server may send a metadata request to the target second server based on the identifier of the target second server.

[0142] If the metadata request does not carry the network address of the first terminal device, the first server may send the metadata request and the network address of the first terminal device to the target second server.

[0143] Optionally, if there is one second server, the second server is the target second server, and therefore, the first server may directly forward the metadata request to the second server.

[0144] Step 403: The second server sends target metadata to the first terminal device.

[0145] After receiving the metadata request, the second server can obtain the target metadata corresponding to the target battery identification and conforming to the target time information and / or target service type from the battery metadata stored in itself, and then feedback the target metadata to the first terminal device based on the network address of the first terminal device.

[0146] From the above, it can be seen that in an embodiment of the present application, when a terminal device requests battery metadata from a first server, the first server can forward the metadata request to a corresponding second server, and the corresponding second server directly feeds back the battery metadata to the terminal device. In this way, the first server does not contact the battery metadata, thereby protecting user privacy and improving data security. In addition, before forwarding the metadata request, the first server may first verify the identity of the terminal device that sends the metadata request, and then forward the metadata request to the second server after the verification is passed, thereby further improving data security.

[0147] Based on the battery data management method described in the above embodiment, the present application embodiment first takes the charging pile maintained by the charging pile operator and the second server as an example to illustrate the storage process of battery metadata and battery feature data. Figure 5 As shown, the process includes the following steps:

[0148] Step 501: When the charging pile is connected to the second server for the first time, the charging pile sends device information of the charging pile to the second server.

[0149] The device information of the charging pile may include the network address of the charging pile, such as an IP (Internet Protocol) address.

[0150] Step 502: The second server sends the device information of the charging pile to the first server.

[0151] Step 503: The first server generates key information of the charging pile based on the device information of the charging pile.

[0152] Step 504: The first server sends the key information to the charging pile.

[0153] The first server may send key information to the charging pile based on the network address included in the device information of the charging pile.

[0154] Step 505: The charging station collects battery metadata when charging the user's battery.

[0155] Step 506: The charging pile sends the battery metadata to the second server.

[0156] Step 507: The second server performs standardization processing on the battery metadata and stores the standardized battery metadata.

[0157] Step 508: The second server generates battery characteristic data based on the battery metadata.

[0158] Step 509: The second server sends the battery characteristic data to the first server.

[0159] Step 510: The first server stores the battery characteristic data.

[0160] Among them, the specific implementation method of steps 501 to 510 can refer to the relevant introduction in the aforementioned embodiment, and the embodiments of the present application will not be repeated here.

[0161] Based on the above process, the first server will store the battery characteristic data sent by each second server operated or maintained by different service providers. Later, when the terminal device requests non-sensitive status characteristic data from the first server, the first server can Figure 6 The process shown provides services to terminal devices. Figure 6 As shown, the process includes the following steps:

[0162] Step 601: The terminal device sends a feature data request to the first server to request non-sensitive target feature data.

[0163] The feature data request does not include key information of the terminal device.

[0164] Step 602: The first server obtains target characteristic data based on the stored battery characteristic data.

[0165] Step 603: The first server sends target feature data to the terminal device.

[0166] Among them, the detailed implementation method of steps 601 to 603 can refer to the relevant introduction in the aforementioned embodiment, and the embodiments of the present application will not be repeated here.

[0167] When the terminal device requests the first server for characteristic data of a sensitive data characteristic class, the first server can Figure 7 The process shown provides services to terminal devices. Figure 7 , the process includes the following steps:

[0168] Step 701: The terminal device sends a feature data request to the first server to request sensitive target feature data, where the feature data request includes key information of the terminal device.

[0169] Step 702: The first server verifies the key information of the terminal device.

[0170] Step 703: If the key information of the terminal device is verified successfully, the first server obtains target characteristic data based on the stored battery characteristic data.

[0171] Step 704: The first server sends target feature data to the terminal device.

[0172] Among them, the detailed implementation method of steps 701 to 704 can refer to the relevant introduction in the aforementioned embodiment, and the embodiments of the present application will not be repeated here.

[0173] When the terminal device requests sensitive battery metadata from the first server, the first server and the second server can Figure 8 The process shown provides services to terminal devices. Figure 8 , the process includes the following steps:

[0174] Step 801: A terminal device sends a metadata request to a first server, where the metadata request includes key information of the terminal device.

[0175] Step 802: The first server verifies the key information of the terminal device.

[0176] Step 803: When the key information of the terminal device is verified successfully, the first server determines the target second server based on the feature data request.

[0177] Step 804: The first server forwards the metadata request to the target second server.

[0178] Step 805: The target second server obtains target metadata based on the metadata request.

[0179] Step 806: The target second server sends the target metadata to the terminal device.

[0180] Among them, the detailed implementation method of steps 801 to 806 can refer to the relevant introduction in the aforementioned embodiment, and the embodiments of the present application will not be repeated here.

[0181] It is worth noting that in the above embodiment, the battery data management method provided in the embodiment of the present application is introduced by taking the first device and the third device as different servers as an example. When the first device and the third device are deployed on different physical devices or are different physical devices of other types, or when the first device and the third device are two independent devices deployed on the same physical device, the first device and the third device can also interact with each other with reference to the interaction process between the second server and the first server described in the above embodiment to achieve battery data management. The second device can also refer to the interaction method between the first terminal device and the first server described in the above embodiment to request services from the third device. In addition, the second device can also refer to the interaction method between the second terminal device and the second server described in the above embodiment to access the first device corresponding to itself, so as to provide the first device with the battery metadata collected by itself.

[0182] Next, the battery data management device provided in the embodiment of the present application is introduced.

[0183] Fig. 9 900 is a schematic diagram of the structure of a battery data management device 900 provided in an embodiment of the present application. The third device in the aforementioned embodiment can implement battery data management through the battery data management device 900, such as Fig. 9 As shown, the battery data management device 900 includes a receiving module 901 and a storage module 902 .

[0184] The receiving module 901 is used to receive battery characteristic data sent by the first device, the first device stores battery metadata, and the battery characteristic data is generated based on the battery metadata; the storage module 902 is used to store the battery characteristic data.

[0185] Optionally, the receiving module 901 is further used to receive a characteristic data request sent by a second device, where the characteristic data request is used to request target characteristic data; the device 900 also includes a sending module 903, which is used to send target characteristic data to the second device based on the battery characteristic data.

[0186] Optionally, the sending module 903 is specifically used for: if the target characteristic data is non-sensitive data, obtaining the target characteristic data based on the battery characteristic data; and sending the target characteristic data to the second device.

[0187] Optionally, the sending module 903 is specifically used to: if the target characteristic data is sensitive data, verify the key information of the second device; if the verification of the key information of the second device is successful, obtain the target characteristic data based on the battery characteristic data; and send the target characteristic data to the second device.

[0188] Optionally, the receiving module 901 is further used to: receive a metadata request sent by the second device; the sending module 903 is further used to: send a metadata request to the first device.

[0189] Optionally, the sending module 903 is further used to: verify the key information of the second device; if the key information of the second device is verified successfully, execute the step of sending a metadata request to the first device.

[0190] Optionally, the receiving module 901 is further used to receive device information of the second device; the sending module is further used to send key information of the second device to the second device based on the device information of the second device.

[0191] Optionally, the sending module 903 is further used to: send a standardization operator to the first device, where the standardization operator includes a rule for standardizing a data format of the battery metadata and a corresponding mapping rule.

[0192] Optionally, the battery characteristic data includes at least one of data characteristic values ​​of battery status data and battery metadata.

[0193] In the embodiment of the present application, the third device can receive and store the battery characteristic data sent by the first device, and the battery characteristic data is generated based on the battery metadata, and the battery metadata is stored in the first device. In this way, the third device can provide services to the outside based on the battery characteristic data without contacting the battery metadata, thereby protecting user privacy and improving data security.

[0194] Fig.10 FIG. 1 is a schematic diagram of the structure of another battery data management device 1000 provided in an embodiment of the present application. The first device in the aforementioned embodiment can realize the corresponding functions through the battery data management device 1000, such as Fig.10 As shown, the battery data management device 1000 includes a receiving module 1001 , a storage module 1002 , a processing module 1003 and a sending module 1004 .

[0195] The receiving module 1001 is used to receive battery metadata; the storage module 1002 is used to store battery metadata; the processing module 1003 is used to generate battery characteristic data based on the battery metadata; and the sending module 1004 is used to send the battery characteristic data to a third device.

[0196] Optionally, the receiving module 1001 is further used to receive a standardization operator sent by a third device; the processing module 1003 is further used to standardize the data format of the battery metadata and the corresponding mapping rules based on the standardization operator.

[0197] Optionally, the receiving module 1001 is further used to receive a metadata request from the second device sent by the third device, where the metadata request is used to request target metadata; the sending module 1004 is further used to send the target metadata to the second device.

[0198] Optionally, the battery characteristic data includes at least one of data characteristic values ​​of battery status data and battery metadata.

[0199] In the embodiment of the present application, the first device stores the battery metadata, generates battery characteristic data based on the battery metadata, and feeds back the battery characteristic data to the third device. On this basis, the third device can provide services to the outside based on the battery characteristic data without contacting the battery metadata, thereby protecting user privacy and improving data security.

[0200] It should be noted that those skilled in the art can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional units and modules as needed, that is, the internal structure of the battery data management device is divided into different functional units or modules to complete all or part of the functions described above. In addition, the specific names of the modules are only for the convenience of distinguishing each other and are not used to limit the scope of protection of this application. The specific working process of the modules in the above-mentioned device can refer to the corresponding process in the aforementioned method embodiment, which will not be repeated here.

[0201] Fig.11 is a schematic diagram of the structure of a computer device provided in an embodiment of the present application. The third device and / or the first device introduced in the above embodiment can be implemented by the computer device. Fig.11 As shown, the computer device 10 of this embodiment includes: a processor 110, a memory 120, and a computer program 130 stored in the memory 120 and executable on the processor 110, such as a program for processing a data set and performing aggregation operations on multi-dimensional processing results of the data set. When the processor 110 executes the computer program 130, the steps in the above-mentioned various method embodiments are implemented, such as Figures 2 to 8 Alternatively, when the processor 110 executes the computer program 130, the functions of each module / unit in the above-mentioned battery data management device embodiment are realized.

[0202] Exemplarily, the computer program 130 may be divided into one or more modules / units, one or more modules / units are stored in the memory 120, and are executed by the processor 110 to complete the present application. One or more modules / units may be a series of computer program instruction segments that can complete specific functions, and the instruction segments are used to describe the execution process of the computer program 130 in the computer device 10. For example, the computer program 130 may be divided into the above-mentioned receiving module, storage module, and sending module (modules in the virtual device).

[0203] The computer device 10 may be a desktop computer, a notebook computer, a PDA, a cloud server, or other computer devices. The computer device may include, but is not limited to, a processor 110 and a memory 120. Those skilled in the art will appreciate that Fig.11 It is only an example of the computer device 10 and does not constitute a limitation of the computer device 10. It may include more or fewer components than shown in the figure, or a combination of certain components, or different components. For example, the computer device may also include input and output devices, network access devices, buses, etc.

[0204] The processor 110 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor, etc.

[0205] The memory 120 may be an internal storage unit of the computer device 10, such as a hard disk or memory of the computer device 10. The memory 120 may also be an external storage device of the computer device 10, such as a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. equipped on the computer device 10. Further, the memory 120 may also include both an internal storage unit of the computer device 10 and an external storage device. The memory 120 is used to store computer programs and other programs and data required by the computer device. The memory 120 may also be used to temporarily store data that has been output or is to be output.

[0206] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0207] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0208] Among them, when the embodiment of the present application is implemented by software, it can be implemented in whole or in part in the form of a computer program product. That is, the present application implements all or part of the process in the above-mentioned embodiment method, and can also be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium, and the computer program can implement the steps of the above-mentioned various method embodiments when executed by the processor. Among them, the computer program includes computer program code, and the computer program code can be in source code form, object code form, executable file or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying computer program code, recording medium, U disk, mobile hard disk, disk, optical disk, computer memory, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), electric carrier signal, telecommunication signal and software distribution medium, etc. It should be noted that the content contained in the computer-readable medium can be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, the computer-readable medium does not include electric carrier signals and telecommunication signals.

[0209] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application, and should all be included in the protection scope of the present application.

Claims

1. A battery data management method, characterized in that: The method comprises: Receiving battery characteristic data sent by a first device, wherein the first device stores battery metadata, and the battery characteristic data is generated based on the battery metadata; The battery characteristic data is stored.

2. The method according to claim 1, characterized in that The method further comprises: receiving a feature data request from a second device, the feature data request being used to request target feature data; Based on the battery characteristic data, the target characteristic data is sent to the second device.

3. The method according to claim 2, characterized in that The sending the target characteristic data to the second device based on the battery characteristic data includes: If the target characteristic data is non-sensitive data, acquiring the target characteristic data based on the battery characteristic data; The target characteristic data is sent to the second device.

4. The method according to claim 2, characterized in that: The sending the target characteristic data to the second device based on the battery characteristic data includes: If the target characteristic data is sensitive data, verifying the key information of the second device; If the key information of the second device is verified, acquiring the target characteristic data based on the battery characteristic data; The target characteristic data is sent to the second device.

5. The method according to any one of claims 1 to 4, characterized in that: The method further comprises: receiving a metadata request from the second device; The metadata request is sent to the first device.

6. The method according to claim 5, characterized in that Before sending the metadata request to the first device, the method further includes: verifying the key information of the second device; If the key information of the second device is verified successfully, the step of sending the metadata request to the first device is performed.

7. The method according to any one of claims 2 to 6, characterized in that: The method further comprises: receiving device information of the second device; Based on the device information of the second device, key information of the second device is sent to the second device.

8. The method according to any one of claims 1 to 7, characterized in that: The method further comprises: A normalization operator is sent to the first device, where the normalization operator includes a rule for normalizing a data format of the battery metadata and a corresponding mapping rule.

9. The method according to any one of claims 1 to 8, characterized in that: The battery characteristic data includes at least one of a data characteristic value of the battery metadata and battery status data.

10. A battery data management device, characterized in that: The device comprises: A receiving module, configured to receive battery characteristic data sent by a first device, wherein the first device stores battery metadata, and the battery characteristic data is generated based on the battery metadata; A storage module is used to store the battery characteristic data.

11. A computer device, characterized in that: The computer device comprises a processor, and the processor is used to execute a computer program in a memory to implement the battery data management method according to any one of claims 1 to 9.

12. 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 computer device, the battery data management method according to any one of claims 1 to 9 is implemented.

Images