Method, device and storage medium for protocol conversion in EMS

Abstract

The application belongs to the technical field of power supply or power distribution circuit device or system, and provides an EMS protocol conversion method and device and a storage medium. According to a configured communication interface, a P2P communication connection is established with a slave device and original data is received, then device data is parsed according to a corresponding communication protocol, the device data is stored into a device data storage unit, the device data is converted into internal data, the internal data is stored into an internal data storage unit, a data mapping relationship between the internal data and the device data is established, and when the slave device data is uploaded, the internal data is called, the compatibility, data reliability, maintainability and scalability of the EMS system are improved, real-time scheduling delay can be reduced, and data calling efficiency is improved.

Description

Technical Field

[0001] This application relates to the field of circuit devices or systems for power supply or distribution, and in particular to a protocol conversion method, device and storage medium in an EMS. Background Technology

[0002] EMS (Energy Management System) is a software-based power grid dispatch automation system that achieves full lifecycle management of energy flow through real-time data acquisition and intelligent strategy optimization. In traditional energy management systems, communication interfaces and protocols are usually "one-to-one hard-coded". When managing multiple slave devices, since each device uses different communication interfaces or different communication protocols, there are two common design approaches: (1) Set up corresponding interfaces and protocol processing modules for different communication interfaces and corresponding communication protocols of the devices to independently handle the data interaction of the slave devices; (2) Use an external independent protocol gateway device to convert the communication of the slave devices into the interface and protocol information that the EMS system has and can process, thereby realizing the protocol conversion function and handling the data interaction with the slave devices.

[0003] However, setting up multiple corresponding interfaces and protocols for different devices still results in encountering unsupported interfaces and communication protocols. Adding new devices requires redeveloping the entire communication module, leading to extremely poor scalability. Furthermore, implementing independent communication interactions for different devices, requiring multiple different interfaces and communication protocols, increases development costs and timelines, hindering rapid product launches and subsequent maintenance. Existing solutions use additional protocol gateways for protocol conversion, but this increases hardware costs, requires more installation space, and impacts the overall data security, stability, and timeliness of the system. Summary of the Invention

[0004] In view of this, the purpose of this application is to provide a protocol conversion method in EMS, an EMS device, a computer device, and a computer-readable storage medium.

[0005] In a first aspect, embodiments of this application provide a protocol conversion method in an EMS, comprising the following steps: establishing a P2P communication connection with the slave device according to the physical link parameters of the configured slave device's communication interface, and receiving raw data sent by the slave device; reading device data from the raw data according to the data read / write rules corresponding to the communication protocol configured by the slave device, and storing the device data in a device data storage unit; converting the device data in the device data storage unit into internal data, and storing the internal data in an internal data storage unit; establishing a data mapping relationship between the internal data and the device data; and, according to the data mapping relationship, calling the internal data when uploading data from the slave device.

[0006] In some embodiments, each slave device is assigned a globally unique identifier, which is included in the original data, the device data, and the internal data.

[0007] In some embodiments, the data conversion includes at least one of verification, cleaning, completion, parameter matching, parameter operation, unit normalization, semantic consistency, and precision standardization; the parameter operation can perform arithmetic or logical operations on the data; the parameter matching can convert multiple bit data into 1 bit data.

[0008] In some embodiments, a unique device data storage area is allocated to each slave device in the device data storage unit, and a unique internal data storage area is allocated to each slave device in the internal data storage unit; the larger the amount of data of the slave device, the larger the allocated storage space.

[0009] In some embodiments, the method further includes the steps of: receiving a generated internal instruction, encapsulating it into instruction internal data, and storing it in the internal data storage unit; updating the instruction device data in the device data storage unit corresponding to the instruction internal data in the internal data storage unit according to the data mapping relationship; converting the instruction device data into corresponding instruction raw data recognizable by the slave device according to the protocol encoding rules corresponding to the communication protocol configured by the slave device; and sending the instruction raw data to the corresponding slave device according to the P2P communication connection established with the slave device.

[0010] In some embodiments, the internal data includes the identity identifier and data priority of the slave device; a three-level bucket architecture is adopted: several primary storage buckets are created in the internal data storage unit according to the identity identifier of the slave device; priority sub-buckets are divided in each primary storage bucket according to the data priority; urgent sub-buckets, high priority sub-buckets, and normal sub-buckets are divided in the priority sub-buckets; the method also includes the steps of: the internal data is stored in the corresponding urgent sub-buckets, high priority sub-buckets, and normal sub-buckets according to the identity identifier and the data priority; during data processing, the data in the urgent sub-buckets is processed first, and then the data in the high priority sub-buckets and normal sub-buckets are processed in turn.

[0011] In some embodiments, the data capacity, batch processing threshold, and timeout duration of the emergency sub-bucket, high-priority sub-bucket, and normal sub-bucket all increase sequentially; when the amount of data in the emergency sub-bucket, the high-priority sub-bucket, and the normal sub-bucket reach their respective batch processing thresholds or when the waiting time for processing reaches their respective timeout durations, batch processing of the data in the bucket is triggered.

[0012] In a second aspect, this application provides an EMS device, comprising: a P2P communication module, configured to establish a P2P communication connection with the slave device according to the physical link parameters of the configured slave device's communication interface, and receive raw data sent by the slave device; a device data acquisition module, configured to read device data from the raw data according to the data read / write rules corresponding to the communication protocol configured by the slave device; a device data storage unit, configured to store the device data; a data conversion unit, configured to convert the device data in the device data storage unit into internal data; an internal data storage unit, configured to store the internal data; and a data mapping module, configured to establish a data mapping relationship between the internal data and the device data, and to call the internal data when uploading data from the slave device according to the data mapping relationship.

[0013] Thirdly, this application also provides a computer device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, it implements the protocol conversion method in EMS as described in any of the above embodiments.

[0014] Fourthly, in this application embodiment, there is also a computer-readable storage medium storing a computer program that can be executed by at least one processor to cause the at least one processor to perform the protocol conversion method in EMS as described in any of the above embodiments.

[0015] The beneficial effects that this application can achieve.

[0016] This application provides a protocol conversion method in an EMS system. A P2P communication connection is established with the slave device based on a configured communication interface to receive raw data. Then, device data is parsed according to the corresponding communication protocol, stored in a device data storage unit, and converted into internal data. This internal data is then stored in an internal data storage unit, establishing a data mapping relationship between the internal data and the device data. When uploading slave device data based on this mapping relationship, the internal data is invoked. This protocol conversion method establishes a P2P connection by configuring the communication interface, eliminating the need to develop dedicated drivers for each type of device. When adding a new device, only the corresponding interface parameters (such as baud rate, IP address, and protocol type) need to be configured for quick access, significantly reducing the adaptation threshold for heterogeneous devices. By parsing the raw data according to the corresponding communication protocol to obtain "device data" and then converting it into "internal data," the decoupling of the "device's native protocol" and the "EMS internal data format" is achieved. When adding devices with different protocols, no modification to the internal core logic is required; only the parsing module for the corresponding protocol needs to be added. This enhances the compatibility of the EMS system and allows for better adaptation to different slave devices. In addition, the "layered storage + data mapping" setup can, on the one hand, avoid data loss and inconsistency and improve data reliability. On the other hand, the device data only needs to complete "protocol parsing - internal data conversion" when it is received for the first time. When uploading / calling data later, the stored internal data can be called directly through the "data mapping relationship" without having to repeatedly parse the original protocol. This greatly reduces the redundant overhead of protocol parsing and reduces the latency of real-time scheduling.

[0017] Furthermore, this application proposes a bucketing algorithm for data processing in the internal data buffer. This method enables refined data management, reduces resource contention during large-scale data processing, and ensures the real-time performance of critical data through priority scheduling, thereby improving the overall efficiency and stability of EMS system protocol conversion.

[0018] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0019] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1A schematic diagram of the topology of an EMS control system according to an embodiment of this application is shown;

[0021] Figure 2 A flowchart illustrating a protocol conversion method in an EMS according to an embodiment of this application is shown;

[0022] Figure 3 This paper illustrates a schematic diagram of the data flow in the EMS according to an embodiment of this application.

[0023] Figure 4 A schematic diagram illustrating the principle of three-level bucketing in the internal data storage unit of this application embodiment is shown.

[0024] The components are: 1-Energy Management System, 2-Upper-Level Management Server, 3-Communication Interface, 4-Energy Storage Converter, 5-Battery Management System, 6-Liquid Cooler, 7-Fire Protection Equipment, 8-P2P Communication Module, 9-Equipment Data Acquisition Module, 10-Equipment Data Storage Unit, 11-Data Conversion Unit, 12-Internal Data Storage Unit, 13-Data Mapping Module, 14-Equipment Management Layer, 15-PCS Management Module, 16-BMS Management Module, 17-Liquid Cooler Management Module, 18-Fire Protection Equipment Management Module, 19-Primary Storage Bucket, 20-Priority Sub-bucket, 21-Emergency Sub-bucket, 22-High-Priority Bucket, 23-Ordinary Sub-bucket, 100-Energy Storage Management System. Detailed Implementation

[0025] The term "comprising" in the specification, claims, and accompanying drawings of this application is synonymous with "including," "containing," or "characterized in," and is inclusive of endpoints or open-ended, and does not exclude additional unstated elements or method steps. "Comprising" is a technical term used in the language of the claims, meaning that the stated element is present, but other elements may be added and still form a construction or method within the scope of the claims.

[0026] It should be noted that similar reference numerals and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance. In this application, the term "about" means including minute variations (at most + / - 10%) of the stated value.

[0027] This application has found that existing solutions cannot quickly achieve compatibility with different communication interfaces and protocols from different manufacturers. Communication interaction needs to be implemented independently for different devices, which increases development costs and development cycle, and is not conducive to the rapid launch and subsequent maintenance of products. Alternatively, an additional protocol gateway can be used to achieve protocol conversion, but this will increase hardware costs and require installation space. Furthermore, adding additional devices will affect the overall stability and timeliness of the system.

[0028] To address the aforementioned issues, this application proposes a protocol conversion method in an EMS, comprising the following steps: establishing a P2P communication connection with the slave device based on the physical link parameters of the configured slave device's communication interface, and receiving raw data sent by the slave device; reading device data from the raw data according to the data read / write rules corresponding to the communication protocol configured by the slave device, and storing the device data in a device data storage unit; converting the device data in the device data storage unit into internal data, and storing the internal data in an internal data storage unit; establishing a data mapping relationship between the internal data and the device data; and, based on the data mapping relationship, calling the internal data when uploading slave device data.

[0029] The method described in the above embodiments breaks the traditional binding relationship of "interface-protocol-data", making the EMS system more compatible and better adaptable to different slave devices. By establishing a P2P connection through "configuring the communication interface", there is no need to develop dedicated drivers for each type of device. When adding a new device, only the corresponding interface parameters (such as baud rate, IP address, and protocol type) need to be configured for quick access, significantly reducing the adaptation threshold for heterogeneous devices. By obtaining "device data" through "parsing the raw data according to the corresponding communication protocol" and then converting it into "internal data", the "device's native protocol" and the "EMS internal data format" are decoupled. When adding devices with different protocols, there is no need to modify the internal core logic; only the parsing module for the corresponding protocol needs to be added. Furthermore, it has the following advantages: dual storage + mapping relationship avoids data loss and inconsistency, improving data reliability; the method can call internal data on demand, reducing real-time scheduling latency and improving data retrieval efficiency; module decoupling + data traceability reduces fault diagnosis costs and improves system maintainability; and it supports P2P direct connection expansion, adapting to distributed EMS architectures and improving system scalability.

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

[0031] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0032] In traditional energy management systems (EMS), communication interfaces (such as RS485 and CAN) and protocols (such as Modbus-RTU and CANopen) are usually "one-to-one hard-coded" (for example, the RS485 interface is directly bound to the Modbus-RTU parsing logic). When managing multiple slave devices (e.g., energy storage converters (PCS), battery management systems (BMS), liquid cooling equipment, fire-fighting equipment, air conditioning, etc.), the EMS system uses different communication interfaces (e.g., CAN communication, RS485, RS232, TCP, UDP, etc.) or different communication protocols (e.g., Modbus TCP, Modbus RTU, CAN messages, IEC104, IEC61850, etc.). There are two common approaches: (1) Set up corresponding interfaces and protocol processing modules for different communication interfaces and corresponding communication protocols of the devices to independently handle the data interaction of the slave devices; (2) Use an external independent protocol gateway device (e.g., CAN to Modbus, or Modbus RTU to Modbus TCP, Modbus to IEC104, etc.) to convert the communication of the slave devices into the interfaces and protocol information that the EMS system has, thereby realizing the protocol conversion function and handling the data interaction with the slave devices.

[0033] This application has revealed that existing solutions, which set up multiple corresponding interfaces and protocols for different devices, still encounter unsupported interfaces and communication protocols. Adding new devices requires the development of an entire communication module, resulting in extremely poor scalability. Furthermore, implementing independent communication interactions for different devices and adding multiple different interfaces and communication protocols increases development costs and time, hindering rapid product launches and subsequent maintenance. Existing solutions use additional protocol gateways for protocol conversion, but this increases hardware costs, requires more installation space, and the addition of extra equipment impacts the overall data security, stability, and timeliness of the system.

[0034] In view of this, the technical solution of this application provides a protocol conversion method in an energy management system. This method breaks the traditional binding relationship of "interface-protocol-data" and adopts a self-developed protocol conversion scheme based on software. It decouples and abstracts different communication interfaces and communication protocols, and uses memory mapping to manage the conversion of data and parameters. The above method has stronger compatibility of the EMS system and can better adapt to different slave devices. By establishing a P2P connection through "configuring the communication interface", there is no need to develop a dedicated driver for each type of device. When adding a new device, only the corresponding interface parameters (such as baud rate, IP address, protocol type) need to be configured for quick access, which greatly reduces the adaptation threshold of heterogeneous devices. By "parsing the original data according to the corresponding communication protocol" to obtain "device data", and then converting it into "internal data", the decoupling of "device native protocol" and "EMS internal data format" is achieved. When adding a device with a different protocol, there is no need to modify the internal core logic, only the corresponding protocol parsing module needs to be added. In addition, it has the following advantages: dual storage + mapping relationship avoids data loss and inconsistency, and improves data reliability; internal data can be called on demand in the method, reducing real-time scheduling latency and improving data calling efficiency; module decoupling + data traceability reduces the cost of troubleshooting and makes the system more maintainable; it supports P2P direct connection expansion, adapts to distributed EMS architecture, and makes the system more scalable.

[0035] See Figure 1 The energy storage management system 100 shown includes an Energy Management System (EMS), a higher-level management server 2, a Power Conversion System (PCS), a Battery Monitoring and Management System (BMS), a liquid chiller 6, and fire-fighting equipment 7, etc. The higher-level management server 2 is signal-connected to the Energy Management System 1, and the Energy Management System 1 is signal-connected to the Power Conversion System 4, the Battery Management System 5, the liquid chiller 6, and the fire-fighting equipment 7. The Energy Management System 1 (EMS) is the "brain" of energy systems such as energy storage power stations and microgrids. It connects to the Power Conversion System 4 (PCS), the Battery Management System 5 (BMS), the liquid chiller 6, and the fire-fighting equipment 7 through a communication interface 3. It collects data from each device in real time, analyzes the energy supply and demand status, and performs hierarchical and coordinated control of core components such as the Power Conversion System 4, the Battery Management System 5, the liquid chiller 6, and the fire-fighting equipment 7, ultimately achieving the goals of efficient energy utilization, safe equipment operation, and stable system output. The upper-level management server 2 connects to the energy management system 1 through a communication link or communication network, and achieves energy management goals across regions and scenarios through interaction with the energy management system 1.

[0036] EMS control is not a single command issuance, but a closed-loop process based on "data acquisition - status analysis - target decision - command execution - feedback adjustment", and must meet three core objectives: (1) Safety first: prioritize ensuring that devices such as batteries and PCS do not exceed safety thresholds (such as battery overcharge / over-discharge, PCS overcurrent); (2) Efficiency best: minimize energy loss (such as optimizing PCS conversion efficiency, liquid cooler energy consumption); (3) Demand matching: respond to grid dispatch (such as peak shaving and valley filling, ancillary services) or load demand (such as microgrid power supply stability).

[0037] Communication interface 3 serves as a "bridge" for data interaction and command transmission between the EMS and various devices and systems. It connects internal components of the energy storage system (such as batteries, PCS, and BMS), external control terminals (such as monitoring platforms and dispatch systems), and third-party devices, ensuring real-time data flow and accurate command delivery. It is a core infrastructure for the coordinated operation of the entire energy storage system. For example, in some embodiments, communication interface 3 can be an industrial bus, such as RS485, CAN / CANopen, Profinet, EtherNet / IP, Modbus-TCP (Ethernet-based Modbus), etc. Alternatively, in some embodiments, communication interface 3 can also be a general network interface, such as an Ethernet port, a wireless interface (including 4G / 5G modules, Wi-Fi (IEEE 802.11), LoRa / LoRaWAN, etc.), etc. For example, in some embodiments, the communication interface 3 may also be a Specialized Protocol Interface (SPTA) for specific devices or industry standards, such as IEC 61850, OPC UA / DA, fire protection protocols (such as GB27974), RS232 (serial interface), etc.

[0038] In this application, the EMS connects to core components such as the energy storage converter 4, battery management system 5, liquid chiller 6, and fire-fighting equipment 7 via communication interface 3 (e.g., RS485, CAN / CANopen, Ethernet, Modbus-TCP, etc.) to monitor and control the operating status and mode of the PCS, BMS, liquid chiller, fire-fighting equipment, dehumidifier, etc. in real time. The connection between each slave device (e.g., the energy storage converter 4, battery management system 5, liquid chiller 6, fire-fighting equipment 7, etc.) and the EMS can use different communication interface types. In some embodiments, an interface conversion module can be set in each slave device to adopt a unified communication interface type for communication interface 3, such as using RS-485 or CAN bus. However, this requires newly added devices to have a unified interface type, losing compatibility with devices using other interface types.

[0039] The PCS (Power Control System) acts as a "bridge" connecting the battery pack to the power grid / load. Its core function is to convert the battery's direct current (DC) to alternating current (AC) and send it to the power grid (discharging), or to convert the power grid's AC to DC to charge the battery (charging). The EMS (Electronic Management System) controls the PCS around "power command issuance + operational status monitoring," and the specific process is as follows.

[0040] Step S01: Data Acquisition. The EMS collects the PCS's operating data in real time. The PCS's operating data includes: (1) Electrical parameters: input / output voltage, current, power, power factor, conversion efficiency; (2) Status parameters: PCS operating mode (standby / charging / discharging), fault codes (such as overcurrent / overvoltage). The acquisition frequency is usually 1-10Hz to ensure data real-time performance. The EMS also receives grid dispatch instructions (such as "100kW needs to be discharged") or load data (such as "current load is 50kW, 30kW of supplementary power is needed").

[0041] Step S02: Decision Calculation. The EMS calculates the target power based on "grid / load demand," "battery status (BMS feedback)," and "PCS safety threshold." For example, if the grid requires peak shaving (off-peak charging), and the BMS reports a remaining battery capacity (SOC) of 30%, the EMS issues a "charging power of 50kW" command. Conversely, if the load suddenly increases (from 50kW to 120kW), and the BMS reports an SOC of 80%, the EMS issues a "discharging power of 70kW" command. The core logic in this step is to balance "demand" and "safety," ensuring the PCS operates within its rated power, voltage, and current range, while avoiding conflicts with the BMS's battery protection commands (e.g., if the BMS prohibits charging, the EMS must not issue a charging command). Safety constraints must be considered in this step: for example, if the PCS reports "output current close to the rated value (e.g., 100A)," the EMS automatically reduces the power command (e.g., from 100kW to 80kW) to avoid overcurrent.

[0042] Step S03: Command execution. The EMS sends the power command to the PCS controller via a communication protocol (such as Modbus-TCP, IEC 61850). The PCS controller converts the "power command" into a PWM (pulse width modulation) signal of the IGBT (insulated gate bipolar transistor) to adjust the DC-AC conversion process and achieve the target power output.

[0043] Step S04: Feedback control. The PCS feeds back the "actual output power" and "operating status" to the EMS in real time. If the deviation between the actual power and the command exceeds the threshold (e.g., ±5%), the EMS will reissue the correction command (e.g., if the command is 50kW and the actual power is 47kW, then it will be corrected to 53kW).

[0044] The Battery Management System (BMS) acts as the battery pack's "personal assistant," responsible for real-time monitoring of individual cell voltage, temperature, State of Charge (SOC), and State of Health (SOH), and implementing overcharge / over-discharge / over-temperature protection. The Energy Management System (EMS) does not directly control individual cells but works in conjunction with the BMS through "command coordination + state constraints" to ensure the battery pack operates within safe limits. The BMS is responsible for "local protection" (e.g., immediately cutting off charging to that branch when a single cell voltage exceeds the limit). The EMS is responsible for "global scheduling" (e.g., determining whether to charge / discharge and the charging / discharging power based on the overall SOC feedback from the BMS). The specific process is as follows.

[0045] Step S11: Data Interaction (BMS—EMS). The BMS uploads the global battery pack status to the EMS at a frequency of 1-5Hz. The global battery pack status includes core parameters and protection commands. Core parameters include total voltage, total current, average SOC, highest / lowest cell voltage, highest / lowest cell temperature, SOH, and fault status (such as "cell voltage overvoltage" or "temperature overheating"). Protection commands include, for example, if the battery status exceeds the safe range, the BMS directly sends constraint commands such as "prohibit charging," "prohibit discharging," and "limit power" to the EMS (e.g., when SOC > 95%, the BMS sends "prohibit charging"; when SOC < 5%, it sends "prohibit discharging").

[0046] Step S12: EMS Decision-Making and Commands (EMS-BMS). Based on the status feedback from the BMS and combined with energy demand, the EMS issues "target constraint commands" to the BMS (not directly controlling individual cells, but limiting the global operating boundary). For example: If the grid requires charging, and the BMS reports a SOC of 60% and no faults, the EMS issues a command to the BMS: "Charging allowed, maximum charging current 50A" (the BMS allocates charging current to each cell based on this constraint to avoid overvoltage in a single cell). For example: If the EMS plans to discharge 100kW, and the BMS reports that "a certain cell temperature has reached 45℃ (safe threshold 50℃)," the EMS issues a command to the BMS: "Limited power discharge, maximum discharge current 80A" (corresponding to 80kW power), and simultaneously triggers the liquid cooler for cooling. For example: If the BMS reports that "SOH has dropped to 80% (retirement threshold 70%)," the EMS will adjust the charging and discharging strategy (such as reducing deep charging and discharging, controlling SOC between 20% and 80%) to extend battery life.

[0047] Step S13: Collaborative fault handling. If the BMS detects a serious fault (such as a sudden drop in cell voltage or a sudden rise in temperature), it will immediately execute an "emergency current cut-off" (disconnect the battery from the PCS) and send an "emergency shutdown" command to the EMS. After receiving the command, the EMS will immediately issue a PCS shutdown command and trigger a fire alarm to prevent battery thermal runaway.

[0048] The charging and discharging efficiency, lifespan, and safety of a battery are strongly correlated with temperature (the optimal operating temperature is typically 25-35℃). A liquid cooler removes heat from the battery through circulating coolant (or provides heating and insulation). The core control principle of the EMS (Electronic Management System) is "on-demand adjustment with minimal energy consumption," and the specific process is as follows:

[0049] Step S21: Temperature data acquisition. The EMS obtains the battery pack's "average temperature", "maximum temperature", and "temperature difference" (if the temperature difference between individual cells is >5℃, temperature equalization is required) through the BMS, and at the same time collects the liquid cooler's "inlet water temperature", "outlet water temperature", and "operating status" (such as standby / cooling / heating).

[0050] Step S22: Temperature Control Decision. The EMS (Electronic Management System) formulates the liquid cooler operating strategy based on the deviation between the "target battery temperature (usually set to 30°C)" and the "actual temperature." For example, a common scenario is as follows:

[0051] Scenario (1): When the battery is charging, it releases heat. The BMS reports an average temperature of 38℃ (8℃ higher than the target). The EMS then sends a message to the liquid chiller: "Cooling mode, water outlet temperature 20℃, flow rate 50L / min".

[0052] Scenario (2): In low-temperature environments (such as winter -5℃), the battery cannot be charged normally. The EMS sends a message to the liquid chiller: "Heating mode, water temperature 40℃, flow rate 30L / min". Once the battery temperature rises to above 15℃, the PCS is allowed to charge.

[0053] Scenario (3): If the temperature difference between individual battery cells is 6°C, the EMS will adjust the liquid cooler’s “local flow distribution” (by controlling the branch valves) to reduce the temperature difference;

[0054] Scenario (4): If the battery temperature is 28℃ (within the target range), the EMS will issue a "standby mode" to avoid the liquid cooler wasting power.

[0055] Step S23: Energy consumption optimization. The EMS will optimize the operation of the liquid chiller in conjunction with the "grid electricity price" (e.g., if the electricity price is low during off-peak hours, the cooling power can be appropriately increased, and the battery temperature can be lowered to 25°C in advance to avoid the liquid chiller running at full load under the high electricity price during peak hours); at the same time, the energy consumption of the liquid chiller will be monitored. If the "cooling capacity / energy consumption ratio" is lower than the threshold (e.g., COP < 3), a maintenance alarm will be triggered (e.g., insufficient coolant, heat exchanger blockage).

[0056] Firefighting equipment is the "last line of defense" for battery safety, including smoke detectors, heat detectors, gas extinguishing systems (such as heptafluoropropane), sprinkler systems, and ventilation systems. The core of EMS's control over these systems is "rapid response and tiered handling," with the specific process as follows:

[0057] Step S31: When the BMS reports a "sudden rise in battery temperature (e.g., a 10°C increase within 10 minutes)" or the smoke detector reports "trace amounts of smoke," it is determined that the system is in the early warning stage (no open flame, only abnormal signs). The EMS then triggers a "Level 1 Early Warning," issuing an audible and visual alarm (e.g., the control room alarm light illuminates) and notifying maintenance personnel. Simultaneously, other equipment is adjusted: a PCS shutdown command is issued (to prevent exacerbated heat generation during charging and discharging), and a liquid chiller "maximum cooling power" command is issued to attempt to reduce temperature and mitigate risk. During this stage, fire-fighting equipment is not activated; only data is monitored. If the temperature / smoke does not subside within 10 minutes, the system is escalated to the "Fire Alarm Stage."

[0058] Step S32: When the temperature sensor reports "temperature reaches 80℃ (ignition threshold)", or the infrared detector detects "local open flame", it is determined that the fire is in the fire alarm stage (fire confirmed, not spreading). The EMS then triggers a "Level 2 fire alarm" and immediately executes the following: 1. Disconnect the battery from the PCS and the power grid (through emergency power cut-off in the BMS and shutdown of the PCS); 2. Start the ventilation system to expel toxic gases; 3. Start the gas extinguishing system (such as heptafluoropropane) to spray extinguishing agent into the battery compartment to suppress combustion. After the extinguishing system is activated, the EMS monitors the "internal temperature" and "smoke concentration" in real time. If the temperature drops below 50℃ within 30 minutes, it is determined that the fire is under control and ventilation is maintained; if the temperature continues to rise, it is upgraded to the "emergency stage".

[0059] Step S33: If gas extinguishing is ineffective and the internal temperature reaches above 150°C, the system is deemed to be in an emergency phase (fire spreading). The EMS triggers a "Level 3 Emergency" and initiates backup fire-fighting measures: 1. Activate the sprinkler system (if it is a waterproof battery pack) to directly cool and extinguish the fire; 2. Send an "emergency disconnection" request to the power grid dispatch center to cut off the connection between the entire energy storage system and the power grid; 3. Send an alarm signal to the fire department (e.g., by pushing location and fire severity information through an IoT platform). At this time, all fire-fighting equipment is activated, and the EMS continuously records data (such as fire time and equipment action sequence) for post-incident tracing and analysis.

[0060] The upper-level management server 2 refers to a higher-level management node located above the EMS, responsible for "overall coordination, global monitoring, strategy optimization, and data aggregation" of single or multiple EMS and their covered energy systems. It does not directly control underlying devices (such as PCS and BMS), but rather achieves cross-regional and cross-scenario energy management goals through interaction with the EMS. Its core role is that of a "global decision-maker and data hub." While the Energy Management System 1 (EMS) typically focuses on managing a single local energy system (such as a microgrid in an industrial park, a power distribution system in a data center, or a regional energy storage power station cluster), the upper-level management server 2 breaks through these "local limitations" and is responsible for: integrating operational data from multiple EMS to form a global energy view; formulating optimization strategies that exceed those of a single EMS (such as cross-regional energy dispatch and network-wide load balancing); connecting to higher-level energy management platforms (such as city-level or national-level energy systems); storing long-term data; generating global reports; and supporting energy decision analysis. In simple terms: EMS is the "regional steward," and the superior management server is the "general steward." The two interact through standardized interfaces to achieve collaboration between "local execution" and "global coordination."

[0061] The upper-level management server 2 does not directly interfere with the underlying control of EMS, but achieves global management through bidirectional interaction of "data uplink + command downlink".

[0062] Data uplink refers to the EMS transmitting information to the upper-level management server. The EMS uploads the operational data of the energy system it manages to the upper-level management server in real time through standardized interfaces (such as MQTT, OPCUA, Modbus-TCP). Core data includes: Status data: equipment operating status (such as whether the PCS is connected to the grid, BMS battery SOC), system fault alarms (such as liquid chiller malfunction); Metering data: real-time power (charging / discharging power), energy consumption statistics (daily / monthly power consumption), renewable energy generation (daily photovoltaic power generation); Environmental data: temperature inside the energy storage compartment, grid voltage / frequency, outdoor solar irradiance (affecting photovoltaic output).

[0063] Downlink commands are issued by the upper-level management server to the EMS. Based on the global optimization goal (e.g., "when the entire network is under peak load, call all energy storage EMS to discharge"), the upper-level management server generates scheduling commands and issues them to each EMS. The EMS then breaks down the commands into control signals for the underlying devices (e.g., setting the discharge power of the PCS). Common command types include: Power commands: such as "a certain energy storage EMS needs to increase its discharge power to 500kW within 15 minutes to participate in grid frequency regulation"; Mode commands: such as "a certain microgrid EMS switches to 'grid-connected mode' to prioritize the consumption of local photovoltaic power, with surplus power fed into the grid"; Threshold commands: such as "setting the lower limit of the energy storage SOC of a certain EMS to 20% (to avoid over-discharge), which can be temporarily lowered to 15% when the entire network is short of power"; Planning commands: such as "a certain industrial EMS needs to reduce its load to 80% from 8:00 to 10:00 the next day (peak period of the grid) to implement off-peak power consumption".

[0064] When the upper-level management server 2 issues commands, it will respect the local safety constraints of the EMS (such as the upper limit of battery temperature of the BMS and the power rating of the PCS) to avoid conflicts between "global optimization" and "local safety". For example, the upper-level management server requires a certain energy storage EMS to discharge at full power (1000kW), but the EMS reports that "the current battery SOC is only 18% (below the safety lower limit of 20%)". In this case, the upper-level management server will adjust the command (such as reducing the discharge power to 500kW) or call on other energy storage EMS to supplement the output.

[0065] For ease of understanding, Table 1 below provides an example of the types of slave devices, communication interfaces, communication protocols, and uplink and downlink data items that EMS must be compatible with.

[0066] Table 1 lists the types, interfaces, protocols, and data items of the slave devices.

[0067]

[0068] like Figure 2 The flowchart in this application illustrates a method for managing protocol conversion in an EMS system, comprising the following steps:

[0069] Step S001: Establish a P2P communication connection with the slave device according to the physical link parameters of the configured slave device's communication interface, and receive the raw data sent by the slave device;

[0070] Step S002: Read the device data in the original data according to the data read / write rules corresponding to the communication protocol configured by the slave device, and store the device data into the device data storage unit;

[0071] Step S003: Convert the device data in the device data storage unit into internal data, and store the internal data into the internal data storage unit;

[0072] Step S004: Establish a data mapping relationship between the internal data and the device data. When uploading the slave device data according to the data mapping relationship, call the internal data.

[0073] It should be noted that although step numbers S01, S02, S03, S11, S12, S13, S21, S22, S23, S31, S32, S33, S001, S002, S003, etc. are used in this application, these numbers are merely designations for the steps and do not limit the order in which the steps are run or executed. For example, in some embodiments, different steps can be executed simultaneously; for instance, steps S31, S32, and S33 are executed in parallel. Or, in some embodiments, the order of different steps can be interchanged; for instance, step S33 may be executed first, followed by step S32 or S31. Similarly, the step numbers appearing below are merely designations for the steps and do not limit the order in which the steps are run or executed.

[0074] In this application, the energy storage management system 100 adopts a three-layer decoupled design of "interface layer - protocol layer - data layer" to adapt to the differences of different slave devices. The interface layer shields the differences in physical connections, manages the physical connection with the slave devices, and unifies the transmit and receive interfaces.

[0075] In step S001, the basic communication data format for P2P communication (peer-to-peer, P2P, also known as peer-to-peer interconnection network technology) is first established. For example, the basic communication data format described in some embodiments is shown in Table 2 below. ID is an identity identifier, which is a globally unique identity identifier configured by the slave device. In this application, each slave device is assigned a globally unique identity identifier, and the identity identifier is included in the original data, the device data, and the internal data. driver_Name is the driver name, describing the object being communicated. driverType is the device type. driverIndex is the index among devices of the same type. modbusMapId is the address mapping of the device during Modbus communication, used by external devices to distinguish different devices when reading device information from P2P through ModbusTCP or ModbusRTU. In actual P2P communication with the sub-devices below, the slave address is 1 by default. ModbusTCP distinguishes different devices through IP. Under ModbusRTU, each device corresponds to a serial port and does not form a bus. serverOrClient is the enabled end type, acting as a server or client. The server handles read data requests to P2P, while the client reads data from external devices via P2P. `channelType` is the communication type, such as Modbus, Zoe, or CAN. `protocolType` is the protocol type. `dataPollTime` is the data polling time. `commmPollTime` is the communication polling time. `commmIntervalTime` is the communication interval. `timeOut` is the communication timeout. `insideDataSize` is the length of the device's internal data. `deviceDataSize` is the length of the device data processed by P2P. `sort` is the sorting order, e.g., sorted as 1. `status` is the status, e.g., 1 for enabled, 2 for disabled. `version` is the version. `remark` is a comment, which can be empty.

[0076] Table 2 shows examples of basic communication data formats for P2P communication.

[0077]

[0078] The above basic communication data format is the foundation of P2P communication. Next, configure the physical link parameters of the communication interfaces of each slave device. For example, the data format of the TCP and UDP physical link parameters can be found in Table 3. Here, ID is the globally unique identifier configured for the slave device, driverId is the driver number to which the slave device belongs, channelName is the channel name, selfIP is the channel IP, selfPort is the channel port, targetIp is the target IP, targetPort is the target port, and Remark is a remark.

[0079] Table 3 shows the data format of the physical link parameters for TCP and UDP.

[0080]

[0081] For example, the data format of the physical link parameters of the serial port can be found in Table 4. Here, driverId is the driver number of the slave device; channelName is the channel name; serialPort is the type of serial port device; baudrate is the baud rate; dataBits are the data bits; stopBits are the stop bits; parity is the parity bit; flowcontrol is the flow control; and remark is the remark information.

[0082] Table 4 shows the data format of the physical link parameters of the serial port.

[0083]

[0084] For example, the data format of the physical link parameters of the CAN interface can be found in Table 4. Here, driverId is the driver number to which the slave device belongs; channelName is the channel name; Baudrate is the CAN speed; canPort is the CAN device port; and Remark is a note, which can be empty.

[0085] Table 5 shows the data format of the physical link parameters for the CAN interface.

[0086]

[0087] After configuring the basic communication data format for P2P communication and the physical link parameters of the communication interfaces of each slave device, the EMS device can establish a P2P communication connection with the slave device based on the constructed basic communication data format for P2P communication and the physical link parameters configured based on the communication interfaces of the slave device, and receive the raw data sent by the slave device.

[0088] See Figure 3The diagram illustrates the data flow of the EMS system. A software-implemented P2P communication module 8 is set up in the interface layer, including configured RS485, Ethernet, and CAN interface channels. This module establishes a P2P communication connection with the slave device based on the physical link parameters of the slave device's communication interface and receives raw data sent by the slave device. The raw data is data sent by the slave device (e.g., PCS, BMS, liquid cooling equipment, fire-fighting equipment, air conditioning, etc.) acting as the P2P communication server, using a basic communication data format.

[0089] This model ensures that when adding new interface types (such as the LoRa wireless interface in the future), only new implementation classes and configuration parsing logic need to be added, without modifying the core factory code. Through the above design, the interface layer can adapt to diverse hardware such as the BMS CAN bus and PCS Ethernet, and provide a stable and unified data flow entry point for upper-layer protocol conversion, which is the foundation for achieving "interface-protocol-data" decoupling.

[0090] In step S002, the protocol layer, based on the protocol type configured in the slave device, calls the decoding method of the corresponding protocol parser to parse the received raw data into standard device data according to protocol rules (such as frame structure, checksum, field offset, etc.) and write it into the device data storage unit. The protocol layer, acting as the "translator" between the interface layer and internal data, plays a crucial role in eliminating format differences between different device protocols, enabling bidirectional conversion between the raw data of the slave device and the device data within the EMS. In this step, "data read / write rules" are defined for different protocols (e.g., ModBus / ZOE / CAN), clarifying "which register to read, which frame to write, and how to poll" during P2P interaction with the slave device; this is the core logical carrier of protocol conversion.

[0091] For example, in some embodiments, read / write register rules for the ModBusTCP / RTU protocol can be defined, applicable to ModBus devices such as PCS and liquid chillers. For instance, Table 6 below defines a device data table for the Modbus protocol, used for reading and writing relevant registers when P2P communicates with external devices via Modbus (modbusTCP / modbusRTU). `driverId` is the driver number of the slave device; `name` is the tag name of the device data; `cmd` is the Modbus command; `slaveAddr` is the Modbus slave address; `regAddr` is the register address; `reglen` is the number of registers; `dataOffset` is the internal data offset address; `sort` is the sorting. `status` is the status, for example, 1 represents enabled, 2 represents disabled. `remark` is the remark information. `pollType` is the polling type, such as timed trigger. Register operations are divided into read and write. Reading registers is generally timed triggering, using polling. Writing registers is generally refresh triggering, sending a value to the device when it changes. For example, 0 is refresh triggering, and 1 is timed triggering.

[0092] Table 6 is the device data table for the Modbus protocol.

[0093]

[0094] For example, in some embodiments, read / write rules for the ZOE internal protocol can be defined, applicable to UDP communication between P2P and internal processes (EMU (Energy Management Unit) / ECU (Energy Control Unit)). For example, a device data table for the ZOE protocol can be defined for reading and writing data from other functional modules during UDP communication between P2P and internal processes. See Table 7 below for the data read / write rules for the ZOE protocol. `driverId` is the driver number of the slave device. `name` is the name of the data tag. `targetType` is the target device type, such as `emu` or `ecu`. `targetIndex` is the target device index, i.e., the number within the same type of device. `cmd` is the operation function code of the ZOE internal protocol. `regAddr` is the starting address of the internal data pool. `regLen` is the data length (number of bytes). `dataOffset` is the internal data offset address. `sort` is the data sorting. `status` is the status, for example, 1 for enabled, 2 for disabled. `remark` is a remark. `pollType` is the polling type, 0 for refresh trigger, 1 for timed trigger.

[0095] Table 7 is the device data table for the Zoe protocol.

[0096]

[0097] For example, frame read / write rules for the CAN protocol can be defined, applicable to CAN devices such as liquid chillers and TMS. For example, a device data table for the CAN protocol can be defined, as shown in Table 8 below, used for reading and writing related registers during P2P CAN communication with external devices. `driverId` is the driver number of the slave device. `name` is the name of the data tag. `canId` is the ID of the CAN data frame. `rW` is the read / write identifier; 1 indicates read, 2 indicates write. `dataOffset` is the address offset in the device's data storage unit. `dataLen` is the data length in the device's data storage unit. `sort` is the sorting, for example, data ranked 1st, 2nd, 3rd, 4th, etc. `status` is status information, such as enabled or disabled. `remark` is remark information. `pollType` is the polling type; for example, 0 for refresh triggering and 1 for timed triggering.

[0098] Table 8 is the device data table for the CAN protocol.

[0099]

[0100] In the protocol layer, the device data in the original data can be read according to the communication protocol configured for the slave device and the data read / write rules corresponding to the communication protocol (see the device data table defining each protocol), and then the device data is stored in the device data storage unit according to the constructed data conversion parameter list.

[0101] The device-to-parameter list is used to store the read device data in a unified format into the device data storage unit. For example, the device-to-parameter list is defined as shown in Table 9 below, where driverId is the driver number of the slave device. name is the name of the data tag. sessionType is the data segment type, for example, 1 is internal data (Zoe device data table), and 2 is external data (P2P organized device data table, temporarily storing read and write data). directionType is the direction type, for example, 1 is data to parameter (Zoe device data table - P2P device data table), and 2 is parameter to data (P2P device data table - Zoe device data table). address is the address of the parameter point in the data table, calculated in bytes. bit is the starting bit of the parameter point in the data address byte. bitLen is the number of bits occupied by the parameter point. dataValue is the data value. dataType is the data type, for example, BIT, U8, U16, U32, U64, I16, I32, I64. dataOffset is the data offset value. precision is the resolution. unit is the bit length. orderType is the byte order type. `sort` sorts the data, for example, sorting it into 1, 2, 3, etc. `status` indicates the status, for example, 1 for enabled, 0 for disabled. `remark` provides comments, which can be omitted.

[0102] Table 9 defines the data format for storing the equipment transfer parameter list.

[0103]

[0104] See Figure 3 The device data acquisition module 9 in the EMS is used to read device data from the original data according to the data read / write rules (e.g., device data tables for Modbus, Zoe, and CAN protocols) corresponding to the communication protocol configured for the slave device (e.g., ModBusTCP / RTU, UDP, CAN). It then stores the device data in the device data storage unit 10 based on the data format defined in the device parameter list. Through this design, the protocol layer can accurately parse different information included in the original data, such as CANopen frames from the BMS and Modbus messages from the PCS, and output standardized device data to the upper layer through a unified interface, laying the foundation for subsequent centralized data management.

[0105] In step S003, the device data in the device data storage unit is converted into internal data through data transformation (e.g., parameter conversion, parameter matching, standardization, etc.). Table 10 shows examples of data transformation for different devices to aid understanding.

[0106] Table 10 lists examples of rules for data transformation of device data for different devices.

[0107]

[0108] See Figure 3 The data conversion unit 11 is used to convert the device data in the device data storage unit 10 into internal data, such as parameter conversion and / or parameter matching, and store the internal data in the internal data storage unit 12. The data conversion in this application includes at least one of the following data standardization processes: verification (e.g., range verification, CRC verification, format verification), cleaning (e.g., filtering outliers, deduplication), completion (e.g., filling in timestamps, device IDs, missing data completion), parameter matching, parameter calculation, unit normalization, semantic consistency, and precision standardization, to ensure that the data conforms to general specifications. The processed data enters the internal data storage unit 12 through a data flow pipeline, and is stored according to device ID and data type for use by management modules such as the PCS management module 15, BMS management module 16, liquid chiller management module 17, and fire equipment management module 18 in the device management layer 14 of the EMS system.

[0109] The data transformation described in this application includes at least one of the following data processing methods.

[0110] (1) Range verification, which is to determine whether the data value is within a reasonable range based on the device parameter threshold (loaded from the configuration file). For example, BMS battery voltage: reasonable range 0~500V (if it exceeds the range, it is marked as invalid); liquid cooler temperature: reasonable range -20~80℃ (if it is below -20℃, it is judged as a sensor fault); PCS active power: reasonable range -1000~1000kW (negative sign indicates charging, positive sign indicates discharging).

[0111] (2) CRC check: If the protocol layer has not completed the CRC check (such as some proprietary protocols), the data layer needs to recalculate the CRC value of the original data and compare it with the check bit in the protocol frame. For example, in a proprietary protocol for fire protection equipment: the CRC field in the original data (such as the last 2 bytes of the frame) is read, the CRC of the data field is recalculated and compared, and if they do not match, it is marked as "check failed".

[0112] (3) Format validation, such as whether the required fields of device data (ID, name, dataValue, etc.) exist and whether the data types match. For example, if the dataValue of the BMS's soc data is a string type (it should be float), mark it as "format error". For example, if driverId is empty, add a default value.

[0113] (4) Outlier filtering, for example, using the “3σ principle” (data exceeding the mean ± 3 times the standard deviation under normal distribution is judged as outlier) or the “sliding window threshold” (the difference from the previous N data exceeds the threshold and is filtered). For example, BMS cell voltage: if the voltage of a certain cell is 2V lower than the mean (exceeding the 3σ range), it is judged as outlier and the previous valid value is used as a substitute.

[0114] (5) Deduplication of duplicate data. For example, if data with the same ID of the same device appears repeatedly within a short period of time (such as within 100ms), only the first record is retained to avoid data redundancy. For example, if a liquid chiller reports the inlet water temperature (25℃) three times in 1 second, only the first data is retained and the timestamp is updated to the latest.

[0115] (6) Complete missing data. For example, if data is not updated within a timeout period (e.g., the configured collection period is 1 second, and no new data is available after 3 seconds), use "linear interpolation" or "forward filling" to fill in the missing data to avoid data loss. For example, if fire equipment fails to report its status for 5 seconds due to network fluctuations, use the previous valid status ("normal") as a temporary substitute and mark it as "timeout completion". For example, for data with "missing fields or inconsistent formats", ensure the integrity of internal data. For example, fill in required fields. If the device type driverType is missing, supplement it by associating it with the driver name driverName in the device configuration. For example, if driverName="1#BMS", associate it with deviceType="BMS" in the configuration. For example, complete units. If the unit field is empty, supplement it with the name in the data storage format. For example, if name="inlet_temperature", complete unit="℃".

[0116] (7) Parameter matching: This is used to handle the conversion between internal data and device data, where multiple bits of data are converted to a single bit. It achieves accurate data mapping through conditional judgment, ensuring the consistency between the internal data of the EMS system and the external data of the slave device. For example, device data may use 1 byte (8 bits) to store fault flags (such as a bit representing "overvoltage" and a bit representing "undervoltage"), while the internal EMS system only needs 1 bit to identify "overvoltage status". For example, the internal status needs to be triggered based on the "range" or "specific value" of the external data (such as when the external temperature data is -10~0℃, the internal system triggers the "low temperature warning" status). Parameter matching refers to establishing a logical mapping relationship between the multi-bit device data (such as fault flag bytes, status words, etc.) output by the external slave device (such as BMS, PCS, liquid chiller, etc.) and the single-bit internal data (such as status / fault bits, such as internal overvoltage fault flag, standby status bits, etc.) in the internal data storage unit 12 through configurable conditional rules. Essentially, it addresses the compatibility issue between "external multi-bit composite data" and "internal single-bit refined status." By pre-setting matching conditions (such as equal to, greater than, or range), it logically filters device data, writing the results that meet the conditions as fixed values ​​(e.g., 0 = reset, 1 = set) to internal target parameter points, forming internal data. This ensures that the internal system can accurately identify the discrete states of external devices (such as fault, normal, and warning), making it a crucial data conversion step for achieving device status monitoring, fault diagnosis, and command response. In short, parameter matching transforms the complex scenario into a precise "if-else" mapping through conditional matching rules, bridging the logical gap between external multi-bit data and internal single-bit status.

[0117] (8) Parameter operation: Implement arithmetic or logical operations on data (such as addition, subtraction, multiplication, division, multiplication by coefficient, AND operation, OR operation, NOT operation, etc.), and solve problems such as data unit conversion and numerical correction. For example, the meter outputs data in the unit "0.1kWh", while the system needs "kWh". Another example is that the device outputs a 16-bit integer, while the system needs a 32-bit floating-point number. Yet another example is summing three single-phase current data to obtain the total current.

[0118] (9) Unit standardization, i.e., converting units according to EMS specifications (e.g., PCS power from "kW" to "MW", BMS voltage from "mV" to "V").

[0119] (10) Precision calibration, i.e. uniformly retaining the number of decimal places (e.g., temperature retains 1 decimal place, voltage retains 2 decimal places).

[0120] (11) Semantic standardization, that is, mapping the device's private status code to a general description (such as 0x05 in BMS representing "battery overheating").

[0121] The device data storage unit 10 is used to store the device data, and the internal data storage unit 12 is used to store the internal data after data transformation. To ensure the orderliness, security, and traceability of data storage, in some embodiments, a unique device data storage area is allocated to each slave device in the device data storage unit 10, and a unique internal data storage area is allocated to each slave device in the internal data storage unit 12. Through physical or logical storage partitioning isolation, independent management of different device data is achieved, providing basic support for data interaction, protocol conversion, and fault tracing. Each slave device has a globally unique identifier (ID), which serves as the index key for the storage area, ensuring that each partition belongs to only a single device (e.g., ID=1 corresponds to the device storage area and internal storage area of ​​PCS #1). In some embodiments, the capacity of the storage areas in the device data storage unit 10 and / or the internal data storage unit 12 can be dynamically allocated according to the amount of device data. The larger the amount of data of the slave device, the larger the allocated storage space. For example, if a PCS needs to store multiple types of data such as power, voltage, and current, 1200 bytes are allocated; if the fire controller only needs to store alarm status, 100 bytes are allocated, avoiding waste of storage resources.

[0122] In step S004, data mapping is a bidirectional logical association rule. For example, in some embodiments of this application, a data conversion table can be constructed to achieve fast and accurate synchronization of two types of data. Referring to Table 11, `sourceDataId` is the source data ID. When uploaded, it is a device data point (see `sessionType=2` in the data format defined in Table 9, Device to Parameter List); when downloaded, it is an internal control data point (see `sessionType=1` in the data format defined in Table 9, Device to Parameter List). `targetDataId` is the target data ID. When uploaded, it is an internal data point (see `sessionType=1` in the data format defined in Table 9, Device to Parameter List); when downloaded, it is an external device data point (see `sessionType=2` in the data format defined in Table 9, Device to Parameter List). `driverId` is the driver number of the slave device. `name` is the name of the conversion rule. `sort` is the sorting order, such as data ranked 1st, 2nd, 3rd, 4th, etc. `status` is the status information, such as 1 for enabled and 0 for disabled. The remark is a note or comment, such as "external standby address 14257 - internal address 1515", which is used by developers / operations personnel to trace the mapping relationship.

[0123] Table 11 is a data transformation table.

[0124]

[0125] See Figure 3 As shown, the EMS is equipped with a data mapping module 13, which is used to establish a data mapping relationship between the internal data and the device data, and to call the internal data when uploading the slave device data according to the data mapping relationship.

[0126] This application provides a protocol conversion method in an EMS (Electronic Management System). The method establishes a P2P communication connection with the slave device using a configured communication interface and receives raw data. Then, it parses the device data according to the corresponding communication protocol, stores the device data in a device data storage unit, converts the device data into internal data, stores the internal data in an internal data storage unit, establishes a data mapping relationship between the internal data and the device data, and calls the internal data when uploading slave device data based on this data mapping relationship. The protocol conversion method in this application has the following advantages.

[0127] (1) The EMS system has stronger compatibility and can better adapt to different slave devices. By establishing a P2P connection through "configuring the communication interface", there is no need to develop a dedicated driver for each type of device. When adding a new device, only the corresponding interface parameters (such as baud rate, IP address, and protocol type) need to be configured for quick access, which greatly reduces the adaptation threshold for heterogeneous devices. By "parsing the original data according to the corresponding communication protocol" to obtain "device data", and then converting it into "internal data", the "device native protocol" and "EMS internal data format" are decoupled. When adding a device with a different protocol, there is no need to modify the internal core logic; only the parsing module of the corresponding protocol needs to be added.

[0128] (2) Dual storage + mapping relationship to avoid data loss and inconsistency and improve data reliability. By using "layered storage + data mapping", on the one hand, data reliability is enhanced. The device data storage unit saves "original device data after protocol parsing" (such as the original values ​​of inverter output voltage and current) to avoid loss of original data due to internal format conversion, which is convenient for subsequent fault tracing (such as comparing the original data with the converted data to locate protocol parsing problems). The internal data storage unit saves internal data in a unified format to ensure that the format is consistent when EMS modules (such as scheduling, monitoring, and reporting) call data, avoiding data format conflicts caused by "each module adapting to different device protocols". A mapping relationship between "internal data and device data" is established (such as the internal data "energy storage SOC_01" corresponding to the device data "SOC value of energy storage converter") to ensure that when calling internal data, it is possible to trace back to the original device data, avoiding the problem of "internal data being disconnected from the original device data".

[0129] (3) The method can call internal data on demand, reduce real-time scheduling latency, and improve data calling efficiency. The device data only needs to complete "protocol parsing-internal data conversion" when it is received for the first time. When it is uploaded / called later, the stored internal data can be called directly through "data mapping relationship". There is no need to repeatedly parse the original protocol, which greatly reduces the redundant overhead of protocol parsing and reduces the latency of real-time scheduling (according to actual tests, the data calling efficiency can be improved by 30%-50% in this scenario).

[0130] (4) Module decoupling + data traceability reduces troubleshooting costs and improves system maintainability. Maintainability is improved by using "layered modules + data mapping". For example, module decoupling facilitates upgrades, and protocol parsing, data storage, and data retrieval are independent of each other. If the communication protocol of a device is upgraded (e.g., from Modbus-RTU to Modbus-TCP), only the protocol parsing module of the corresponding device needs to be modified, without adjusting the internal data storage and retrieval logic. For example, the data mapping design facilitates fault traceability. When the EMS displays abnormal data (e.g., the internal data "photovoltaic power_02" is abnormally low), the corresponding device data (e.g., "original output power of photovoltaic inverter B") can be quickly located through the mapping relationship. The difference between the two can be compared: if the device data is normal, the problem lies in the "internal data conversion link"; if the device data is abnormal, the problem lies in the "device hardware or communication link", which greatly shortens the troubleshooting time (existing technologies often require checking the protocol, device, and link one by one, and the troubleshooting time can be shortened by more than 50%).

[0131] (5) Supports P2P direct connection expansion, adapts to distributed EMS architecture, and provides better system scalability. The "P2P communication connection" advantage of the above method adapts to distributed architecture, does not rely on a centralized gateway, and the EMS can directly establish P2P connections with distributed slave devices (such as through wireless communication such as 4G / 5G and LoRa), supporting geographically distributed deployment of devices (such as energy storage devices in sub-microgrid A and photovoltaic inverters in sub-microgrid B, which can establish P2P connections with the EMS respectively). When adding distributed devices, only the corresponding P2P interface parameters need to be configured, without modifying the existing centralized gateway, reducing the expansion cost of distributed EMS (existing technologies require upgrading gateway hardware or increasing the number of gateways, resulting in higher expansion costs).

[0132] In some embodiments of this application, the protocol management method in the EMS further includes a downlink data conversion step (e.g., EMS internal data—device data of the slave device):

[0133] Step S005: Receive the generated internal instruction, encapsulate it as instruction internal data, and store it in the internal data storage unit;

[0134] Step S006: According to the data mapping relationship, update the instruction device data in the device data storage unit corresponding to the instruction internal data in the internal data storage unit;

[0135] Step S007: According to the protocol encoding rules corresponding to the communication protocol configured in the slave device, convert the instruction device data into the corresponding raw instruction data that can be recognized by the slave device;

[0136] Step S008: Send the original instruction data to the corresponding slave device according to the P2P communication connection established with the slave device.

[0137] In step S005, the control module of the EMS system (such as remote control and parameter configuration of the upper-level management server 2, and control commands generated internally by the EMS) generates internal commands, encapsulates them into internal command data (see the data format in Table 9), and writes them into the storage area of ​​the internal data storage unit 12.

[0138] In step S006, based on the established data mapping relationship between the internal data and the device data, the instruction device data in the device data storage unit 10 corresponding to the instruction internal data in the internal data storage unit 12 is updated.

[0139] In step S007, the instruction device data is converted into corresponding instruction raw data that can be recognized by the slave control device according to the protocol encoding rules corresponding to the communication protocol configured by the slave control device.

[0140] In step S008, the original instruction data is sent to the corresponding slave device based on the P2P communication connection established with the slave device.

[0141] The protocol management method described above in the EMS achieves a two-way closed loop of "uplink data acquisition - downlink control," improving the integrity of EMS management and control. Simultaneously, the "layered processing + mapping update" of downlink commands ensures the accuracy and traceability of command execution. This closed-loop design associates "uplink-acquired device status" and "downlink-issued control commands" based on the same "data mapping relationship," ensuring that the EMS can accurately issue corresponding control commands (such as stopping discharge or starting charging) based on real-time acquired device data (e.g., low energy storage SOC). This avoids management and control disconnect caused by "inconsistent uplink and downlink protocols," and is particularly suitable for real-time closed-loop control scenarios of EMS for devices.

[0142] In some embodiments of this application, further, an independent storage area is allocated for each slave device (BMS, PCS, liquid chiller, fire-fighting equipment, etc.) in the storage areas of the device data storage unit 10 and the internal data storage unit 12. This design ensures that data from different devices is isolated from each other during the transfer process, avoiding cross-interference, while improving the parallelism and reliability of data processing.

[0143] The Bucketing Algorithm, also known as the Bucket Sort Algorithm, is a strategy that uses space to save time for efficient data classification, storage, and processing. Essentially, it divides continuous or discrete datasets into multiple non-overlapping "buckets" according to predefined rules, ensuring that the data within each bucket has similar characteristics. Differential management (such as priority scheduling, batch processing, and fast querying) is then applied to different buckets to optimize overall data processing efficiency. In EMS (Energy Management System) protocol conversion scenarios, the Bucketing Algorithm can resolve the contradictions between the disorder, high concurrency, and real-time requirements of heterogeneous data from multiple devices (PCS, BMS, liquid cooling systems, etc.), making it one of the core technologies for data buffer management.

[0144] In one embodiment of the protocol conversion method in an EMS in this application, see [link to relevant documentation]. Figure 4 The internal data includes the identity identifier and data priority of the slave device. The management of the internal data in the internal data storage unit 12 adopts a three-level bucket architecture: several first-level storage buckets 19 are created in the internal data storage unit 12 according to the identity identifier of the slave device; priority sub-buckets 20 are divided in each first-level storage bucket 19 according to the data priority; and emergency sub-buckets 21, high priority buckets 22, and ordinary sub-buckets 23 are divided in the priority sub-buckets 20.

[0145] The protocol conversion method in EMS further includes the following steps:

[0146] Step S004001: The internal data is stored in the corresponding emergency sub-bucket 21, high priority bucket 22 and normal sub-bucket 23 according to the identity identifier and the data priority, respectively;

[0147] Step S004002: During data processing, prioritize processing the data in the urgent sub-bucket 21, and then process the data in the high-priority bucket 22 and the normal sub-bucket 23 in sequence.

[0148] In the above embodiments, primary storage buckets can be divided according to the ID hash mapping of the slave devices. In this embodiment, primary storage bucket 19 can be, for example, a PCS bucket, BMS bucket, liquid cooling bucket, fire suppression bucket, etc., with one primary storage bucket configured for each slave device. Each primary storage bucket 19 can be further divided into priority sub-buckets (urgent / high / normal), type sub-buckets (telemetry data / status signals / alarm information), time-sensitive sub-buckets (real-time data / minute-level data / hour-level data), etc. Within the priority sub-buckets 20, data is allocated to different priority sub-buckets based on its urgency (e.g., alarm data, normal monitoring data). The emergency bucket stores emergency alarm data from the devices, such as fire alarm signals from fire suppression equipment and battery over-temperature alarms from the BMS. The high-priority bucket stores critical data that needs real-time processing, such as real-time power data from the PCS and SOC status from the BMS. The normal bucket stores non-real-time data, such as historical temperature curves of liquid cooling equipment and equipment operation logs. The urgency or priority can be identified based on protocol fields, such as marking the BMS over-temperature signal as "urgent" and the PCS historical data as "normal".

[0149] By introducing the bucketing algorithm, this method can achieve refined data management, reduce resource competition during large-scale data processing, and ensure the real-time performance of critical data through priority scheduling, thereby improving the overall efficiency and stability of EMS system protocol conversion.

[0150] In some embodiments of this application, regarding the parameter configuration of the buckets, the data capacity, batch processing threshold, and timeout duration of the emergency sub-bucket 21, high-priority bucket 22, and ordinary sub-bucket 23 all increase sequentially. For example, the emergency sub-bucket has a small data capacity (e.g., 50 records), a short timeout duration (100ms), and a batch processing threshold of 40 records to ensure timely processing of emergency signals. The high-priority bucket has a relatively small data capacity (e.g., 200 records), a short timeout duration (500ms), and a batch processing threshold of 160 records, supporting batch processing. The ordinary sub-bucket has a large data capacity (e.g., 1000 records), a long timeout duration (5s), and a batch processing threshold of 800 records, supporting batch processing. The emergency sub-bucket, high-priority bucket, and ordinary sub-bucket trigger batch processing of the data in their respective buckets when the amount of data in the bucket reaches its corresponding batch processing threshold or when the waiting time reaches its corresponding timeout duration.

[0151] In some embodiments, the emergency bucket (e.g., alarms) can be configured for immediate single-item processing, prioritizing thread scheduling so that processing is triggered immediately after data is entered into the bucket, avoiding delays. For example, after BMS "battery overheating" data is entered into the emergency bucket, the EMS alarm module is triggered within 100ms, pushing an audible and visual alarm to the monitoring interface, and simultaneously triggering a cooling command for the liquid cooling equipment. The high-priority bucket (e.g., real-time telemetry) performs near real-time batch processing. When the data in the bucket reaches a "batch threshold" (e.g., 50 records) or a "timeout period" (e.g., 1 second), batch calculation is triggered. For example, when PCS "real-time active power" data is entered into the high-priority bucket, the average power and peak power are calculated in batches every 50 records accumulated or every 1 second of timeout, and the EMS real-time monitoring curve is updated synchronously. The ordinary bucket (e.g., historical data) performs offline batch archiving. When the bucket is full or at a set time (e.g., 10 minutes), the data is compressed and written to the historical database. For example, when liquid cooling equipment "1-hour temperature curve" data is entered into the ordinary bucket, the data is compressed in batches every 10 minutes and written to the EMS historical database for report generation and trend analysis.

[0152] The above embodiments employ a bucketing mechanism and bucket parameter configuration based on different priorities. This can optimize resources, prevent different types of data from competing for system resources, and prioritize the processing of urgent data. It can also improve data processing efficiency by reducing redundant calculations through in-bucket aggregation, thereby improving query efficiency. Furthermore, it can achieve fault isolation, confining abnormal data (such as communication storms) of a single device to its dedicated bucket without affecting other devices. It also offers good scalability, as adding a new device only requires configuring the corresponding bucketing rules without modifying the core processing logic.

[0153] Corresponding to the protocol conversion method in an EMS as described in the above embodiments, other embodiments of this application also provide an EMS device, including: a P2P communication module, used to establish a P2P communication connection with the slave device according to the physical link parameters of the configured slave device's communication interface, and to receive raw data sent by the slave device; a device data acquisition module, used to read device data from the raw data according to the data read / write rules corresponding to the communication protocol configured by the slave device; a device data storage unit, used to store the device data; a data conversion unit, used to convert the device data in the device data storage unit into internal data; an internal data storage unit, used to store the internal data; and a data mapping module, used to establish a data mapping relationship between the internal data and the device data, and to call the internal data when uploading the slave device data according to the data mapping relationship. See the description of the EMS device above; it will not be described in detail here.

[0154] Accordingly, this application also provides a computer device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, it implements the protocol conversion method in EMS described in any of the above embodiments.

[0155] Accordingly, this application also provides a computer-readable storage medium storing a computer program that can be executed by at least one processor to perform the protocol conversion method in EMS as described in any of the above embodiments.

[0156] This application provides a protocol conversion method in EMS, breaking the traditional "interface-protocol-data" binding relationship. It adopts a self-developed software-based protocol conversion scheme, decoupling and abstracting different communication interfaces and protocols. Data and parameter conversion is managed using memory mapping. This method offers stronger compatibility for the EMS system and better adapts to different slave devices. A P2P connection is established by "configuring the communication interface," eliminating the need to develop dedicated drivers for each type of device. When adding a new device, only the corresponding interface parameters (such as baud rate, IP address, and protocol type) need to be configured for quick access, significantly reducing the adaptation threshold for heterogeneous devices. "Device data" is obtained by "parsing the raw data according to the corresponding communication protocol" and then converted into "internal data," achieving decoupling between the "device's native protocol" and the "EMS internal data format." When adding devices with different protocols, no modification to the internal core logic is required; only the corresponding protocol parsing module needs to be added. In addition, it has the following advantages: dual storage + mapping relationship avoids data loss and inconsistency, and improves data reliability; internal data can be called on demand in the method, reducing real-time scheduling latency and improving data calling efficiency; module decoupling + data traceability reduces the cost of troubleshooting and makes the system more maintainable; it supports P2P direct connection expansion, adapts to distributed EMS architecture, and makes the system more scalable.

[0157] The embodiments of this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for protocol conversion in an EMS, characterized by, The method comprises the following steps: configuring a basic communication data format of P2P communication and physical link parameters of a communication interface of each slave device, wherein the basic communication data format of P2P communication comprises an identity, a communication type and a protocol type; each slave device is assigned a globally unique identity; establishing a P2P communication connection with the slave device according to the configured physical link parameters of the communication interface of the slave device, and receiving original data sent by the slave device; reading device data in the original data according to a data read-write rule corresponding to a communication protocol configured by the slave device, and storing the device data into a device data storage unit; performing data conversion on the device data in the device data storage unit, converting the device data into internal data, and storing the internal data into an internal data storage unit; establishing a data mapping relationship between the internal data in the internal data storage unit and the device data in the device data storage unit; synchronizing the device data and the internal data according to the data mapping relationship, and calling corresponding internal data in the internal data storage unit when uploading data of the slave device.

2. The method for protocol conversion in EMS according to claim 1, wherein, The identity is included in the original data, the device data and the internal data.

3. The method for protocol conversion in EMS as claimed in claim 1 wherein, The data conversion comprises at least one of checking, cleaning, completing, parameter matching, parameter operation, unit normalization, semantic consistency and precision standardization; The parameter operation can realize arithmetic or logical operation of data; The parameter matching can realize conversion of multiple bit data into 1 bit data.

4. The method for protocol conversion in EMS as claimed in claim 1 wherein, A unique device data storage area is allocated for each slave device in the device data storage unit, and a unique internal data storage area is allocated for each slave device in the internal data storage unit; the larger the data volume of the slave device is, the larger the allocated storage space is.

5. The method for protocol conversion in EMS as claimed in claim 1 wherein, The method further comprises the following steps: receiving generated internal instructions, packaging the internal instructions into instruction internal data, and storing the instruction internal data into the internal data storage unit; updating instruction device data in the device data storage unit corresponding to the instruction internal data in the internal data storage unit according to the data mapping relationship; converting the instruction device data into instruction original data recognizable by the corresponding slave device according to a protocol encoding rule corresponding to the communication protocol configured by the slave device; downloading the instruction original data to the corresponding slave device through the established P2P communication connection with the slave device.

6. The EMS protocol conversion method according to claim 1, wherein the internal data comprises an identity of a slave device and a data priority; a three-level bucket architecture is adopted: a plurality of first-level storage buckets are created in the internal data storage unit according to the identity of the slave device; and a priority sub-bucket is divided in each first-level storage bucket according to the data priority; an emergency sub-bucket, a high-priority bucket and a normal sub-bucket are divided in the priority sub-bucket; the method further comprises the following steps: the internal data is stored into the corresponding emergency sub-bucket, high-priority bucket and normal sub-bucket according to the identity and the data priority. In data processing, data in the emergency sub-barrel is processed first, and then data in the high-priority barrel and the ordinary sub-barrel is processed in turn.

7. The method for protocol conversion in EMS according to claim 6, wherein, The data capacity, batch processing threshold and timeout duration of the emergency sub-barrel, the high-priority barrel and the ordinary sub-barrel increase in turn. The batch processing of data in the barrel is triggered when the data amount in the barrel reaches the batch processing threshold corresponding to the barrel or the waiting processing duration reaches the timeout duration corresponding to the barrel.

8. An EMS device, characterized by Comprise: A parameter configuration module is configured to configure the basic communication data format of P2P communication and the physical link parameters of the communication interface of each slave device, wherein the basic communication data format of P2P communication includes identity, communication type and protocol type; each slave device is assigned a globally unique identity; A P2P communication module is configured to establish a P2P communication connection with the slave device according to the configured physical link parameters of the communication interface of the slave device, and receive raw data sent by the slave device; A device data acquisition module is configured to read device data in the raw data according to the data read / write rules corresponding to the communication protocol configured by the slave device; A device data storage unit is configured to store the device data; A data conversion unit is configured to convert the device data in the device data storage unit into internal data; An internal data storage unit is configured to store the internal data; A data mapping module is configured to establish a data mapping relationship between the internal data in the internal data storage unit and the device data in the device data storage unit, and is configured to synchronize the device data and the internal data according to the data mapping relationship, and to call the corresponding internal data in the internal data storage unit when uploading data of the slave device.

9. A computer device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, The computer program is executed by the processor to realize the EMS protocol conversion method in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer readable storage medium stores a computer program, which can be executed by at least one processor to make the at least one processor execute the EMS protocol conversion method in any one of claims 1 to 7.

Images