A device state analysis method based on a multi-level data architecture

Abstract

The application discloses a device state analysis method based on a multi-level data architecture, and relates to the technical field of big data analysis.The method comprises the following steps: collecting device state data from a production control area of an electrochemical energy storage power station; performing protocol analysis, standardized conversion and measurement point mapping on the device state data in a management information area of the electrochemical energy storage power station to generate time sequence measurement point data; unidirectionally transmitting the time sequence measurement point data to a non-control area of the electrochemical energy storage power station through a forward isolation device; writing the time sequence measurement point data into a Kafka cluster for message buffering, and storing the time sequence measurement point data into a TDengine time sequence database by a consumer program; based on a configuration algorithm tool provided by an algorithm platform, performing algorithm modeling and instantiation on the time sequence measurement point data to generate a device state analysis algorithm; and executing an instance of the device state analysis algorithm through an algorithm center to output a device state analysis result.The application can accurately analyze the device state.

Description

Technical Field

[0001] This application relates to the field of big data analytics, and in particular to a device status analysis method based on a multi-level data architecture. Background Technology

[0002] In the field of equipment condition monitoring in electrochemical energy storage power stations, traditional methods face three prominent challenges. First, the heterogeneous communication protocols between equipment and sensors within the station lead to poor data acquisition compatibility and high parsing costs. Second, power systems require physical isolation between production control areas and management information areas, and cross-regional data transmission must meet the compliance requirement of "one-way security," posing security risks to traditional through-transmission methods. Third, electrochemical energy storage power stations generate tens of thousands of time-series data points per second, which traditional relational databases struggle to support for high-concurrency writing and real-time analysis, resulting in data accumulation and query delays, failing to meet the needs for real-time equipment condition early warning and accurate analysis. Summary of the Invention

[0003] The main objective of this application is to propose a device status analysis method and related equipment based on a multi-level data architecture, so as to be compatible with multiple protocols, ensure cross-regional security, and realize efficient processing and intelligent analysis of massive device time-series data.

[0004] To achieve the above objectives, one aspect of this application proposes a device status analysis method based on a multi-level data architecture, the method comprising the following steps:

[0005] Equipment status data is collected from the production control area of ​​the electrochemical energy storage power station using a preset communication protocol;

[0006] In the management information area of ​​the electrochemical energy storage power station, the equipment status data is parsed, standardized, and mapped to measurement points to generate time-series measurement point data in a unified format.

[0007] The time-series measurement data is transmitted unidirectionally to the non-control area of ​​the electrochemical energy storage power station through a positive isolation device;

[0008] In the non-control area, the time series measurement point data is written to the Kafka cluster for message buffering, and the consumer program stores the time series measurement point data in the TDengine time series database.

[0009] Based on the configuration algorithm tools provided by the algorithm platform, the stored time-series measurement point data is modeled and instantiated to generate an equipment status analysis algorithm.

[0010] The algorithm center schedules and executes instances of the device status analysis algorithm, outputting the device status analysis results.

[0011] In some embodiments, the step of collecting equipment status data from the production control area of ​​the electrochemical energy storage power station via a preset communication protocol includes the following steps:

[0012] The 104 protocol is used to collect remote signaling and telemetry data from station control equipment, and the ASDU type is parsed to extract the time stamp, data value and quality bit.

[0013] Data from device-level sensors is acquired using the Modbus protocol, and register values ​​are converted into standardized measurement point data through a register mapping table.

[0014] The remote signaling data, the telemetry data, and the standardized measurement point data are time-stamped and their quality is verified to achieve time consistency and effectiveness.

[0015] In some embodiments, the configuration algorithm tool provided by the algorithm platform performs algorithm modeling and instantiation on the stored time-series measurement point data to generate a device status analysis algorithm, including the following steps:

[0016] The algorithm flow is constructed by dragging and dropping using an algorithm modeling tool, and the algorithm model is obtained by taking the measurement model, equipment technical parameter model, maintenance test data model and calculation index model as inputs.

[0017] Configure the output node of the algorithm model, and set whether the results are displayed and persisted, and whether multiple indicators are output;

[0018] The algorithm model is instantiated into specific power plants and energy storage subsystems, and associated with actual measurement point data to obtain the equipment status analysis algorithm.

[0019] In some embodiments, before referencing the measurement model, equipment technical parameter model, maintenance test data model, and calculation index model as input, the method further includes the following steps:

[0020] Construct the measurement model to associate the same performance index measurement points of different power plants or energy storage subsystems;

[0021] A technical parameter model for the equipment is constructed to provide technical parameters for the instantiation of the equipment status analysis algorithm; wherein, the technical parameters include the rated capacity and rated power of the power station;

[0022] Construct the maintenance and testing data model to input the equipment status data collected during the maintenance and testing process;

[0023] The calculation index model is constructed to store the equipment status analysis results and reuse them in subsequent algorithms.

[0024] In some embodiments, the step of scheduling and executing the device status analysis algorithm through the algorithm center and outputting the device status analysis results includes the following steps:

[0025] Register and publish the device status analysis algorithm in the algorithm center to enable algorithm query, document management and uninstallation;

[0026] The device status analysis results are obtained by executing the device status analysis algorithm through scheduled tasks at set time periods.

[0027] In some embodiments, the method further includes the following steps:

[0028] Deploy machine learning models to the algorithm platform to call the corresponding models by algorithm name, power plant abbreviation, and unit number;

[0029] The mechanism algorithm code is integrated into the algorithm platform so that the configuration algorithm operator can be called through the interface and the input parameters are encapsulated.

[0030] An integrated result parsing utility class is incorporated into the algorithm platform to encapsulate the algorithm output in a unified format and persist it for storage.

[0031] In some embodiments, the method further includes the following steps:

[0032] The monitoring data from the EMS, PCS, transformer substation system, and battery system of the electrochemical energy storage power station are received and transmitted in a standardized manner.

[0033] The collected data is cleaned, and abnormal data is identified and processed; wherein, the abnormal data includes exceeding limits, jumps, and unchanged bits after reaching a set time.

[0034] The measurement data of the electrochemical energy storage power station is obtained through the data platform interface and used in conjunction with the pre-built time-series database data source.

[0035] To achieve the above objectives, another aspect of this application proposes a device status analysis apparatus based on a multi-level data architecture, the apparatus comprising:

[0036] The data acquisition unit is used to collect equipment status data from the production control area of ​​the electrochemical energy storage power station through a preset communication protocol;

[0037] The data preprocessing unit is used to perform protocol parsing, standardization conversion, and measurement point mapping on the equipment status data in the management information area of ​​the electrochemical energy storage power station to generate time-series measurement point data in a unified format.

[0038] The data transmission unit is used to transmit the time-series measurement data unidirectionally to the non-control area of ​​the electrochemical energy storage power station through a forward isolation device;

[0039] The data storage unit is used to write the time series measurement point data into the Kafka cluster for message buffering in the non-control area, and the consumer program stores the time series measurement point data into the TDengine time series database.

[0040] The algorithm generation unit is used to perform algorithm modeling and instantiation on the stored time-series measurement point data based on the configuration algorithm tools provided by the algorithm platform, and generate equipment status analysis algorithms.

[0041] The equipment analysis unit is used to schedule and execute instances of the equipment status analysis algorithm through the algorithm center, and output the equipment status analysis results.

[0042] To achieve the above objectives, another aspect of this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described method.

[0043] To achieve the above objectives, another aspect of the embodiments of this application proposes a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0044] To achieve the above objectives, another aspect of this application provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0045] The embodiments of this application include at least the following beneficial effects:

[0046] This application provides a device status analysis method based on a multi-level data architecture. The method involves collecting device status data from the production control area of ​​an electrochemical energy storage power station via a pre-defined communication protocol; performing protocol parsing, standardization conversion, and measurement point mapping on the device status data in the management information area of ​​the electrochemical energy storage power station to generate time-series measurement point data in a unified format; transmitting the time-series measurement point data unidirectionally to the non-control area of ​​the electrochemical energy storage power station via a forward isolation device; writing the time-series measurement point data into a Kafka cluster for message buffering in the non-control area, and having the consumer program store the time-series measurement point data in the TDengine time-series database; using the configuration algorithm tools provided by the algorithm platform, performing algorithm modeling and instantiation on the stored time-series measurement point data to generate a device status analysis algorithm; and executing instances of the device status analysis algorithm through the algorithm center to output the device status analysis results. This application achieves unified access and secure cross-regional transmission of heterogeneous device data by parsing multiple protocols; it supports high-concurrency buffering and efficient storage of massive time-series data by utilizing Kafka and TDengine clusters; and it provides flexible and configurable device status analysis capabilities by combining a configuration algorithm platform and algorithm center, thereby comprehensively improving the real-time performance, security, and intelligent analysis level of electrochemical energy storage power station equipment status monitoring. Attached Figure Description

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

[0048] Figure 1 A flowchart illustrating a device status analysis method based on a multi-level data architecture, provided in an embodiment of this application;

[0049] Figure 2 Example diagram of the application architecture provided in the embodiments of this application;

[0050] Figure 3 Example diagrams of the technical components provided in the embodiments of this application;

[0051] Figure 4 Example diagram of the algorithm platform provided in the embodiments of this application;

[0052] Figure 5 A flowchart illustrating the analog quantity algorithm provided in the embodiments of this application;

[0053] Figure 6 Example diagram of the algorithm registration and release process provided in the embodiments of this application;

[0054] Figure 7Example diagram of the algorithm scheduling process provided in the embodiments of this application;

[0055] Figure 8 Example diagram of a device analysis algorithm flow provided for an embodiment of this application;

[0056] Figure 9 Example diagrams of algorithm metrics provided in embodiments of this application;

[0057] Figure 10 Example diagrams illustrating the calculation methods of the various algorithms provided in the embodiments of this application;

[0058] Figure 11 A schematic diagram of the structure of a device status analysis device based on a multi-level data architecture provided in this application embodiment;

[0059] Figure 12 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0060] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit it. In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with those of this application; they are merely examples of apparatuses and methods consistent with some aspects of the embodiments of this application as detailed in the appended claims.

[0061] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0062] This application provides a device status analysis method and related equipment based on a multi-level data architecture, relating to the field of big data analytics. The device status analysis method and related equipment based on a multi-level data architecture provided in this application can be applied to terminals, servers, or software running on terminals or servers. In some embodiments, the terminal can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, or in-vehicle terminal, but is not limited to these. The server can be configured as an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The server can also be a node server in a blockchain network. The software can be an application implementing a device status analysis method based on a multi-level data architecture, but is not limited to the above forms.

[0063] This application can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics devices, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0064] Reference Figure 1 This application provides a device status analysis method based on a multi-level data architecture. This method may include, but is not limited to, steps S100 to S150, as follows:

[0065] S100: Collects equipment status data from the production control area of ​​the electrochemical energy storage power station through a preset communication protocol;

[0066] S110: In the management information area of ​​the electrochemical energy storage power station, the equipment status data is parsed according to protocol, standardized and converted, and the measurement points are mapped to generate time-series measurement point data in a unified format;

[0067] S120: The time-series measurement data is transmitted unidirectionally to the non-control area of ​​the electrochemical energy storage power station through a forward isolation device;

[0068] S130: In the non-control area, the time series measurement point data is written into the Kafka cluster for message buffering, and the consumer program stores the time series measurement point data into the TDengine time series database.

[0069] S140: Based on the configuration algorithm tools provided by the algorithm platform, perform algorithm modeling and instantiation on the stored time-series measurement point data to generate an equipment status analysis algorithm;

[0070] S150: Execute an instance of the device status analysis algorithm through the algorithm center, and output the device status analysis results.

[0071] Optionally, the step of collecting equipment status data from the production control area of ​​the electrochemical energy storage power station via a preset communication protocol includes the following steps:

[0072] The 104 protocol is used to collect remote signaling and telemetry data from station control equipment, and the ASDU type is parsed to extract the time stamp, data value and quality bit.

[0073] Data from device-level sensors is acquired using the Modbus protocol, and register values ​​are converted into standardized measurement point data through a register mapping table.

[0074] The remote signaling data, the telemetry data, and the standardized measurement point data are time-stamped and their quality is verified to achieve time consistency and effectiveness.

[0075] Optionally, the configuration algorithm tool provided by the algorithm platform performs algorithm modeling and instantiation on the stored time-series measurement point data to generate a device status analysis algorithm, including the following steps:

[0076] The algorithm flow is constructed by dragging and dropping using an algorithm modeling tool, and the algorithm model is obtained by taking the measurement model, equipment technical parameter model, maintenance test data model and calculation index model as inputs.

[0077] Configure the output node of the algorithm model, and set whether the results are displayed and persisted, and whether multiple indicators are output;

[0078] The algorithm model is instantiated into specific power plants and energy storage subsystems, and associated with actual measurement point data to obtain the equipment status analysis algorithm.

[0079] Optionally, before using the measurement model, equipment technical parameter model, maintenance test data model, and calculation index model as input, the method further includes the following steps:

[0080] Construct the measurement model to associate the same performance index measurement points of different power plants or energy storage subsystems;

[0081] A technical parameter model for the equipment is constructed to provide technical parameters for the instantiation of the equipment status analysis algorithm; wherein, the technical parameters include the rated capacity and rated power of the power station;

[0082] Construct the maintenance and testing data model to input the equipment status data collected during the maintenance and testing process;

[0083] The calculation index model is constructed to store the equipment status analysis results and reuse them in subsequent algorithms.

[0084] Optionally, the step of scheduling and executing instances of the device status analysis algorithm through the algorithm center and outputting device status analysis results includes the following steps:

[0085] Register and publish the device status analysis algorithm in the algorithm center to enable algorithm query, document management and uninstallation;

[0086] The device status analysis results are obtained by executing the device status analysis algorithm through scheduled tasks at set time periods.

[0087] Optionally, the method further includes the following steps:

[0088] Deploy machine learning models to the algorithm platform to call the corresponding models by algorithm name, power plant abbreviation, and unit number;

[0089] The mechanism algorithm code is integrated into the algorithm platform so that the configuration algorithm operator can be called through the interface and the input parameters are encapsulated.

[0090] An integrated result parsing utility class is incorporated into the algorithm platform to encapsulate the algorithm output in a unified format and persist it for storage.

[0091] Optionally, the method further includes the following steps:

[0092] The monitoring data from the EMS, PCS, transformer substation system, and battery system of the electrochemical energy storage power station are received and transmitted in a standardized manner.

[0093] The collected data is cleaned, and abnormal data is identified and processed; wherein, the abnormal data includes exceeding limits, jumps, and unchanged bits after reaching a set time.

[0094] The measurement data of the electrochemical energy storage power station is obtained through the data platform interface and used in conjunction with the pre-built time-series database data source.

[0095] The following sections will provide a detailed description and explanation of some optional embodiments of this application, using specific application examples.

[0096] Specifically, this embodiment includes three parts: data flow architecture, algorithm design, and other algorithms.

[0097] The first part, the data flow architecture, is described as follows:

[0098] I. Overview of the overall data flow.

[0099] The data acquisition and processing flow of an electrochemical energy storage power station involves collecting remote signaling (status quantities, such as switch open / close status and protection action signals) and telemetry (analog quantities, such as voltage, current, temperature, and SOC) data from equipment / subsystems (e.g., Battery Management System (BMS), Energy Management System (EMS), environmental monitoring, and fire protection systems) in Zone I (production control area) of the power plant. This data is then processed by the integrated processing unit in Zone II (management information area) to perform multi-protocol (primarily IEC104 and Modbus) parsing, data standardization, and security filtering. Afterward, it is transmitted securely across security zones via a forward isolation device (gateway) to Zone III (non-control / information area). The data is then parsed and processed by the acquisition program in Zone III, enters the data lake at the power plant site, and is forwarded to the main station. The main station's Kafka cluster then performs high-concurrency message buffering, and finally, the main station's consumer program writes the data to the TDengine time-series database cluster, achieving efficient storage and real-time analysis of massive amounts of time-series data.

[0100] The core of this embodiment's architecture lies in: resolving compatibility issues for heterogeneous device data access through precise parsing of the 104 protocol (the mainstream protocol at the station control layer) and the Modbus protocol (the mainstream protocol at the device layer); addressing compliance issues for power production data transmission across security zones through multi-level collaborative processing and security isolation mechanisms; and resolving the performance conflict between real-time consumption of massive time-series data and high-concurrency writing through Kafka buffering and TDengine optimized storage.

[0101] II. Detailed data flow steps and the role of architectural components.

[0102] 1. Zone I (Production Control Zone) – Data Source Layer and Protocol Acquisition Layer.

[0103] 1.1 Data source and type.

[0104] Data sources include BMS (cell / cluster voltage, temperature, SOC), EMS (power dispatch, equipment status), environmental sensors (temperature, humidity, smoke), and fire protection systems (alarm signals), etc., and the data is divided into two categories:

[0105] Remote signaling (status quantities): discrete quantities such as switch open / closed status (0 / 1), protection action (such as overcurrent trip), and alarm signal (such as temperature over-limit);

[0106] Telemetry (analog quantities): Continuous quantities such as voltage (V), current (A), temperature (°C), SOC (%), power (kW), etc., usually with accuracy requirements (e.g., voltage is retained to 3 decimal places).

[0107] 1.2 Mainstream communication protocols and their parsing technologies

[0108] (1) IEC 60870-5-104 protocol (hereinafter referred to as 104 protocol) - the core protocol of the station control layer.

[0109] Application scenarios: Used in station control layer equipment (such as EMS master station, BMS centralized management module, substation protection device, etc.), it is the standard protocol for power system telecontrol, supporting high reliability, long distance, and standardized data transmission.

[0110] Protocol characteristics: Based on TCP / IP, employing a client-server model, transmitting data via ASDU (Application Service Data Unit), and key information object types include:

[0111] Remote signaling: M_DP_NA_1 (single-point remote signaling), M_DP_TB_1 (time-stamped two-point remote signaling, such as switch state change event SOE).

[0112] Telemetry: M_ME_NA_1 (analog quantity), M_ME_TF_1 (time-stamped short floating-point analog quantity, such as voltage / temperature, IEEE 754 format);

[0113] Cumulative amount: M_IT_NA_1 (e.g., battery power).

[0114] Analysis of key technical points:

[0115] Connection Management: The data collector acts as a 104 client, establishing a long-lived TCP connection with the station control equipment, supporting automatic reconnection after disconnection (recovery in less than 1 second).

[0116] ASDU Decoding: Parse key ASDU types (such as M_DP_TB_1 for SOE events, M_ME_TF_1 for time-stamped analog quantities), and extract information object address, time stamp (CP56Time2a format), data value (such as floating-point voltage), and quality bits (validity / over-range flags).

[0117] Time stamp synchronization: Data is synchronized with the station clock through the 7-byte time stamp embedded in ASDU (accurate to milliseconds), ensuring the accuracy of the Sequence of Events (SOE);

[0118] Verification mechanism: The integrity of the data frame is verified by checking the check field (the sum of all bytes of ASDU) and the end symbol, with an error rate of <0.001%.

[0119] Function: Accurately collect key status data (such as switch on / off) and high-precision analog quantities (such as battery voltage) of station control equipment, providing the system with time-stamped, highly reliable "golden data".

[0120] (2) Modbus protocol (RTU / TCP, TCP is commonly used) - a general protocol for the device layer.

[0121] Application scenarios: Used in equipment layers such as sensors (temperature / humidity), PLCs, smart meters, DC power supplies, and fire alarm control panels. It features lightweight, open and universal design, and easy deployment, making it the mainstream choice for third-party device access.

[0122] Protocol features: Based on a master-slave model, the master station (data collector) reads the slave station's registers via function codes.

[0123] Commonly used function codes:

[0124] 03 (Read Holding Registers): Read analog values ​​(such as 4-byte floating-point voltage / temperature, or 2-byte integer values);

[0125] 01 (Read Coils) / 02 (Read Discrete Inputs): Read switch inputs / remote signals (such as relay status, alarm signals);

[0126] 04 (Read Input Registers): Reads analog signals of input register type.

[0127] Transmission mode: Commonly used Modbus TCP (Ethernet), supporting parallel polling of multiple devices.

[0128] Analysis of key technical points:

[0129] Register mapping: Define the mapping relationship of "physical register address → measurement point ID → data type (floating point / integer) → unit → upper and lower limits" through the configuration file (e.g., register 40001 → measurement point "BMS_001_voltage" → float → unit V → range 0~5V).

[0130] Function code response parsing: Parse the returned data based on the function code (e.g., function code 03 returns a 4-byte floating-point value, which needs to be converted according to IEEE 754 format);

[0131] Robustness mechanisms: Supports CRC check (RTU mode), timeout retransmission (TCP mode), and slave disconnection detection (heartbeat packet) to ensure continuous data collection.

[0132] Function: It can flexibly connect to non-standard or third-party equipment at the equipment layer, cover sensor data in the "last mile" (such as battery cluster temperature and ambient smoke), and supplement the monitoring dimensions not covered by the station control layer.

[0133] 2. Zone II (Management Information Zone) – Comprehensive Processing and Protocol Adaptation Layer.

[0134] Core function: Perform protocol parsing, standardization conversion, and measurement point mapping on the raw protocol data (104 message / Modbus register value) collected in Zone I, and output time-series measurement point data in a unified format (such as timestamp + measurement point ID + value + quality bit + type) to provide "standardized input" for cross-zone transmission.

[0135] Key technologies:

[0136] 104 Protocol Parsing Engine: Decodes ASDU types (e.g., M_ME_TF_1 → analog quantity, M_DP_TB_1 → SOE remote signaling), extracts timestamps, data values, and quality bits, and converts them into internal models (e.g., {timestamp: 1699340384000, point_id:"DGLB_1278_V001", value: 3.712, quality: 0, type: "analog"}).

[0137] Modbus protocol parsing engine: Based on the register mapping table, it converts function code responses (such as the 4-byte floating-point value of function code 03) into standardized measurement point data (such as {timestamp: 1699340396000, point_id: "DGLB_1278_T001", value: 25.3, quality: 0, type: "temperature"}).

[0138] Data standardization module: unifies the data format of different protocols (such as mapping the "information object address" of 104 and the "register address" of Modbus to a unified "measuring point ID"), and supplements labels such as power station ID and equipment type (such as station: "DGLB", device: "BMS_001").

[0139] Measurement point management: Protocol parameters (such as ASDU type definition of 104 and register mapping table of Modbus) are dynamically maintained through configuration center (such as Nacos), and hot update is supported (without restarting the service).

[0140] Function: Eliminate protocol heterogeneity, transform "raw messages" into "standardized time-series data", and provide a consistent data view for subsequent cross-regional transmission and storage.

[0141] 3. Forward Isolation Device (Gateway) – Secure Cross-City Transmission Layer.

[0142] Core function: As the only unidirectional transmission channel between Zone I / II and Zone III, based on physical or logical unidirectional technology (such as optical disc transfer, proprietary protocol encapsulation), it ensures that data can only flow from the production area to the information area, and strictly prohibits the reverse flow, thus meeting the mandatory requirements of the power industry for "safety zoning and horizontal isolation".

[0143] characteristic:

[0144] Packet encapsulation: Receive standardized data (such as JSON / binary stream) from Zone II and encapsulate it into UDP packets or specific TCP packets (such as fixed header + payload) that conform to the network gateway transmission specifications.

[0145] Security checks: Perform format checks (such as length checks and checksums) and whitelist filtering on transmitted data packets (allowing only data from specific IPs / ports to pass through);

[0146] Transmission reliability: Supports retransmission after disconnection (active request in Zone III) and data encryption (optional AES encryption) to ensure transmission integrity.

[0147] Function: To solve the compliance problem of power production data transmission across security zones and eliminate the risk of control commands being tampered with or illegally transmitted back.

[0148] 4. Zone III (Non-control Zone / Information Zone) – Data Reception and Processing Layer.

[0149] 4.1 Kafka Cluster – A High-Concurrency Message Buffer Layer

[0150] Data reception: After the data packets transmitted by the network gateway are parsed by the III zone monitoring service, they are written to Kafka topics (such as topic_dglb_analog, topic_dglb_status) according to the power station ID + measurement point type (remote signaling / telemetry).

[0151] Architecture optimization:

[0152] Large sites: adopt multiple topics + high-concurrency partitions (8~16, sharded according to test point type), 3-replica mechanism (ISR minimum 2), support small batch high-frequency submission (500 records per batch, 50ms interval) to avoid memory accumulation;

[0153] Small sites: merge partitions (2~4 per site, allocated by site ID hash), enable compression strategies (such as ZSTD), and use large batch low-frequency submissions (2000 records per batch, 200ms interval) to reduce IO overhead.

[0154] Core function: Decouple data production (II zone) from consumption (TDengine write), cope with traffic surges (such as sudden large-scale SOE events), and ensure system stability.

[0155] 4.2 Consumer-side program – Data is written to the TDengine layer.

[0156] Function: Consumes real-time data from a Kafka topic, supplements it with power plant ID and test point label (such as battery cluster number), and then calls the TDengine taos_insert / taos_insert_lines interface to write it to the cluster.

[0157] Optimization strategy:

[0158] Batch commit: Submit every 1000 records or every 100ms to reduce network and disk I / O.

[0159] Exception handling: Failed data is stored in a dead-letter queue, supporting retries and manual intervention;

[0160] Parallel consumption: Multiple consumer groups process different topics in parallel, improving throughput.

[0161] Function: Enables efficient data flow from "message queue" to "time-series database", ensuring real-time performance (second-level latency) and reliability (no data loss).

[0162] 5. TDengine Cluster – A massive time-series data storage and analysis layer.

[0163] Core Functions: A distributed database optimized for time-series data, supporting high-concurrency writing, efficient compression, and fast querying, meeting the dual needs of energy storage power stations for "real-time monitoring + historical analysis".

[0164] Architecture Design:

[0165] Large stations: database sharding and table partitioning (each station has an independent database, with tables partitioned by day), partitioning by device / test point (such as battery cluster), using a super table to manage similar test points (such as all voltage test points sharing the same structure), supporting asynchronous batch writing (10,000 to 20,000 rows per batch) and memory control (adjusting WAL parameters to avoid blocking);

[0166] Small stations: Share a super table (such as battery_data) and distinguish data from different power stations by tags (such as station_id) to reduce storage redundancy.

[0167] Write and query optimization:

[0168] Write: Large sites enable asynchronous batch commit + compression (such as Delta-of-Delta encoding), while small sites use synchronous lightweight write + automatic merging (triggered once every 200ms).

[0169] Query: Pre-calculate hotspot reports (such as daily average voltage) and cache them in Redis, supporting queries for the latest values ​​(LAST_ROW function) and time range retrieval.

[0170] Function: To solve the problem of "high storage cost and slow query of massive time series data (such as millions of measurement points per second)", and support business scenarios such as real-time monitoring (such as SOE alarms) and historical analysis (such as battery degradation trend).

[0171] III. Implementation method for resolving key contradictions in this embodiment.

[0172] Table 1

[0173]

[0174] IV. Key Component Collaboration Relationships (The Hub Role of Protocol Resolution).

[0175] Table 2

[0176]

[0177] V. Conclusion.

[0178] This embodiment's architecture utilizes precise parsing technology of the 104 protocol (station control layer) and Modbus protocol (device layer), combined with multi-level collaborative processing (I-zone acquisition → II-zone parsing → network gateway transmission → Kafka buffering → TDengine storage), to achieve the following:

[0179] Full-scenario coverage of heterogeneous devices (from station control layer to sensors);

[0180] Strict compliance and high security for the transmission of power production data across security zones;

[0181] Efficient storage and real-time consumption of massive time-series data (millions of measurement points per second);

[0182] Standardization and high reliability across the entire data acquisition and analysis chain.

[0183] The second part, the algorithm design explanation, is as follows:

[0184] 1. System architecture design.

[0185] 1.1 System Architecture.

[0186] The system architecture design follows standard management and development specifications, and is divided into three layers: data layer, middleware service layer, and application layer.

[0187] 1) The application layer consists of early warning stations, trend analysis, visualization, etc.

[0188] 2) A unified middleware service, built upon configuration algorithms, enables algorithm development, integration, and sharing. This primarily includes:

[0189] a. Configuration algorithm tools and configuration data management;

[0190] b. Public data management for algorithms, including algorithm center, algorithm registration and release, algorithm uninstallation, algorithm computation tasks, algorithm computation results, algorithm documentation, algorithm interfaces, algorithm standard library, etc.

[0191] 3) The data layer consists of a time-series database, a relational database, and a data platform service for storing the original data of the measurement points.

[0192] 1.2 Application architecture design.

[0193] Reference Figure 2 The application platform integrates various digital applications. Intelligent early warning stations monitor equipment status in real time and issue timely warnings; multi-level drilling and early warning facilitate in-depth analysis of the causes of warnings; data analysis reports are automatically generated, providing data support for decision-making; the equipment status evaluation module and curve query enable assessment of equipment status and formulation of maintenance strategies. All application modules collaborate to improve the intelligence level of equipment status monitoring and operation and maintenance management in electrochemical energy storage power stations.

[0194] 1.2.1 System module design.

[0195] Table 3

[0196]

[0197] 1.2.2 Component Design.

[0198] Microservices and application component division:

[0199] Table 4

[0200]

[0201] 1.3 Network architecture design.

[0202] The system network topology is mainly divided into three areas: Area III, Area IV, and the user access area. Data exchange between these areas is achieved through secure and reliable network connections. Area III deploys microservices using an integrated deployment approach. Area IV deploys proxy services to forward applications from Area III, enabling users to access the system from the office network.

[0203] 1.4 Data Architecture Design.

[0204] The data to be collected and accessed this time is mainly the status monitoring data generated at the production end. These monitoring data are characterized by simple structure, large quantity of unit points, and high transmission frequency. These measured point data are generated by the production monitoring systems supporting EMS, PCS, and BMS. It is estimated that the number of monitoring points is between 40,000 and 50,000.

[0205] The production systems for calculation and docking are shown in Table 5 below:

[0206] Table 5

[0207]

[0208] 1.5 Technical architecture.

[0209] Refer to Figure 3 , the technical components cover multiple levels. The container engine uses docker to package software and its dependencies into containers to achieve isolated operation of programs.

[0210] The program framework adopts Spring - boot to provide a basis for programming and microservice component communication.

[0211] The microservice architecture is supported by Spring Cloud and includes components such as Eureka, Ribbon, Feign, XXL - JOB, etc., to achieve service registration and discovery, load balancing, remote call, and scheduled task scheduling.

[0212] Nacos is selected as the registration and configuration center to manage the registration and configuration information of component services.

[0213] The front - end framework Vue2 is responsible for building the user interaction interface, the message queue Kafka provides reliable communication guarantee, and the web server Nginx proxies the front - end interface to improve access performance.

[0214] 3.7 Data access design.

[0215] Based on the data center uniformly built by the company, standard point tables and interface services are designed and released, integrating 2.84 million measured points of 7 energy storage stations, and data governance work such as default data supplementation, management data entry, and non - standard measured point feature calculation is carried out.

[0216] 3.7.1 Scope of accessed data.

[0217] Data from the operation and maintenance management process is integrated, including defect management, work order management, production indicator management, two-ticket management, and equipment operation management data. Standardized data transmission for power plants is implemented to ensure comprehensive collection of operational status data from battery arrays, BMS, EMS, PCS, fire protection systems, network security, operating environment, and other electrical equipment in electrochemical energy storage power plants. Technical measures are employed to identify and clean abnormal data such as out-of-limit data, jump data, and data that has remained unchanged for extended periods, ensuring data quality. Technical parameter data from key on-site equipment is integrated with the intelligent energy storage digital operation and management platform of the Southern Power Grid Energy Storage Central Control Center.

[0218] 3.7.2 Access data quality.

[0219] Consistency: The fields and values ​​of the data should be consistent with the definitions and values ​​of the access system.

[0220] Completeness: All production data from each access system should be connected to the data center and the storage structure should be formulated according to the sorting rules of the original system. Backup data measurement points in the original system should also be transmitted and stored.

[0221] Real-time performance: The time delay of the latest data point in the database after data access should be less than 5 seconds.

[0222] Time stamps: The time stamps for switch quantities in each system should use the millisecond-level time stamps of the computer monitoring system itself. The time stamps for general call and analog data should, as far as possible, use the millisecond-level time stamps of the computer monitoring system itself. If the data source system does not technically support this, the data aggregation server of the plant can use the second-level time stamps, but it should be ensured that the time deviation between the server responsible for the time stamps and the computer monitoring system is less than 1 second.

[0223] Storage: Switch data should be stored in a database at the millisecond level. Data at the second level, millisecond level, and the original data in the database should be stored for more than 5 years.

[0224] 2. Algorithm platform design.

[0225] 2.1 Overall functional design.

[0226] The algorithm platform provides a platform for algorithm development, integration, and sharing. It includes algorithm configuration tools to support low-code development of time-series data analysis algorithms; standardized algorithm interfaces to ensure unified algorithm invocation; a persistence module responsible for storing algorithm calculation results; and an algorithm management service to manage the entire lifecycle of algorithms, including registration, deployment, and uninstallation.

[0227] A unified scheduling mechanism ensures the efficient operation of the algorithm and provides a standardized algorithm calling interface for external systems.

[0228] Reference Figure 4The platform constructs a centralized, standardized, and reusable algorithm model middleware, realizing a closed-loop end-to-end solution from algorithm access, management, scheduling to service provision. It supports multiple algorithm types, possesses complete lifecycle management capabilities, and enhances usability and execution efficiency through visualization tools and a scheduling engine. It is suitable for enterprise-level AI platforms or industrial intelligent systems.

[0229] 2.1.1 Algorithm modeling.

[0230] Through no-code configuration of energy storage station equipment operation data analysis algorithms, including scenarios such as key analog quantity analysis under different charging and discharging states, the algorithm configuration tool has the following characteristics:

[0231] The algorithm configuration tool has drawing tools and an interface that graphically represents various elements of the algorithm, and can quickly build algorithms through simple drag-and-drop and configuration.

[0232] It supports hyperparameter configuration, allowing algorithm instances to specify specific parameters during operation through external configuration, without having to specify them during algorithm configuration;

[0233] It supports the function of generating multiple indicator results simultaneously with a single algorithm, and can ensure automatic alignment and adjustment of time scales between different technical indicators;

[0234] It supports algorithm persistence. The system automatically performs data persistence work on a regular basis according to user configuration requirements. The algorithm results data are stored in the database for a long time for easy secondary query and use.

[0235] It has a high adaptability to algorithms and can efficiently and horizontally synchronize and unify the algorithms of different subsystems, battery arrays, and battery clusters.

[0236] (1) Switching quantity algorithm.

[0237] In energy storage power stations, switch data is primarily used to represent the status of equipment, such as charging and discharging states. The main algorithms for processing this type of data include:

[0238] Status monitoring: Real-time monitoring of the status changes of switch quantities. For example, when a switch changes from closed to open, the corresponding alarm or processing procedure is immediately triggered.

[0239] Logical judgment: Based on the combination of switch states, logical judgments are performed to determine the operating status or control flow of the equipment. For example, based on the states of multiple switches, it can be determined whether a system is in the startup condition.

[0240] Timing analysis: Analyze the timing relationship of changes in switch status to assess the operating sequence of the equipment or the order in which faults occur.

[0241] Duration Analysis: By calculating the duration of switching signals, the trend of device opening and closing duration can be analyzed. At the same time, a threshold range for the duration can be set to generate early warning information for the device.

[0242] (2) Analog quantity algorithm.

[0243] Analog data in energy storage power stations is mainly used to represent continuously changing physical quantities, such as temperature, pressure, flow rate, voltage, and current. The main algorithms for processing this type of data include:

[0244] Threshold judgment: Set a reasonable threshold range to judge analog data. When the data exceeds or falls below the threshold, trigger the corresponding alarm or processing procedure. For example, when the temperature exceeds the set safety value, start the cooling system.

[0245] Trend analysis: Performing trend analysis on analog data to predict future trends. This helps to identify potential problems early or optimize equipment operation strategies.

[0246] Through reasonable algorithm design and application, functions such as real-time monitoring of power plant operation status, fault prediction and optimized control can be realized, thereby improving the operating efficiency and safety of the power plant.

[0247] Reference Figure 5 The algorithm tool is developed based on a time series data analysis model. The tool designs a set of modular logical operators to extract features from time series data, perform numerical calculations and statistics, and encapsulates the behavior of manual data analysis into multiple standardized computational operation units. These units can be freely combined to realize various types of data analysis scenarios.

[0248] The algorithm tool analysis framework mainly consists of the following modules:

[0249] ① Algorithm editing and drawing tool: This tool allows users to draw algorithm logic in a "drag and drop" manner. The tool compiles the algorithm logic diagram into algorithm information composed of nodes and edges.

[0250] ② Algorithm logic parser: Parses drawing elements into algorithm models and stores them in the algorithm library. This model structure will retain all the information features required for algorithm operation. The parser is also responsible for instantiating the algorithm model into an algorithm task according to the user's instantiation configuration.

[0251] ③ Algorithm logic processor: When an external application accesses the algorithm, the processor is responsible for performing the algorithm task, retrieving database data and calling module functions according to the algorithm interface requirements, and finally outputting two-dimensional structured data.

[0252] ④ Algorithm management tools: These tools are used by users to interact with and manage algorithms, such as creating, deleting, modifying, using, querying, grouping, and configuring them.

[0253] The algorithm output by the algorithm tool is called the "configuration algorithm". In addition to being searchable in the configuration algorithm tool management tool, the configuration algorithm is also registered in the algorithm center to provide services for subsequent digital applications.

[0254] 2.1.1.1 New algorithm added.

[0255] During algorithm modeling, users can quickly build algorithm models through drag-and-drop and configuration, and view the results and effects of the algorithm in real time through a visual interface. This not only improves the efficiency of algorithm development but also lowers the development threshold, enabling more non-professional users to participate in algorithm development.

[0256] Furthermore, algorithm modeling tools also need to provide algorithm testing and verification capabilities. Users can compute algorithm results through computational tasks and observe whether the algorithm's output meets expectations, thereby verifying the algorithm's accuracy and reliability. This step is crucial for algorithm development, ensuring the stability and effectiveness of the algorithm in practical applications. Algorithm development is a vital component in building a highly available and scalable microservice ecosystem. Through the collaborative work of components such as an algorithm center, algorithm registration, algorithm standard library, algorithm persistence, access control, and algorithm modeling tools, we can achieve rapid development, deployment, and operation and maintenance of data analysis algorithms for energy storage power stations, providing strong support for the intelligent transformation of the power industry.

[0257] Algorithm List: View information about algorithms created using the algorithm tool.

[0258] Algorithm modeling: The algorithm modeling process consists of the following steps.

[0259] Enter a quote:

[0260] The algorithm's input references include four types of data: measurement model, equipment technical parameter model, maintenance and test data model, and calculation index model.

[0261] Measurement model: A relational data model established from the original measurement point data.

[0262] Equipment technical parameter model: Equipment technical parameter attributes.

[0263] Maintenance and testing data model: The data model formed by planning and organizing the test data generated during the maintenance and testing process.

[0264] Computational index model: A relational data model established based on the results of algorithmic calculations.

[0265] (1) Algorithm flow construction.

[0266] The process involves breaking down business scenarios, using different operators, and transferring reference data and intermediate result data between operators to form the final target result.

[0267] (2) Output settings.

[0268] During the algorithm's computation, each operator produces different computation results. The final result display of the algorithm is controlled by the output node. This allows control over whether the result is output and displayed, whether it is persisted, and also the setting of the display order and unit of the result.

[0269] 2.1.1.2 Algorithm instantiation.

[0270] After the algorithm is built in the algorithm modeling canvas, the "Synchronize Indicators" function will synchronize the results of the output nodes in the canvas to form model indicators under the current algorithm. At the same time, the "Instantiation" function can create different algorithm instances by selecting specified power plants and energy storage subsystems. In this process, the data models referenced by the input nodes in the algorithm modeling are replaced with associated measurement points or values.

[0271] Instantiate "algorithm instances generated according to power plants, energy storage subsystems, and applicable equipment scope".

[0272] The data details associated with the data model referenced by the input node after the algorithm is instantiated.

[0273] 2.1.1.3 Algorithm calculation.

[0274] By performing computational tasks on algorithm instances, we can test whether the algorithm's logic and output results meet the requirements of the business scenario.

[0275] 2.1.2 Algorithm Center.

[0276] The roles of users in the Algorithm Center are defined as follows:

[0277] Table 6

[0278]

[0279] Figure 6 This describes the algorithm registration and release process.

[0280] Figure 7 This describes the algorithm scheduling process.

[0281] The algorithm center implements basic functions such as algorithm query, algorithm registration, algorithm details, algorithm documentation, quick access to applications, and algorithm uninstallation.

[0282] 2.1.2.1 Algorithm registration.

[0283] To register and publish an algorithm, fill in the relevant form fields required for registration, save the information, and update the status through the publishing function, which will then be displayed in the algorithm center.

[0284] 2.1.2.2 Algorithm Standard Library.

[0285] Implement the management function of the algorithm standard library. Editing the standard library requires the implementation of a custom standard directory tree and support for associating each directory tree node with an algorithm from the algorithm center.

[0286] 2.1.2.3 Algorithm persistence.

[0287] Through the persistent configuration of the algorithm center, the timed task automatically schedules the persistent program of the algorithm and stores the calculation results in the business database.

[0288] 2.1.2.4 Access Control.

[0289] The third-party account configuration enables the creation, deletion, modification, and querying of third-party login accounts, as well as the authorization of specific roles to these accounts.

[0290] The third-party application configuration implements CRUD (Create, Read, Update, Delete) functionality for third-party applications, as well as algorithm permission configuration. If a third-party application needs to integrate the algorithm platform's interface, it needs to add application information, generating a clientid and clientsecret. If it's accessing algorithms, it needs to grant access permissions to the algorithm data.

[0291] 2.1.3 Online service framework for machine learning models.

[0292] 4.1.3.1 Machine learning algorithm model.

[0293] Based on existing requirements, an online runtime environment for machine learning algorithms is proposed, using Python 3.10.14 and installing machine learning platform components such as sklearn and tensorflow.

[0294] Algorithm model file deployment path:

[0295] Specify the deployment file path and file naming rules for each algorithm. Since the algorithms are mainly targeted at generating units, a fixed algorithm model file name is formed by combining the algorithm name, power plant abbreviation, and generating unit number. When the algorithm is called, the algorithm model file name is determined by the parameters and then assembled and passed in to achieve algorithm calling for different power plants and generating units.

[0296] 4.1.3.2 Mechanism Algorithm.

[0297] It provides the ability to deploy and invoke mechanistic algorithms (i.e., local algorithms), integrating the code of these algorithms into the Fluent development component. Through interfaces, it allows users to call configured algorithm operators within the algorithm platform, encapsulate parameters as input parameters for each operator, and schedule tools for parsing and reassembling the returned results after computation. To meet the requirements of algorithm writing standards, scalability, and simplicity, the following capabilities are implemented:

[0298] Input parameter encapsulation:

[0299] Depending on the parameter type, it returns data in various structures. It also provides separate wrapper functions for the input parameters of different operators, allowing the user's algorithm input parameters to generate the input parameter format of the specified operator.

[0300] Result Analysis:

[0301] The returned results are encapsulated in a format consistent with the configuration algorithm, facilitating persistent data storage.

[0302] Utility class encapsulation:

[0303] Provides utility classes for converting data such as time, strings, and arrays.

[0304] 4.1.3.3 System Design.

[0305] Schedule tasks:

[0306] Set up a separate scheduled task to acquire algorithms of the type mechanistic algorithm and machine learning algorithm. Set the time period to five minutes. If the current system time minus the data acquisition time is greater than or equal to the set period (interval time), the execution condition is met, and the current algorithm is scheduled and executed.

[0307] Period settings:

[0308] Selecting the mechanism algorithm or machine learning algorithm provides more granular time period options, with additional intervals including every five minutes, every 10 minutes, every 30 minutes, and every hour.

[0309] Data acquisition time:

[0310] After each scheduled task is completed, the data acquisition time is set to the task execution time. If the data acquisition time + period is less than the current time, execution needs to continue, and the data is padded to the time point closest to the period.

[0311] Algorithm parameters:

[0312] Data acquisition time and task execution time are typically used as input parameters for the current algorithm.

[0313] 4.1.4 Data Model.

[0314] A data model is an abstract representation that describes data, data structure, relationships between data, and how data is manipulated. It is an abstract representation of entities in the real world and their relationships, providing the foundation and framework for data processing, storage, analysis, and application by defining data types, structures, attributes, constraints, etc.

[0315] The selection and design of data models have a significant impact on the performance, maintainability, and scalability of algorithms. Therefore, four data models were designed in the platform.

[0316] 4.1.4.1 Measurement model.

[0317] Measurement models are used to describe the same performance indicators and behaviors across different power plants or energy storage subsystems. These models typically involve classifying various measurement points within the system, enabling efficient use and querying of different power plants and energy storage subsystems within algorithmic tools.

[0318] 4.1.4.1.1 Added a new measurement model.

[0319] The measurement model can be added by clicking the "Add" button in the system. After saving the basic data of the measurement model, the measurement points can be attached to the measurement model by using the "Add" or batch addition function in the details interface.

[0320] 4.1.4.2 Equipment technical parameter model.

[0321] To allow the addition of technical parameters for different power plants and subsystems to the algorithm, such as the rated capacity, rated power, and system manufacturer of the energy storage station, a technical parameter model of the equipment is constructed so that the algorithm automatically substitutes the technical parameter values ​​during instantiation.

[0322] 4.1.4.2.1 Added technical parameter model.

[0323] Add a technical parameter model by clicking the "Add" button in the system. After saving the basic data of the technical parameter model, use the "Import" or "Instantiate" function on the details page to enter the technical parameters.

[0324] 4.1.4.3 Overhaul test data model.

[0325] Maintenance and testing data refers to the data collected and recorded by technical maintenance personnel using various measuring tools and instruments during maintenance and testing. This data is often difficult or unnecessary to collect in real time through sensors, but it reflects the current safety status or performance of the equipment. By constructing a maintenance and testing data model, this data can be entered and formatted for storage, and it is also easy to incorporate into the algorithm development process.

[0326] 4.1.4.3.1 Added maintenance test data model.

[0327] Add a maintenance test model by clicking the "Add" button in the system. After saving the basic data of the maintenance test model, use the "Import" or "Instantiate" function on the details interface to enter the maintenance test data.

[0328] 4.1.4.2.4 Calculation index model.

[0329] Calculated metrics are the results data calculated through algorithms. By constructing a calculated metric model, the data can be reused in the algorithm, achieving the goal of recycling calculated data.

[0330] 4.1.4.4.1 Added a new calculation index model.

[0331] Add a calculation indicator model by clicking the "Add" button in the system. After saving the basic data of the calculation indicator model, use the "Model Indicator" or "Instance Indicator" in the details interface to associate the calculation indicator data.

[0332] 2.2 Algorithm Platform Development.

[0333] 2.2.1 Functional optimization and improvement design and development.

[0334] 2.2.1.1 Algorithm data statistics.

[0335] The existing algorithm platform applications and dashboard data are used to collect and query statistics based on role-based data permissions.

[0336] 2.2.1.2 Data model optimization.

[0337] A data warehouse suitable for large-scale, high-real-time data governance of energy storage stations was developed based on the full dataset of a certain energy storage station. This included data warehouse selection, data model adaptation, data cleaning function development, data quality supervision module development, related interface development, and function deployment. This improved the computational efficiency of downstream computing tasks or applications, and enhanced the accuracy of data analysis and decision support.

[0338] 2.2.2 New feature development and design.

[0339] 2.2.2.1 Measurement model upgrade.

[0340] The current algorithm system uses a plant + energy storage system / battery array approach for abstraction. When the algorithm application requires instantiated measurement points, the model service returns the measurement point code by identifying the device object + model name to complete the instantiation calculation. This approach is not suitable for the algorithm calculation scheme of electrochemical energy storage power stations, nor does it meet the needs of the future development of pumped storage data analysis. Electrochemical energy storage power station data has multi-level and multi-dimensional characteristics, so the following upgrades are made.

[0341] (1) Multi-level.

[0342] In an abstract sense, an electrochemical energy storage power station can be divided into subsystems, battery compartments, battery clusters, and battery cells.

[0343] (2) Multidimensional.

[0344] Analogous to: battery arrays, energy conversion systems (energy management systems, battery management systems), intelligent fire protection systems (cabin-level fire protection systems, fire-fighting air pressure tanks, fire-fighting hydraulic tanks), battery thermal management systems (battery compartment air-cooling systems, battery compartment liquid-cooling systems), and energy storage power distribution systems (AC uninterruptible power supplies, power distribution modules).

[0345] 2.2.2.2 Algorithm tools have been added and upgraded.

[0346] 2.2.2.2.1 Add operators.

[0347] 1. Add a range operator.

[0348] Range of an array. The input supports a variable number of curves, and the output is the set of absolute values ​​of the differences between the maximum and minimum values ​​of the curves in the same time segment. If the curves are of different lengths, align them to the shortest curve.

[0349] 2. Custom company operators.

[0350] Based on the calculation objective and data, input a formula. The formula can be a simple arithmetic operation or a complex combination of functions. For example:

[0351] Variables: Outputs of other operators in the algorithm.

[0352] Operators: Choose appropriate operators, such as addition (+), subtraction (-), multiplication (*), division ( / ), squaring (^), etc.

[0353] Functions: Built-in functions can be used, but are not currently supported.

[0354] For example, you can enter the following in the input box: 1+(variable A*2)-variable B^.

[0355] 2.2.2.2.2 Data integration.

[0356] Add a data interface source for calling the data platform. When the queried measurement point is a measurement point of an electrochemical energy storage power station, call different interfaces depending on whether it is a regular measurement point. The original test power plant measurement points will still use the tdengine data source.

[0357] 2.3 Algorithm Development and Deployment.

[0358] We construct a measurement data model centered on an electrochemical energy storage device model, encompassing real-time production data and business management data such as measurements, algorithms, and indicators, providing comprehensive support in data transmission, fusion, governance, processing, and display.

[0359] 2.3.1 Algorithm design and development.

[0360] 4.3.1.1 Algorithm development function.

[0361] Automatic data source matching: The system automatically matches different data sources (data lake / data warehouse) according to the type of power plant and optimizes the efficiency of data reading and preprocessing.

[0362] Adapted calculation indicators: The system is adapted to the management and configuration functions of electrochemical calculation indicators. After the algorithm calculation is completed, the corresponding equipment type of the calculation indicators will be automatically set according to the data model used by the algorithm and its equipment type.

[0363] New calculation operators: To adapt to electrochemical energy storage data analysis scenarios, three new operators have been added: multi-curve range calculation, curve-customized arithmetic operations, and monotonically increasing / decreasing feature time range retrieval, to support data analysis scenarios.

[0364] Implementation example: Temperature rise monitoring algorithm function: calculate the temperature change rate (°C / min) at the cell / module level; input: real-time temperature sequence T(t), sampling interval Δt; output: temperature rise value ΔT(n)=T(n)-T(n-1); alarm logic: trigger a level 2 alarm when ΔT>5°C / min.

[0365] Figure 8 This is an example of a device analysis algorithm flow.

[0366] 4.3.1.2 Algorithm development code implementation.

[0367] Development layer: Python 3.8 + Java hybrid programming; Interface layer: RESTful API + gRPC dual protocol; Containerization: Docker image encapsulation.

[0368] 4.3.2 Algorithm index design and construction.

[0369] To address the comparative analysis of multiple technical approaches and the needs of daily equipment operation and maintenance, an algorithm requirement list was designed, and more than 15 data analysis configuration algorithm models were designed and constructed, including "Battery Cluster Temperature Cooling Performance Analysis" and "Battery Cluster Charging SOC Change Rate Analysis".

[0370] Algorithm indicator design: Typical algorithms are designed for early warning of battery systems, battery clusters, and individual battery cells. Monitoring is carried out in different dimensions of battery charging, discharging, standby process and the whole life cycle to identify weak batteries and realize fault early warning and comprehensive equipment analysis.

[0371] The algorithm is designed according to the application stage, device, and actual scenario, and three main categories of indicators are designed: basic data indicators, battery performance comparison, and application scenario indicators. Specific indicator design examples are shown below. Figure 9 As shown.

[0372] Examples of the calculation methods for each algorithm are as follows: Figure 10 As shown.

[0373] 2.3.2 Algorithm Deployment.

[0374] Algorithm implementation involves creating the algorithm on the platform, and then running, computing, and storing the algorithm. The main steps are as follows:

[0375] 1. Data Model Implementation: By creating a data model, the association between the measurement points and the model is completed or the basic data related to the model is entered.

[0376] 2. Algorithm Implementation: By introducing a data model into the newly created algorithm model during algorithm modeling, the algorithm can be used in conjunction with measurement point data and other basic data to achieve the purpose of algorithm calculation.

[0377] 3. Algorithm Center: After the algorithm modeling is completed, the algorithm is published to the algorithm center. The timed scheduling control will realize the scheduling of the algorithm and the computation and storage in the relational database.

[0378] 4. Based on the above functions and with the guidance of the bidding party's business experts, complete the parameter configuration of each algorithm and its indicators.

[0379] The third part, other algorithms, are explained below:

[0380] 1. Data Model.

[0381] A data model is an abstract representation that describes data, data structure, relationships between data, and how data is manipulated. It is an abstract representation of entities in the real world and their relationships, providing the foundation and framework for data processing, storage, analysis, and application by defining data types, structures, attributes, constraints, etc.

[0382] The selection and design of data models have a significant impact on the performance, maintainability, and scalability of algorithms. Therefore, four data models were designed in the platform.

[0383] 1.1 Measurement Model.

[0384] Measurement models are used to describe the same performance indicators and behaviors across different power plants or energy storage subsystems. These models typically involve classifying various measurement points within the system, enabling efficient use and querying of different power plants and energy storage subsystems within algorithmic tools.

[0385] 1.1.1 Added a new measurement model.

[0386] The measurement model can be added by clicking the "Add" button in the system. After saving the basic data of the measurement model, the measurement points can be attached to the measurement model by using the "Add" or batch addition function in the details interface.

[0387] 1.2 Equipment technical parameter model.

[0388] To allow the addition of technical parameters for different power plants and subsystems to the algorithm, such as the rated capacity, rated power, and system manufacturer of the energy storage station, a technical parameter model of the equipment is constructed so that the algorithm automatically substitutes the technical parameter values ​​during instantiation.

[0389] 1.2.1 Added a new technical parameter model.

[0390] Add a technical parameter model by clicking the "Add" button in the system. After saving the basic data of the technical parameter model, use the "Import" or "Instantiate" function on the details page to enter the technical parameters.

[0391] 1.3 Overhaul test data model.

[0392] Maintenance and testing data refers to the data collected and recorded by technical maintenance personnel using various measuring tools and instruments during maintenance and testing. This data is often difficult or unnecessary to collect in real time through sensors, but it reflects the current safety status or performance of the equipment. By constructing a maintenance and testing data model, this data can be entered and formatted for storage, and it is also easy to incorporate into the algorithm development process.

[0393] 1.3.1 Added maintenance test data model.

[0394] Add a maintenance test model by clicking the "Add" button in the system. After saving the basic data of the maintenance test model, use the "Import" or "Instantiate" function on the details interface to enter the maintenance test data.

[0395] 1.2.4 Calculation index model.

[0396] Calculated metrics are the results data calculated through algorithms. By constructing a calculated metric model, the data can be reused in the algorithm, achieving the goal of recycling calculated data.

[0397] 1.4.1 Added a new calculation index model.

[0398] Add a calculation indicator model by clicking the "Add" button in the system. After saving the basic data of the calculation indicator model, use the "Model Indicator" or "Instance Indicator" in the details interface to associate the calculation indicator data.

[0399] The beneficial effects of this embodiment include at least the following:

[0400] 1. By using a dual-protocol parsing engine (104 protocol and Modbus protocol) and a forward isolation device, the problems of heterogeneous device access compatibility and cross-security zone data transmission compliance are systematically solved.

[0401] 2. By using the data processing chain of "Kafka buffer + TDengine dedicated database", the performance contradiction between high-concurrency writing of massive time-series data, real-time consumption and long-term efficient storage and query is effectively resolved.

[0402] 3. By organically combining configuration algorithm tools, multi-level data models and algorithm center scheduling mechanisms, a closed-loop platform is provided, from low-code algorithm development and instantiation configuration to task scheduling and result persistence. This significantly reduces the development and application threshold of data analysis algorithms and improves the intelligence level and efficiency of real-time monitoring, intelligent early warning, accurate evaluation and operation and maintenance decision-making for electrochemical energy storage power station equipment status.

[0403] Reference Figure 11 This application also provides a device status analysis apparatus based on a multi-level data architecture, which can implement the above-mentioned device status analysis method based on a multi-level data architecture. The apparatus includes:

[0404] The data acquisition unit is used to collect equipment status data from the production control area of ​​the electrochemical energy storage power station through a preset communication protocol;

[0405] The data preprocessing unit is used to perform protocol parsing, standardization conversion, and measurement point mapping on the equipment status data in the management information area of ​​the electrochemical energy storage power station to generate time-series measurement point data in a unified format.

[0406] The data transmission unit is used to transmit the time-series measurement data unidirectionally to the non-control area of ​​the electrochemical energy storage power station through a forward isolation device;

[0407] The data storage unit is used to write the time series measurement point data into the Kafka cluster for message buffering in the non-control area, and the consumer program stores the time series measurement point data into the TDengine time series database.

[0408] The algorithm generation unit is used to perform algorithm modeling and instantiation on the stored time-series measurement point data based on the configuration algorithm tools provided by the algorithm platform, and generate equipment status analysis algorithms.

[0409] The equipment analysis unit is used to schedule and execute instances of the equipment status analysis algorithm through the algorithm center, and output the equipment status analysis results.

[0410] It is understood that the content of the above method embodiments is applicable to the present device embodiments. The specific functions implemented by the present device embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0411] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the method of this application. This electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.

[0412] It is understood that the content of the above method embodiments is applicable to the device embodiments. The specific functions implemented by the device embodiments are the same as those of the methods of this application, and the beneficial effects achieved are the same as those achieved by the methods of this application.

[0413] Figure 12 The hardware structure of an electronic device according to another embodiment is illustrated. The electronic device includes:

[0414] The processor 101 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application.

[0415] The memory 102 can be implemented as a read-only memory (ROM), static storage device, dynamic storage device, or random access memory (RAM). The memory 102 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 102 and is called and executed by the processor 101.

[0416] Input / output interface 103 is used to implement information input and output;

[0417] The communication interface 104 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0418] Bus 105 transmits information between various components of the device (e.g., processor 101, memory 102, input / output interface 103, and communication interface 104);

[0419] The processor 101, memory 102, input / output interface 103 and communication interface 104 are connected to each other within the device via bus 105.

[0420] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method of this application.

[0421] It is understood that the content of the above method embodiments is applicable to this storage medium embodiment. The specific functions implemented in this storage medium embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0422] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0423] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0424] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0425] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0426] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0427] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0428] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0429] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

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

[0431] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0432] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0433] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0434] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A device status analysis method based on a multi-level data architecture, characterized in that, The method includes the following steps: Equipment status data is collected from the production control area of ​​the electrochemical energy storage power station using a preset communication protocol; In the management information area of ​​the electrochemical energy storage power station, the equipment status data is parsed, standardized, and mapped to measurement points to generate time-series measurement point data in a unified format. The time-series measurement data is transmitted unidirectionally to the non-control area of ​​the electrochemical energy storage power station through a positive isolation device; In the non-control area, the time series measurement point data is written to the Kafka cluster for message buffering, and the consumer program stores the time series measurement point data in the TDengine time series database. Based on the configuration algorithm tools provided by the algorithm platform, the stored time-series measurement point data is modeled and instantiated to generate an equipment status analysis algorithm. The algorithm center schedules and executes instances of the device status analysis algorithm, outputting the device status analysis results. The configuration algorithm tool provided by the algorithm platform performs algorithm modeling and instantiation on the stored time-series measurement point data to generate a device status analysis algorithm, including the following steps: The algorithm flow is constructed by dragging and dropping using an algorithm modeling tool, and the algorithm model is obtained by taking the measurement model, equipment technical parameter model, maintenance test data model and calculation index model as inputs. Configure the output node of the algorithm model, and set whether the results are displayed and persisted, and whether multiple indicators are output; The algorithm model is instantiated into specific power plants and energy storage subsystems, and the time-series measurement data is associated to obtain the equipment status analysis algorithm. Before using the measurement model, equipment technical parameter model, maintenance test data model, and calculation index model as input, the method further includes the following steps: Construct the measurement model to associate the same performance index measurement points of different power plants or energy storage subsystems; A technical parameter model for the equipment is constructed to provide technical parameters for the instantiation of the equipment status analysis algorithm; wherein, the technical parameters include the rated capacity and rated power of the power station; Construct the maintenance and testing data model to input the equipment status data collected during the maintenance and testing process; The calculation index model is constructed to store the equipment status analysis results and reuse them in subsequent algorithms.

2. The device status analysis method based on a multi-level data architecture according to claim 1, characterized in that, The process of collecting equipment status data from the production control area of ​​the electrochemical energy storage power station via a preset communication protocol includes the following steps: The 104 protocol is used to collect remote signaling and telemetry data from station control equipment, and the ASDU type is parsed to extract the time stamp, data value and quality bit. Data from device-level sensors is acquired using the Modbus protocol, and register values ​​are converted into standardized measurement point data through a register mapping table. The remote signaling data, the telemetry data, and the standardized measurement point data are time-stamped and their quality is verified to achieve time consistency and validity.

3. The device status analysis method based on a multi-level data architecture according to claim 1, characterized in that, The execution of the device status analysis algorithm through the algorithm center, and the output of the device status analysis results, includes the following steps: Register and publish the device status analysis algorithm in the algorithm center to enable algorithm query, document management and uninstallation; The device status analysis results are obtained by executing the device status analysis algorithm through scheduled tasks at set time periods.

4. The device status analysis method based on a multi-level data architecture according to claim 1, characterized in that, The method further includes the following steps: Deploy machine learning models to the algorithm platform to call the corresponding models by algorithm name, power plant abbreviation, and unit number; The mechanism algorithm code is integrated into the algorithm platform so that the configuration algorithm operator can be called through the interface and the input parameters are encapsulated. An integrated result parsing utility class is incorporated into the algorithm platform to encapsulate the algorithm output in a unified format and persist it for storage.

5. A device status analysis method based on a multi-level data architecture according to any one of claims 1 to 4, characterized in that, The method further includes the following steps: The monitoring data from the EMS, PCS, transformer substation system, and battery system of the electrochemical energy storage power station are received and transmitted in a standardized manner. The collected data is cleaned, and abnormal data is identified and processed; wherein, the abnormal data includes exceeding limits, jumps, and unchanged bits after reaching a set time. The measurement data of the electrochemical energy storage power station is obtained through the data platform interface and used in conjunction with the pre-built time-series database data source.

6. A device status analysis apparatus based on a multi-level data architecture, characterized in that, The apparatus is used to implement the device status analysis method based on a multi-level data architecture as described in claim 1, the apparatus comprising: The data acquisition unit is used to collect equipment status data from the production control area of ​​the electrochemical energy storage power station through a preset communication protocol; The data preprocessing unit is used to perform protocol parsing, standardization conversion, and measurement point mapping on the equipment status data in the management information area of ​​the electrochemical energy storage power station to generate time-series measurement point data in a unified format. The data transmission unit is used to transmit the time-series measurement data unidirectionally to the non-control area of ​​the electrochemical energy storage power station through a forward isolation device; The data storage unit is used to write the time series measurement point data into the Kafka cluster for message buffering in the non-control area, and the consumer program stores the time series measurement point data into the TDengine time series database. The algorithm generation unit is used to perform algorithm modeling and instantiation on the stored time-series measurement point data based on the configuration algorithm tools provided by the algorithm platform, and generate equipment status analysis algorithms. The equipment analysis unit is used to schedule and execute instances of the equipment status analysis algorithm through the algorithm center, and output the equipment status analysis results.

7. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the method as described in any one of claims 1 to 5.

8. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 5.

Images