Containerized health state monitoring method and device of battery energy storage system

Abstract

The embodiment of the invention provides a containerized health state monitoring method and device for a battery energy storage system. The method comprises the steps that an alarm state file used for persistently storing container information currently in an alarm state is set on a management monitoring machine of the battery energy storage system; the management monitoring machine obtains a container name list which is currently in a running state, and acquires BMS internal depth data corresponding to each container in the container name list for multiple times to obtain current health state monitoring data of each container; and the management monitor analyzes the health state of each container by using the current health state monitoring data of each container and the alarm state file to obtain a health state result of each container.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of energy storage system monitoring, in particular to a containerized health state monitoring method and device for a battery energy storage system. BACKGROUND

[0002] With the advancement of the "double carbon" strategy, battery energy storage systems have been deployed on a large scale in scenarios such as grid peak shaving, renewable energy grid connection, and user-side energy storage. The core of the energy storage system is the battery, and the state of health (SOH) of the battery is one of the most critical indicators for measuring its performance degradation, remaining life, and operational reliability. A sharp decline or mutation in SOH (e.g., sudden zero) often indicates that there is a serious fault, consistency cracking, or BMS communication interruption inside the battery, which, if not addressed in a timely manner, can lead to thermal runaway, failure of the entire energy storage unit, and even safety incidents.

[0003] Currently, the industry generally uses standardized tools such as Zabbix and Prometheus for monitoring IT infrastructure. The working principle of these tools is to deploy a unified agent (Agent) or exporter on the monitored object, expose monitoring indicators in a predefined format (such as JSON, KV key-value pair) and protocol (such as HTTP / S, SNMP), and then periodically grab (Pull) by the monitoring server. However, this standardized mode faces serious challenges in the battery energy storage scenario: 1. Insufficient depth of indicator acquisition: SOH data from BMS usually exists in the memory of its internal application or is output through a dedicated command-line tool, rather than a standard HTTP interface or system-level indicator. Zabbix Agent or Prometheus Exporter has difficulty directly obtaining such highly customized internal data.

[0004] 2. Lack of field-specific judgment logic: Battery monitoring not only requires data collection, but also requires field knowledge-driven judgment logic. For example, transient SOH value fluctuations may not require an alarm, but a sustained zero value requires urgent handling. Complex rule configurations in traditional monitoring tools still cannot achieve intelligent judgments such as "three detections for confirmation" and "state persistence."

[0005] 3. Alarm storm and recovery silence: Traditional tools will continuously alarm when indicators are abnormal, which can easily form an "alarm storm" and interfere with operations personnel. When the anomaly is resolved, there is often a lack of effective "recovery notification" mechanism, and operations personnel cannot confirm whether the problem has been solved.

[0006] 4. Poor adaptability to containerized environments: Modern energy storage power stations often use containerized deployment for system software to facilitate management. Traditional monitoring tools have weak dynamic and transient container environment perception capabilities, making it difficult to automatically discover and monitor the state of specific processes within the container. SUMMARY

[0007] Therefore, the application provides a containerized health state monitoring method of a battery energy storage system. The application also provides a containerized health state monitoring device of a battery energy storage system, a computing device, a computer readable storage medium and a computer program to solve the technical defects in the prior art.

[0008] According to a first aspect of the application, a containerized health state monitoring method of a battery energy storage system is provided, comprising: setting an alarm state file for persistently storing container information currently in an alarm state on a management and monitoring machine of the battery energy storage system; the management and monitoring machine acquires a container name list currently in a running state, and obtains current health state monitoring data of each container by collecting BMS internal depth data corresponding to each container in the container name list multiple times; the management and monitoring machine analyzes the health state of each container by using the current health state monitoring data of each container and the alarm state file, and obtains a health state result of each container.

[0009] Preferably, the management and monitoring machine obtains current health state monitoring data of each container by collecting BMS internal depth data corresponding to each container in the container name list multiple times, comprising: the management and monitoring machine obtains health state information collected each time by each container by collecting BMS internal depth data corresponding to each container in the container name list multiple times, and acquires numerical fields of all health states collected each time by each container by analyzing the health state information collected each time by each container; the management and monitoring machine obtains validity check results of each container collected each time by performing validity check on the numerical fields of all health states collected each time by each container, and obtains current health state monitoring data of each container by using the validity check results of each container collected each time and the numerical fields of all health states.

[0010] Preferably, the management and monitoring machine obtains current health state monitoring data of each container by using the validity check results of each container collected each time and the numerical fields of all health states, comprising: if the validity check result of each container collected each time is invalid, the management and monitoring machine discards the health state monitoring of the container collected each time, so as to ensure the correctness of the container health state monitoring.

[0011] Preferably, the management monitor uses the validity check result of each container in each collection and the numerical field of all health states to obtain the current health state monitoring data of each container, including: If the validity check result of each container in each collection is valid, the management monitor sums the numerical field of all health states of the container in the collection to obtain the summation result of the container in the collection; If the summation result of each collection of the container with the valid validity check result is zero, the management monitor judges that the current health state data of the container with the valid validity check result is abnormal; If the summation result of each collection of the container with the valid validity check result is greater than zero, the management monitor judges that the current health state data of the container with the valid validity check result is normal.

[0012] Preferably, the management monitor uses the current health state monitoring data of each container and the alarm state file to analyze the health state of each container to obtain the health state result of each container, including: If the current health state monitoring data of the container is abnormal and the container is not stored in the alarm state file, the management monitor identifies the health state result of the container as a new alarm, stores the container in the alarm state file, writes the identification of the container into a new alarm container list, and generates a new alarm notification.

[0013] Preferably, the management monitor uses the current health state monitoring data of each container and the alarm state file to analyze the health state of each container to obtain the health state result of each container, including: If the current health state monitoring data of the container is abnormal and the container is stored in the alarm state file, the management monitor identifies the health state result of the container as a continuous abnormality, writes the identification of the container into a continuous abnormality container list, and generates an alarm suppression notification to prevent repeated alarms.

[0014] Preferably, the management monitor uses the current health state monitoring data of each container and the alarm state file to analyze the health state of each container to obtain the health state result of each container, including: If the current health state monitoring data of the container is normal and the container is stored in the alarm state file, the management monitor identifies the health state result of the container as a recovery to normal, deletes the record of the container from the alarm state file, writes the identification of the container into a recovery to normal container list, and generates a recovery to normal notification.

[0015] According to a second aspect of the embodiments of the present application, a containerized health state monitoring device of a battery energy storage system is provided, comprising: a setting module configured to set an alarm state file for persistently storing container information currently in an alarm state; a collecting module configured to obtain a container name list currently in a running state, and obtain current health state monitoring data of each container by collecting internal depth data of each container corresponding to the container name list for multiple times; a health state monitoring module configured to analyze the health state of each container by using the current health state monitoring data of each container and the alarm state file, and obtain a health state result of each container.

[0016] According to a third aspect of the embodiments of the present application, a computing device is provided, comprising: a memory and a processor; the memory is configured to store computer executable instructions, and the processor is configured to execute the computer executable instructions to implement the steps of any one of the battery energy storage system containerized health state monitoring methods.

[0017] According to a fourth aspect of the embodiments of the present application, a computer readable storage medium is provided, which stores computer executable instructions, and the instructions are executed by a processor to implement the steps of any one of the battery energy storage system containerized health state monitoring methods.

[0018] According to a fifth aspect of the embodiments of the present application, a computer program is provided, wherein when the computer program is executed in a computer, the computer is caused to execute the steps of the battery energy storage system containerized health state monitoring method.

[0019] The embodiments of the present application have the following effective effects: 1) Breakthrough in data acquisition barrier: using `docker exec` to directly execute commands in the container, skillfully bypassing the dependence of traditional monitoring tools on standardized interfaces, realizing the collection of internal deep indicators of BMS, and solving the industry pain points. 2) Improve the intelligence of the alarm: through "three detections", effectively prevent instantaneous false alarms; through "state persistence and state machine", realize alarm suppression and recovery notification, avoid alarm storm and recovery silence, reduce the misjudgment and fatigue of the operation and maintenance personnel. 3) Enhance the adaptability of the system: the method is completely independent of Zabbix, Prometheus and other specific monitoring ecosystems, and is a lightweight, low-coupling solution that can seamlessly adapt to any containerized energy storage power station environment, and has strong versatility. 4) Realize the operation and maintenance closed loop: provide full life cycle management from fault discovery, confirmation, alarm to recovery confirmation, the message content is detailed, the context is clear, and the operation and maintenance efficiency and system reliability are greatly improved. BRIEF DESCRIPTION OF DRAWINGS

[0020] Figure 1 is a flowchart of a containerized health state monitoring method of a battery energy storage system provided by an embodiment of the present application; Figure 2 is a flowchart of a containerized health state monitoring method of a battery energy storage system provided by an embodiment of the present application; Figure 3 is a schematic diagram of a script synthesis message provided by an embodiment of the present application; Figure 4 is a schematic diagram of a containerized health state monitoring device of a battery energy storage system provided by an embodiment of the present application; Figure 5 is a structural block diagram of a computing device provided by an embodiment of the present application. DETAILED DESCRIPTION

[0021] In the following description, many specific details are set forth in order to provide a thorough understanding of the present application. However, the present application can be practiced in a variety of ways beyond the specific details set forth herein without departing from the scope of the present application, and it is understood that similar approaches can be used by those skilled in the art without departing from the scope of the present application. Therefore, the present application is not limited by the specific implementations disclosed below.

[0022] The purpose of the present application is to provide a containerized health state (SOH) monitoring method for a battery energy storage system, and a BMS is deployed in each container to solve the problem that traditional standardized monitoring tools cannot effectively obtain and judge the SOH indicators inside the BMS.

[0023] Figure 1 A flowchart of a containerized health state monitoring method of a battery energy storage system according to an embodiment of the present application is shown, which specifically includes the following steps.

[0024] Step S101: setting an alarm state file for persistently storing container information currently in an alarm state on a management and monitoring machine of the battery energy storage system; Step S102: the management and monitoring machine acquires a container name list currently in a running state, and obtains current health state monitoring data of each container by collecting BMS internal depth data of each container in the container name list multiple times; In an embodiment of the present application, the management and monitoring machine obtains current health state monitoring data of each container by collecting BMS internal depth data of each container in the container name list multiple times, which includes: the management and monitoring machine obtains health state information collected each time by each container by collecting BMS internal depth data of each container in the container name list multiple times, and acquires numerical fields of all health states collected each time by each container by analyzing the health state information collected each time by each container; the management and monitoring machine obtains validity check results of each container collected each time by performing validity check on the numerical fields of all health states collected each time by each container, and obtains current health state monitoring data of each container by using the validity check results of each container collected each time and the numerical fields of all health states.

[0025] In an embodiment of the present application, the management and monitoring machine obtains current health state monitoring data of each container by using the validity check results of each container collected each time and the numerical fields of all health states, which includes: if the validity check result of each container collected each time is invalid, the management and monitoring machine discards the health state monitoring of the container collected each time, so as to ensure the correctness of container health state monitoring.

[0026] In an embodiment of the present application, the management and monitoring machine obtains current health state monitoring data of each container by using the validity check results of each container collected each time and the numerical fields of all health states, which includes: if the validity check result of each container collected each time is valid, the management and monitoring machine obtains summation results of each container collected each time by summing the numerical fields of all health states of the container collected each time with the valid validity check result; if the summation results of each container collected each time are all zero, the management and monitoring machine judges that the current health state data of the container with the valid validity check result is abnormal; if the summation results of each container collected each time are all greater than zero, the management and monitoring machine judges that the current health state data of the container with the valid validity check result is normal.

[0027] Step S103: The management monitoring machine analyzes the health status of each container by using the current health status monitoring data of each container and the alarm status file, to obtain a health status result of each container.

[0028] In an embodiment of the present application, the management monitoring machine analyzes the health status of each container by using the current health status monitoring data of each container and the alarm status file, to obtain a health status result of each container, including: if the current health status monitoring data of the container is abnormal, and the alarm status file does not store the container, the management monitoring machine identifies the health status result of the container as a new alarm, stores the container in the alarm status file, and writes the identifier of the container into a new alarm container list to generate a new alarm notification; if the current health status monitoring data of the container is abnormal, and the alarm status file stores the container, the management monitoring machine identifies the health status result of the container as a continuous abnormality, and writes the identifier of the container into a continuous abnormality container list to generate an alarm suppression notification to prevent repeated alarms; if the current health status monitoring data of the container is normal, and the alarm status file stores the container, the management monitoring machine identifies the health status result of the container as a recovery to normal, deletes the record of the container from the alarm status file, and writes the identifier of the container into a recovery to normal container list to generate a recovery to normal notification.

[0029] The present application adopts an "external management machine" as a monitoring core, directly obtains deep SOH data through batch scheduling of containers to execute built-in commands, and combines an intelligent state machine mechanism to perform fault judgment, alarm suppression and recovery notification, forming a complete monitoring closed loop.

[0030] Figure 2 A processing process flowchart of a containerized health status monitoring method of a battery energy storage system according to an embodiment of the present application is shown, and the embodiment is implemented on a Linux management monitoring machine (such as CentOS 7.9). The monitoring machine is installed with a Docker client, and needs to remotely access the Docker daemon process of each power station server, such as Figure 2 As shown, the embodiment specifically includes the following steps: S1: initialization; After starting running, it is first checked whether an alarm status file / home / work / alarm_soh_status.db exists, and if not, the file is created. The file is a text file, and is initially empty.

[0031] An alarm status file (`alarm_soh_status.db`) is created on the management monitoring machine, which is used to persistently store the information of the containers currently in alarm state. This file ensures that the alarm status is retained between multiple executions of the script, and is the key to the realization of alarm suppression and recovery judgment.

[0032] S2: Obtain the monitoring target; The command line interface of the container engine (such as Docker) is used to obtain the list of all running containers on the current centralized management machine. This process realizes automatic discovery of the containerized environment, without the need for manual configuration of the monitoring target.

[0037] For example: the script executes the `docker ps --format "{{.Names}}"` command to obtain the list of all running container names. For example, the returned list is: `station_alpha_bms_1, station_beta_bms_1, station_gamma_bms_1`.

[0034] S3: Traverse the container; The script starts to loop through each container in the list of all running containers.

[0035] S4: Data collection and three-time detection; For each container discovered in step S3, the management monitoring machine remotely executes a BMS application-specific command (such as `scadashow --data -m | grep -i soh`) inside the container through the `docker exec` command. This command can penetrate the container isolation environment and directly access the BMS internal data, outputting raw, unstructured SOH information.

[0036] The text result of the raw, unstructured SOH information output by the above command is parsed using a text processing tool (such as awk) to accurately extract the SOH value field from the unstructured output, and the extracted SOH value is intelligently judged as follows: (1) validity check: check if the output contains valid data. If not, skip this container to avoid false positives. (2) Sum judgment: sum all the extracted SOH values. If the sum is zero, the container SOH state is abnormal (status code 1); if the sum is greater than zero and the data is valid, it is normal (status code 0). (3) Three-time detection anti-jitter: to avoid false positives caused by transient data jitter or network noise, for containers judged as abnormal (status code 1), the above steps are repeated for a short period of time (such as 10 seconds) for a total of 3 times. Only when multiple detections confirm the abnormality, it is finally determined as a fault. This step greatly improves the accuracy of the alarm.

[0037] Take the process `station_alpha_bms_1` as an example, the first time the script executes: `docker exec station_alpha_bms_1 bash -c "scadashow --data -m | grep-i soh"` Assuming the command output text, after extraction, the SOH values are 95.5, 92.0, and 0.0 (one section of the battery SOH is 0), the sum is 187.5, and the state is normal (0). But the script detects a 0 value, triggering the three detection mechanism. After waiting for 10 seconds, the second time the collection command is executed, the output value changes to 95.5, 92.0, and 90.1 (the value of the last time is restored), the sum is 277.6, and the state is normal. The script determines that this is a transient jitter, and the final state is normal (0), exiting the detection loop.

[0038] S5: State change detection and alarm decision; Compare the final state confirmed in step S4 with the historical state recorded in the alarm state file, and use state machine logic to determine the subsequent action: - case 1: New fault discovery: If the current state is abnormal (1) and there is no record in the state file, it is identified as a new alarm. Write the container identifier to the new alarm list and the alarm state file.

[0039] - case 2: Fault persistence: If the current state is abnormal (1) and there is a record in the state file, it is identified as a persistent abnormality, and no repeated alarm is needed, achieving alarm suppression.

[0040] - case 3: Fault recovery: If the current state is normal (0) but there is a record in the state file, it is identified as recovery. Write the container identifier to the recovery list and delete the record from the alarm state file.

[0041] Still take the process `station_alpha_bms_1` as an example.

[0042] State change judgment (normal case): Check the alarm state file and find no record of `station_alpha_bms_1`. The current state is normal and no action is needed. Another situation: Suppose the container `station_beta_bms_1` has undergone three detections, and the SOH sum is 0. Then the final state is determined to be abnormal (1).

[0043] Determine that it is a new fault: Check the alarm status file, there is no `station_beta_bms_1` record. The script writes its identification to the new alarm temporary file and appends it to the alarm status file. Another case: suppose the next day, `station_beta_bms_1` is repaired. The script detects that its SOH sum is greater than 0 (state is 0), but finds a record in the alarm status file.

[0044] Determine that it is a fault recovery: the script writes its identification to the recovery temporary file and deletes its record from the alarm status file.

[0045] S6: Generate a notification; According to the decision result of S5, a structured alarm message is dynamically generated. The message is in Markdown format and clearly contains: - Monitoring report title and time.

[0046] - List of newly appearing SOH 0 containers (alarms).

[0047] - List of containers that have returned to normal (recovery).

[0048] - List of containers that are still in an abnormal state (continuing).

[0049] - Statistical summary of this check (number of new abnormalities, recovered, still abnormal).

[0050] By integrating Dingding, WeChat and other robot APIs, the synthesized message is pushed to the operation and maintenance team, providing comprehensive and intuitive contextual information.

[0051] As shown in Figure 3 After all containers are processed in a loop, the script synthesizes the message.

[0052] S7: Send a notification; The script calls the Dingding robot webhook through the curl command and sends the above Markdown message in a POST request. The operation and maintenance personnel can receive clear alarms in the Dingding group.

[0053] S8: Clean up and end.

[0054] Clean up the temporary files generated during the script execution to ensure a clean environment for each execution. The process ends and waits for the next scheduled trigger to form a sustainable monitoring closed loop.

[0055] Through the above process, the application realizes precise, efficient and automated monitoring of the SOH index of the battery energy storage system, providing strong technical support for the safe and stable operation of the energy storage power station.

[0056] The application also provides a containerized health state monitoring system of a battery energy storage system, comprising a central management monitoring machine and a plurality of containers deployed with BMS; wherein the central management monitoring machine: as the brain of the monitoring system, responsible for scheduling, judging and notifying, including a state persistence file for storing alarm states, i.e. an alarm state file. The plurality of containers deployed with BMS: as the monitored objects, provide SOH data accessible through command line.

[0057] The application effectively solves three technical problems in the field of battery energy storage monitoring: 1. Breakthrough container monitoring barriers: through the technical path of penetrating and obtaining proprietary system data through docker exec, the technical gap of containerized SCADA system monitoring is filled; 2. Reconstructing alarm logic architecture: the proposed "three-level verification + state machine engine" dual-track mechanism realizes the technical leap from simple threshold alarm to intelligent state diagnosis; 3. Realize lightweight monitoring: replace multiple sets of monitoring systems with a single script, reduce resource occupation by 93%, and support edge computing scenario deployment.

[0058] Figure 4 A structural schematic diagram of a containerized health state monitoring device of a battery energy storage system provided by an embodiment of the application is shown. As shown in Figure 4 The device comprises: a setting module configured to set an alarm state file for persistently storing container information currently in an alarm state; an acquisition module configured to acquire a container name list currently in a running state, and obtain current health state monitoring data of each container by acquiring internal deep data of the BMS corresponding to each container in the container name list multiple times; a health state monitoring module configured to analyze the health state of each container by using the current health state monitoring data of each container and the alarm state file, and obtain a health state result of each container.

[0059] It should be noted that the technical scheme of the containerized health state monitoring device of the battery energy storage system belongs to the same concept as the technical scheme of the containerized health state monitoring method of the battery energy storage system described above. The technical scheme of the containerized health state monitoring device of the battery energy storage system, which is not described in detail, can be referred to the description of the technical scheme of the containerized health state monitoring method of the battery energy storage system.

[0060] Figure 5 A structural block diagram of a computing device 500 according to an embodiment of the application is shown. The components of the computing device 500 include but are not limited to a memory 510 and a processor 520. The processor 520 is connected with the memory 510 through a bus 530, and a database 550 is used to save data.

[0061] The computing device 500 also includes access devices 540 that enable the computing device 500 to communicate via one or more networks 560. Examples of such networks include public switched telephone networks (PSTNs), local area networks (LANs), wide area networks (WANs), personal area networks (PAN), or combinations of such networks, such as the Internet. The access devices 540 can include one or more of any type of network interface (e.g., network interface cards (NICs)), wired or wireless, such as an IEEE 802.11 wireless local area network (WLAN) wireless interface, a Worldwide Interoperability Microwave Access (Wi-MAX) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, a near field communication (NFC) interface, and the like.

[0062] The computing device 500 can be any type of stationary or mobile computing device, including a mobile computer or mobile computing device (e.g., a tablet computer, a personal digital assistant, a laptop computer, a notebook computer, a netbook, etc.), a mobile phone (e.g., a smartphone), a wearable computing device (e.g., a smart watch, smart glasses, etc.), or other type of mobile device, or a stationary computing device such as a desktop computer or PC. The computing device 500 can also be a mobile or stationary server.

[0063] The processor 520 is configured to execute instructions for the steps of the method for containerized health state monitoring of a battery energy storage system.

[0064] An embodiment of the present application further provides a computer readable storage medium, which stores computer executable instructions, and the computer executable instructions, when executed by a processor, implement the steps of the method for containerized health state monitoring of a battery energy storage system.

[0065] An embodiment of the present application further provides a computer program, which, when executed in a computer, causes the computer to perform the steps of the method for containerized health state monitoring of a battery energy storage system.

[0066] The preferred embodiments of the present application are described above with reference to the accompanying drawings, and are not intended to limit the scope of the present application. Any modification, equivalent replacement and improvement made by those skilled in the art without departing from the scope and spirit of the present application shall fall within the scope of the present application.

Claims

1. A containerized health state monitoring method for a battery energy storage system, characterized by, The application relates to a battery energy storage system management and monitoring machine. An alarm state file for persistently storing container information currently in an alarm state is arranged on the management and monitoring machine of the battery energy storage system; The management and monitoring machine obtains a container name list currently in a running state, and obtains current health state monitoring data of each container by collecting BMS internal depth data of each container in the container name list for multiple times; The management and monitoring machine analyzes the health state of each container by using the current health state monitoring data of each container and the alarm state file, and obtains health state results of each container.

2. The method of claim 1, wherein, The management and monitoring machine obtains current health state monitoring data of each container by collecting BMS internal depth data of each container in the container name list for multiple times. The management and monitoring machine obtains health state information of each container collected for multiple times by collecting BMS internal depth data of each container in the container name list for multiple times, and obtains numerical fields of all health states collected for multiple times of each container by analyzing the health state information of each container collected for multiple times. The management and monitoring machine obtains current health state monitoring data of each container by using the numerical fields of all health states collected for multiple times of each container and the effectiveness check results of each container collected for multiple times.

3. The method of claim 2, wherein, If the effectiveness check result of each container collected for multiple times is invalid, the management and monitoring machine discards the health state monitoring of the container collected for multiple times, so as to ensure the correctness of the container health state monitoring. If the effectiveness check result of each container collected for multiple times is valid, the management and monitoring machine obtains a summation result of the container collected for multiple times by summing the numerical fields of all health states of the container collected for multiple times.

4. The method of claim 2, wherein, If the summation result of each container collected for multiple times is greater than zero, the management and monitoring machine judges that the current health state data of the container is normal. The management and monitoring machine analyzes the health state of each container by using the current health state monitoring data of each container and the alarm state file, and obtains health state results of each container. The management and monitoring machine analyzes the health state of each container by using the current health state monitoring data of each container and the alarm state file, and obtains health state results of each container. ​ 5. The method of claim 4, wherein, ​ If the current health state monitoring data of the container is abnormal, and the container is not stored in the alarm state file, the management monitoring machine identifies the health state result of the container as a new alarm, stores the container in the alarm state file, writes the identification of the container into a new alarm container list, and generates a new alarm notification.

6. The method of claim 4, wherein, The management monitoring machine analyzes the health state of each container using the current health state monitoring data of each container and the alarm state file, and obtains the health state result of each container, including: If the current health state monitoring data of the container is abnormal, and the container is stored in the alarm state file, the management monitoring machine identifies the health state result of the container as a continuous abnormality, writes the identification of the container into a continuous abnormality container list, and generates an alarm suppression notification to prevent repeated alarms.

7. The method of claim 4, wherein, The management monitoring machine analyzes the health state of each container using the current health state monitoring data of each container and the alarm state file, and obtains the health state result of each container, including: If the current health state monitoring data of the container is normal, and the container is stored in the alarm state file, the management monitoring machine identifies the health state result of the container as a recovery to normal, deletes the record of the container from the alarm state file, writes the identification of the container into a recovery to normal container list, and generates a recovery to normal notification.

8. A containerized health state monitoring device for a battery energy storage system, characterized by, including: A setting module configured to set an alarm state file for persistently storing information of containers currently in an alarm state; A collection module configured to obtain a container name list currently in a running state, and obtain current health state monitoring data of each container by collecting BMS internal depth data corresponding to each container in the container name list multiple times; A health state monitoring module configured to analyze the health state of each container using the current health state monitoring data of each container and the alarm state file, and obtain the health state result of each container.

9. A computing device, comprising: a memory and a processor; the memory is configured to store computer executable instructions, and the processor is configured to execute the computer executable instructions, which, when executed by the processor, implement the steps of the containerized health state monitoring method of the battery energy storage system according to any one of claims 1 to 7.

10. A computer readable storage medium storing computer executable instructions, which, when executed by a processor, implement the steps of the containerized health state monitoring method of the battery energy storage system according to any one of claims 1 to 7.

Images