Data processing method and device, equipment, storage medium and program product

Abstract

The embodiment of the invention provides a data processing method and device, equipment, a storage medium and a program product, and the method comprises the steps: classifying the obtained battery data based on the battery type identification of a battery, and obtaining the battery type data corresponding to each battery type; based on a data mapping rule corresponding to each battery type identifier, performing normalization processing on the battery type data corresponding to each battery type to obtain normalized data corresponding to each battery type data; the data mapping rule comprises a conversion relation between the battery type data and the normalized data. In this way, through classification and normalization of the battery data, the processing efficiency and the use efficiency of the processing flow when the downstream application processes the battery data are improved.

Description

Technical Field

[0001] This application relates to the field of battery technology, and includes, but is not limited to, a data processing method, apparatus, device, storage medium, and program product. Background Technology

[0002] In recent years, the world has faced significant challenges to sustainable development, including energy shortages, climate change, and pollutant emissions. Consequently, countries have begun to focus extensively on the development of new energy vehicles, represented by electric vehicles, which use batteries as their power source. To improve the performance of batteries and electric vehicles, it is necessary to analyze battery usage data to make improvements.

[0003] However, the market offers a variety of new energy vehicles, resulting in a variety of battery data that needs to be processed. Furthermore, battery data from different manufacturers can vary significantly. Therefore, in order to analyze battery data, relevant technologies need to develop an independent data processing workflow for each type of battery data. This not only leads to low data processing efficiency but also results in low efficiency of the battery data processing workflow for a particular vehicle model due to the limited number of models available, leading to high development costs. Summary of the Invention

[0004] To address the problems existing in related technologies, embodiments of this application provide a data processing method, apparatus, device, storage medium, and program product. By classifying and normalizing battery data, data processing of different battery types can be performed through the same data processing flow. This provides battery data with a unified data format for downstream application layer data processing services, improving the processing efficiency and workflow efficiency of downstream applications when processing battery data.

[0005] Firstly, this application provides a data processing method, which includes: classifying acquired battery data based on battery type identifiers to obtain battery type data corresponding to each battery type; and normalizing the battery type data corresponding to each battery type based on data mapping rules corresponding to each battery type identifier to obtain normalized data corresponding to each battery type data; the data mapping rules include the conversion relationship between battery type data and normalized data.

[0006] In the above embodiments, firstly, by classifying the received battery data, all data of a certain battery type can be obtained at once when analyzing data of a particular type, eliminating the need to filter data from the entire database to obtain data of a specific type. Secondly, by using data mapping rules for different types of battery data, the classified battery data is normalized. This not only provides downstream application layer data processing services with battery data in a unified data format, but also allows for the analysis of battery data of different battery types through a single data processing flow, improving both the efficiency of the processing flow and the processing efficiency of downstream applications. Finally, by converting data of different battery types to a unified format and standard through normalization, the consistency and comparability of data fields are ensured, which helps reduce analysis errors and improve the accuracy of model training when performing data analysis and model training based on normalized data.

[0007] In some embodiments, the data processing method further includes: in response to a configuration message corresponding to any battery type identifier, determining whether a data storage structure corresponding to the battery type identifier exists in the storage partition corresponding to the battery type identifier in the battery database; the configuration message includes at least a data field, a normalized field, and a mapping relationship between the data field and the normalized field of the battery corresponding to the battery type identifier; in response to the absence of a data storage structure in the battery database, generating a data storage structure corresponding to the battery type identifier based on the data field, the normalized field, and the mapping relationship, and storing the data storage structure in the storage partition corresponding to the battery type identifier.

[0008] In the above embodiments, a data storage structure corresponding to each battery type identifier is established in advance. After obtaining the battery data, the corresponding data storage structure can be obtained directly based on the type of battery data. The battery data is normalized based on the data mapping rules in the data storage structure, thereby improving data processing efficiency.

[0009] In some embodiments, the data processing method further includes: in response to the existence of a data storage structure in the battery database, comparing the existing data fields and existing normalized fields in the data storage structure with the data fields and normalized fields in the configuration message respectively to obtain a comparison result; in response to the comparison result indicating that at least one of the existing data fields and existing normalized fields is different, determining the new field in the configuration message; and adding the new field to the data storage structure to update the data storage structure corresponding to the battery type identifier.

[0010] In the above embodiments, when a data storage structure corresponding to the battery type identifier exists in the battery database, the existing data storage structure is updated based on the configuration information issued by the user, so that the data storage structure in the battery database can always store the received battery data, and will not fail to store data due to the absence of certain battery data fields in the data storage structure.

[0011] In some embodiments, the acquired battery data is classified based on the battery type identifier to obtain battery type data corresponding to each battery type, including: when the time interval reaches a preset time interval, the battery data acquired in real time during the time interval is integrated to obtain integrated data corresponding to the time interval; based on the battery type identifier, the battery data of different battery types in the integrated data is classified to obtain battery type data corresponding to each battery type; correspondingly, the data processing method further includes: based on the data field of the battery corresponding to each battery type identifier, the data in the battery type data is stored in the corresponding location in the data storage structure corresponding to each battery type identifier.

[0012] In the above embodiments, data integration over a period of time can simplify the process and reduce repetitive work; the integration operation and the reception of battery data are executed asynchronously, which will not block the writing of new battery data and can ensure the real-time performance of battery data processing.

[0013] In some embodiments, the acquired battery data is classified based on the battery type identifier to obtain battery type data corresponding to each battery type, including: performing data format processing on the acquired battery data from the database to be processed to obtain processed data; and classifying the battery data of different battery types in the processed data based on the battery type identifier to obtain battery type data corresponding to each battery type.

[0014] In the above embodiments, the battery data in the known database is converted and processed in a format, so that the data processing method provided by this application can not only normalize the acquired real-time data, but also normalize the data in the existing database, thus broadening the application scenarios of this application and improving the efficiency of the data processing process.

[0015] In some embodiments, the configuration message further includes data format configuration rules and field derivation rules; data format processing is performed on the battery data obtained from the database to be processed to obtain processed data, including: converting the battery data from the database to be processed according to the data format configuration rules to obtain battery data with a preset data format; generating derived fields and derived data corresponding to the derived fields based on the battery data with the preset data format and the field derivation rules; and determining the battery data with the preset data format and the derived data as processed data.

[0016] In some embodiments, the data processing method further includes: cleaning the data stored in the data storage structure of the battery database at preset time intervals to obtain cleaned data; deduplicating the cleaned data to obtain deduplicated data; and converting the units of data with the same numerical type in the deduplicated data to obtain the processed data storage structure.

[0017] In the above embodiments, data cleaning, deduplication, and unit conversion operations are performed to eliminate noise and abnormal data in the data storage structure, ensuring data consistency and providing a reliable foundation for subsequent battery analysis and modeling, thereby improving the accuracy of data analysis and prediction.

[0018] In some embodiments, based on the data mapping rules corresponding to each battery type identifier, the battery type data corresponding to each battery type is normalized to obtain normalized data corresponding to each battery type data. This includes: based on the conversion relationship between battery type data and normalized data, mapping the data corresponding to each data field in the battery type data to the normalized field corresponding to each data field to obtain initial normalized data; and normalizing the non-numerical data in the initial normalized data to obtain normalized data.

[0019] In the above embodiments, by normalizing the fields of battery data, battery data with a unified data format can be provided for downstream application layer data processing services, thereby improving the efficiency of downstream data utilization.

[0020] In some embodiments, the data processing method further includes: responding to a data application request from a data application terminal, determining the required battery type identifier corresponding to the required data in the data application request, and obtaining normalized data corresponding to the required battery type identifier from the battery database; performing data analysis on the normalized data corresponding to the required battery type identifier based on the data analysis logic in the data application request, obtaining data analysis results, and sending the data analysis results to the data application terminal.

[0021] In the above embodiments, through various data processing logics, normalized battery data can be used to achieve accurate evaluation and optimized management of battery performance.

[0022] Secondly, embodiments of this application provide a data processing apparatus, which includes: a classification module for classifying acquired battery data based on battery type identifiers to obtain battery type data corresponding to each battery type; and a normalization module for normalizing the battery type data corresponding to each battery type based on data mapping rules corresponding to each battery type identifier to obtain normalized data corresponding to each battery type data; the data mapping rules include the conversion relationship between battery type data and normalized data.

[0023] In the above embodiments, firstly, by classifying the received battery data, all data of a certain battery type can be obtained at once when analyzing data of a particular type, eliminating the need to filter data from the entire database to obtain data of a specific type. Secondly, by using data mapping rules for different types of battery data, the classified battery data is normalized. This not only provides downstream application layer data processing services with battery data in a unified data format, but also allows for the analysis of battery data of different battery types through a single data processing flow, improving both the efficiency of the processing flow and the processing efficiency of downstream applications. Finally, by converting data of different battery types to a unified format and standard through normalization, the consistency and comparability of data fields are ensured, which helps reduce analysis errors and improve the accuracy of model training when performing data analysis and model training based on normalized data.

[0024] Thirdly, embodiments of this application provide a data processing device, including a memory and a processor. The memory stores a computer program that can run on the processor, and the processor executes the program to implement the steps in the above-described data processing method.

[0025] Fourthly, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps in the above-described data processing method.

[0026] Fifthly, embodiments of this application provide a computer program product, including a computer program or instructions, which, when executed by a processor, implement the steps in the above-described data processing method.

[0027] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0028] Figure 1 This is a schematic diagram of the structure of the data processing device provided in the embodiments of this application;

[0029] Figure 2 This is an optional flowchart illustrating the data processing method provided in the embodiments of this application. Figure 1 ;

[0030] Figure 3 This is an optional flowchart illustrating the data processing method provided in the embodiments of this application. Figure 2 ;

[0031] Figure 4 This is an optional flowchart illustrating the data processing method provided in the embodiments of this application. Figure 3 ;

[0032] Figure 5 This is a schematic diagram of the structure of the data normalization system for the battery device provided in the embodiments of this application;

[0033] Figure 6 This is a schematic diagram of the dynamic table creation process provided in the embodiments of this application;

[0034] Figure 7 This is a schematic diagram of the data access process provided in an embodiment of this application;

[0035] Figure 8 This is a schematic diagram of the data preprocessing process provided in the embodiments of this application. Detailed Implementation

[0036] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0037] In the following description, references to "some embodiments" refer to a subset of all possible embodiments. However, it is understood that "some embodiments" may be the same or different subsets of all possible embodiments and may be combined with each other without conflict. Unless otherwise defined, all technical and scientific terms used in the embodiments of this application have the same meaning as commonly understood by one of ordinary skill in the art to which the embodiments of this application pertain. The terminology used in the embodiments of this application is for the purpose of describing the embodiments of this application only and is not intended to limit the application.

[0038] Currently, new energy batteries are increasingly widely used in daily life and industry. They are not only used in energy storage systems such as hydropower, thermal power, wind power, and solar power plants, but also extensively used in electric vehicles such as electric bicycles, electric motorcycles, and electric cars, as well as in aerospace and other fields. With the continuous expansion of the application areas of power batteries, the market demand is also constantly increasing. In this application embodiment, the battery involved can be a battery cell, also known as a battery unit. A battery cell refers to a basic unit capable of converting chemical energy into electrical energy, which can be used to manufacture battery modules or battery packs to supply power to electrical devices. A battery cell can be a rechargeable battery, which refers to a battery cell that can be recharged after discharge to activate the active materials and continue to be used. Battery cells can be lithium-ion batteries, sodium-ion batteries, sodium-lithium-ion batteries, lithium metal batteries, sodium metal batteries, lithium-sulfur batteries, magnesium-ion batteries, nickel-metal hydride batteries, nickel-cadmium batteries, lead-acid batteries, etc., and this application embodiment is not limited to these.

[0039] In this application embodiment, the term "battery cell" can refer to any shape, such as a square cell or a round cell. Furthermore, "battery cell" typically refers to a battery cell, which is one of the basic units constituting a battery. The battery cell is the core component of a battery, responsible for storing and releasing electrical energy. A battery cell can be a lithium-ion battery cell (Li-ion Cell), a lithium-polymer battery cell (Li-polymer Cell), a nickel-metal hydride battery cell (NiMH Cell), etc. This application embodiment does not limit the type of battery cell; the specific type can be selected according to the actual application scenario.

[0040] In this embodiment, the battery cell is the core component of the battery pack. A battery pack typically includes multiple battery cells, which are combined to provide the required energy capacity and voltage. The components of a battery pack include at least: individual battery cells, a battery management system (BMS), a casing, wiring harnesses, connectors, and interfaces. These components work together to combine the battery cells into a fully functional battery pack for various applications. For example, the battery pack can be used in electric vehicles, energy storage systems, portable electronic devices, solar power systems, wind power systems, emergency backup power supplies, power tools, or electric bicycles, etc. This embodiment does not impose any limitations on this; the specific choice can be made according to the actual application scenario.

[0041] It should be noted that the battery pack can use different types of battery cells, such as lithium-ion batteries, nickel-metal hydride batteries, lithium polymer batteries, etc., depending on the specific application requirements and performance specifications.

[0042] In this embodiment, the battery may also be a single physical module comprising one or more battery cells to provide higher voltage and capacity. When there are multiple battery cells, the multiple battery cells are connected in series, parallel, or mixed via a busbar.

[0043] Currently, there are various types of new energy vehicles on the market, which generates a variety of battery data that needs to be processed. The battery data of different battery models will have significant differences. Therefore, in order to facilitate the analysis of battery data of different models, relevant technologies need to develop an independent data processing flow for each type of battery data. This not only leads to low data processing efficiency, but also, because the number of many models is small, the efficiency of the battery data processing flow corresponding to that model is low, resulting in high development costs and wasted resources.

[0044] To address the significant differences in battery data from different manufacturers and models in related technologies, which leads to inconsistent data processing workflows and necessitates the development of separate processing workflows for each type of battery data, the applicant has discovered that after acquiring battery data, it is possible to categorize the acquired battery data based on the battery type identifier. Then, based on the data mapping rules corresponding to each battery type identifier, the battery type data corresponding to each battery type is normalized, thus completing the normalization of different types of battery data. This provides downstream application-layer data processing services with battery data in a unified data format. Furthermore, the embodiments of this application can analyze different types of battery data through a single data processing workflow, improving data processing efficiency and workflow utilization efficiency.

[0045] Based on the above considerations, the inventors, through in-depth research, have found that the acquired battery data can be classified based on the battery type identifier to obtain battery type data corresponding to each battery type. Based on the conversion relationship between the battery type data corresponding to each battery type identifier and the normalized data, the battery type data corresponding to each battery type can be normalized to obtain normalized data corresponding to each battery type.

[0046] Based on the above solution, this application embodiment classifies the received battery data, enabling the analysis of data for a specific battery type to retrieve all data of that type at once, eliminating the need for data filtering across the entire database. Secondly, by using data mapping rules for different battery types, the classified battery data is normalized. This not only provides downstream application-level data processing services with battery data in a unified format, but also allows for the analysis of battery data from different battery types through a single data processing flow, improving both the efficiency of the processing flow and the processing efficiency of downstream applications. Finally, normalization converts data from different battery types to a unified format and standard, ensuring the consistency and comparability of data fields. This helps reduce analysis errors and improve the accuracy of model training when performing data analysis and model training based on normalized data.

[0047] In this embodiment, after obtaining data with normalized fields, the downstream application layer can call the normalized data with a unified format to manage and analyze the entire lifecycle of the battery from use to retirement, and predict the battery's lifespan based on the battery's usage data. It can also collect key parameters such as battery voltage, temperature, and internal resistance in real time based on a dynamic data table, and achieve real-time monitoring and fault warning of the battery status through cloud computing. Furthermore, it can build battery models based on battery data to simulate battery performance, providing early fault warnings during battery use to improve system safety and reliability. Simultaneously, it can also help companies optimize parameters and improve performance during cell research and development and production based on data collected during battery operation.

[0048] The data processing method disclosed in this application can be used, but is not limited to, in electronic devices such as vehicles, ships, or aircraft.

[0049] Figure 1 This is a schematic diagram of the structure of the data processing device provided in the embodiments of this application. Figure 1 The data processing device shown includes at least one processor 110, a memory 150, at least one network interface 120, and a user interface 130. The various components in the data processing device are coupled together via a bus system 140. It is understood that the bus system 140 is used to implement communication between these components. In addition to a data bus, the bus system 140 also includes a power bus, a control bus, and a status signal bus. However, for clarity, ... Figure 1 The general labeled all buses as Bus System 140.

[0050] The processor 110 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc.

[0051] User interface 130 includes one or more output devices 131 that enable the presentation of media content, and one or more input devices 132.

[0052] Memory 150 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state memory, hard disk drives, optical disk drives, etc. Memory 150 may optionally include one or more storage devices physically located remote from processor 110. Memory 150 may include volatile memory or non-volatile memory, or both. Non-volatile memory may be read-only memory (ROM), and volatile memory may be random access memory (RAM). The memory 150 described in this application embodiment is intended to include any suitable type of memory. In some embodiments, memory 150 is capable of storing data to support various operations, examples of which include programs, modules, and data structures, or subsets or supersets thereof, as exemplified below.

[0053] Operating system 151 includes system programs for handling various basic system services and performing hardware-related tasks, such as the framework layer, core library layer, driver layer, etc., for implementing various basic business functions and handling hardware-based tasks;

[0054] The network communication module 152 is used to reach other computing devices via one or more (wired or wireless) network interfaces 120, such as Bluetooth, WiFi, and Universal Serial Bus.

[0055] The input processing module 153 is used to detect and translate one or more user inputs or interactions from one or more input devices 132.

[0056] In some embodiments, the apparatus provided in this application may be implemented in software. Figure 1A data processing device 154 stored in memory 150 is shown. This data processing device 154 can be a data processing unit within a data processing apparatus, and can be software in the form of programs and plug-ins. It includes the following software modules: a classification module 1541 and a normalization module 1542. These modules are logically related and can therefore be arbitrarily combined or further divided according to their implemented functions. The functions of each module will be described below.

[0057] In other embodiments, the apparatus provided in this application can be implemented in hardware. As an example, the data processing apparatus provided in this application can be a processor in the form of a hardware decoding processor, which is programmed to execute the data processing method provided in this application. For example, the processor in the form of a hardware decoding processor can be one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0058] The data processing methods provided in the embodiments of this application can be executed by a data processing device, which can be any terminal with data processing capabilities, or it can be a server. That is, the data processing methods in the embodiments of this application can be executed by a terminal, by a server, or by interaction between a terminal and a server. The technical solutions of this application will be described in detail below with reference to the accompanying drawings.

[0059] Figure 2 This is an optional flowchart illustrating the data processing method provided in the embodiments of this application. Figure 1 ,like Figure 2 As shown, the data processing method provided in this application embodiment can be implemented through steps S201 to S202:

[0060] Step S201: Based on the battery type identifier, classify the acquired battery data to obtain the battery type data corresponding to each battery type.

[0061] In this embodiment, battery data can be real-time usage data of various electrical devices. This real-time battery data can be obtained through, but is not limited to, Hypertext Transfer Protocol (HTTP), real-time Message Queue (MQ), Message Queuing Telemetry Transport (MQTT), offline Comma Separated Values ​​(CSV) message import, Object Storage Service (OSS) / MinIO / FTP, wireless communication, mobile networks, Bluetooth vehicle-to-cloud connectivity, or other methods (e.g., data extraction). Here, battery data can refer to battery usage data, which can be transmitted in real-time to the data processing device provided in this embodiment via the battery management system or the vehicle's infotainment system using the aforementioned communication methods.

[0062] In some embodiments, battery data can also be data from an existing database, such as the database of a car manufacturer. In this case, the battery data obtained is all the battery data corresponding to different battery models in the car manufacturer's database.

[0063] Here, the battery type identifier can be used to characterize the type of battery, such as a passenger car battery or a commercial vehicle battery from a particular manufacturer. Battery data refers to data corresponding to at least one data field generated during battery use. The data field is used to characterize the type of data; for example, the data field can be fields such as voltage, current, and temperature, and battery data can be voltage values, current values, etc.

[0064] In some embodiments, the data processing device can be deployed in a cluster with multiple servers. Each server receives battery data in real time and stores the received battery data locally. This results in battery data of the same type being stored in different locations, requiring the analysis of usage data for a specific type of battery to be filtered across different servers. Therefore, this embodiment classifies the acquired battery data based on the battery type identifier, categorizing different types of battery data together. This allows battery data of the same type to be stored together, so that when the application needs to analyze data of a specific type of battery, it can directly obtain all battery data for that type without having to search through different storage locations for specific battery data.

[0065] Step S202: Based on the data mapping rules corresponding to each battery type identifier, normalize the battery type data corresponding to each battery type to obtain normalized data corresponding to each battery type data; the data mapping rules include the conversion relationship between battery type data and normalized data.

[0066] In this embodiment, the data mapping rule is the mapping relationship between battery type data corresponding to each battery type identifier and normalized data. Battery data refers to data with different data fields generated during the use of different types of batteries. Normalized data refers to battery data with normalized fields. Normalized fields are unified fields used by downstream applications to process battery data. Normalized fields can be set by technicians according to the analysis needs of downstream applications. The data mapping rule can refer to the mapping relationship between data fields and normalized fields. For example, if the voltage data field is vol and the voltage data field in the normalized field is voltage, then the data mapping rule can include the mapping relationship between vol and voltage. That is, after obtaining the voltage value with field vol in the original data, this voltage value can be mapped to the normalized field voltage.

[0067] In some embodiments, after obtaining the categorized battery type data, the data corresponding to each data field in the battery type data can be mapped to the corresponding normalized field according to the data mapping rules. For example, the original data field vol can be mapped to the normalized field voltage, so that the battery type data is converted into normalized data, thereby achieving data field unification and obtaining normalized data.

[0068] In some embodiments, normalization processing may include, in addition to field normalization, processing logic that converts data fields into normalized fields. For example, it may unify the units of numerical data of the same type in the normalized data, such as converting the current unit to amperes (A). It may also normalize the battery state data in the normalized data, such as standardizing data such as battery charging state, vehicle operating state, and battery operating condition, mapping the state to between 0 and 1 to facilitate use by downstream application layers. It may also normalize the results generated by the algorithm on the original data, such as the state of charge (SOC) calculated by the algorithm using current, voltage, and temperature.

[0069] In this embodiment, after obtaining normalized data, the downstream battery data application layer can directly use the normalized data to manage and analyze the entire lifecycle of the battery from use to retirement, and predict the battery's lifespan based on various types of normalized data. It can also use cloud computing to monitor the battery status and provide early warnings of faults based on real-time collected key parameters such as battery voltage, temperature, and internal resistance. Furthermore, it can build battery models based on battery data to simulate battery performance and provide early warnings of faults during battery use, thereby improving system safety and reliability. Simultaneously, it can also help companies optimize parameters and improve performance during cell research and development and production based on data collected during battery operation.

[0070] In this embodiment, firstly, by classifying the received battery data, all data of a certain battery type can be obtained at once when analyzing data of a particular type, eliminating the need to filter data from the entire database to obtain data of a specific type. Secondly, by using data mapping rules for different types of battery data, the classified battery data is normalized. This not only provides downstream application layer data processing services with battery data in a unified data format, but also allows for the analysis of battery data of different battery types through a single data processing flow, improving both the efficiency of the processing flow and the processing efficiency of downstream applications. Finally, by converting data of different battery types to a unified format and standard through normalization, the consistency and comparability of data fields are ensured, which helps reduce analysis errors and improve the accuracy of model training when performing data analysis and model training based on normalized data.

[0071] In some embodiments, the normalized data is stored in a battery database. The battery database can be an Operational Data Store (ODS), a Time Series Database (TSDB), or a data warehouse. The battery's normalized data is stored through a data storage structure in the ODS. The data storage structure can be a dynamic table in a relational database management system (MySQL) or a time series data table, etc., used to store data.

[0072] In some embodiments, the battery database may contain data storage structures for each battery type. In this case, it is necessary to determine whether there is data in the received battery data that corresponds to a data field that is not in the data storage structure. If so, the data storage structure needs to be updated and the normalized data stored in the data storage structure. If there is data in the received battery data for a battery type that does not have a corresponding data storage structure in the battery database, then a new data storage structure corresponding to that battery type needs to be created.

[0073] Figure 3 This is an optional flowchart illustrating the data processing method provided in the embodiments of this application. Figure 2 ,like Figure 3 As shown, the data processing method provided in this application embodiment can also be implemented through steps S301 to S305:

[0074] Step S301: In response to the configuration message corresponding to any battery type identifier, determine whether there is a data storage structure corresponding to the battery type identifier in the storage partition corresponding to the battery type identifier in the battery database; the configuration message includes at least the data field, normalized field, and mapping relationship between the data field and the normalized field of the battery corresponding to the battery type identifier.

[0075] In some embodiments, the configuration message may be issued by the user through the Human Machine Interface (HMI) of the data processing device, indicating to the user that the battery data format configuration is complete. The user can set data fields for different battery types based on the HMI interface, such as basic fields, field type identifiers (keys), and field types. The basic fields may include basic information, descriptions, tags, and transmission protocols for that battery type; the field type identifier may be a type identifier for the battery data, such as current, voltage, or temperature; the battery data is the data corresponding to each field type identifier, such as the current value; and the field type is the type corresponding to the original data, such as integer, single-precision floating-point, double-precision floating-point, enumeration, boolean, string, time, or structure types.

[0076] In some embodiments, users can also set normalized fields for normalized data based on the HMI interface. The set of normalized fields includes multiple normalized fields, which are unified fields that can be used by the application layer. Normalized fields can be fields for passenger vehicles, commercial vehicles, and other categories. Taking passenger vehicles as an example, normalized fields can include basic fields such as device code, timestamp, total voltage, cell voltage array, highest voltage, lowest voltage, highest voltage cell number, lowest voltage cell number, current, sensor temperature array, highest temperature, lowest temperature, highest temperature sensor number, lowest temperature sensor number, insulation resistance, SOC, cumulative mileage, vehicle status, and charging status. The normalized fields for commercial vehicles mainly include equipment code, timestamp, battery pack number (e.g., pack1, pack2, pack3...packn), measured voltage of the battery compartment, accumulated voltage of the battery compartment, current of the battery compartment, SOC, State of Health (SOH), highest single-cell voltage, lowest single-cell voltage, highest single-cell voltage cell number, lowest single-cell voltage cell number, current, sensor temperature array, highest temperature, lowest temperature, highest temperature sensor number, lowest temperature sensor cell supervision circuit (CSC) number, negative temperature coefficient (NTC) number for the lowest temperature, SOC for display, average single-cell voltage, relay status, allowable charge / discharge current, positive and negative insulation resistance, key-on signal voltage (unit can be volts, V), battery management unit (BMU) supply voltage (V), DC charging supply voltage (V), constant voltage charging (CC)... The basic fields include: Voltage 1 (V), current charging capacity (in milliamperes, Ah), total charge / discharge cycles, maximum single-cell SOC (%), minimum single-cell SOC (%), system weighted SOC (%), grid charging relay, charging demand current (in amperes, A), dual-gun charging relay 2, heating relay 2 status, CC detection voltage 2 (V), wireless charging relay status, AC charging supply voltage (V), CSC power consumption current sampled by BMU (mA), 24V Uout voltage sampling of software battery pack module (BPM, Battery Pack Module) (V), air conditioning relay status, relay internal voltage (V), and Controller Area Network (CAN) bus life signals. User-extended fields can also be included.

[0077] In some embodiments, users can also categorize batteries based on new additions.

[0078] In some embodiments, users can also set the mapping relationship between data fields and normalized fields based on the HMI interface, i.e., data mapping rules. Data mapping rules can be mapping rules between data fields and normalized fields, and the mapping rules can be represented by the following data structure:

[0079] {

[0080] source:target

[0081] source2:target2

[0082] }

[0083] Here, source and source2 can be different data fields, and target and target2 can be different normalization fields. In addition to the data mapping function, the mapping rules can also configure the processing logic from data fields to normalization fields. The processing logic can include unit conversion (such as ampere to milliampere), value normalization (such as charging status, vehicle operating status, and unified operating condition enumeration values), and data normalization of the results generated by the algorithm (i.e., processing the obtained battery data by the algorithm, such as voltage analysis by the cloud platform).

[0084] After constructing the data mapping rules, this application embodiment can issue a configuration completion message based on the HMI to generate a data storage structure corresponding to each battery type identifier based on the configuration message.

[0085] In this embodiment of the application, upon receiving a configuration message corresponding to any battery type identifier, indicating that the configuration of the battery corresponding to the battery type identifier in the normalization process is complete, a data storage structure corresponding to the battery type identifier can be generated based on the configuration content, or the existing data storage structure of the battery type identifier can be updated.

[0086] Here, when a configuration message corresponding to any battery type identifier is received, it can be determined whether a data storage structure corresponding to that battery type identifier exists in the storage partition corresponding to the battery type identifier in the battery database. If it exists, it is determined whether an update is needed; otherwise, a data storage structure corresponding to that battery type identifier is generated.

[0087] Here, the storage partition corresponding to each battery type identifier is used to store the battery data corresponding to that battery type identifier, so that all data corresponding to that battery type can be retrieved at once.

[0088] Step S302: In response to the absence of a data storage structure in the battery database, a data storage structure corresponding to the battery type identifier is generated based on the data fields, normalized fields, and mapping relationships, and the data storage structure is stored in the storage partition corresponding to the battery type identifier.

[0089] Here, in the absence of a data storage structure in the battery database, a data storage structure corresponding to the battery type identifier is generated based on the data fields, normalized fields, and mapping relationships, and the data storage structure is stored in the storage partition corresponding to the battery type identifier.

[0090] In this application embodiment, a data storage structure corresponding to each battery type identifier is established in advance. After obtaining the battery data, the corresponding data storage structure can be obtained directly based on the type of battery data. The battery data is normalized based on the data mapping rules in the data storage structure, thereby improving data processing efficiency.

[0091] Step S303: In response to the existence of a data storage structure in the battery database, the existing data fields and existing normalized fields in the data storage structure are compared with the data fields and normalized fields in the configuration message to obtain the comparison results.

[0092] In some embodiments, the battery database may have previously established a data storage structure for battery data of the current battery type. However, new fields may have been added during the configuration process. This could be due to the addition of new fields to the data field set (i.e., data with new fields generated for this type of battery) or the addition of fields to the normalized field set. In this case, the existing data fields and normalized fields in the data storage structure can be compared with the data fields and normalized fields in the configuration message to obtain the comparison results and determine whether there are incremental fields in the configuration message. Incremental fields are the newly added fields.

[0093] Step S304: In response to the comparison result indicating that at least one of the existing data fields and the existing normalized fields are different, determine the new field in the configuration message.

[0094] Here, if at least one of the existing data fields in the data storage structure representing the structure is different from the data fields in the configuration message, and the existing normalized fields are different from the normalized fields in the configuration message, then the newly added fields in the data fields or normalized fields in the configuration message are determined to be the newly configured fields.

[0095] Step S305: Add the new field to the data storage structure to update the data storage structure corresponding to the battery type identifier.

[0096] Add the new field to the data storage structure to update the data storage structure corresponding to this battery type identifier. After adding the new field to the data storage structure, a mapping relationship can be established between the new field and the normalized field to achieve data normalization.

[0097] In this embodiment of the application, when a data storage structure corresponding to the battery type identifier exists in the battery database, the existing data storage structure is updated based on the configuration information issued by the user, so that the data storage structure in the battery database can always store the received battery data, and will not fail to store data due to the absence of certain battery data fields in the data storage structure.

[0098] In some embodiments, battery data may be received in real time, and the classification of the real-time received data can be achieved through steps S1 to S2:

[0099] Step S1: When the time interval reaches the preset time interval, the battery data acquired in real time during the time interval is integrated to obtain the integrated data corresponding to the time interval.

[0100] In this embodiment of the application, in order to improve classification efficiency, battery data received within a time period can be integrated, and then the integrated data can be classified.

[0101] In this embodiment of the application, the preset time interval can be set by the user according to the frequency of receiving battery data. If the frequency of receiving battery data is low (e.g., receiving one message per minute), the preset interval can be longer (e.g., 15 minutes); if the frequency of receiving battery data is high (e.g., receiving one message every 5 seconds), the preset interval can be shorter (e.g., 5 minutes).

[0102] Here, data integration can be achieved through a timed program. When the time interval reaches the preset time interval, the timed program integrates the battery data corresponding to each battery type identifier received in real time during the time interval. Data integration can be the process of merging multiple battery data received during the time interval into one data based on the receiving time, i.e., integrating data.

[0103] Step S2: Based on the battery type identifier, classify the battery data of different battery types in the integrated data to obtain the battery type data corresponding to each battery type.

[0104] This application embodiment can classify battery data of different battery types in the integrated data based on battery type identifiers to obtain battery type data corresponding to each battery type.

[0105] Correspondingly, the data processing method provided in the embodiments of this application may further include step S3:

[0106] Step S3: Based on the data field of the battery corresponding to each battery type identifier, store the data in the battery type data to the corresponding location in the data storage structure corresponding to each battery type identifier.

[0107] In this embodiment of the application, the classified battery type data can be stored in the data storage structure corresponding to the battery type identifier. Specifically, the data in the data storage structure can be the data of each data field in the battery type data placed in the corresponding data field in the data storage structure. Each data field can include the field value under the same timestamp. These field values ​​can be stored in the actual physical address (such as the sector of the hard disk) of the data storage disk corresponding to the data processing device.

[0108] This application integrates data over a period of time, which simplifies the process and reduces repetitive work. The integration operation and the reception of battery data are executed asynchronously, which will not block the writing of new battery data and can ensure the real-time performance of battery data processing.

[0109] In some embodiments, battery data can also be data from a known database, such as all battery data from a certain automaker. In this case, the battery data from the known database can be converted into a different format and then categorized. Therefore, the data processing method provided in this application embodiment may further include steps S4 and S5:

[0110] Step S4: Perform data format processing on the battery data obtained from the database to be processed to obtain processed data.

[0111] In some embodiments, the database to be processed can be a database of other companies, containing battery usage data of that company. When configuring, the user can configure the data format of the battery data in the database to be processed. After receiving the battery data from the database to be processed, the user can perform format conversion on the battery data in the database to be processed based on the configured data format to obtain processed data with the correct data format.

[0112] Here, users can also pre-configure the storage partition for the battery data in the database to be processed. This refers to configuring the physical storage location of the data corresponding to each field of the battery data in the database to be processed. The battery data obtained from the database to be processed can have multiple fields, and different fields can be stored in different physical addresses.

[0113] In some embodiments, data format processing may also involve mapping battery data with specified fields from the database to be processed to preset fields. For example, the specified fields may be the battery device code field (a code used to identify the battery model) and the timestamp field corresponding to the battery data. The preset fields refer to a subset of normalized fields configured by the user, used to determine battery information based on the data corresponding to the normalized fields. The battery device code can be used to determine the battery type identifier; for example, the battery device code is 01010225, and different digits in the battery code can be used to represent the battery manufacturer and battery type.

[0114] In some embodiments, new fields can be generated based on existing fields in the battery data of the database to be processed. For example, the battery data in the database to be processed may contain fields such as voltage, current and temperature. The remaining battery power can be calculated based on the remaining power algorithm. In this case, the derived field is the remaining power, and the data of the derived field is the calculated remaining power value.

[0115] Step S5: Based on the battery type identifier, classify the battery data of different battery types in the processed data to obtain the battery type data corresponding to each battery type.

[0116] After obtaining the processed data, the battery data of different battery types can be classified based on the battery type identifier to obtain the battery type data corresponding to each battery type.

[0117] Here, after obtaining the battery type data corresponding to each battery type, the battery type data can also be stored in the corresponding storage partition.

[0118] This application embodiment performs format conversion and processing on battery data in a known database, enabling the data processing method provided by this application embodiment to not only normalize the acquired real-time data, but also normalize the data in an existing database, thus broadening the application scenarios of this application and improving the efficiency of the data processing flow.

[0119] In some embodiments, step S4 can be implemented by steps S41 to S43:

[0120] Step S41: Based on the data format configuration rules, convert the battery data from the database to be processed to obtain battery data with a preset data format.

[0121] In some embodiments, the data format configuration rules are configured by the user based on the HMI interface, and are used to convert the data in the database to be processed into a format, for example, converting the data segment of the CAN message into binary characters to obtain battery data with a preset data format.

[0122] Step S42: Based on battery data with a preset data format and field derivation rules, generate derived fields and corresponding derived data.

[0123] In some embodiments, new fields can be generated based on existing fields in the battery data of the database to be processed. For example, the battery data in the database to be processed contains fields such as voltage, current and temperature. The remaining battery power can be calculated based on the remaining power algorithm. In this case, the derived field is the remaining power, and the data of the derived field is the calculated remaining power value.

[0124] Step S43: The battery data and derived data with preset data formats are identified as processing data.

[0125] In some embodiments, the data in the battery database can be cleaned periodically to remove useless data from the battery database. Figure 4 This is an optional flowchart illustrating the data processing method provided in the embodiments of this application. Figure 3 ,like Figure 4 As shown, the data processing method provided in this application embodiment may further include steps S401 to S403:

[0126] Step S401: At preset time intervals, clean the data stored in the data storage structure of the battery database to obtain cleaned data.

[0127] In some embodiments, users can pre-set data cleaning rules based on the HMI. Data cleaning rules may include the value range of different fields, the opening and closing relationship of the value range, a list of legal values, a list of illegal values, and data processing scripts.

[0128] Here, data cleaning can be based on filtering data according to the value range and the opening / closing relationship of the corresponding data fields. For example, the voltage field has a value range of (2.5, 4], with a left-open and right-closed relationship. In this case, data with values ​​greater than 2.5 and less than or equal to 4.5V corresponding to the voltage field in the data storage structure are deleted to remove outliers. Each data field corresponds to a list of valid values ​​and a list of invalid values. Invalid values ​​in each data field are removed to ensure data reliability. Data processing scripts can amplify or reduce the data in each field. For example, all values ​​in a batch of data can be multiplied by 100 or divided by 100, or addition, subtraction, multiplication, and division can be performed to avoid values ​​that are too large or too small. Based on the above data cleaning rules, data can be cleaned in the data storage structure to obtain cleaned data.

[0129] In some embodiments, data cleaning refers to cleaning numerical data.

[0130] Step S402: Perform data deduplication on the cleaned data to obtain the deduplicated data.

[0131] In some embodiments, battery data is data with a timestamp field. For data fields with the same battery type identifier, data with the same timestamp are removed to obtain deduplicated data.

[0132] Step S403: Perform unit conversion on the data with the same numerical type in the deduplicated data to obtain the processed data storage structure.

[0133] In the embodiments of this application, the unit conversion can be vehicle speed conversion, energy conversion, resistance value conversion, voltage unit conversion, temperature unit conversion, current unit conversion, etc. For example, all units related to voltage values ​​(e.g., mV) can be converted to V.

[0134] This application's embodiments eliminate noise and abnormal data in the data storage structure through operations such as data cleaning, deduplication, and unit conversion, ensuring data consistency and thus providing a reliable foundation for subsequent battery analysis and modeling, improving the accuracy of data analysis and prediction.

[0135] In some embodiments, step S202 can be implemented by steps S2021 and S2022:

[0136] Step S2021: Based on the conversion relationship between battery type data and normalized data, map the data corresponding to each data field in the battery type data to the normalized field corresponding to each data field to obtain the initial normalized data.

[0137] In some embodiments, after obtaining the conversion relationship between battery type data and normalized data, the data corresponding to each data field in the battery type data can be mapped to the corresponding normalized field according to the conversion relationship. For example, the original data field vol can be mapped to the normalized field voltage, so that the data fields of the battery type data are converted into normalized fields, thereby achieving data field unification and obtaining normalized data.

[0138] Step S2022: Normalize the non-numerical data in the initial normalized data to obtain normalized data.

[0139] Here, normalizing non-numerical data can be achieved by standardizing non-numerical data such as battery charging status, vehicle operating status, and battery condition, mapping the status information to between 0 and 1 to facilitate use by downstream application layers.

[0140] This application embodiment normalizes battery data fields, providing downstream application layer data processing services with battery data in a unified data format, thereby improving the efficiency of downstream data utilization.

[0141] In some embodiments, after obtaining the normalized data, when the downstream application needs data, the normalized data can be analyzed based on the application's requirements, and the analysis results can be displayed or sent to the application.

[0142] The data processing method provided in this application embodiment may further include steps S10 to S20:

[0143] Step S10: In response to the data application request from the data application terminal, determine the required battery type identifier corresponding to the required data in the data application request, and obtain the normalized data corresponding to the required battery type identifier from the battery database.

[0144] In some embodiments, the data application request is issued by the user based on other terminals or electronic devices. The data application request includes at least the demand data and the corresponding demand battery type identifier. The demand data refers to the data that needs to be analyzed, such as normalized data for a certain battery type. The demand battery type identifier refers to the battery type identifier for that type of battery, used to retrieve the data storage structure corresponding to the battery type identifier from the battery database, in order to obtain the normalized data within the data storage structure.

[0145] Step S20: Based on the data analysis logic in the data application request, perform data analysis on the normalized data corresponding to the required battery type identifier, obtain the data analysis results, and send the data analysis results to the data application terminal.

[0146] In some embodiments, the data analysis logic can be battery state assessment and prediction, which can evaluate and predict the battery's state of health (SOH) and state of charge (SOC) using normalized data corresponding to the required battery type identifier. For example, Long Short-Term Memory (LSTM) neural networks or Convolutional Neural Networks (CNNs) can be used to jointly predict the SOC and SOH of lithium batteries. Alternatively, deep learning methods (such as the Transformer algorithm) can be used to extract data features and predict the remaining useful life (RUL). The data analysis logic can also monitor the battery's performance under different environmental conditions, such as temperature and humidity, to optimize battery efficiency and lifespan through continuous monitoring. Furthermore, it can be used to build a virtual battery model based on data to reflect battery performance.

[0147] This application embodiment utilizes various data processing logics to achieve accurate evaluation and optimized management of battery performance using normalized battery data.

[0148] The above embodiments provide a scheme for classifying and normalizing battery data through a data processing device. The following will describe an exemplary application of the embodiments of this application in a practical application scenario.

[0149] In some application scenarios, data processing devices may include a data normalization system for battery devices. The system includes different data processing layers, and the battery data is normalized based on the interaction of each data processing layer.

[0150] Due to the inconsistent battery data formats, diverse storage formats, and lack of standardized data processing methods among different battery manufacturers, the data processing efficiency is low. In this application embodiment, a data normalization scheme and system for battery devices can also be provided. The system includes a battery data classification and processing configuration module, a battery data preprocessing module, and a battery data normalization module. Based on the modules of the above system, the classification and normalization of battery data are realized.

[0151] In some embodiments, the battery data classification and processing configuration module can define the original data fields of battery data and the data normalization field set mapping rules (i.e., the data mapping rules in the aforementioned embodiments), and also provide functions for data storage format configuration, special data field mapping configuration, and derived field mapping configuration; the battery data preprocessing module can perform data cleaning and deduplication preprocessing of battery data; the battery data normalization module can standardize battery data of different formats (i.e., the normalization processing in the aforementioned embodiments), thereby facilitating better use in subsequent business applications.

[0152] To address the issues of inconsistencies in data formats across different manufacturers, which necessitate independent development of data processing workflows for each manufacturer, resulting in low data processing efficiency and inefficient use of these workflows, this application provides a battery data classification and processing configuration module for the three data content formats (Chinese standard, enterprise standard, and custom) used by different battery manufacturers. This module offers functions for defining raw data fields, defining normalized fields, and mapping between raw data fields and normalized fields. The raw data field definition function allows defining the format of device measurement data (i.e., battery data in the aforementioned embodiments) and the raw data fields included in the device measurement data (i.e., data fields in the aforementioned embodiments), resulting in a set of raw data fields.

[0153] Users can define different field types (e.g., integer, single-precision floating-point, double-precision floating-point, enumeration, boolean, string, time, structure) and corresponding identifiers based on the battery data classification and processing configuration module to add fields to the original data field set. Simultaneously, users can define cleaning rules for numeric fields such as integer, single-precision floating-point, and double-precision floating-point. These rules can include: minimum and maximum value ranges, the opening and closing relationships of min and max values, lists of valid and invalid values, and processing scripts. After completing these steps, users can publish the currently edited model definition online through the system's publishing module. The system converts the user-defined device model fields into the syntax structure of Things Specification Language (TSL) (here, TSL can be defined using JavaScript Object Notation (JSON) format) and sends a configuration message to the data model layer. The data model layer then creates the data tables using dynamic table creation technology.

[0154] The data normalization field set can include the system's built-in normalization field set and the user-defined extended normalization field set. The field classification information in the system's built-in data normalization field set can include categories such as passenger vehicles and commercial vehicles. The passenger vehicle data normalization field set can include normalized fields such as equipment code, total voltage, cell voltage array, maximum voltage, and minimum voltage. The user-defined extended normalization field set consists of new data normalization fields added by the user based on their business scenarios.

[0155] In some embodiments, after the normalized field set is configured, the user maps the data corresponding to the original data field to the normalized field in the data normalized field set, thus completing the mapping from the original field to the data normalization standard field.

[0156] Once the mapping between the original data field set and the data normalization field set is completed, the mapped battery data can undergo a standardized data processing flow through the battery data preprocessing module and the battery data normalization module to complete data normalization and obtain normalized data. This normalized data can provide downstream businesses with battery data of different battery types with a unified data format, improving the efficiency of downstream applications in data processing based on normalized data and the efficiency of the normalization process.

[0157] To address the issues of diverse storage formats for battery data from different manufacturers and varying physical storage methods, which necessitate independent development of data processing workflows for different batteries, resulting in low data processing efficiency and inefficient use of data processing workflows for some batteries, this application provides advanced configuration, data storage format configuration, special data field mapping configuration, and derived field mapping configuration functions in the battery data classification and processing configuration module. This enables adaptation to the diverse storage formats of different batteries, thereby achieving data normalization.

[0158] The data processing method provided in this application embodiment can be implemented through the data normalization system of the battery device in the data processing equipment. Figure 5 This is a schematic diagram of the structure of the data normalization system for the battery device provided in the embodiments of this application, as shown below. Figure 5 As shown, the data normalization system for battery devices may include a configuration layer 501, a data model layer 502, an operation layer 503, and a data application layer 504, and a battery data normalization method is implemented based on this system.

[0159] In some embodiments, the configuration layer 501 may include a battery data classification and processing configuration module, which provides functions such as device model management, device model definition, data normalization field set definition, mapping relationship between raw data fields and normalized fields, and advanced configuration. Battery data is configured once for each battery type; for example, in passenger vehicles, one model of battery corresponds to one battery type.

[0160] The device model management feature allows the creation of basic fields required for a device (e.g., a battery of a specific type). These basic fields include fundamental information such as the battery's basic data, description, tags, and transmission protocol. After a user creates the basic fields for a particular type of battery device, the system can generate a device model for that type of battery based on these fields and assign a device model identifier (i.e., the battery type identifier in the aforementioned embodiment), which is the identification code corresponding to the device model, used to determine which type of battery the device model belongs to.

[0161] The definition of raw data fields in the device model definition can include the definition of field identifiers (keys), field types, and cleaning rules. Field identifiers can be identifiers of raw data (e.g., identifiers representing raw data types such as voltage and current), and field types are the types corresponding to raw data (e.g., integer, single-precision floating-point, double-precision floating-point, enumeration, boolean, string, time, structure, etc.). Cleaning rules can include the range of minimum and maximum values ​​of battery data, the opening and closing relationship of minimum and maximum values, a list of legal or illegal battery data values, and processing scripts, etc.

[0162] After users define the raw data fields based on the system, they can publish the device model. The system publishes the user-defined raw data fields as a Device Model (TSL). Each configuration and publication generates a new version of the Device Model, and simultaneously establishes an association between the Device Model TSL and the Device Model Identifier generated by the Device Model Management system. That is, a Device Model Identifier can have one or more versions of the Device Model, of which the valid version is the latest published version, and the rest are historical versions. Users can choose to roll back to a historical version.

[0163] In some embodiments, the data normalization field set may include a classification of battery data (e.g., passenger vehicles, commercial vehicles, and other classifications) and a set of fields under each classification. Specifically, the normalized field set for passenger vehicles may include basic fields such as device code, timestamp, total voltage, cell voltage array, maximum voltage, minimum voltage, maximum voltage cell number, minimum voltage cell number, current, sensor temperature array, maximum temperature, minimum temperature, maximum temperature sensor number, minimum temperature sensor number, insulation resistance, SOC, cumulative mileage, vehicle status, and charging status. The normalized field set for commercial vehicles may include device code, timestamp, pack1 number, pack2 number, pack3 number…packn number, battery pack measured voltage, battery pack accumulated voltage, battery pack current, SOC, SOH, maximum single cell voltage, minimum single cell voltage, maximum single cell voltage cell number, minimum single cell voltage cell number, current, sensor temperature array, and maximum temperature. The system includes basic fields such as minimum temperature, maximum temperature sensor number, minimum temperature sensor CSC number, minimum temperature NTC number, display SOC, average cell voltage, relay status, allowable charge / discharge current, positive and negative insulation resistance, KeyOn signal voltage (V), BMU power supply voltage (V), DC charging power supply voltage (V), CC2 detection voltage (V), current charging capacity (Ah), total charge / discharge cycles, maximum cell SOC (%), minimum cell SOC (%), system weight SOC (%), grid charging relay, charging demand current (A), dual-gun charging relay 2, heating relay 2 status, CC2 detection voltage 2 (V), wireless charging relay status, AC charging power supply voltage (V), BMU CSC power consumption current (mA), BPM24V Uout voltage sampling (V), air conditioning relay status, relay internal voltage (V), CAN bus life signal, etc. Regardless of passenger car, commercial vehicle, or other categories, users can expand their normalized fields based on the existing categories. Users can also add new categories and add normalized field sets to new categories.

[0164] In some embodiments, the mapping between raw data fields and normalized fields may include functionality for establishing a mapping between raw data fields and fields in a set of normalized fields. The fields after the mapping is established are represented by the following data structure:

[0165] {

[0166] source:target

[0167] source2:target2

[0168] }

[0169] Here, source and source2 are the original data fields, and target and target2 are the normalized fields in the set of normalized fields. In addition to the mapping between the original data fields and the normalized fields, the normalized field mapping can also configure the processing logic from the original data fields to the normalized fields. Common processing logics include unit conversion (such as ampere to milliampere), value normalization (such as unifying the enumerated values ​​of charging status, vehicle operating status, and operating conditions), and data normalization of the results generated by the algorithm (i.e., processing the obtained battery data by the algorithm, such as voltage analysis by the cloud platform).

[0170] In some embodiments, advanced configuration is used to unify the diversity of storage formats from different manufacturers. This is achieved through the configuration functions provided by the battery data classification and processing configuration module, such as advanced functions like data storage format configuration, special data field mapping configuration, and derived field mapping configuration. Specifically, data storage format configuration supports user-defined data partitions and storage formats (used to define different data partitions, where a partition stores data for certain fields, and specifying the compression format used for that partition); special data field mapping configuration supports user-defined device codes and mapping timestamp fields to system-built-in fields (system-built-in fields may include device codes, timestamps, and device model identifiers); and derived field mapping configuration allows users to generate new fields based on existing fields using scripts.

[0171] Based on the above configuration functions, the system adapts to the diverse storage formats of different manufacturers. This solves the problem that the different storage formats of different manufacturers lead to different physical storage methods for different data volumes, resulting in the need for independent development of battery data processing workflows for different manufacturers, low data processing efficiency, and low efficiency of some battery data processing workflows.

[0172] Here, the advanced configuration can be used for scenarios corresponding to user private data (i.e., battery data in the database to be processed in the aforementioned embodiment). If a manufacturer's battery data is stored in a private cloud environment, the private data cannot leave the domain. However, if the manufacturer needs to use the normalization algorithm of this application, it can access the data in the private cloud environment into the system through the advanced configuration and perform normalization processing on the data.

[0173] In some embodiments, the data model layer 502 is used to dynamically create tables based on the data configured by the configuration layer 501. Figure 6 This is a schematic diagram of the dynamic table creation process provided in the embodiments of this application, such as... Figure 6 As shown, dynamic table creation can be achieved through steps S601 to S614:

[0174] S601, Received configuration layer message.

[0175] In some embodiments, after the configuration layer is configured, it sends a configuration layer message (i.e., the configuration message in the aforementioned embodiments) to the data model layer. After receiving the configuration layer message, the data model layer parses the configuration layer message sent by the configuration layer to create tables. Here, the message content of the configuration layer may include device model identifier, original data field set, normalized field set, mapping relationship between original data fields and normalized fields, and advanced configuration (which may be empty, i.e., not configured), etc.

[0176] S602, Parse the set of raw data fields in the message.

[0177] Parsing the set of raw data fields in the message refers to parsing the set of raw data fields carried in the configuration layer message to obtain the set of raw data fields for various types of batteries.

[0178] S603, Add a collection of built-in system fields.

[0179] The system's built-in field set can be device code, timestamp, and device model identifier. In this embodiment, the system's built-in fields can be added to the original data field set to form a new original data field set.

[0180] S604. Determine if an advanced configuration exists.

[0181] Here, if there is no advanced configuration in the configuration layer message, that is, the user has not configured the advanced configuration, proceed to step S607; if there is advanced configuration in the configuration layer message, proceed to step S605.

[0182] S605, Advanced Configuration Analysis.

[0183] In some embodiments, advanced configuration is used for users to customize the data storage partitions and storage formats of battery data in different vendors' private clouds. In this case, the advanced configuration is parsed and used for subsequent data storage of battery data in the private cloud.

[0184] S606, Add user-defined partition fields and storage format parsing.

[0185] Here, adding user-defined partition fields and storage format parsing refers to adding the user-configured custom partition fields and storage format fields to memory so that battery data can be stored based on the custom partition fields and storage format fields.

[0186] S607. Determine if a dynamic table corresponding to a device model identifier exists in the data warehouse.

[0187] In some embodiments, the ODS database corresponding to the data model layer 502 may contain a dynamic table for the device model identifier (i.e., the data storage structure in the aforementioned embodiments), in which case step S609 is executed; if the data model layer 502 does not contain a dynamic table for the device model identifier, step S608 is executed.

[0188] S608, Create a new dynamic table.

[0189] Here, if there is no dynamic table for the device model identifier in the data model layer 502, a new dynamic table is created.

[0190] S609, Calculate the incremental field.

[0191] Here, an incremental field refers to a field that exists in the user-configured set of original data fields but not in the existing dynamic table. In other words, it is a field added to the set of original data fields configured this time compared to the fields in the existing dynamic table.

[0192] S610, Add a new field.

[0193] The new field is added to the existing dynamic table to obtain a new dynamic table for the device model identifier, which updates the dynamic table in the data model layer 502 (i.e., updates the data storage structure corresponding to the battery type identifier in the aforementioned embodiment).

[0194] S611, Parse the normalized field set.

[0195] S612. Parse the mapping relationship between the original data fields and the normalized fields.

[0196] S613. Generate a normalized view table creation statement based on the normalized field set and mapping relationship.

[0197] Here, a normalized logical view of different types of battery data is generated based on the original data field set, the normalized field set, and the mapping relationship between the original data fields and the normalized fields. This view can clearly display the mapping relationship between the original data field set and the normalized field set of the battery.

[0198] S614. Create or replace a normalized view.

[0199] Here, if the data model layer contains a previous normalized logical view of the device model identifier, the new normalized logical view is used to replace the existing normalized logical view; if the data model layer does not contain a previous normalized logical view of the device model identifier, the newly generated normalized logical view is used as the view of the device model identifier.

[0200] In this embodiment, the runtime layer 503 provides a data access module, a data warehouse adaptation module for different manufacturers, a battery data preprocessing module, and a battery data normalization module to complete the access of battery data and data warehouse adaptation, battery data preprocessing, and the establishment of a logically normalized view based on battery data, thereby providing it to the data application layer 604 for use.

[0201] Here, the battery data generated in real time by various types of batteries is accessed in real time by the data access module 5031. The connection of battery data input is completed through adaptation (including but not limited to HTTP protocol, MQ real-time message, MQTT message, offline CSV import, OSS / MinIO / FTP) and other methods (such as data extraction).

[0202] Among them, the HTTP protocol adaptation module, MQ real-time message receiving module, MQTT message access module, CSV import module, and OSS / MinIO / FTP docking module can first convert the battery data into a standardized format of message header + message body after receiving the battery data. The message header includes fields such as device model identifier, and the message body includes the accessed battery data (i.e., the battery data obtained in the aforementioned embodiment). This battery data can be stored in the dynamic table of the ODS database first, and then processed by the battery data preprocessing module 5033 after storage.

[0203] Figure 7 This is a schematic diagram of the data access process provided in the embodiments of this application, such as... Figure 7 As shown, dynamic table creation can be achieved through steps S701 to S705:

[0204] S701, convert the incoming data into a standardized message format.

[0205] In this embodiment of the application, after the battery data is obtained based on the data access module 5031, the battery data is converted into a standardized format of message header + message body, wherein the message header includes fields such as device model identifier, and the message body includes the accessed battery data.

[0206] S702. Obtain the corresponding dynamic table in the data model layer based on the device model identifier in the message header.

[0207] In some embodiments, the dynamic table (i.e., the data storage structure in the foregoing embodiments) corresponding to the device model identifier in the data model layer 502 can be obtained based on the device model identifier in the message header.

[0208] S703: Merge messages for the data received in real time.

[0209] In some embodiments, the ODS database stores data in batches rather than in real time. However, battery data is received in real time; therefore, a timed program can be used to merge the battery data received within those ten minutes every ten minutes and store the merged data into the ODS database at once.

[0210] S704. Store the data in the database.

[0211] S705, preprocesses battery data.

[0212] In this embodiment, preprocessing involves reading the device model definition in configuration layer 501 using the device model identifier to determine the data cleaning rules corresponding to the device model identifier. Based on these rules, the battery data is cleaned. Simultaneously, data deduplication can be performed based on device code and timestamp. Finally, unit conversion is performed (which may include vehicle speed conversion, energy conversion, resistance value conversion, voltage unit conversion, temperature unit conversion, current unit conversion, etc.). Furthermore, if manufacturer data is already available, the preprocessing module loads different manufacturer data warehouse adaptation modules for data warehouse adaptation, i.e., acquiring battery data from other manufacturers and then performing data cleaning and other operations on that data to complete the battery data preprocessing.

[0213] Here, the different vendor data warehouse adaptation module 5032 can adapt to different vendor data when vendor data already exists (i.e., battery data in the database to be processed in the aforementioned embodiment). It does not need to access the data through the data access module, but instead obtains advanced configuration from the configuration layer 501 to complete advanced functions such as storage format configuration, special data field mapping configuration, and derived field mapping configuration for different vendor data, thereby achieving vendor data adaptation. For different vendor data warehouses, the data storage format configuration can support user-defined data partitions and storage formats; the special data field mapping configuration supports user-defined mapping of device codes and timestamp fields to system-built-in fields (system-built-in fields include device codes, timestamps, and device model identifiers); the derived field mapping configuration supports users generating new fields based on existing fields using scripts, i.e., derived fields. Finally, the data is processed by the battery data preprocessing module.

[0214] Figure 8 This is a schematic diagram of the data preprocessing process provided in the embodiments of this application, such as... Figure 8 As shown, data preprocessing can be achieved through steps S801 to S810:

[0215] S801. Load the advanced configuration in the configuration layer according to the device model identifier.

[0216] S802, Determine if advanced configuration exists.

[0217] Here, whether the advanced configuration exists refers to whether the user has configured different vendor data storage format configurations, special data field mapping configurations, and derived field mapping configurations when configuring the configuration layer. If they are configured, it means that the advanced configuration exists in the configuration layer, and step S803 is executed. If not, it means that the advanced configuration does not exist in the configuration layer, and step S806 is executed.

[0218] S803 performs format processing on data from different manufacturers.

[0219] In some embodiments, for data warehouses of different manufacturers, the data storage format configuration supports user-defined data partitions and storage formats. That is, the data storage format configuration in the advanced configuration can be loaded to determine the storage area and storage format of battery data of different manufacturers.

[0220] S804. Map fields to data from different manufacturers.

[0221] In this embodiment of the application, the device code and timestamp fields in the data of different manufacturers can be mapped to the built-in fields of the system. The built-in fields of the system include device code, timestamp, and device model identifier.

[0222] S805 generates derived fields for data from different manufacturers.

[0223] In some embodiments, new fields, i.e. derived fields, can be generated based on existing fields using scripts, according to data from different manufacturers.

[0224] S806. Load cleaning rules in the configuration layer based on the device model identifier.

[0225] S807. Perform data cleaning on data from different manufacturers according to the cleaning rules.

[0226] In some embodiments, data cleaning can be based on the minimum and maximum value ranges of battery data, cleaning data outside these ranges. For example, if a manufacturer's data cleaning rules specify that the voltage value range in the battery data is between 2.5 and 4.5V, then voltage data outside this range can be deleted. Cleaning rules may also include open / closed relationships between minimum and maximum values, lists of valid values, and lists of invalid values.

[0227] S808: Remove duplicates from the cleaned data.

[0228] In some embodiments, deduplication refers to deduplicating identical data encoded by the same device based on timestamps.

[0229] S809. Convert the units of the deduplicated data.

[0230] In some embodiments, unit conversion refers to conversion of vehicle speed, energy, resistance value, voltage unit, temperature unit, current unit, etc., in order to achieve unit unification for the same type of data.

[0231] S810, Store the converted data.

[0232] Here, the converted data can be stored in a dynamic table corresponding to the device model identifier or stored in the system's memory for use by the data application layer 504.

[0233] Here, the battery data normalization module 5034 can provide the data generated by the battery data preprocessing module to the data application layer 504 in the form of a normalized data view. With the normalized data view, the data application layer 504 can perform battery business logic development and data processing based on different types of battery data with unified fields after normalization, which greatly improves efficiency.

[0234] The data application layer 504 can be a user of battery data. This layer includes, but is not limited to, data analysis products such as Business Intelligence (BI) reports, indicator systems, and user profiles, as well as other data analysis products. The data application layer 504 can use the normalized data view generated by the battery data normalization module 5034 for subsequent logic development and data processing.

[0235] First, this embodiment uses a battery data classification and processing configuration module to configure data fields for different batteries to adapt to the three major data content formats in the battery data field: national standards, enterprise standards, and custom formats. Simultaneously, it configures data cleaning rules for different data fields. Finally, the data model layer uses dynamic table creation technology to define different data types and create dynamic data tables. Second, this embodiment can configure a normalized field set and a user-defined extended normalized field set through the battery data classification and processing configuration module. Finally, in this embodiment, the acquired battery data undergoes a standardized data processing flow through a battery data preprocessing module and a battery data normalization module to complete data normalization.

[0236] This application embodiment completes data normalization through the above three steps. When the downstream data application layer uses the data, it obtains normalized data with unified fields and format standards. There is no need to develop corresponding processes for data of different types of batteries, which improves the efficiency of data processing and the efficiency of data processing process usage.

[0237] The following continues to describe the exemplary structure of the data processing device 154 provided in the embodiments of this application as a software module. In some embodiments, such as Figure 1 As shown, the data processing device 154 includes a classification module 1541 and a normalization module 1542. The classification module 1541 classifies the acquired battery data based on the battery type identifier to obtain battery type data corresponding to each battery type. The normalization module 1542 normalizes the battery type data corresponding to each battery type based on the data mapping rules corresponding to each battery type identifier to obtain normalized data corresponding to each battery type. The data mapping rules include the conversion relationship between battery type data and normalized data.

[0238] In some embodiments, the data processing apparatus further includes: a first determining module, configured to, in response to a configuration message corresponding to any battery type identifier, determine whether a data storage structure corresponding to the battery type identifier exists in the storage partition corresponding to the battery type identifier in the battery database; the configuration message includes at least a data field, a normalized field, and a mapping relationship between the data field and the normalized field of the battery corresponding to the battery type identifier; and a generating module, configured to, in response to the absence of a data storage structure in the battery database, generate a data storage structure corresponding to the battery type identifier based on the data field, the normalized field, and the mapping relationship, and store the data storage structure in the storage partition corresponding to the battery type identifier.

[0239] In some embodiments, the data processing apparatus further includes: a comparison module, configured to, in response to the existence of a data storage structure in the battery database, compare the existing data fields and existing normalized fields in the data storage structure with the data fields and normalized fields in the configuration message, respectively, to obtain a comparison result; a second determination module, configured to, in response to the comparison result indicating that at least one of the existing data fields and existing normalized fields differs from each other, to determine the new field in the configuration message; and an adding module, configured to add the new field to the data storage structure to update the data storage structure corresponding to the battery type identifier.

[0240] In some embodiments, the classification module 1541 is further configured to integrate the battery data acquired in real time during the time interval when the time interval reaches a preset time interval, to obtain integrated data corresponding to the time interval; and to classify the battery data of different battery types in the integrated data based on the battery type identifier, to obtain battery type data corresponding to each battery type; correspondingly, the data processing device further includes a storage module, wherein the user stores the data in the battery type data to the corresponding location in the data storage structure corresponding to each battery type identifier based on the data field of the battery corresponding to each battery type identifier.

[0241] In some embodiments, the classification module 1541 is further configured to perform data format processing on the battery data obtained from the database to be processed to obtain processed data; and classify the battery data of different battery types in the processed data based on the battery type identifier to obtain battery type data corresponding to each battery type.

[0242] In some embodiments, the configuration message further includes data format configuration rules and field derivation rules; the classification module 1541 is also used to perform format conversion on the battery data from the database to be processed based on the data format configuration rules to obtain battery data with a preset data format; generate derived fields and derived data corresponding to the derived fields based on the battery data with the preset data format and the field derivation rules; and determine the battery data with the preset data format and the derived data as the processing data.

[0243] In some embodiments, the data processing device further includes: a data cleaning module, used to clean the data stored in the data storage structure of the battery database at preset time intervals to obtain cleaned data; a data deduplication module, used to deduplicate the cleaned data to obtain deduplicated data; and a unit conversion module, used to convert the units of data with the same numerical type in the deduplicated data to obtain the processed data storage structure.

[0244] In some embodiments, the normalization module 1542 is further configured to map the data corresponding to each data field in the battery type data to the normalized field corresponding to each data field based on the conversion relationship between the battery type data and the normalized data, to obtain initial normalized data; and to perform normalization processing on the non-numerical data in the initial normalized data to obtain normalized data.

[0245] In some embodiments, the data processing apparatus further includes: a third determining module, configured to, in response to a data application request from a data application terminal, determine the required battery type identifier corresponding to the required data in the data application request, and obtain normalized data corresponding to the required battery type identifier from the battery database; and a data analysis module, configured to, based on the data analysis logic in the data application request, perform data analysis on the normalized data corresponding to the required battery type identifier, obtain data analysis results, and send the data analysis results to the data application terminal.

[0246] It should be noted that the description of the apparatus in this application embodiment is similar to the description of the method embodiment described above, and has similar beneficial effects as the method embodiment; therefore, it will not be repeated. For technical details not disclosed in this apparatus embodiment, please refer to the description of the method embodiment of this application for understanding.

[0247] This application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements some or all of the steps in the above-described method. The computer-readable storage medium can be transient or non-transient.

[0248] This application provides a computer program including computer-readable code. When the computer-readable code is run in a computer device, the processor in the computer device performs some or all of the steps in the above-described method.

[0249] This application provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program. When the computer program is read and executed by a computer, it implements some or all of the steps in the above-described method. This computer program product can be implemented specifically through hardware, software, or a combination thereof. In some embodiments, the computer program product is specifically embodied as a computer storage medium; in other embodiments, the computer program product is specifically embodied as a software product, such as a software development kit (SDK), etc.

[0250] It should be understood that the phrase "one embodiment" or "an embodiment" throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of this application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It should be understood that in the various embodiments of this application, the sequence numbers of the above steps / processes do not imply a sequential order of execution; the execution order of each step / process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. The sequence numbers of the above embodiments of this application are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0251] This application uses terms such as "upper," "lower," "top," "bottom," "front," "back," "inner," and "outer" to indicate orientation or positional relationships. This is only for the convenience of describing this application and is not intended to indicate or imply that the device referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, it should not be construed as a limitation on the scope of protection of this application.

[0252] In the description of this application, it should also be noted that, unless otherwise expressly specified and limited, the terms "installation," "connection," and "joining" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a direct connection or an indirect connection through an intermediate medium. Those skilled in the art can understand the specific meaning of the above terms in this application depending on the specific circumstances.

[0253] It should be noted that, in this application, the terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus 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 apparatus. 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 apparatus that includes that element.

[0254] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components may be combined, or integrated into another system, or some features may be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed may be through some interfaces, and the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0255] The units described above as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; they may be located in one place or distributed across multiple network units; some or all of the units may be selected to achieve the purpose of this embodiment according to actual needs. Furthermore, the functional units in the embodiments of this application may all be integrated into one processing unit, or each unit may be a separate unit, or two or more units may be integrated into one unit; the integrated unit may be implemented in hardware or in a combination of hardware and software functional units.

[0256] The above are merely embodiments of this application and are not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. A data processing method, characterized in that, include: Based on the battery type identifier, the acquired battery data is classified to obtain the battery type data corresponding to each battery type. Based on the data mapping rules corresponding to each battery type identifier, the battery type data corresponding to each battery type is normalized to obtain normalized data corresponding to each battery type data; the data mapping rules include the conversion relationship between battery type data and normalized data.

2. The data processing method according to claim 1, characterized in that, The data processing method further includes: In response to a configuration message corresponding to any battery type identifier, it is determined whether a data storage structure corresponding to the battery type identifier exists in the storage partition corresponding to the battery type identifier in the battery database; the configuration message includes at least the data field, the normalized field, and the mapping relationship between the data field and the normalized field of the battery corresponding to the battery type identifier. In response to the absence of the data storage structure in the battery database, a data storage structure corresponding to the battery type identifier is generated based on the data field, the normalization field, and the mapping relationship, and the data storage structure is stored in the storage partition corresponding to the battery type identifier.

3. The data processing method according to claim 2, characterized in that, The data processing method further includes: In response to the existence of the data storage structure in the battery database, the existing data fields and existing normalized fields in the data storage structure are compared with the data fields and normalized fields in the configuration message to obtain the comparison results; In response to the comparison result indicating that at least one of the existing data fields and the data field, and the existing normalized field and the normalized field are different, the newly added field in the configuration message is determined; The newly added field is added to the data storage structure to update the data storage structure corresponding to the battery type identifier.

4. The data processing method according to claim 2 or 3, characterized in that, The battery type identifier based on the battery classifies the acquired battery data to obtain battery type data corresponding to each battery type, including: When the time interval reaches a preset time interval, the battery data acquired in real time during the time interval is integrated to obtain the integrated data corresponding to the time interval; Based on the battery type identifier, the battery data of different battery types in the integrated data are classified to obtain the battery type data corresponding to each battery type. Correspondingly, the data processing method further includes: Based on the data fields of the battery corresponding to each battery type identifier, the data in the battery type data is stored in the corresponding location in the data storage structure corresponding to each battery type identifier.

5. The data processing method according to claim 4, characterized in that, The battery type identifier based on the battery classifies the acquired battery data to obtain battery type data corresponding to each battery type, including: The battery data acquired from the database to be processed is processed to obtain the processed data. Based on the battery type identifier, the battery data of different battery types in the processed data are classified to obtain the battery type data corresponding to each battery type.

6. The data processing method according to claim 5, characterized in that, The configuration message also includes data format configuration rules and field derivation rules; the data format processing of the battery data obtained from the database to be processed to obtain processed data includes: Based on the data format configuration rules, the battery data from the database to be processed is converted to obtain battery data with a preset data format. Based on the battery data with the preset data format and the field derivation rules, a derived field and the derived data corresponding to the derived field are generated; The battery data with the preset data format and the derived data are identified as the processed data.

7. The data processing method according to any one of claims 4 to 6, characterized in that, The data processing method further includes: At preset time intervals, the data stored in the data storage structure of the battery database is cleaned to obtain cleaned data; The cleaned data is then deduplicated to obtain the deduplicated data. The units of data with the same numerical type in the deduplicated data are converted to obtain the processed data storage structure.

8. The data processing method according to any one of claims 1 to 7, characterized in that, The data mapping rules corresponding to each battery type identifier are used to normalize the battery type data corresponding to each battery type, resulting in normalized data for each battery type, including: Based on the conversion relationship between the battery type data and the normalized data, the data corresponding to each data field in the battery type data is mapped to the normalized field corresponding to each data field to obtain the initial normalized data. The non-numerical data in the initial normalized data are normalized to obtain the normalized data.

9. The data processing method according to any one of claims 1 to 8, characterized in that, The data processing method further includes: In response to a data application request from a data application terminal, the required battery type identifier corresponding to the required data in the data application request is determined, and the normalized data corresponding to the required battery type identifier is obtained from the battery database. Based on the data analysis logic in the data application request, the normalized data corresponding to the required battery type identifier is analyzed to obtain the data analysis results, and the data analysis results are sent to the data application terminal.

10. A data processing apparatus, characterized in that, The data processing device includes: The classification module is used to classify the acquired battery data based on the battery type identifier, and obtain the battery type data corresponding to each battery type. The normalization module is used to normalize the battery type data corresponding to each battery type based on the data mapping rules corresponding to each battery type identifier, so as to obtain the normalized data corresponding to each battery type data; the data mapping rules include the conversion relationship between battery type data and normalized data.

11. A data processing device, comprising a memory and a processor, wherein the memory stores a computer program executable on the processor, characterized in that, When the processor executes the program, it implements the steps in the data processing method according to claims 1 to 9.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the data processing method according to claims 1 to 9.

13. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by the processor, they implement the steps of the data processing method according to any one of claims 1 to 9.

Images