Multi-protocol adaptation method and device of energy storage system, computer equipment and storage medium

Abstract

The invention relates to the technical field of energy management, and discloses an energy storage system multi-protocol adaptation method and device, computer equipment and a storage medium, the separation of equipment communication generality and personality is realized by abstractly constructing a unified model and creating a general protocol driver library and an exclusive protocol description file, the exclusive driver does not need to be manually developed and a core code does not need to be manually modified, and the implementation is convenient. A protocol integration process is greatly simplified, a development threshold is reduced, heterogeneous equipment access and data normalization processing can be rapidly realized, a standard data object is output, an integration period is effectively shortened, time and labor costs are reduced, equipment diversification and rapid iteration requirements are adapted, and energy storage system deployment efficiency and data application convenience are remarkably improved.

Description

Technical Field

[0001] This invention relates to the field of energy management technology, and in particular to a method, apparatus, computer equipment, and storage medium for multi-protocol adaptation of energy storage systems. Background Technology

[0002] With the rapid development of the electrochemical energy storage industry, the scale of energy storage power stations continues to expand, and the integration of energy storage systems is constantly improving. A typical energy storage power station usually integrates a variety of heterogeneous devices from different manufacturers, such as battery management systems (BMS), energy storage converters (PCS), and temperature control equipment (air conditioning, liquid cooling units). These devices use different communication protocols, including Modbus RTU / TCP, CAN, IEC 104, and proprietary protocols defined by each manufacturer.

[0003] When a new brand or model of device is connected to the system, the development team needs to manually parse its specific protocol, develop dedicated drivers, and modify the core code, making the integration work repetitive and tedious. This model, which relies on customized development, not only leads to a lengthy equipment integration development cycle but also significantly increases the project's time and manpower costs. It is difficult to adapt to the actual needs of diversified and rapidly evolving energy storage power station equipment, severely restricting the deployment efficiency of energy storage systems.

[0004] Therefore, there is an urgent need for a multi-protocol adaptation solution for energy storage systems that can simplify the protocol integration process, lower the development threshold, and shorten the access cycle, in order to address the shortcomings of existing technologies. Summary of the Invention

[0005] This invention provides a method, apparatus, computer equipment, and storage medium for multi-protocol adaptation of energy storage systems, in order to solve the technical problems of existing multi-protocol access solutions being cumbersome, having high development thresholds, and being time-consuming.

[0006] Firstly, it provides a multi-protocol adaptation method for energy storage systems, including: The communication protocols and data points of various devices in the energy storage system are abstracted and constructed into a unified communication channel model and data point model; Based on the communication channel model and data point model, a protocol driver library and a protocol description file are created; wherein, the protocol driver library includes a general protocol driver for the communication protocol, and the protocol description file is used to describe the communication parameters and data point information of a specific device; Using the protocol description file, the corresponding general protocol driver is loaded from the protocol driver library and a communication connection is established; Data acquisition and normalization are performed using the loaded general protocol driver and protocol description file; The normalized data is output and encapsulated into a standard data object for use by upper-layer applications.

[0007] Secondly, it provides a multi-protocol adaptation device for energy storage systems, including: The abstract module is used to abstract the communication protocols and data points of various devices in the energy storage system and build them into a unified communication channel model and data point model. The configuration module is used to create a protocol driver library and a protocol description file based on the communication channel model and data point model; wherein, the protocol driver library includes a general protocol driver for the communication protocol, and the protocol description file is used to describe the communication parameters and data point information of a specific device; The connection module is used to load the corresponding general protocol driver from the protocol driver library and establish a communication connection using the protocol description file; The processing module is used to perform data acquisition and normalization processing through the loaded general protocol driver and protocol description file; The encapsulation module is used to output normalized data and encapsulate it into a standard data object for use by upper-layer applications.

[0008] Thirdly, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described multi-protocol adaptation method for energy storage systems.

[0009] Fourthly, a computer-readable storage medium is provided, which stores a computer program that, when executed by a processor, implements the steps of the above-described multi-protocol adaptation method for energy storage systems.

[0010] The beneficial effects of this invention compared with the prior art are as follows: This invention achieves the separation of common and individual communication characteristics of devices by abstractly constructing a unified model, creating a general protocol driver library and a dedicated protocol description file. It eliminates the need to manually develop dedicated drivers and modify core code, greatly simplifies the protocol integration process, lowers the development threshold, and enables rapid access to heterogeneous devices and data normalization processing, outputting standard data objects. This effectively shortens the integration cycle, reduces time and manpower costs, adapts to the diverse needs of devices and rapid iteration, and significantly improves the deployment efficiency and data application convenience of energy storage systems.

[0011] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention, it can be implemented according to the contents of the specification. In order to make the above and other objects, features and advantages of the present invention more obvious and understandable, preferred embodiments are described in detail below. Attached Figure Description

[0012] Figure 1 This is a flowchart illustrating a multi-protocol adaptation method for an energy storage system according to an embodiment of the present invention; Figure 2 yes Figure 1 A schematic diagram of a specific implementation method for step S10; Figure 3 yes Figure 1 A schematic diagram of a specific implementation method for step S20; Figure 4 yes Figure 1 A schematic diagram of a specific implementation method for step S30; Figure 5 yes Figure 1 Another flowchart illustrating a specific implementation of step S40; Figure 6 yes Figure 1 A schematic diagram of a specific implementation method for step S50; Figure 7 This is a schematic diagram of a multi-protocol adaptation device for an energy storage system according to an embodiment of the present invention; Figure 8 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention; Figure 9 This is another structural schematic diagram of a computer device according to one embodiment of the present invention. Detailed Implementation

[0013] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. The technical solutions in the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0014] It should be understood that, when used in this specification and the appended claims, the terms “comprising” and “including” indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

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

[0016] It should also be further understood that the term "and / or" as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0017] Please see Figure 1 As shown, Figure 1 This is a schematic flowchart illustrating a multi-protocol adaptation method for an energy storage system provided in an embodiment of the present invention. The multi-protocol adaptation method for an energy storage system includes the following steps: S10: Abstract the communication protocols and data points of various devices in the energy storage system, and construct them into a unified communication channel model and data point model.

[0018] Step S10 involves extracting the common patterns of communication across all energy storage devices, standardizing the general logic scattered across different device protocols, and forming a unified meta-model—the communication channel model and data point model. This lays the foundation for the subsequent separate design of common bearers and individual configurations. The common patterns here refer to the fact that regardless of the brand, type, or protocol of the device, its communication process with the energy storage system inevitably includes two core stages: connection establishment and data interaction. Each stage has common core elements. Specifically, the connection stage requires specifying the parameters for connection, and the data interaction stage requires specifying the attributes of what the data is, where it is located, and how it is interpreted. This is the core basis for abstract modeling. The unique parameter differences of each type of device within these common patterns constitute its individual characteristics. For example, the serial port baud rate of brand A BMS is 9600, while the TCP port of brand B PCS is 503, or the storage address of the same physical quantity differs in different devices. Overcoming the fragmented nature of traditional solutions where each device has its own set of rules, this approach ensures that the adaptation of all devices is based on a unified standard. The generated meta-model serves as a communication template, providing precise entry points for the unique parameters of each type of device and avoiding rule confusion caused by individual differences.

[0019] In some embodiments of the present invention, such as Figure 2 As shown, a specific abstraction scheme is provided. In S10, the communication protocols and data points of various devices in the energy storage system are abstracted and constructed into a unified communication channel model and data point model, which specifically includes the following steps S11-S12.

[0020] S11: Abstract the communication protocols of various devices in the energy storage system, extract common communication channel parameters, and form the communication channel model; wherein, the communication channel model includes at least one of serial port, TCP client / server, and CAN bus parameters.

[0021] It is understandable that the common pattern of communication protocols is that the communication connection of all devices is essentially to realize data transmission through a specific channel type, and the connection parameters of the same channel type have a fixed core dimension. This is the commonality that needs to be extracted.

[0022] Taking serial communication as an example, its common parameters must include the serial port number used to identify the physical port, the baud rate used to control the data transmission rate, the data bits used to reflect the basic storage length of the data, the stop bits used to indicate the end of the data frame, and the check bits used to verify the accuracy of data transmission.

[0023] Taking TCP client / server communication as an example, its common parameters must include IP address, port number, connection mode (such as client / server mode) used to identify who initiates the connection, and timeout.

[0024] Taking CAN bus communication as an example, its common parameters must include baud rate, node address used to represent the unique identifier of the device in the CAN bus, and filtering rules used to select the data frames to be received.

[0025] The communication channel model constructed in this embodiment integrates the common parameters of these similar channels into a standardized template. Regardless of which device is subsequently connected, as long as the channel type is determined, the connection parameters can be directly configured using this template without redesigning the parameter dimensions.

[0026] S12: Abstract the data point attributes of multiple types of devices in the energy storage system and define the data point model; wherein, the data point model includes at least one of the following attributes for each data point: globally unique point number, standard name, device internal address, data type, read / write permission, scaling factor, offset, unit, and alarm threshold.

[0027] As can be understood, a data point refers to all information items that can be read from and / or written to the device. For example, the battery voltage of a BMS is typically read-only, while charge / discharge enable commands need to be written. In this embodiment, writable data points used to issue commands to the device or modify device status or parameters are defined as control points.

[0028] It is also understandable that the common patterns of data points are specifically reflected in all the collectable or controllable physical quantities of all devices, such as temperature, power, and voltage. Regardless of their definition in the device protocol, they must have the core attributes of being identifiable, locatable, interpretable, and usable. This is the abstract basis of the data point model.

[0029] The data point model in this embodiment identifies nine common attribute dimensions, and the unique characteristics of each dimension are as follows: Globally unique point number (point_id): A unique identifier for this data point in the entire energy storage system. The naming rule is device type_device number_physical quantity (e.g., cooling_001.temp_in) to avoid conflicts between data points with the same name on different devices and to ensure the uniqueness of data traceability.

[0030] Standard name (name): The common Chinese name for a physical quantity, such as inlet water temperature or charging / discharging power. It is used to unify the different names for the same physical quantity within the industry. For example, if brand A names it as "inlet water temperature" and brand B names it as "inlet water temperature", the former should be used for standardization.

[0031] Device address: The storage location of the data point in the device's own protocol, such as 30001 or 0x0002, which is the precise location for the driver to read / write data.

[0032] Data type (data_type): The storage format of the data, such as uint16 representing a 16-bit unsigned integer and float32 representing a 32-bit floating-point number, used to ensure that the driver correctly parses the raw data.

[0033] Read / write permissions (rw): Indicate whether a data point supports control operations. Specifically, "r" means read-only and is only used for data collection, "w" means write-only, and "rw" means read and write.

[0034] Scaling factor: A scaling factor for converting the original value into the actual physical quantity, such as 0.1 or 0.001, used to address the difference in magnitude between the original value of the equipment and the engineering value.

[0035] Offset: The correction value for converting the original value. It is usually 0, but in special scenarios such as sensor calibration, it needs to be set to a non-zero value.

[0036] Unit: A standard unit for physical quantities, including but not limited to ℃, kV, and kW, used to standardize unit differences between different devices.

[0037] Alarm threshold (alarm_threshold): Includes upper and lower limits, used to determine in real time whether an alarm is triggered after data collection.

[0038] Therefore, the data point model brings all heterogeneous data points to the same standard dimension. Subsequently, no matter what kind of device is connected, the data can be interpreted in a standardized manner simply by filling in the attribute values ​​according to the model.

[0039] S20: Based on the communication channel model and data point model, create a protocol driver library and a protocol description file; wherein, the protocol driver library includes a general protocol driver for the communication protocol, and the protocol description file is used to describe the communication parameters and data point information of a specific device.

[0040] For step S20, two components are used to carry the commonalities of communication and the individual characteristics of the devices respectively. Specifically, the protocol driver library encapsulates the common logic of communication of all devices, ensuring that the driver of the same protocol can be reused. The protocol description file records the unique parameters of a single type of device, ensuring that the differences between devices are only reflected through configuration and that there is no need to modify the core code. The two work together to completely solve the pain points of driver binding to devices and code coupling to protocols in traditional solutions.

[0041] In some embodiments of the present invention, such as Figure 3 As shown, a specific scheme for creating a protocol driver library and a protocol description file is provided. In S20, that is, based on the communication channel model and the data point model, the protocol driver library and the protocol description file are created, which specifically includes the following steps S21-S22.

[0042] S21: Define general protocol drivers for multiple communication protocols to form a protocol driver library. Each general protocol driver is used to implement frame assembly, parsing and communication link management of the corresponding protocol, but does not contain device-specific data point information.

[0043] Among them, the general protocol driver is a standardized plug-in for a certain type of underlying protocol, such as Modbus RTU or CAN2.0B. It has rules that are completely consistent regardless of which device using the protocol is connected, and these rules do not need to be modified.

[0044] In this embodiment, the core functions and common logic of the general protocol driver are as follows: Frame assembly: Generate data read / write instruction frames according to the protocol standard format. For example, the read frame format of the Modbus RTU driver is fixed as slave address-function code-start address-data length-CRC check. The driver only needs to receive the slave address, destination address, length and other personalized parameters in the protocol description file to automatically assemble compliant frames.

[0045] Frame parsing: According to the protocol standard, the protocol shell of the device response frame is stripped to extract the raw data. For example, for Modbus RTU driver, it automatically checks the CRC and determines whether the function code is correct before extracting the raw data in the middle, without needing to care about the actual physical meaning of the data.

[0046] Communication link management: Implements general logic for connection establishment, disconnection, reconnection, and status monitoring. For example, the reconnection mechanism of TCP driver is to retry once every 2 seconds after the connection is disconnected, and report an alarm if it fails 10 times in total.

[0047] The protocol driver library in this embodiment includes three core drivers: Modbus RTU, Modbus TCP, and CAN2.0B. When adding new protocols in the future, it is only necessary to develop new drivers according to the same logic and store them in the library. No system architecture needs to be modified, which makes it highly scalable.

[0048] S22: For each type of device to be accessed, a structured protocol description file is generated using the data point model according to its communication manual. The protocol description file includes a device type identifier, a protocol type field, communication channel configuration parameters, and a data point list. The data point list describes all data point information of the device based on the data point model, including at least one of address, data type, scaling factor, offset, and unit.

[0049] In this embodiment, the structured protocol description file adopts JSON format to reflect the unique information of the device, that is, the exclusive parameters that distinguish one type of device from other devices.

[0050] The following is an application example of the Modbus RTU protocol: Suppose the system needs to connect to a new brand C liquid chiller unit. This device uses the Modbus RTU protocol. The specific contents of its protocol description file and the meaning of each field are as follows: Device type identifier (device_type): Used to identify the device category for easy classification and management.

[0051] Protocol type field (protocol): This field is completely identical to the driver identifier in the protocol driver library and is used for automatic driver matching.

[0052] Communication channel configuration parameters (channel_config): Following the communication channel model in step S11, fill in the unique connection parameters for this device. Each parameter must be completely matched with the actual device settings.

[0053] Data point list (point_list): Following the data point model in step S12, fill in the individual attributes of all data points that need to be collected / controlled by the device, for example: { "point_id": "cooling_001.temp_in", "name": "Inlet water temperature", "address": 30001, "data_type": "uint16", "scale": 0.1, "offset": 0, "unit": "°C", "rw": "r" } S30: Using the protocol description file, load the corresponding general protocol driver from the protocol driver library and establish a communication connection.

[0054] In step S30, guided by the protocol description file and the execution of the general driver, automatic device adaptation and access are achieved. The entire process from device discovery to connection establishment can be completed without manual intervention, truly enabling hot-swapping of devices. Specifically, the system uses the personalized information in the protocol description file to call the common logic of the driver library, giving it the ability to adapt to different devices.

[0055] In some embodiments of the present invention, such as Figure 4 As shown, a specific connection scheme is provided. In S30, the corresponding general protocol driver is loaded from the protocol driver library and a communication connection is established using the protocol description file. Specifically, this includes the following steps S31-S33.

[0056] S31: When the energy storage system starts up or receives a device scan command, it automatically scans all protocol description files in the preset directory.

[0057] The preset directory is the fixed storage path for the configuration files of the energy storage system. In this embodiment, it is set to / EMS / Config / DeviceProtocols / . In actual implementation, the field engineer does not need to modify the system code, but only needs to copy the protocol description file of the new device (such as BrandC_Chiller.json) to this directory.

[0058] In this embodiment, the scan triggering mechanism includes two types: one is automatic scanning upon system startup, which initializes all device connections; the other is manual scanning, which is achieved by clicking the device scan button on the system's local monitoring interface for quick identification when a new device is added. During the scan, the system will traverse all JSON / XML format files in the directory, read the device_type and protocol fields in the file header, and determine whether they are valid protocol description files. Invalid files, such as those with incorrect formats or missing core fields, will be marked and an alarm will be reported.

[0059] S32: Determine the required protocol driver based on the protocol type field in the protocol description file, and automatically load the corresponding general protocol driver from the protocol driver library.

[0060] Understandably, the corresponding generic protocol driver is automatically loaded from the protocol driver library, i.e., driver matching is performed. Specifically, each type of driver in the protocol driver library has a unique identifier, such as "Modbus_RTU_Driver" for the Modbus RTU driver. The protocol field in the protocol description file must correspond exactly to this identifier, which is automatically mapped internally by the system.

[0061] It is also understandable that driver reuse can be achieved through step S32. If another air conditioning device using the Modbus RTU protocol is subsequently connected, only its protocol description file needs to be generated, and the system will automatically load the same Modbus RTU driver, eliminating the need for repeated development.

[0062] S33: Establish a physical communication connection with the device based on the communication channel configuration parameters in the protocol description file.

[0063] It is understandable that a physical communication connection is the actual data transmission link between the system and the device, in order to facilitate subsequent data acquisition and processing. The connection establishment process strictly follows the general rules of the communication channel model and the individual parameters of the protocol description file.

[0064] S40: Data acquisition and normalization are performed using the loaded general protocol driver and protocol description file.

[0065] In step S40, in this embodiment, all data processing is completed at the system edge, without needing to upload to the cloud for processing. This solves the pain point of inconsistent data models in traditional solutions and improves data processing efficiency. During this process, the general driver is responsible for executing common acquisition logic, while the protocol description file provides customized conversion rules. Together, they achieve automatic data acquisition and standardization.

[0066] In some embodiments of the present invention, such as Figure 5 As shown, a specific processing scheme is provided. In S40, data acquisition and normalization processing are performed through the loaded general protocol driver and protocol description file, specifically including the following steps S41-S43.

[0067] S41: Using the loaded general protocol driver, a data read request is sent to the device according to the address information of the data point list in the protocol description file.

[0068] In this embodiment, the data read request is essentially a combination of a general protocol driver and a custom address. The general protocol driver provides the universal format of the protocol frame, while the protocol description file provides the unique address of the data point. The two are combined to form an instruction that the device can recognize.

[0069] S42: Receive the raw response data returned by the receiving device and parse it using the general protocol driver to obtain the raw value.

[0070] The raw response data is binary data returned by the device according to its own protocol. It does not contain any physical meaning and the raw value needs to be extracted through the common parsing logic of the general driver.

[0071] S43: Based on at least one of the scaling factor, offset, and unit conversion rules configured in the data point list, the original value is converted into a normalized engineering value with standard units and precision in real time.

[0072] For step S43, the system automatically converts the original value into an engineering value with standard units and standard precision based on the personalized conversion rules preset in the protocol description file, specifically, according to the scaling factor, offset, and unit conversion rules configured for the data point.

[0073] For example, the original value of the device "5000" is converted to "5.0kV" according to the configuration (coefficient 0.001, offset 0, unit kV).

[0074] S50: Outputs normalized data and encapsulates it into a standard data object for use by upper-layer applications.

[0075] Understandably, the encapsulated standard data object is completely independent of the underlying device protocol, enabling data to be used out of the box in the cloud and providing a unified data foundation for local applications and advanced cloud applications of energy storage systems.

[0076] In some embodiments of the present invention, such as Figure 6 As shown, a specific encapsulation scheme is provided. In S50, the normalized data is output and encapsulated into a standard data object for use by upper-layer applications. Specifically, it includes the following steps S51-S53.

[0077] S51: Bind the normalized data with the globally unique point number and standard name of the data point to generate bound data.

[0078] Understandably, the core purpose of binding is to make data identifiable and traceable. Specifically, the globally unique point number (point_id) is used to ensure the uniqueness of data throughout the entire energy storage system. For example, cooling_001.temp_in clearly points to the inlet water temperature of the No. 1 liquid cooler unit, avoiding confusion of data points with the same name on different devices. The standard name allows upper-layer applications, whether local or in the cloud, to intuitively understand the meaning of the data without having to interpret the protocol.

[0079] S52: Encapsulate the binding data into a unified data object independent of the underlying device protocol. The unified data object includes at least one of point number, value, unit, and timestamp.

[0080] In this embodiment, the unified data object adopts JSON format, which is a structured data carrier. Its field design fully follows the general requirements of the upper layer application and does not contain any information related to the underlying protocol.

[0081] The following is an example of a wrapper implementation: The energy storage system detects the new configuration file, automatically loads the built-in Modbus RTU universal protocol driver, and establishes a serial port connection according to the configuration. Subsequently, the driver automatically reads data at address 30001, obtains the raw value "250", applies the configuration "scale:0.1", obtains the normalized value "25.0°C", and then encapsulates it into a standard message "{"point_id":"cooling_001.temp_in", "value":25.0, "unit":"°C", "timestamp":...}".

[0082] S53: Provide the unified data object to the local application of the energy storage system or upload it to the cloud platform through a standard interface.

[0083] In this embodiment, the output of the unified data object is divided into two scenarios: local application use and cloud upload use, both of which can be used without secondary processing.

[0084] Local application usage: The system's local monitoring interface directly reads the name, value, and unit fields of the data object to display the equipment's operating status in real time; the energy optimization algorithm calls the value field, combines it with ambient temperature data to calculate the heat dissipation efficiency of the liquid-cooled unit, and dynamically adjusts the operating strategy.

[0085] Cloud upload usage: In practice, the corresponding topic can be uploaded via the standard MQTT interface, such as / EMS / DeviceData / BrandC_Chiller / cooling_001.temp_in. After the cloud platform subscribes to this topic, it directly receives the data objects and stores them in the time-series database. Cloud applications can directly read the data from the database to generate device operation reports and predict faults without needing to perform protocol parsing or data conversion.

[0086] S60: When a standard format control command is received from an upper-layer application, reverse control is performed on the device based on the protocol description file.

[0087] For step S60, the design logic of separating common and specific features continues, addressing the pain point of traditional solutions requiring customized development of control commands and achieving plug-and-play functionality at the control layer. The core is to convert standard control commands from upper-layer applications into device-specific commands that can be recognized by the device through the custom rules of the protocol description file, without modifying the core system code.

[0088] In some embodiments of the present invention, a specific reverse control scheme is provided. In S60, when a standard format control command is received from an upper-layer application, reverse control of the device is performed based on the protocol description file, specifically including the following steps: When a standard format control command is received from an upper-layer application, the corresponding protocol description file for the target device is searched. Based on the scaling factor, offset, and preset writing rules defined in the protocol description file, the standard format control commands are converted into the raw values ​​required for device communication. The loaded generic protocol driver corresponding to the target device is invoked to assemble the original values ​​into a complete instruction frame; Through the established communication connection, the instruction frame is sent to the target device to complete the reverse control.

[0089] In practice, when a standard format control command is received from an upper-layer application, such as {"point_id":"cooling_001.target_temp", "value":22.0, "unit":"℃"}, the system first searches the protocol description file corresponding to that point number. This file contains pre-defined writing rules for the control point, including the target data point's internal device address, data type, and write frame format. Then, based on the configured scaling factor and offset, the system converts the 22.0℃ in the standard command into the original value 220 that the device can recognize. Next, it calls the loaded general protocol driver, such as Modbus RTU, to assemble the original value into a command frame conforming to the protocol rules, containing the slave address, function code, target address, and original value. Finally, it sends the command to the device through the established communication connection. The device executes the command and returns a response, completing the reverse control. The entire process requires no modification to the core system code; it can adapt to the control needs of different devices simply through configuration files, significantly reducing the integration and maintenance costs of the control logic.

[0090] As can be seen, the above solution achieves the separation of common and individual communication characteristics of devices by abstracting and constructing a unified model, creating a general protocol driver library and a dedicated protocol description file. This eliminates the need to manually develop dedicated drivers and modify core code, greatly simplifying the protocol integration process, lowering the development threshold, and enabling rapid access to heterogeneous devices and data normalization processing, outputting standard data objects. This effectively shortens the integration cycle, reduces time and labor costs, adapts to the diverse needs of devices and rapid iteration, and significantly improves the deployment efficiency and data application convenience of energy storage systems.

[0091] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0092] In one embodiment, the present invention provides a multi-protocol adaptation device 100 for energy storage systems, which corresponds one-to-one with the multi-protocol adaptation method for energy storage systems described in the above embodiments. For example... Figure 7 As shown, the multi-protocol adaptation device 100 for the energy storage system includes an abstraction module 101, a configuration module 102, a connection module 103, a processing module 104, an encapsulation module 105, and a reverse control module 106. Detailed descriptions of each functional module are as follows: Abstract module 101 is used to abstract the communication protocols and data points of various devices in the energy storage system and construct them into a unified communication channel model and data point model.

[0093] The configuration module 102 is used to create a protocol driver library and a protocol description file based on the communication channel model and the data point model; wherein, the protocol driver library includes a general protocol driver for the communication protocol, and the protocol description file is used to describe the communication parameters and data point information of a specific device.

[0094] The connection module 103 is used to load the corresponding general protocol driver from the protocol driver library and establish a communication connection using the protocol description file.

[0095] The processing module 104 is used to perform data acquisition and normalization processing through the loaded general protocol driver and protocol description file.

[0096] Encapsulation module 105 is used to output normalized data and encapsulate it into a standard data object for use by upper-layer applications.

[0097] The reverse control module 106 is used to perform reverse control on the device based on the protocol description file when it receives a standard format control command issued by the upper layer application.

[0098] In one embodiment, the abstract module 101 is specifically used for: The communication protocols of various devices in the energy storage system are abstracted, and common communication channel parameters are extracted to form the communication channel model; wherein, the communication channel model includes at least one of serial port, TCP client / server, and CAN bus parameters; The data point attributes of various types of devices in the energy storage system are abstracted to define the data point model; wherein, the data point model includes at least one of the following attributes for each data point: globally unique point number, standard name, device internal address, data type, read / write permission, scaling factor, offset, unit, and alarm threshold.

[0099] In one embodiment, the configuration module 102 is specifically used for: A general protocol driver is defined for each type of communication protocol to form a protocol driver library. Each general protocol driver is used to implement frame assembly, parsing and communication link management of the corresponding protocol, but does not contain device-specific data point information. For each type of device to be connected, a structured protocol description file is generated using the data point model based on its communication manual. The protocol description file includes a device type identifier, a protocol type field, communication channel configuration parameters, and a data point list. The data point list describes all data point information of the device based on the data point model, including at least one of address, data type, scaling factor, offset, and unit.

[0100] In one embodiment, the connection module 103 is specifically used for: When the energy storage system starts up or receives a device scan command, it automatically scans all protocol description files in the preset directory; The required protocol driver is determined based on the protocol type field in the protocol description file, and the corresponding general protocol driver is automatically loaded from the protocol driver library. A physical communication connection with the device is established based on the communication channel configuration parameters in the protocol description file.

[0101] In one embodiment, the processing module 104 is specifically used for: By loading the general protocol driver, a data read request is sent to the device according to the address information of the data point list in the protocol description file; The raw response data returned by the receiving device is parsed by the general protocol driver to obtain the raw value; Based on at least one of the scaling factor, offset, and unit conversion rules configured in the data point list, the original values ​​are converted into normalized engineering values ​​with standard units and precision in real time.

[0102] In one embodiment, the encapsulation module 105 is specifically used for: The normalized data is bound to the globally unique point number and standard name of the data point to generate bound data; The bound data is encapsulated into a unified data object independent of the underlying device protocol. The unified data object includes at least one of point number, value, unit, and timestamp. The unified data object can be provided to the local application of the energy storage system or uploaded to the cloud platform through a standard interface.

[0103] In one embodiment, the anti-control module 106 is specifically used for: When a standard format control command is received from an upper-layer application, the corresponding protocol description file for the target device is searched. Based on the scaling factor, offset, and preset writing rules defined in the protocol description file, the standard format control commands are converted into the raw values ​​required for device communication. The loaded generic protocol driver corresponding to the target device is invoked to assemble the original values ​​into a complete instruction frame; Through the established communication connection, the instruction frame is sent to the target device to complete the reverse control.

[0104] Specific limitations regarding the multi-protocol adaptation device 100 for energy storage systems can be found in the limitations of the multi-protocol adaptation method for energy storage systems described above, and will not be repeated here. Each module in the aforementioned multi-protocol adaptation device 100 for energy storage systems can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0105] In one embodiment, a computer device 200 is provided, which may be a server, and its internal structure diagram may be as follows: Figure 8 As shown. The computer device 200 includes a processor 220, memory, and a network interface 250 connected via a system bus 210. The processor 220 provides computing and control capabilities. The memory of the computer device 200 includes non-volatile and / or volatile storage media and internal memory 240. The non-volatile storage media 230 stores an operating system 231, computer programs 232, and a database 233. The internal memory 240 provides an environment for the operation of the operating system and computer programs in the non-volatile storage media 230. The network interface 250 of the computer device 200 is used for communication with external clients via a network connection. When the computer program is executed by the processor 220, it implements the functions or steps of a server-side method for multi-protocol adaptation in an energy storage system. That is, when the processor 220 executes the computer program, it performs the following steps: The communication protocols and data points of various devices in the energy storage system are abstracted and constructed into a unified communication channel model and data point model; Based on the communication channel model and data point model, a protocol driver library and a protocol description file are created; wherein, the protocol driver library includes a general protocol driver for the communication protocol, and the protocol description file is used to describe the communication parameters and data point information of a specific device; Using the protocol description file, the corresponding general protocol driver is loaded from the protocol driver library and a communication connection is established; Data acquisition and normalization are performed using the loaded general protocol driver and protocol description file; The normalized data is output and encapsulated into a standard data object for use by upper-layer applications.

[0106] In one embodiment, a computer device 300 is provided, which may be a client, and its internal structure diagram may be as follows: Figure 9 As shown. The computer device includes a processor 320, memory, network interface 350, display screen 370, and input device 360 ​​connected via a system bus 310. The processor 320 provides computing and control capabilities. The memory includes a non-volatile storage medium 330 and internal memory 340. The non-volatile storage medium 330 stores an operating system 331 and a computer program 332. The internal memory provides an environment for the operation of the operating system 331 and the computer program 332 in the non-volatile storage medium 330. The network interface 350 of the computer device 300 is used for communication with an external server via a network connection. When the computer program is executed by the processor 320, it implements the functions or steps on the client side of a multi-protocol adaptation method for an energy storage system. That is, when the processor 320 executes the computer program 332, it implements the following steps: The communication protocols and data points of various devices in the energy storage system are abstracted and constructed into a unified communication channel model and data point model; Based on the communication channel model and data point model, a protocol driver library and a protocol description file are created; wherein, the protocol driver library includes a general protocol driver for the communication protocol, and the protocol description file is used to describe the communication parameters and data point information of a specific device; Using the protocol description file, the corresponding general protocol driver is loaded from the protocol driver library and a communication connection is established; Data acquisition and normalization are performed using the loaded general protocol driver and protocol description file; The normalized data is output and encapsulated into a standard data object for use by upper-layer applications.

[0107] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor: The communication protocols and data points of various devices in the energy storage system are abstracted and constructed into a unified communication channel model and data point model; Based on the communication channel model and data point model, a protocol driver library and a protocol description file are created; wherein, the protocol driver library includes a general protocol driver for the communication protocol, and the protocol description file is used to describe the communication parameters and data point information of a specific device; Using the protocol description file, the corresponding general protocol driver is loaded from the protocol driver library and a communication connection is established; Data acquisition and normalization are performed using the loaded general protocol driver and protocol description file; The normalized data is output and encapsulated into a standard data object for use by upper-layer applications.

[0108] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0109] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and RAMbus dynamic RAM (RDRAM), etc.

[0110] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0111] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A multi-protocol adaptation method for an energy storage system, characterized in that, include: The communication protocols and data points of various devices in the energy storage system are abstracted and constructed into a unified communication channel model and data point model; Based on the communication channel model and data point model, a protocol driver library and a protocol description file are created; wherein, the protocol driver library includes a general protocol driver for the communication protocol, and the protocol description file is used to describe the communication parameters and data point information of a specific device; Using the protocol description file, the corresponding general protocol driver is loaded from the protocol driver library and a communication connection is established; Data acquisition and normalization are performed using the loaded general protocol driver and protocol description file; The normalized data is output and encapsulated into a standard data object for use by upper-layer applications.

2. The multi-protocol adaptation method for energy storage systems according to claim 1, characterized in that, The abstraction of communication protocols and data points for various types of devices in the energy storage system, and the construction of a unified communication channel model and data point model, includes: The communication protocols of various devices in the energy storage system are abstracted, and common communication channel parameters are extracted to form the communication channel model; wherein, the communication channel model includes at least one of serial port, TCP client / server, and CAN bus parameters; The data point attributes of various devices in the energy storage system are abstracted to define the data point model; wherein, the data point model includes at least one of the following attributes for each data point: globally unique point number, standard name, device internal address, data type, read / write permission, scaling factor, offset, unit, and alarm threshold.

3. The multi-protocol adaptation method for energy storage systems according to claim 2, characterized in that, The creation of a protocol driver library and protocol description file based on the communication channel model and data point model includes: A general protocol driver is defined for each type of communication protocol to form a protocol driver library. Each general protocol driver is used to implement frame assembly, parsing and communication link management of the corresponding protocol, but does not contain device-specific data point information. For each type of device to be connected, a structured protocol description file is generated using the data point model based on its communication manual. The protocol description file includes a device type identifier, a protocol type field, communication channel configuration parameters, and a data point list. The data point list describes all data point information of the device based on the data point model, including at least one of address, data type, scaling factor, offset, and unit.

4. The multi-protocol adaptation method for energy storage systems according to claim 3, characterized in that, The step of using the protocol description file to load the corresponding general protocol driver from the protocol driver library and establish a communication connection includes: When the energy storage system starts up or receives a device scan command, it automatically scans all protocol description files in the preset directory; The required protocol driver is determined based on the protocol type field in the protocol description file, and the corresponding general protocol driver is automatically loaded from the protocol driver library. A physical communication connection with the device is established based on the communication channel configuration parameters in the protocol description file.

5. The multi-protocol adaptation method for energy storage systems according to claim 4, characterized in that, The data acquisition and normalization process, performed using the loaded general protocol driver and protocol description file, includes: By loading the general protocol driver, a data read request is sent to the device according to the address information of the data point list in the protocol description file; The raw response data returned by the receiving device is parsed by the general protocol driver to obtain the raw value; Based on at least one of the scaling factor, offset, and unit conversion rules configured in the data point list, the original values ​​are converted into normalized engineering values ​​with standard units and precision in real time.

6. The multi-protocol adaptation method for energy storage systems according to claim 5, characterized in that, The process of outputting normalized data and encapsulating it into a standard data object for use by upper-layer applications includes: The normalized data is bound to the globally unique point number and standard name of the data point to generate bound data; The bound data is encapsulated into a unified data object independent of the underlying device protocol. The unified data object includes at least one of point number, value, unit, and timestamp. The unified data object can be provided to the local application of the energy storage system or uploaded to the cloud platform through a standard interface.

7. The multi-protocol adaptation method for energy storage systems according to claim 6, characterized in that, After the normalized data is output and encapsulated into a standard data object for use by upper-layer applications, the method further includes: when a standard format control command is received from an upper-layer application, reverse control of the device is performed based on the protocol description file; specifically, the reverse control of the device based on the protocol description file includes: When a standard format control command is received from an upper-layer application, the corresponding protocol description file for the target device is searched. Based on the scaling factor, offset, and preset writing rules defined in the protocol description file, the standard format control commands are converted into the raw values ​​required for device communication. The loaded generic protocol driver corresponding to the target device is invoked to assemble the original values ​​into a complete instruction frame; Through the established communication connection, the instruction frame is sent to the target device to complete the reverse control.

8. A multi-protocol adaptation device for an energy storage system, characterized in that, include: The abstract module is used to abstract the communication protocols and data points of various devices in the energy storage system and build them into a unified communication channel model and data point model. The configuration module is used to create a protocol driver library and a protocol description file based on the communication channel model and data point model; wherein, the protocol driver library includes a general protocol driver for the communication protocol, and the protocol description file is used to describe the communication parameters and data point information of a specific device; The connection module is used to load the corresponding general protocol driver from the protocol driver library and establish a communication connection using the protocol description file; The processing module is used to perform data acquisition and normalization processing through the loaded general protocol driver and protocol description file; The encapsulation module is used to output normalized data and encapsulate it into a standard data object for use by upper-layer applications.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the multi-protocol adaptation method for energy storage systems as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the multi-protocol adaptation method for energy storage systems as described in any one of claims 1 to 7.

Images