Equipment state analysis method based on multi-level data architecture

Abstract

The invention discloses an equipment state analysis method based on a multistage data architecture, and relates to the technical field of big data analysis, and the method comprises the steps: collecting equipment state data from a production control region of an electrochemical energy storage power station; performing protocol analysis, standardized conversion and measuring point mapping on the equipment state data in the management information large area of the electrochemical energy storage power station to generate time sequence measuring point data; transmitting time sequence measuring point data to a non-control area of the electrochemical energy storage power station in a one-way manner through a forward isolation device; the time sequence measuring point data are written into a Kafka cluster for message buffering in the non-control area, and the time sequence measuring point data are stored in a TD engine time sequence database by a consumption end program; based on a configuration algorithm tool provided by an algorithm platform, algorithm modeling and instantiation are carried out on the time sequence measuring point data, and an equipment state analysis algorithm is generated; and scheduling and executing an instance of the equipment state analysis algorithm through the algorithm center, and outputting an equipment state analysis result. The equipment state can be accurately analyzed.

Description

A device status analysis method based on a multi-level data architecture 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 includes the following steps: collecting device status data from the production control area of ​​an electrochemical energy storage power station via a preset 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; unidirectionally transmitting the time-series measurement point data 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; performing algorithm modeling and instantiation on the stored time-series measurement point data based on the configuration algorithm tools provided by the algorithm platform to generate a device status analysis algorithm; and scheduling and executing instances of the device status analysis algorithm through an algorithm center to output the device status analysis results.

[0005] In some embodiments, the process of collecting equipment status data from the production control area of ​​an electrochemical energy storage power station via a preset communication protocol includes the following steps: using the 104 protocol to collect remote signaling data and telemetry data from the station control layer equipment, parsing the ASDU type and extracting the time stamp, data value, and quality bit; using the Modbus protocol to collect data from the equipment layer sensors, converting the register values ​​into standardized measurement point data through a register mapping table; and performing time stamp synchronization and quality verification on the remote signaling data, the telemetry data, and the standardized measurement point data to achieve time consistency and validity.

[0006] 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 an equipment status analysis algorithm, including the following steps: constructing the algorithm flow by dragging and dropping using the algorithm modeling tool, referencing the measurement model, equipment technical parameter model, maintenance test data model, and calculation index model as inputs to obtain the algorithm model; configuring the output nodes of the algorithm model, setting whether the results are displayed and persisted, and whether multiple indicators are output; instantiating the algorithm model into algorithm instances of specific power plants and energy storage subsystems, associating them with actual measurement point data to obtain the equipment status analysis algorithm.

[0007] 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: constructing the measurement model to associate the same performance index measurement points of different power plants or energy storage subsystems; constructing the equipment technical parameter model to provide technical parameters for the instantiation of the equipment condition analysis algorithm; wherein the technical parameters include the rated capacity and rated power of the power plant; constructing the maintenance test data model to input the equipment condition data collected during the maintenance test; and constructing the calculation index model to store the equipment condition analysis results and reuse them in subsequent algorithms.

[0008] In some embodiments, 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: registering and publishing the device status analysis algorithm in the algorithm center to enable algorithm querying, document management and uninstallation; and executing instances of the device status analysis algorithm by scheduling tasks at a set time period to obtain the device status analysis results.

[0009] In some embodiments, the method further includes the following steps: deploying a machine learning model to the algorithm platform to call the corresponding model by algorithm name, power plant abbreviation and unit number; integrating the mechanism algorithm code to the algorithm platform to call the configuration algorithm operator through the interface and encapsulate the input parameters; and integrating the result parsing utility class to the algorithm platform to encapsulate the algorithm output results into a unified format and persist them for storage.

[0010] In some embodiments, the method further includes the following steps: accessing the monitoring data of the EMS, PCS, transformer substation system and battery system of the electrochemical energy storage power station and uploading them in a standardized manner; cleaning the collected data and identifying and processing abnormal data; wherein, the abnormal data includes exceeding limits, jumps and no change after reaching a set time; obtaining the measurement point data of the electrochemical energy storage power station through the data platform interface and using it in conjunction with a pre-built time series database data source.

[0011] To achieve the above objectives, another aspect of this application proposes a device for analyzing device status based on a multi-level data architecture. The device includes: a data acquisition unit for acquiring device status data from the production control area of ​​an electrochemical energy storage power station via a preset communication protocol; a data preprocessing unit for 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; a data transmission unit for unidirectionally transmitting the time-series measurement point data to the non-control area of ​​the electrochemical energy storage power station via a forward isolation device; a data storage unit for writing the time-series measurement point data into a Kafka cluster for message buffering in the non-control area, and having a consumer program store the time-series measurement point data in a TDengine time-series database; an algorithm generation unit for performing algorithm modeling and instantiation on the stored time-series measurement point data based on configuration algorithm tools provided by an algorithm platform to generate a device status analysis algorithm; and a device analysis unit for scheduling and executing instances of the device status analysis algorithm through an algorithm center and outputting device status analysis results.

[0012] 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.

[0013] 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.

[0014] 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.

[0015] The embodiments of this application include at least the following beneficial effects: This application provides a device status analysis method based on a multi-level data architecture. The solution of this application collects device status data from the production control area of ​​an electrochemical energy storage power station through a preset communication protocol; in the management information area of ​​the electrochemical energy storage power station, the device 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 point data is unidirectionally transmitted to the non-control area of ​​the electrochemical energy storage power station through a forward isolation device; in the non-control area, the time-series measurement point data is written into a 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 a device status analysis algorithm; the instance of the device status analysis algorithm is executed through the algorithm center, and the device status analysis results are output. 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

[0016] 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.

[0017] Figure 1 is a flowchart illustrating a device status analysis method based on a multi-level data architecture provided in an embodiment of this application; Figure 2 is an example diagram of an application architecture provided in an embodiment of this application; Figure 3 is an example diagram of technical components provided in an embodiment of this application; Figure 4 is an example diagram of an algorithm platform provided in an embodiment of this application; Figure 5 is a flowchart illustrating an analog quantity algorithm provided in an embodiment of this application; Figure 6 is an example diagram of an algorithm registration and release process provided in an embodiment of this application; Figure 7 is an example diagram of an algorithm scheduling process provided in an embodiment of this application; Figure 8 is an example diagram of a device analysis algorithm flow provided in an embodiment of this application; Figure 9 is an example diagram of algorithm indicators provided in an embodiment of this application; Figure 10 is an example diagram of the calculation methods of various algorithms provided in an embodiment of this application; Figure 11 is a structural schematic diagram of a device status analysis device based on a multi-level data architecture provided in an embodiment of this application; Figure 12 is a hardware structure schematic diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0018] 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.

[0019] 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.

[0020] 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.

[0021] 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.

[0022] Referring to Figure 1, this application embodiment 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: S100: Collect device status data from the production control area of ​​an electrochemical energy storage power station via a preset communication protocol; S110: Perform 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; S120: Transmit the time-series measurement point data unidirectionally to the non-control area of ​​the electrochemical energy storage power station via a forward isolation device; S130: Write the time-series measurement point data into a Kafka cluster for message buffering in the non-control area, and have the consumer program store the time-series measurement point data in the TDengine time-series database; 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 a device status analysis algorithm; S150: Execute instances of the device status analysis algorithm through algorithm center scheduling, and output the device status analysis results.

[0023] Optionally, the step of collecting equipment status data from the production control area of ​​the electrochemical energy storage power station through a preset communication protocol includes the following steps: using the 104 protocol to collect remote signaling data and telemetry data of the station control layer equipment, parsing the ASDU type and extracting the time stamp, data value and quality bit; using the Modbus protocol to collect data from the equipment layer sensors, converting the register values ​​into standardized measurement point data through a register mapping table; and performing time stamp synchronization and quality verification on the remote signaling data, the telemetry data and the standardized measurement point data to achieve time consistency and validity.

[0024] 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 an equipment status analysis algorithm, including the following steps: constructing the algorithm flow by dragging and dropping using the algorithm modeling tool, referencing the measurement model, equipment technical parameter model, maintenance test data model, and calculation index model as inputs to obtain the algorithm model; configuring the output nodes of the algorithm model, setting whether the results are displayed and persisted, and whether multiple indicators are output; instantiating the algorithm model into algorithm instances of specific power plants and energy storage subsystems, associating them with actual measurement point data to obtain the equipment status analysis algorithm.

[0025] 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: constructing the measurement model to associate the same performance index measurement points of different power plants or energy storage subsystems; constructing the equipment technical parameter model to provide technical parameters for the instantiation of the equipment condition analysis algorithm; wherein, the technical parameters include the rated capacity and rated power of the power plant; constructing the maintenance test data model to input the equipment condition data collected during the maintenance test; and constructing the calculation index model to store the equipment condition analysis results and reuse them in subsequent algorithms.

[0026] 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: registering and publishing the device status analysis algorithm in the algorithm center to enable algorithm query, document management and uninstallation; and executing instances of the device status analysis algorithm by scheduling tasks at a set time period to obtain the device status analysis results.

[0027] Optionally, the method further includes the following steps: deploying machine learning models to the algorithm platform to call the corresponding models by algorithm name, power plant abbreviation, and unit number; integrating mechanism algorithm code to the algorithm platform to call configuration algorithm operators and encapsulate input parameters through an interface; and integrating result parsing utility classes to the algorithm platform to encapsulate the algorithm output results into a unified format and persist them for storage.

[0028] Optionally, the method further includes the following steps: accessing the monitoring data of the EMS, PCS, transformer substation system and battery system of the electrochemical energy storage power station and uploading them in a standardized manner; cleaning the collected data and identifying and processing abnormal data; wherein, the abnormal data includes exceeding limits, jumps and no change after reaching a set time; obtaining the measurement point data of the electrochemical energy storage power station through the data platform interface and using it in conjunction with a pre-built time-series database data source.

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

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

[0031] Part One, the data flow architecture is described as follows: I. Overview of the overall data flow.

[0032] 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.

[0033] 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.

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

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

[0036] 1.1 Data source and type.

[0037] Data sources include BMS (cell / cluster voltage, temperature, SOC), EMS (power dispatch, equipment status), environmental sensors (temperature, humidity, smoke), fire protection system (alarm signals), etc. The data is divided into two categories: remote signaling (status quantities): discrete quantities such as switch open / close status (0 / 1), protection actions (such as overcurrent tripping), alarm signals (such as temperature exceeding limits); and telemetry (analog quantities): continuous quantities such as voltage (V), current (A), temperature (°C), SOC (%), power (kW), etc., usually with accuracy requirements (such as voltage retaining 3 decimal places).

[0038] 1.2 Mainstream communication protocols and their parsing technologies

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

[0040] 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.

[0041] Protocol characteristics: Based on TCP / IP, it adopts a client-server model and transmits data through ASDU (Application Service Data Unit). Key information object types include: 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); 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); Cumulative quantity: M_IT_NA_1 (such as electricity consumption).

[0042] Key technical points: Connection Management: The data acquisition unit acts as a 104 client, establishing a long-lived TCP connection with the station control equipment, supporting automatic reconnection after disconnection (recovery in <1 second); ASDU Decoding: Parsing key ASDU types (such as M_DP_TB_1 for SOE events, M_ME_TF_1 for time-stamped analog quantities), extracting information object address, time stamp (CP56Time2a format), data value (such as floating-point voltage), and quality bits (validity / over-range flag); Time Stamp Synchronization: Synchronizing data with the station clock through the 7-byte time stamp embedded in the ASDU (accurate to milliseconds), ensuring the accuracy of the Sequence of Events (SOE); Verification Mechanism: Verifying data frame integrity through the check field (the sum of all bytes in the ASDU) and the end marker, with an error rate of <0.001%.

[0043] 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".

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

[0045] 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.

[0046] Protocol features: Based on the master-slave model, the master station (data acquisition unit) reads slave station registers through function codes: Common function codes: 03 (Read Holding Registers): Read analog quantities (such as 4-byte floating-point voltage / temperature, or 2-byte integer values); 01 (Read Coils) / 02 (Read Discrete Inputs): Read digital quantities / remote signals (such as relay status, alarm signals); 04 (Read Input Registers): Read analog quantities of input register type.

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

[0048] Key technical points: 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); Function code response parsing: Parse the returned data according to 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); Robustness mechanism: Support CRC check (RTU mode), timeout retransmission (TCP mode), slave disconnection detection (heartbeat packet) to ensure the continuity of data acquisition.

[0049] 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.

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

[0051] 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.

[0052] Key technologies: 104 Protocol Parsing Engine: Decodes ASDU types (e.g., M_ME_TF_1 → analog quantity, M_DP_TB_1 → SOE telemetry), 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"}); Modbus Protocol Parsing Engine: Based on the register mapping table, converts function code responses (e.g., the 4-byte floating-point value of function code 03) into standardized measurement point data (e.g., {timestamp: 1699340396000, point_id: "DGLB_1278_T001", value: 25.3, quality: 0, type: "temperature"}); 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 "measurement point ID"), and supplements labels such as power station ID and device type (such as station: "DGLB", device: "BMS_001"); Measurement point management: dynamically maintains protocol parameters (such as the ASDU type definition of 104 and the register mapping table of Modbus) through a configuration center (such as Nacos), and supports hot updates (without restarting the service).

[0053] 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.

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

[0055] 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".

[0056] Features: Packet encapsulation: Receives standardized data (such as JSON / binary stream) from Zone II and encapsulates it into UDP packets or specific TCP messages (such as fixed header + payload) conforming to the network gateway transmission specifications; Security verification: Performs format verification (such as length verification, checksum) and whitelist filtering on transmitted data packets (only allowing data from specific IPs / ports to pass); Transmission reliability: Supports retransmission after disconnection (actively requested by Zone III) and data encryption (optional AES encryption) to ensure transmission integrity.

[0057] 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.

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

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

[0060] 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).

[0061] Architecture optimization: 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 commits (500 records per batch, 50ms interval) to avoid memory accumulation; Small sites: merge partitions (2~4 per site, distributed by site ID hash), enable compression strategy (such as ZSTD), adopt large batch low-frequency commits (2000 records per batch, 200ms interval) to reduce IO overhead.

[0062] 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.

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

[0064] 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.

[0065] Optimization strategies: Batch submission: Submit once every 1000 records or every 100ms to reduce network and disk I / O; Exception handling: Failed data is stored in a dead letter queue to support retries and manual intervention; Parallel consumption: Multiple consumer groups process different topics in parallel to improve throughput.

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

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

[0068] 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".

[0069] Architecture Design: Large stations: Database sharding and table partitioning (each station has an independent database, with tables partitioned by day), partitioned by device / test point (e.g., battery cluster tags), using a super table to manage similar test points (e.g., all voltage test points share the same structure), supporting asynchronous batch writing (10,000 to 20,000 rows per batch) and memory control (adjusting WAL parameters to avoid blocking); Small stations: Shared super table (e.g., battery_data), using tags (e.g., station_id) to distinguish data from different power stations, reducing storage redundancy.

[0070] Write and query optimizations: Write: Large sites enable asynchronous batch submission + compression (such as Delta-of-Delta encoding), while small sites use synchronous lightweight write + automatic merging (triggered once every 200ms); Query: Pre-calculate hotspot reports (such as daily average voltage) and cache them in Redis, supporting latest value queries (LAST_ROW function) and time range retrieval.

[0071] 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).

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

[0073] Table 1

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

[0075] Table 2

[0076] V. Conclusion.

[0077] This embodiment's architecture utilizes precise parsing technology of the 104 protocol (station control layer) and the Modbus protocol (device layer), combined with multi-level collaborative processing (Zone I acquisition → Zone II parsing → network gateway transmission → Kafka buffer → TDengine storage), to achieve: full-scenario coverage of heterogeneous devices (from the station control layer to sensors); strict compliance and high security for power production data transmission across security zones; efficient storage and real-time consumption of massive time-series data (millions of measurement points per second); and end-to-end standardization and high reliability of data from acquisition to analysis.

[0078] Part Two, Algorithm Design Description: 1. System Architecture Design.

[0079] 1.1 System Architecture.

[0080] The system architecture design follows standard management and standard development specifications, and is designed in three layers: data layer, middle platform service, and application layer. 1) The application layer consists of early warning station, trend analysis, visualization, etc.

[0081] 2) The middle platform service, combined with the configuration algorithm, is a unified middle platform service that realizes algorithm development, algorithm integration, and algorithm sharing. It mainly includes: a. Configuration algorithm tools and configuration data management; b. Algorithm public data management, including algorithm center, algorithm registration and release, algorithm uninstallation, algorithm calculation tasks, algorithm calculation results, algorithm documentation, algorithm interface, algorithm standard library, etc.; 3) The data layer consists of time-series database, relational database, data middle platform service, etc., which store the original data of measurement points.

[0082] 1.2 Application architecture design.

[0083] Referring to Figure 2, the application platform integrates various digital applications. The intelligent early warning station monitors equipment status in real time and issues 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. These application modules collaborate to improve the intelligence level of equipment status monitoring and operation and maintenance management in electrochemical energy storage power stations.

[0084] 1.2.1 System module design.

[0085] Table 3

[0086] 1.2.2 Component Design.

[0087] Microservices and application component division: Table 4

[0088] 1.3 Network architecture design.

[0089] 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.

[0090] 1.4 Data Architecture Design.

[0091] 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.

[0092] The production systems for calculation and docking are as shown in Table 5 below: Table 5 [[ID=Z]]

[0093] 1.5 Technical Architecture.

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

[0095] The program framework adopts Spring - boot to provide a foundation for programming and communication between microservice components.

[0096] 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.

[0097] The registration and configuration center selects Nacos to manage the registration and configuration information of component services.

[0098] 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.

[0099] 3.7 Data Access Design.

[0100] 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.

[0101] 3.7.1 Scope of Access Data.

[0102] 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.

[0103] 3.7.2 Access data quality.

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

[0105] 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.

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

[0107] 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.

[0108] 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.

[0109] 2. Algorithm platform design.

[0110] 2.1 Overall functional design.

[0111] 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.

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

[0113] Referring to Figure 4, the platform constructs a centralized, standardized, and reusable algorithm model middleware, realizing a closed-loop end-to-end system 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.

[0114] 2.1.1 Algorithm modeling.

[0115] By configuring energy storage station equipment operation data analysis algorithms without code, including scenarios such as key analog quantity analysis under different charging and discharging states, the algorithm configuration tool has the following characteristics: The algorithm configuration tool has drawing tools and an interface that graphically represents various elements of the algorithm, enabling quick algorithm construction through simple drag-and-drop and configuration; it supports hyperparameter configuration, allowing algorithm instances to specify specific parameters during operation through external configuration, eliminating the need to specify them during algorithm configuration; it supports the function of generating multiple index results simultaneously from a single algorithm, ensuring automatic alignment and adjustment of timescales between different technical indicators; and it supports algorithm persistence, automatically and periodically performing data persistence according to user configuration requirements, with algorithm results data permanently stored in the database for easy secondary querying and utilization.

[0116] 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.

[0117] (1) Switching quantity algorithm.

[0118] In energy storage power stations, switch data is mainly used to represent the status of equipment, such as charging and discharging status. The main algorithms for processing this type of data include: Status monitoring: real-time monitoring of changes in the status of switch quantities, such as immediately triggering corresponding alarms or processing procedures when a switch changes from closed to open.

[0119] 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.

[0120] 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.

[0121] 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.

[0122] (2) Analog quantity algorithm.

[0123] 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. For this type of data, the main algorithmic processing includes: threshold judgment: setting a reasonable threshold range to judge the analog data. When the data exceeds or falls below the threshold, corresponding alarms or processing procedures are triggered. For example, when the temperature exceeds a set safety value, the cooling system is activated.

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

[0125] 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.

[0126] Referring to Figure 5, the algorithm tool is developed based on a time series data analysis model. This tool designs a set of modular logical operators to extract features of 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.

[0127] The algorithm tool analysis framework mainly consists of the following modules: ① Algorithm editing and drawing tool: This tool allows users to draw algorithm logic by dragging and dropping modules. The tool compiles the algorithm logic diagram into algorithm information composed of nodes and edges.

[0128] ② 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.

[0129] ③ 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.

[0130] ④ 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.

[0131] 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.

[0132] 2.1.1.1 New algorithm added.

[0133] 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.

[0134] 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.

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

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

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

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

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

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

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

[0142] (1) Algorithm flow construction.

[0143] 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.

[0144] (2) Output settings.

[0145] 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.

[0146] 2.1.1.2 Algorithm instantiation.

[0147] 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.

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

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

[0150] 2.1.1.3 Algorithm calculation.

[0151] 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.

[0152] 2.1.2 Algorithm Center.

[0153] The roles of users in the Algorithm Center are defined as follows: Table 6

[0154] Figure 6 shows the algorithm registration and release process.

[0155] Figure 7 shows the algorithm scheduling process.

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

[0157] 2.1.2.1 Algorithm registration.

[0158] 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.

[0159] 2.1.2.2 Algorithm Standard Library.

[0160] 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.

[0161] 2.1.2.3 Algorithm persistence.

[0162] 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.

[0163] 2.1.2.4 Access Control.

[0164] 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.

[0165] 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.

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

[0167] 4.1.3.1 Machine learning algorithm model.

[0168] 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.

[0169] Algorithm model file deployment path: Specifies 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 parameter is used to determine and assemble the passed algorithm model file name to achieve algorithm calling for different power plants and generating units.

[0170] 4.1.3.2 Mechanism Algorithm.

[0171] 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 an interface, it allows users to call configured algorithm operators within the algorithm platform, encapsulate parameters into 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: Input parameter encapsulation: Returning data with various structures based on different parameter types. It also provides separate encapsulation functions for the input parameters of different operators, enabling users to generate input parameter formats for specified operators from their algorithm inputs.

[0172] Result parsing: The returned results are encapsulated in a format consistent with the configuration algorithm to facilitate persistent data storage.

[0173] Utility class encapsulation: Provides utility classes for conversions such as time, string, array, etc.

[0174] 4.1.3.3 System Design.

[0175] Scheduling Task: Set up a separate timed scheduling task, and select the algorithm type as mechanistic algorithm or 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 period setting (interval time), the execution condition is met, and the current algorithm is scheduled and executed.

[0176] Period settings: Selecting the mechanism algorithm or machine learning algorithm provides more refined time period options, and additional intervals such as every five minutes, every 10 minutes, every 30 minutes, and every hour can be added.

[0177] Data Acquisition Time: After each algorithm-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.

[0178] Algorithm parameters: Data acquisition time and task execution time are usually used as input parameters for the current algorithm.

[0179] 4.1.4 Data Model.

[0180] 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.

[0181] 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.

[0182] 4.1.4.1 Measurement model.

[0183] 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.

[0184] 4.1.4.1.1 Added a new measurement model.

[0185] 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.

[0186] 4.1.4.2 Equipment technical parameter model.

[0187] 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.

[0188] 4.1.4.2.1 Added a new technical parameter model.

[0189] 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.

[0190] 4.1.4.3 Overhaul test data model.

[0191] 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.

[0192] 4.1.4.3.1 Added maintenance test data model.

[0193] 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.

[0194] 4.1.4.2.4 Calculation index model.

[0195] 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.

[0196] 4.1.4.4.1 Added a new calculation index model.

[0197] 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.

[0198] 2.2 Algorithm Platform Development.

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

[0200] 2.2.1.1 Algorithm data statistics.

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

[0202] 2.2.1.2 Data model optimization.

[0203] 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.

[0204] 2.2.2 New feature development and design.

[0205] 2.2.2.1 Measurement model upgrade.

[0206] 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.

[0207] (1) Multi-level.

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

[0209] (2) Multidimensional.

[0210] 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).

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

[0212] 2.2.2.2.1 Add operators.

[0213] 1. Add a range operator.

[0214] 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.

[0215] 2. Custom company operators.

[0216] 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: variables; other operators in the algorithm; output content.

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

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

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

[0220] 2.2.2.2.2 Data integration.

[0221] 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.

[0222] 2.3 Algorithm Development and Deployment.

[0223] 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.

[0224] 2.3.1 Algorithm design and development.

[0225] 4.3.1.1 Algorithm development function.

[0226] 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.

[0227] 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.

[0228] 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.

[0229] 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.

[0230] Figure 8 shows an example of a device analysis algorithm flow.

[0231] 4.3.1.2 Algorithm development code implementation.

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

[0233] 4.3.2 Algorithm Indicator Design and Construction.

[0234] 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".

[0235] 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.

[0236] The algorithm is designed according to the application stage, device object, and actual scenario. Three categories of indicators are designed: basic data indicators, battery performance comparison, and application scenario indicators. A specific indicator design example is shown in Figure 9.

[0237] Figure 10 shows examples of the calculation methods for each algorithm.

[0238] 2.3.2 Algorithm Deployment.

[0239] Algorithm implementation involves creating an algorithm through the platform, enabling the algorithm to run, compute, and store data. The main steps are as follows: 1. Data model implementation: By creating a data model, the association between the measurement points and the model is completed, or basic data related to the model is entered.

[0240] 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.

[0241] 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.

[0242] 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.

[0243] Part Three, other algorithms are explained as follows: 1. Data Model.

[0244] 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.

[0245] 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.

[0246] 1.1 Measurement Model.

[0247] 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.

[0248] 1.1.1 Added a new measurement model.

[0249] 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.

[0250] 1.2 Equipment technical parameter model.

[0251] 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.

[0252] 1.2.1 Added a new technical parameter model.

[0253] 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.

[0254] 1.3 Overhaul test data model.

[0255] 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.

[0256] 1.3.1 Added maintenance test data model.

[0257] 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.

[0258] 1.2.4 Calculation index model.

[0259] 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.

[0260] 1.4.1 Added a new calculation index model.

[0261] 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.

[0262] The beneficial effects of this embodiment include at least the following: 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.

[0263] 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.

[0264] 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.

[0265] Referring to Figure 11, this application embodiment also provides a device for equipment status analysis 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 device includes: a data acquisition unit, used to acquire equipment status data from the production control area of ​​an electrochemical energy storage power station through a preset communication protocol; a data preprocessing unit, 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; a data transmission unit, used to transmit the time-series measurement point data unidirectionally to the non-control area of ​​the electrochemical energy storage power station through a forward isolation device; a data storage unit, used to write the time-series measurement point data into a Kafka cluster for message buffering in the non-control area, and have the consumer program store the time-series measurement point data in the TDengine time-series database; an algorithm generation unit, 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 to generate an equipment status analysis algorithm; and an equipment analysis unit, used to schedule and execute instances of the equipment status analysis algorithm through the algorithm center and output the equipment status analysis results.

[0266] 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.

[0267] 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.

[0268] 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.

[0269] Figure 12 illustrates the hardware structure of an electronic device according to another embodiment. The electronic device includes: a processor 101, which can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, for executing related programs to implement the technical solutions provided in the embodiments of this application; and a memory 102, which can be implemented using a read-only memory (ROM), static storage device, dynamic storage device, or random access memory (RAM), etc. The memory 102 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented by software or firmware, the relevant program code is stored in the memory 102 and is called and executed by the processor 101. The input / output interface 103 is used to implement information input and output. The communication interface 104 is used to realize communication interaction between this device and other devices. Communication can be realized by wired means (e.g., USB, network cable, etc.) or by wireless means (e.g., mobile network, WIFI, Bluetooth, etc.). The bus 105 transmits information between various components of the device (e.g., processor 101, memory 102, input / output interface 103 and communication interface 104). The processor 101, memory 102, input / output interface 103 and communication interface 104 are connected to each other within the device through the bus 105.

[0270] 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.

[0271] 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.

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

[0273] 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.

[0274] 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.

[0275] 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.

[0276] 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.

[0277] 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.

[0278] 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.

[0279] 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.

[0280] 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.

[0281] 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.

[0282] 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.

[0283] 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.

[0284] 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: collecting equipment status data from the production control area of ​​the electrochemical energy storage power station through a preset communication protocol; performing 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; transmitting the time-series measurement point data unidirectionally to the non-control area of ​​the electrochemical energy storage power station through 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; performing algorithm modeling and instantiation on the stored time-series measurement point data based on the configuration algorithm tools provided by the algorithm platform to generate an equipment status analysis algorithm; and executing instances of the equipment status analysis algorithm through the algorithm center to output the equipment status analysis results.

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: using the 104 protocol to collect remote signaling data and telemetry data from the station control layer equipment, parsing the ASDU type and extracting the time stamp, data value, and quality bit; using the Modbus protocol to collect data from the equipment layer sensors, converting the register values ​​into standardized measurement point data through a register mapping table; and performing time stamp synchronization and quality verification on the remote signaling data, the telemetry data, and the standardized measurement point data 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 configuration algorithm tool provided by the algorithm platform performs algorithm modeling and instantiation on the stored time-series measurement point data to generate an equipment status analysis algorithm. This includes the following steps: constructing the algorithm flow using the algorithm modeling tool in a drag-and-drop manner, referencing the measurement model, equipment technical parameter model, maintenance test data model, and calculation index model as inputs to obtain the algorithm model; configuring the output nodes of the algorithm model, setting whether the results are displayed and persisted, and whether multiple indicators are output; instantiating the algorithm model into algorithm instances for specific power plants and energy storage subsystems, associating them with actual measurement point data to obtain the equipment status analysis algorithm.

4. The device status analysis method based on a multi-level data architecture according to claim 3, characterized in that, 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: constructing the measurement model to associate the same performance index measurement points of different power plants or energy storage subsystems; constructing the equipment technical parameter model to provide technical parameters for the instantiation of the equipment condition analysis algorithm; wherein, the technical parameters include the rated capacity and rated power of the power plant; constructing the maintenance test data model to input the equipment condition data collected during the maintenance test; and constructing the calculation index model to store the equipment condition analysis results and reuse them in subsequent algorithms.

5. The device status analysis method based on a multi-level data architecture according to claim 1, characterized in that, The process of executing instances of the device status analysis algorithm through the algorithm center and outputting device status analysis results includes the following steps: registering and publishing the device status analysis algorithm in the algorithm center to enable algorithm querying, document management, and uninstallation; and executing instances of the device status analysis algorithm through scheduling tasks at a set time period to obtain the device status analysis results.

6. 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: deploying machine learning models to the algorithm platform to call the corresponding models by algorithm name, power plant abbreviation and unit number; integrating mechanism algorithm code to the algorithm platform to call configuration algorithm operators and encapsulate input parameters through interfaces; and integrating result parsing utility classes to the algorithm platform to encapsulate the algorithm output results into a unified format and persist them for storage.

7. A device status analysis method based on a multi-level data architecture according to any one of claims 1 to 6, characterized in that, The method further includes the following steps: accessing the monitoring data of the EMS, PCS, transformer substation system and battery system of the electrochemical energy storage power station and uploading them in a standardized manner; cleaning the collected data and identifying and processing abnormal data; wherein, the abnormal data includes exceeding limits, jump changes and no change after reaching a set time; obtaining the measurement point data of the electrochemical energy storage power station through the data platform interface and using it in conjunction with the pre-built time series database data source.

8. A device for analyzing equipment status based on a multi-level data architecture, characterized in that, The device includes: a data acquisition unit for acquiring equipment status data from the production control area of ​​the electrochemical energy storage power station via a preset communication protocol; a data preprocessing unit for performing 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; a data transmission unit for unidirectionally transmitting the time-series measurement point data to the non-control area of ​​the electrochemical energy storage power station via a forward isolation device; a data storage unit for 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; an algorithm generation unit for performing algorithm modeling and instantiation on the stored time-series measurement point data based on the configuration algorithm tools provided by the algorithm platform to generate an equipment status analysis algorithm; and an equipment analysis unit for scheduling and executing instances of the equipment status analysis algorithm through the algorithm center and outputting equipment status analysis results.

9. 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 7.

10. 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 7.

Images