A power system containerized operation state information identification and fault detection method and system

Abstract

The application discloses a kind of power system container operation state information identification and fault detection method and system, comprising: definition includes system identification, container group, container type, scene, container number Container naming rule;Process management, container state management and sub-scene state management model are constructed;Container image is constructed, and container host name resolution engine and process management configuration are preset;By self-defined configuration, the container name, environment variable and container number that meet the container naming rule are set;When container starts, container name is resolved by host name resolution engine, identifies the scene, sub-scene and container number of the container belonging to, and determines sub-scene instance number;Process management calculates the container health index according to the sub-scene process health index in container, triggers container fault, and triggers corresponding fault handling by cascading to host computer sub-scene.The problems of non-standard container identification, low scene deployment flexibility, fault response lag and insufficient full-link association in the prior art are solved.

Description

Technical Field

[0001] This invention relates to a method for identifying operational status information and detecting faults, and more particularly to a containerized operational status information identification and fault detection method and system for power systems, belonging to the field of power system automation technology. Background Technology

[0002] With the deepening of the digital and intelligent transformation of the power system, containerization technology has become the mainstream solution for the deployment of power automation systems due to its lightweight, portable and easily scalable characteristics. However, in the multi-scenario container collaborative operation scenario of the distribution automation system, the adaptability of the existing solution is still significantly insufficient. The specific problems are as follows: (1) The container cluster scheduling capability is lacking. The existing solution only supports simple scheduling of containers to designated hosts and cannot achieve clustered scheduling. When the container or host fails or the host resources are tight, container drift is likely to occur. In extreme cases, it may even be impossible to complete the state switch and container migration, which seriously affects the stability of system operation. (2) The container naming lacks a unified standard, which makes it difficult to quickly identify the container role, function and the scenario to which it belongs, which brings great trouble to fault location and operation and maintenance management. (3) The multi-scenario identification and deployment flexibility is insufficient. The container and the scenario are strongly bound. Only the single-scenario deployment of the container is supported. Multi-scenario deployment causes resource waste and high configuration and deployment complexity. At the same time, the instance number of the container group sub-scenario depends on the container management platform interface. In special scenarios (such as black start), if the container is started with priority of the container management platform, the failure of the interface call will cause the business to be unable to recover, which weakens the emergency response capability of the system. (4) State management is fragmented. The state management of processes within the container, the container itself, and the upper-level sub-scenarios are independent of each other and no cascading correlation mechanism is formed. When a fault occurs, it is impossible to achieve rapid response and accurate transmission. (5) The fault detection mechanism is singular. It only targets a single level of process or container and cannot achieve full-link fault root cause correlation from process to system sub-scenario. This results in a long delay in fault handling and affects the continuity and stability of power grid control services.

[0003] To address the problems existing in the above-mentioned technologies, a method is needed that has the capabilities of structured identification, hierarchical status management, and end-to-end fault response, so as to improve the standardization, deployment flexibility, and efficiency of fault handling in the containerized sub-scenario management of the power grid control system. Summary of the Invention

[0004] Purpose of the invention: The purpose of this invention is to provide a method and system for identifying containerized operation status information and detecting faults in power systems, thereby improving the standardization of containerized sub-scenario management and the efficiency of fault handling in power grid control systems.

[0005] Technical solution: The present invention provides a method for identifying containerized operation status information and detecting faults in a power system, comprising:

[0006] Define container naming rules that include system identifier, container group, container type, scenario, and container number;

[0007] Construct process management, container status management, and sub-scenario status management models; the process management defined fields include process name, process PID, scenario, scenario instance, sub-scenario, sub-scenario instance, process status, health index, and health status; the container status management defined fields include container status, health index, and health status; the sub-scenario status management defined fields include scenario ID, sub-scenario, sub-scenario application status, health index, and health status.

[0008] Build a container image and pre-configure the container hostname resolution engine and process management settings; during the container deployment phase, set the container name, environment variables, and container number that conform to the container naming rules through custom configuration.

[0009] When a container starts, the container name is resolved by the container hostname resolution engine to identify the scene, sub-scene and container number to which the current container belongs. Based on the container name resolution result, it is determined whether the container is a sharded container or a non-sharded container, and the sub-scene instance number is determined.

[0010] After the container starts, the process management calculates the container health index based on the health index of the sub-scene processes within the container and synchronizes it to the container status. If the container health index is lower than a preset threshold, a container failure is triggered. The container failure is cascaded to the host machine sub-scene and triggers corresponding failure handling.

[0011] Furthermore, the container naming rules adapt to a four-tuple management format including scenario, scenario instance, sub-scenario, and sub-scenario instance; the system identifier indicates the subsystem to which the container belongs, the container group determines the container cluster affiliation, including sharded containers and non-sharded containers; the container type is used to distinguish containers, including critical containers and ordinary containers; the scenario includes real-time state, learning state, and inversion state; the container number indicates the number of replicas of the container and corresponds to the sub-scenario instance number.

[0012] Furthermore, the process name is the process name registered in the process management within the container; the process PID is the unique identifier of the process; the scenario includes real-time state, learning state, and inversion state; the scenario instance is the instance identifier of the process running scenario; the sub-scenario is the subsystem in which the specific process runs; the sub-scenario instance is the instance identifier of the sub-scenario; the process state is the current running state of the process, including online and offline; the health state includes healthy, good, alarm, fault, and crash.

[0013] The container status includes online, offline, restarted, and error;

[0014] The scenario ID is the identifier of the running scenario in which the container is located; the application status of the sub-scenario includes host, standby, fault, and exit.

[0015] Furthermore, the health index describes the health status through a range of 0 to 1. Specifically, when the health index is 0.9 to 1.0, the health status is healthy; when the health index is 0.7 to 0.89, the health status is good; when the health index is 0.5 to 0.69, the health status is alarming; when the health index is 0.3 to 0.49, the health status is faulty; and when the health index is 0 to 0.3, the health status is crashed.

[0016] Furthermore, identifying the current scenario to which the container belongs includes: if the environment variable MORE_STATE_RUN is in a polymorphic running mode, then the container name does not contain scenario information; if the environment variable MORE_STATE_RUN is in a unimorphic running mode, then the scenario field is parsed from the container name, and the process corresponding to that scenario is started.

[0017] Furthermore, the sub-scene processes within the sharded container run in the sharded sub-scene, and the sub-scene processes within the non-sharded container run in the non-sharded sub-scene; if it is a sharded sub-scene, the sub-scene instance number is calculated according to the formula: sub-scene instance number = container number + offset - 1; if it is a non-sharded sub-scene, the sub-scene instance number is the container number, which is obtained by resolving the container name using the container hostname resolution engine.

[0018] Furthermore, the method also includes: when the sub-scene process is running, registering and activating the process state with the process management, the activated process is monitored by the process management, and the activated process is checked for failure. If it is a normal process, the process management sets the failure process state to offline and restarts the process; if it is a critical process, the process management transmits the failure information to the cascaded host sub-scene through the message bus and triggers the container restart operation.

[0019] Furthermore, the transmission of fault information to the cascaded host sub-scene state management includes two methods: the process management transmits the fault information to the container state management, the container state management triggers corresponding operations, and cascades to the host sub-scene state management to trigger a fault in the host sub-scene; or the process management transmits the fault information to the cascaded host process management to trigger fault handling in the host sub-scene state management, and issues instructions to the container state management to trigger corresponding operations.

[0020] Furthermore, the method also includes diagnostic verification of the fragmented containers: when the offsets of fragmented containers in different container groups intersect, abnormal containers are diagnosed and removed through container status management.

[0021] This invention provides a power system containerized operation status information identification and fault detection system, comprising:

[0022] Naming rule definition module: Defines container naming rules including system identifier, container group, container type, scenario, and container number;

[0023] The three-level modeling module constructs process management, container state management, and sub-scenario state management models. The process management definition fields include process name, process PID, scenario, scenario instance, sub-scenario, sub-scenario instance, process state, health index, and health state. The container state management definition fields include container state, health index, and health state. The sub-scenario state management definition fields include scenario ID, sub-scenario, sub-scenario application state, health index, and health state.

[0024] Configuration module: Builds container images and pre-configures container hostname resolution engine and process management; during container deployment, it allows users to customize the container name, environment variables, and container number to conform to the container naming rules.

[0025] Scene recognition and instance number confirmation module: When the container starts, the container name is resolved by the container hostname resolution engine to identify the scene, sub-scene and container number to which the current container belongs. Based on the container name resolution result, it is determined whether the container is a sharded container or a non-sharded container, and the sub-scene instance number is determined.

[0026] Fault cascading module: After the container starts, the process management calculates the container health index based on the process health index of the sub-scenes within the container and synchronizes it to the container status. If the container health index is lower than a preset threshold, a container fault is triggered. The container fault is cascaded to the host machine sub-scenes and triggers corresponding fault handling.

[0027] Beneficial effects: Compared with the prior art, the present invention has the following significant advantages:

[0028] This invention employs structured container naming, a three-level modeling approach (process management, container state management, and sub-scenario state management), and end-to-end fault correlation technology to achieve container cluster scheduling, flexible deployment of scenarios and sub-scenarios, and accurate fault detection across all dimensions. This addresses the problems of poor compatibility in containerized sub-scenario scheduling and low efficiency in status information identification in existing technologies. Through intelligent hostname resolution and a fault hierarchical propagation mechanism, it reduces the management costs of container scenario and sub-scenario identification, the latency of scenario and sub-scenario identification, and the cost of operation and maintenance intervention, solving the problems of difficult container fault location and delayed propagation in existing technologies. At the same time, it avoids business recovery obstacles in special scenarios, enhances system operational reliability, promotes the deep integration of containerization technology and power systems, and significantly improves the fault handling efficiency and management level of the distribution network DSCADA system. Attached Figure Description

[0029] Figure 1This is a flowchart of the container operation status information identification method of the present invention.

[0030] Figure 2 This is a schematic diagram illustrating the naming of the structured containers of this invention.

[0031] Figure 3 This is a schematic diagram illustrating the calculation of the container sub-scene instance number of the present invention.

[0032] Figure 4 This is a schematic diagram of the container fault detection and application cascade response mechanism of the present invention. Detailed Implementation

[0033] The technical solution of the present invention will be further described below with reference to the accompanying drawings.

[0034] Example 1

[0035] This embodiment provides a method for identifying containerized operation status information and detecting faults in a power system, including...

[0036] (1) Define container naming rules including system identifier, container group, container type, scenario, and container number;

[0037] The container naming format is "System Identifier_Container Group_Container Type_Scenario_Container Number". The functions of each field will be adapted to the "Scenario-Scenario Instance-Sub-Scenario-Sub-Scenario Instance" four-tuple management format of the power grid control system, as defined below:

[0038] System Identifier: Used to identify the subsystem to which the container belongs. It is the basic identifier for container fault detection and cascaded subsystem fault propagation. For example, "SCA" identifies the power grid SCADA subsystem and "DSCA" identifies the distribution network SCADA subsystem.

[0039] Container Groups: Used to determine the ownership of container clusters and manage them. When a container or subsystem experiences a cascading failure, the failure is transferred via container groups, ensuring the continuity and consistency of service switching between different subsystem modules. Values ​​include "areagroupX" and "dscada". In "areagroupX", X is a shard number ranging from 1 to 99, used to calculate the sub-scenario instance number. "areagroup" indicates that the container is a sharded container, and the sub-scenario processes within it run under the sharded sub-scenario (dscada_area). The value "dscada" represents a container that is not sharded; the application processes within a non-sharded container run under the dscada sub-scenario.

[0040] Container Type: Used to distinguish between critical and general containers. A critical container failure will trigger a cascading application (subsystem) failure response. Values ​​include "crucial" and "general". "crucial" marks the container as critical, while "general" or no keyword marks the container as general.

[0041] Scenario: Used to indicate the working mode of the container, corresponding to the control system scenario. Values ​​include real (real-time state), study (study state), pdr (inversion state), etc., and are optional segments in the hostname. When this field is included, it indicates that a single container is deployed independently in a single state. When this field is not included, it supports multi-state operation of a single container.

[0042] Container ID: The number of replicas of the container, which is a replica sequence number generated by the container management platform. It is an integer from 1 to 99, increasing sequentially. It corresponds to the instance number of the sub-scenario of the control system. All processes in the container are bound to this instance to run.

[0043] Based on the above naming rules, here are some examples of hostnames: dsca_areagroup1_crucial_real_1, which means "Critical Real-Time Container No. 1 in Distribution Network SCADA Segment 1"; dsca_dscada_crucial_study_2, which means "Critical Learning Container No. 2 in Distribution Network SCADA (Unsegmented)".

[0044] (2) Construct process management, container state management and sub-scenario state management models;

[0045] The process management includes in-container process management and out-of-container process management, including: process name, process PID, scenario, scenario instance, sub-scenario, sub-scenario instance, process status, health index and health status;

[0046] Process name: The name of the process registered in the container's process management.

[0047] Process PID: A unique identifier for a process.

[0048] Scenario: The running state of the process, adapting to the different scenario requirements of the control system.

[0049] Scenario Instance: A specific instance identifier for the process execution scenario.

[0050] Sub-scenario: The process runs in a specific subsystem.

[0051] Sub-scene instance: A specific instance identifier for a sub-scene, used to identify multiple sub-scene instances within the container.

[0052] Process status: The current running state of a process, including "online" and "offline".

[0053] Process health index: describes the health status of a process by dividing it into intervals between 0 and 1.

[0054] Process health status: describes the health status of a process, including "healthy", "good", "alarming", "faulty", and "crashed". When the health index is between 0.9 and 1.0, the health status is "Healthy," indicating that the process is running stably, all indicators meet the thresholds, and there are no abnormalities. When the health index is between 0.7 and 0.89, the health status is "Good," indicating that the core functions of the process are normal, and a few non-core indicators are slightly out of limit (such as short-term CPU usage of 75% or slightly high memory growth rate), with no business impact. When the health index is between 0.5 and 0.69, the health status is "Alarm," indicating that the core indicators of the process are close to the threshold (such as memory usage exceeding 80% or slightly exceeding the heartbeat interval), or that secondary functions are abnormal (such as zero non-core terminal connections), indicating potential risks. When the health index is between 0.3 and 0.49, the health status is "Fault," indicating that the core functions of the process are abnormal (such as business request response timeout or data transmission packet loss rate > 5%), or that resource indicators are severely out of limit (such as CPU usage consistently exceeding 90%), which has affected some business operations. When the health index is between 0 and 0.3, the health status is "Crash," indicating that the process has stopped running, or that core business operations have completely failed (such as SCADA). Data acquisition is interrupted, remote control commands are unresponsive, and the container restarts frequently (≥3 times per hour).

[0055] Command details: The commands and parameters used to start or run a process, helping to trace the process's startup configuration.

[0056] Process type: Used to distinguish different types of processes, such as "regular process", "critical process", etc.

[0057] Management status: Indicates whether the management function of the current process of the container is activated.

[0058] The container state management definition fields include:

[0059] Container status: including "online", "offline", "restarted", and "error" status.

[0060] Container health status; including "Healthy", "Good", "Alarm", "Faulty", and "Crash".

[0061] The sub-scenario state management is used to track and control the overall health status of the container, ensuring that the sub-scenario state of the container is adjusted in real time according to changes in internal processes and responds in coordination with the host system; including:

[0062] Scene ID: The identifier of the running scene in which the container resides.

[0063] Sub-scenario: The specific functional module or service module to which the container belongs.

[0064] Sub-scene instance: The specific sub-scene instance ID, used to distinguish multiple instances.

[0065] Sub-scenario application status: Host machine sub-scenario status, including "Master", "Standby", "Fault", and "Exit".

[0066] Health status: The health status of the host machine sub-scenario, including "healthy", "good", "alarm", "fault" and "crash".

[0067] Health Index: Describes the health status of sub-scenes by dividing the range between 0 and 1.

[0068] (3) Build a container image and pre-configure the container hostname resolution engine and process management configuration; during the container deployment phase, set the container name, environment variables and container number that conform to the container naming rules through custom configuration;

[0069] By constructing a three-pronged application deployment mechanism encompassing "structured name resolution, environment variable configuration, and container platform adaptation," a deep binding between container hostnames and application information is achieved, ensuring that containers can automatically start and connect to the corresponding sub-scenarios. This includes:

[0070] During the container image building phase, process management processes and configuration files are injected, along with the container hostname resolution engine and environment variables.

[0071] During the container management configuration phase, container environment variables are set to override the preset environment variables when building the image. This allows users to customize environment variables to preset different container startup modes. Container process startup parameters are set to replace preset process parameters, enabling container processes to run in diverse scenarios. The container name is set to a formatted name according to the container naming rules. The container group offset is set, and the number of container replicas is set. The scenario, sub-scenario, and sub-scenario instance information are extracted through the container hostname resolution engine.

[0072] (4) When the container starts, the container name is resolved by the container hostname resolution engine to identify the scene, sub-scene and container number to which the current container belongs. Based on the container name resolution result, it is determined whether the container is a sharded container or a non-sharded container, and the sub-scene instance number is determined.

[0073] The scene information recognition is as follows:

[0074] The container hostname resolution engine parses the container name and identifies the current container's context, sub-context, and container number. Contexts include real-time, study, and PDR states. The matching rules for context states are as follows:

[0075] When the environment variable MORE_STAE_RUN configured in step (3) is true, it is marked as a polymorphic running mode. At this time, the container hostname does not contain scene information, for example: dsca_areagroup1_crucial_1; the container starts the real-time process by default, and will also start the scene configured by the environment variable MORE_STAE_LIST (start polymorphic list) set in step (3). The value of MORE_STAE_LIST is an array type, and multiple scenes are separated by commas.

[0076] When the environment variable MORE_STAE_RUN configured in step (3) is false, it is marked as a single-state running mode. At this time, the container hostname will contain scene information, such as real in dsca_areagroup1_crucial_real_1. The rules for matching the scene state in the hostname are as follows: matching _real_ corresponds to realtime, matching _pdr_ corresponds to prd inversion state, matching _study_ corresponds to learning state, etc. The sub-scene state is determined by parsing the suffix in the container name. After the container starts, the identified current scene and sub-scene processes are launched.

[0077] The identification of sub-scenes and sub-scene instance numbers is as follows:

[0078] The container hostname resolution engine parses the container name to extract the sub-scene and container number. Combined with the environment variable OFFSET_AREAGROUP_X (shard group offset) injected in step (3), the sub-scene instance number is calculated, which specifically includes:

[0079] The sub-scene type is determined by parsing the middle part of the container name, which includes either a fragmented container (areagroup) or a non-fragmented container (dscada). The areagroup type corresponds to the fragmented sub-scene dscada_area, with the matching rule being areagroup[0-9]+_[az]+_[0-9]+. The dscada type corresponds to the non-fragmented sub-scene dscada, with the matching rule being dscada+_[^_]+_[^_]+_[0-9]+.

[0080] When a container starts, it is configured according to step (3) to start a specified number of containers. The suffix of the container hostname of each container is the container number. The container numbers are sorted in Arabic numerals to ensure the uniqueness of the containers. The container hostname resolution engine matches the last digit of the hostname as the container number shard.

[0081] When the container type is dscada, the container corresponds to a non-sharded sub-scene, and the sub-scene instance number is the container number shard identified above. When the container corresponds to a sharded sub-scene, firstly, the shard group number X is extracted according to the container name areagroupX, and then the environment variable OFFSET_AREAGROUP_X=offset is set in step (3). The sub-scene instance number subscn_inst is calculated as follows: sub-scene instance number subscn_inst = container number shard + offset offset - 1.

[0082] This embodiment provides a configuration example of deploying a 4-shard sub-scene under 2 container groups as follows: In step (3), the OFFSET_AREAGROUP_1 value of container group 1 is configured to be 1 (the starting offset of container group 1 is 1), and the number of replicas of container group 1 is configured to be 2; the OFFSET_AREAGROUP_2 value of container group 2 is configured to be 2 (the starting offset of container group 2 is 3), and the number of replicas of container group 2 is configured to be 2. At this time, according to the calculation relationship between the sub-scene instance number and the offset, it is determined that the sub-scene instance [1-2] interval is assigned to container group 1, and the sub-scene instance [3-4] interval is assigned to container group 2.

[0083] (5) After the container starts, the process management calculates the container health index based on the process health index of the sub-scene in the container and synchronizes it to the container status. If the container health index is lower than the preset threshold, the container failure is triggered. The container failure is cascaded to the host machine sub-scene and triggers the corresponding failure handling.

[0084] A dual fault detection mechanism is constructed, integrating process management monitoring and sub-scenario process health status reporting, through high-performance shared memory communication and state synchronization. This includes:

[0085] The process management and monitoring system construction process includes: Process management is launched when the container starts. It reads the process name and process type from the preset process management configuration file and initializes this process information in the shared memory of the process management system. At this time, the process information in the shared memory is in an inactive state. When a sub-scenario process is launched, it registers with the process management system and activates its process state. Activated processes are monitored sequentially by the process management system to detect whether they are abnormal or have disappeared. If an irreversible failure occurs in a process (core dump, process crash, program interruption), the process management system responds differently depending on the importance of the process type. For ordinary processes, the process management system sets the failed process state to offline and restarts the process. For critical processes, the process management system transmits the failure information to the cascaded host sub-scenario through the message bus and triggers a container restart operation.

[0086] A sub-scenario process health status reporting system is constructed, using a data tracking mechanism to mark processes in real time at key locations within the sub-scenario. When a process becomes unresponsive within a certain timeframe (e.g., CPU usage is normal, but there is no output), the sub-scenario is marked as "frozen" or at a fault level, and this is written to the health index of the shared memory process. During sequential monitoring, process management calculates the container's health index by combining the health indices of each process within the container, and synchronizes this index to the container's status. When the container's health index falls below a specific threshold, the process triggers a container failure, and the process is restarted.

[0087] The container health index calculation adopts a "layered weighted combined with state correction" approach. Layering is based on the type attribute (critical process / normal process) of the processes in the sub-scene within the container, which is used to assign differentiated weights. State correction is then dynamically adjusted based on the process health status. The calculation process includes:

[0088] Process weighting: critical processes The weight range is (0.7~0.9), for normal processes. The weight range is (0, 1 to 0.3), with processes of the same type having the same weight. Process weights are normalized to ensure the total weight matches the number of processes, avoiding exponential overflow within the 0-1 range. For example, if a container contains m critical processes and k ordinary processes, with a total process count n = m + k, then the normalization calculation must satisfy the following:

[0089] .

[0090] Container health baseline index calculation: The health index of sub-scene processes within the container ranges from 0 to 1. It is then weighted and summed with the normalized weights of the corresponding processes. Processes with higher weights contribute more to the container's baseline index. The calculation formula is as follows:

[0091] ;

[0092] in Let i be the health index of the i-th process. It is the normalized weight of the i-th process.

[0093] Dynamic adjustment calculation of basic index: This embodiment does not consider the impact of differences in the health status of processes on the calculation of basic index, and introduces a process status correction factor. Strong constraints on critical process failures The base index is dynamically adjusted to calculate the final container health index. The process status correction factor corresponds one-to-one with the process health status: a health status of "healthy" corresponds to a status correction factor of 1.0; a health status of "good" corresponds to a status correction factor of 0.95; a health status of "alarm" corresponds to a status correction factor of 0.8; a health status of "fault" corresponds to a status correction factor of 0.5; and a health status of "crash" corresponds to a status correction factor of 0.1.

[0094] Critical process failure forced constraint factor (Values ​​range from 0.3 to 0.5), a secondary constraint is applied to the corrected index process to ensure that when a critical process fails, the container health index directly falls into the corresponding interval of the "failure / alarm" health status, providing a basis for failure cascading. First, the average state correction coefficient is calculated using the following formula:

[0095] ;

[0096] in, The state correction factor for the i-th process determines whether there is a critical process with a health state of "fault / alarm". If so, a mandatory constraint factor is triggered. (Values ​​range from 0.3 to 0.5), if it does not exist then =1.0. The formula for calculating the container health index is:

[0097] = .

[0098] State mapping: The final container health index is mapped to a preset 0-1 threshold range to determine the health status of the container and synchronized to the container state management model, providing a quantitative basis for fault triggering and cascading processing.

[0099] The container and process status information is cascaded and synchronized to the host machine. When a critical process or container failure is detected, the application-level status change and fault response on the host machine are triggered. When the container process management starts, the container type is extracted from the host name of the container. The host name contains CRUCIAL to mark the container type as a core container and NORMAL to mark a normal container. The container name also contains SCA to cascade and register with the host machine's SCADA application, and DSCA to cascade and register with the host machine's DSCADA application. The following two methods are supported for cascading to the application on the host machine.

[0100] Method 1: Container-level process management cascades with host process management via the message bus. This allows all processes within the container to be monitored by external process management. When a process within the container fails, external process management can respond quickly and also view the health status of all processes running within the container, greatly reducing the difficulty of troubleshooting host application failures. Host process management receives notification messages from container-level process management and responds to failures. For example, when host process management receives a container status of "offline" or "failed," it cascades and synchronizes the corresponding process status in host process management to "offline" or "failed," recalculates the host sub-scenario health index, and if it's a critical process, simultaneously triggers an application-level failure (host sub-scenario failure), potentially triggering other system emergency responses.

[0101] Method 2: The host machine's container status management system polls and monitors the container status, registering the containers as logical processes within a sub-scenario with the host machine's process management system. Status and health indices are reported and synchronized in real time. The host machine's process management system polls and monitors the health indices of the container's logical processes. When the health index of a container's logical process changes, it triggers a change in the health index of the host machine's sub-scenario. For example, if a critical container's health status is set to "fault," the health index of the host machine's container logical process is cascaded and synchronized to "fault," and the health index of the host machine's sub-scenario is recalculated. If it is a critical container logical process, this also triggers an application-level fault, potentially triggering other system emergency responses.

[0102] (6) Based on the predefined shard group configuration information, verify the instance allocation of each container group, diagnose and handle instance crossover or overflow anomalies.

[0103] When shard group offsets overlap in different container groups, container management can automatically diagnose the abnormal container and remove it. Diagnostic verification is performed after all container groups and containers are launched. For example, if the OFFSET_AREAGROUP_1 value in container group 1 is 1 (the starting offset of container group 1 is 1), and the replica count of container group 1 is 3; and the OFFSET_AREAGROUP_2 value in container group 2 is 3 (the starting offset of container group 2 is 3), and the replica count of container group 2 is 2, then based on the calculation relationship between the sub-scene instance number and the offset, the sub-scene instance range [1-3] is assigned to container group 1, and the range [3-4] is assigned to container group 2. Instance number 3 will appear in both container groups 1 and 2.

[0104] During container management initialization, it pre-reads the shard group definition table. First, it verifies whether the number of container group instances matches the number of shards in the shard group definition table. If so, it takes the extra containers in the container group offline and issues an alarm. A modeling example of the shard group definition table is shown in Table 1:

[0105] Table 1:

[0106] Sub-scene Segmentation Group Number of slices Fragmentation Start Sequence 1 Fragmentation Start Sequence 2 Fragmentation start order n dscada areagroup1 2 1 2 dscada areagroup2 2 3 4

[0107] Example 2

[0108] This embodiment provides a specific example of the method for identifying containerized operation status information and detecting faults in power systems.

[0109] This embodiment provides the following three container naming representations:

[0110] Container name 1: dsca_areagroup1_crucial_real_1 (SCADA Container No. 1 in Distribution Network Sharding Group No. 1, Key Real-Time Container), belongs to the single-scenario sub-scenario container deployment mode (one container can only support the deployment of one scenario sub-scenario), and is a key container for SCADA applications.

[0111] Container name 2: dsca_dscada_crucial_study_2 (Critical learning state container for SCADA without sharding), belongs to the multi-scenario sub-scenario container deployment mode (one container supports the deployment of multiple scenario sub-scenario processes), and is a critical container for dscada applications.

[0112] Container name 3: dsca_areagroup1_general_pdr_2 (Distribution network SCADA No. 2 container shard group 2 ordinary inversion state container), belongs to the single-scenario sub-scenario container deployment mode (one container supports the deployment of one scenario sub-scenario process), and is a dscada application ordinary container.

[0113] In container state management, configure the hostname of the DSCADA data processing container to be the container name defined above. The following explanation uses container name 1 as an example.

[0114] During the image building phase, the container name resolution engine script service.sh is injected into the image. The Dockerfile is configured to automatically execute service.sh to start container name resolution and launch critical processes within key containers when the container starts. An example of the Dockerfile configuration is as follows:

[0115] ENV run_mode="start"

[0116] RUN echo " / home / nusp / service.sh \$run_mode" > / home / nusp / start.sh &&chmod 777 / home / nusp / start.sh

[0117] ENTRYPOINT / home / nusp / start.sh

[0118] Taking the deployment of 2 DSCADA container shard groups and 4 shard containers as an example, with each container shard group running 2 containers, first, configure the offset of DSCADA data processing container shard group 1 to 1 and the starting offset of container shard group 2 to 2 in the container management. An example configuration of DSCADA data processing container management in `dsca_analog_config.yaml` is as follows:

[0119] env:

[0120] - OFFSET_AREAGROUP_1:1

[0121] - OFFSET_AREAGROUP_2:3

[0122] When a container starts, the hostname resolution engine `service.sh start` is automatically executed to start the processes within the container. The `service.sh` script first extracts information such as system type, container group, and scene sub-scene from the container hostname, which is used to dynamically load configurations and routing strategies. Combined with environment variables, it completes runtime adaptation, achieving configuration isolation and communication coordination between multiple instances. The execution flow of the container name resolution engine `service.sh` includes:

[0123] Initialize local variables in the script, read the DSCADA data processing container environment variable run_more_state (polymorphic model run) preset by the container management, verify the correctness of the container hostname based on the value of the variable run_more_state, if the container name contains the scenario keyword, it only supports single-scenario deployment, if it does not contain the scenario keyword, it supports multi-scenario deployment, and finally complete the local variable container name into the standard name "system identifier_container group_container type_scenario_container number".

[0124] set check_hostname_format = 0

[0125] if ("$sh_run_more_state" == "true") then

[0126] echo "$dockername" | grep -Eq '^.*_analog_[^_]+_[^_]+_[0-9]+$'

[0127] set check_hostname_format = $status

[0128] if ($check_hostname_format != 0) then

[0129] exit

[0130] endif

[0131] set last_digit = `echo "$dockername" | sed -E 's / .*_([0-9]+)$ / \1 / '`

[0132] set dockername_base = `echo "$dockername" | sed -E 's / _[0-9]+$ / / '`

[0133] set dockername = "${dockername_base}_real_${last_digit}"

[0134] Endif

[0135] Regular expressions are used to match standard name keywords to identify application-state variables, which are then stored in the local variable `state`. The expression `echo "$name_only" | grep -Eq '([a-zA-Z]_)?dscada+_[^_]+_[^_]+_[0-9]+$'` is used to match whether a dscada container is unsharded, and this is stored in the local variable `is_dscada`. The expression `echo "$name_only" | grep -Eq '^areagroup[0-9]+_[^_]+_[^_]+_[0-9]+$'` is used to match whether a dscada container is sharded, and this is stored in the local variable `is_areagroup`.

[0136] The sub-scene and its instance number are calculated based on is_areagroup and is_dscada, indicating the process running within the container. This includes:

[0137] When the variable `is_areagroup` is true, it indicates that the process is running under the sharded sub-scene `dscada_area`. The calculation of the sub-scene instance number first requires identifying the shard group number `X` in the container name keyword `areagroupX`. Then, it reads the pre-set environment variable `OFFSET_AREAGROUP_X` (the starting offset of container group number `X`). Finally, it calculates the sub-scene instance ID number based on the identified and resolved container number. The sub-scene instance number `subscn_inst` = container number `shard` + container group offset `offset` - 1. An example of the calculation script is as follows:

[0138] if ($is_areagroup == 0) then

[0139] set areagroup = `echo $name_only | cut -d'_' -f1`

[0140] set app = "dscada_area"

[0141] set areagroup_number = `echo $areagroup | sed -E 's / areagroup([0-9]+) / \1 / '`

[0142] set shard = `echo $name_only | awk -F'_' '{print $NF}'`

[0143] set offset_var = "OFFSET_AREAGROUP_$areagroup_number"

[0144] set offset = `printenv $offset_var`

[0145] if ( "$offset" == "") then

[0146] set offset = 1

[0147] endif

[0148] endif

[0149] @subscn_inst = $shard + $offset - 1

[0150] When the variable is_dscada is true, it indicates that the process is running in a non-fragmented sub-scada environment, with the sub-scada instance number and container number as the identifier.

[0151] Depending on the scenario, the sub-scenario and sub-scenario instance number are used to launch critical processes within the container. This also includes other logic that is determined by preset environment variables. For example, if it is a multi-scenario deployment mode (i.e., the environment variable MORE_STAE_RUN is true), before launching processes within the container, the value of the environment variable MORE_STAE_LIST will be read, and the processes will be launched in all scenarios configured in MORE_STAE_LIST.

[0152] During the image building phase, the process management configuration file `container_proc_mng.ini` is injected into the image. `container_proc_mng.ini` configures the core information of processes allowed to be registered with the container's process management, including sub-scene process names and process type attributes. An example of the `container_proc_mng.ini` configuration is as follows:

[0153] [dscada]

[0154] dms_doc_analog=crucial

[0155] dms_analog_event=general

[0156] [dscada_area]

[0157] dms_doc_analog=crucial

[0158] dms_analog_event=general

[0159] During the container startup phase, the container process management is initiated through the container name resolution engine. The shared memory for process management within the container is initialized by reading container_proc_mng.ini. Taking container 1 (without sharding) as an example, the key fields of the shared memory initialization information are as follows: Status 0 and Index 0 indicate initialization, Type 1 indicates a critical process, Type 0 indicates a normal process, Command "." indicates that the full command for starting the managed process, including startup parameters, will be obtained, and PID indicates the PID information assigned by the operating system after the process starts, as shown in Table 2.

[0160] Table 2:

[0161] process name Scene Sub-scene Sub-scene instance state health status Health Index Management Status type Order PID dms_doc_analog realtime dscada 1 initial 0 0 0 1 . . dms_analog_event realtime dscada 1 initial 0 0 0 0 . . dms_doc_analog pdr dscada 1 initial 0 0 0 1 . . dms_analog_event pdr dscada 1 initial 0 0 0 0 . .

[0162] During the container startup phase, the container process management matches the keywords "critical" or "general" in the container name to identify whether the container type is critical or ordinary. Based on the identified DSCA keywords, it registers with the host process management via the message bus and registers with the host DSCADA sub-scenario. At this time, all processes in the container are also indirectly monitored in real time by the host process management.

[0163] The container's process management system cascades and registers with the host machine's process management system via a message bus, simultaneously reporting process status and container type (registering the container type as the process type in the host machine's process management system). The host machine can then view all registered processes and their status information within the container through the process management system. When a process within the container fails, such as a core failure, the host machine's process management system receives a notification message from the container's process management system and synchronizes the host machine's process status to offline. Upon detecting the offline status, the host machine switches the application to a standby machine. Simultaneously, the container's process management system responds differently depending on the process type (critical / normal). If the process type is normal, the system restarts the process according to the registration command. If the process type is critical, the system automatically restarts it three times; if it still cannot restart, it notifies the container management system to restart the container.

[0164] The host container management registers each scheduled container as a separate logical process with the host process management; the container process management calculates the container's health status based on the health status of all processes within the container and reports the synchronized health status to the container management; the host process management monitors the container status, and when the health index of a container's logical process changes, it triggers a change in the host application's health index. For example, if the health status of a critical container is set to "fault," the health index of the host container's logical process will be cascaded and synchronized to "fault," and the host sub-scenario health index will be recalculated. If it is a critical container logical process, an application-level fault will be triggered simultaneously, which may trigger other emergency responses in the system.

[0165] A process management and monitoring system is constructed. Process management is initiated when the container starts. By reading the process name and process type from the preset process management configuration file, it initializes this process information into the shared memory of process management. At this time, the process information in the shared memory is in an inactive state. When a sub-scenario process within the container is launched, it registers with process management and activates its process state. The activated process is polled and monitored by process management to detect whether the activated process is abnormal or disappears. If an irreversible failure occurs in a process (core dump, process crash, program interruption), process management responds differently depending on the process type (importance). For ordinary processes, process management sets the failed process state to offline and restarts the process. For critical processes, process management transmits the failure information to the cascaded host sub-scenario through the message bus and triggers the container state management to restart the target container.

[0166] A sub-scenario process health status reporting system is constructed, utilizing a data tracking mechanism to mark key process locations in sub-scenarios in real time. When a process becomes unresponsive within a certain timeframe (e.g., CPU usage is normal, but there is no output), the sub-scenario process is marked as "frozen" or at a fault level, and this is written to the shared memory process health index. During polling and monitoring, process management calculates the container's health index based on the health indices of each process within the container and synchronizes it to the container status. When the container's health index falls below a specific threshold, the process triggers a container failure, and the process is restarted.

[0167] This embodiment provides a specific example of calculating the container health index. The process information of the sub-scene within the container is shown in Table 3.

[0168] Table 3

[0169] Serial Number process name Process type Process Health Index Process status summary 1 dsca_analog Key Process 0.95 healthy 2 dsca_point Key Process 0.40 Fault 3 dsca_event normal process 0.75 good

[0170] Calculate the normalized value:

[0171] Key Process 1 or 2: Single Weight =0.8 / (2+1)=0.2667;

[0172] Normal Process 3: Single Weight =0.2 / (2+1)=0.0667;

[0173] Normalized value verification: 2*0.2667+1*0.0667=0.6, which is consistent with the health index range of 0-1.

[0174] Calculate the container's basic health index:

[0175] =(0.95×0.2667)+(0.40×0.2667)+(0.75×0.0667)=0.2534+0.1067+0.0500=0.4101;

[0176] State correction and final index calculation: First, assign values ​​to the state correction factor. Process 1 is considered healthy. =1.0; Process 2 is faulty; =0.5; Process 3 is in good condition: =0.95.

[0177] Calculate the mean state correction factor:

[0178]

[0179] Among them, the status of critical process number 2 is "faulty", triggering... =0.4;

[0180] The final index is calculated as follows:

[0181] =0.4101×0.7725×0.4=0.4101×0.309=0.1267.

[0182] in, According to the mapping rules, the container's health status is crashed.

[0183] Example 3

[0184] This embodiment provides a containerized operation status information identification and fault detection system for power systems, including:

[0185] Naming rule definition module: Defines container naming rules including system identifier, container group, container type, scenario, and container number;

[0186] The three-level modeling module constructs process management, container state management, and sub-scenario state management models. The process management definition fields include process name, process PID, scenario, scenario instance, sub-scenario, sub-scenario instance, process state, health index, and health state. The container state management definition fields include container state, health index, and health state. The sub-scenario state management definition fields include scenario ID, sub-scenario, sub-scenario application state, health index, and health state.

[0187] Configuration module: Builds container images and pre-configures container hostname resolution engine and process management; during container deployment, it allows users to customize the container name, environment variables, and container number to conform to the container naming rules.

[0188] Scene recognition and instance number confirmation module: When the container starts, the container name is resolved by the container hostname resolution engine to identify the scene, sub-scene and container number to which the current container belongs. Based on the container name resolution result, it is determined whether the container is a sharded container or a non-sharded container, and the sub-scene instance number is determined.

[0189] Fault cascading module: After the container starts, the process management calculates the container health index based on the process health index of the sub-scenes within the container and synchronizes it to the container status. If the container health index is lower than a preset threshold, a container fault is triggered. The container fault is cascaded to the host machine sub-scenes and triggers corresponding fault handling.

[0190] This embodiment is based on the same inventive concept as Embodiment 1, and will not be repeated here.

[0191] Example 4

[0192] This embodiment provides a computer device, including one or more processors, a memory, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, and the programs, when executed by the processors, implement the steps of the method for identifying and detecting containerized operating status information of a power system.

[0193] Example 5

[0194] This embodiment provides a computer-readable storage medium storing a computer program thereon. When the computer program is executed by a processor, it implements the steps of the method for identifying containerized operating status information and detecting faults in a power system.

Claims

1. A method for identifying containerized operating status information and detecting faults in a power system, characterized in that, include: Define container naming rules that include system identifier, container group, container type, scenario, and container number; Construct process management, container status management, and sub-scenario status management models; the process management defined fields include process name, process PID, scenario, scenario instance, sub-scenario, sub-scenario instance, process status, health index, and health status; the container status management defined fields include container status, health index, and health status; the sub-scenario status management defined fields include scenario ID, sub-scenario, sub-scenario application status, health index, and health status. Build a container image and pre-configure the container hostname resolution engine and process management settings; during the container deployment phase, set the container name, environment variables, and container number that conform to the container naming rules through custom configuration. When a container starts, the container name is resolved by the container hostname resolution engine to identify the scene, sub-scene and container number to which the current container belongs. Based on the container name resolution result, it is determined whether the container is a sharded container or a non-sharded container, and the sub-scene instance number is determined. After the container starts, the process management calculates the container health index based on the health index of the sub-scene processes within the container and synchronizes it to the container status. If the container health index is lower than a preset threshold, a container failure is triggered. The container failure is cascaded to the host machine's sub-scene status management and triggers corresponding failure handling.

2. The method for identifying and detecting faults in containerized operation status information of a power system according to claim 1, characterized in that, The container naming rules adapt to a four-tuple management format including scenario, scenario instance, sub-scenario, and sub-scenario instance; the system identifier indicates the subsystem to which the container belongs, the container group determines the container cluster affiliation, including sharded containers and non-sharded containers; the container type is used to distinguish containers, including critical containers and ordinary containers; the scenario includes real-time state, learning state, and inversion state; the container number indicates the number of replicas of the container and corresponds to the sub-scenario instance number.

3. The method for identifying containerized operation status information and detecting faults in a power system according to claim 1, characterized in that, The process name is the process name registered in the process management of the container; the process PID is the unique identifier of the process; the scenario includes real-time state, learning state, and inversion state; the scenario instance is the instance identifier of the process running scenario; the sub-scenario is the subsystem in which the specific process runs; the sub-scenario instance is the instance identifier of the sub-scenario; the process state is the current running state of the process, including online and offline; the health status includes healthy, good, alarm, fault, and crash. The container status includes online, offline, restarted, and error; The scenario ID is the identifier of the running scenario in which the container is located; the application status of the sub-scenario includes host, standby, fault, and exit.

4. The method for identifying containerized operation status information and detecting faults in a power system according to claim 1, characterized in that, The health index describes the health status using a range from 0 to 1. Specifically, a health index of 0.9 to 1.0 indicates a healthy health status; a health index of 0.7 to 0.89 indicates a good health status; a health index of 0.5 to 0.69 indicates an alarm health status; a health index of 0.3 to 0.49 indicates a fault health status; and a health index of 0 to 0.3 indicates a crash health status.

5. The method for identifying containerized operation status information and detecting faults in a power system according to claim 1, characterized in that, The process of identifying the current container's scenario includes: if the environment variable MORE_STATE_RUN is in a polymorphic running mode, the container name does not contain scenario information; if the environment variable MORE_STATE_RUN is in a unimorphic running mode, the scenario field is parsed from the container name, and the process corresponding to that scenario is started.

6. The method for identifying containerized operation status information and detecting faults in a power system according to claim 1, characterized in that, The sub-scene process within the sharded container runs in the sharded sub-scene, and the sub-scene process within the non-sharded container runs in the non-sharded sub-scene; if it is a sharded sub-scene, the sub-scene instance number is calculated according to the formula: sub-scene instance number = container number + offset - 1; if it is a non-sharded scene, the sub-scene instance number is the container number, which is obtained by resolving the container name using the container hostname resolution engine.

7. The method for identifying containerized operation status information and detecting faults in a power system according to claim 1, characterized in that, The method further includes: when the sub-scene process is running, registering and activating the process state with the process management. The activated process is monitored by the process management, which detects whether the activated process is faulty. If it is a normal process, the process management sets the faulty process state to offline and restarts the process. If it is a critical process, the process management transmits the fault information to the cascaded host sub-scene state management through the message bus and triggers the container restart operation.

8. The method for identifying containerized operation status information and detecting faults in a power system according to claim 7, characterized in that, The method of transmitting fault information to the cascaded host sub-scene state management includes two ways: the process management transmits the fault information to the container state management, the container state management triggers the corresponding operation, and cascades to the host sub-scene state management to trigger the host sub-scene fault; or the process management transmits the fault information to the cascaded host process management to trigger the host sub-scene state management to trigger fault handling, and issues instructions to the container state management to trigger the corresponding operation.

9. The method for identifying containerized operation status information and detecting faults in a power system according to claim 1, characterized in that, The method also includes diagnostic verification of fragmented containers: when the offsets of fragmented containers in different container groups intersect, abnormal containers are diagnosed and removed through container status management.

10. A containerized operation status information identification and fault detection system for power systems, characterized in that, include: Naming rule definition module: Defines container naming rules including system identifier, container group, container type, scenario, and container number; The three-level modeling module constructs process management, container state management, and sub-scenario state management models. The process management definition fields include process name, process PID, scenario, scenario instance, sub-scenario, sub-scenario instance, process state, health index, and health state. The container state management definition fields include container state, health index, and health state. The sub-scenario state management definition fields include scenario ID, sub-scenario, sub-scenario application state, health index, and health state. Configuration module: Builds container images and pre-configures container hostname resolution engine and process management; during container deployment, it allows users to customize the container name, environment variables, and container number to conform to the container naming rules. Scene recognition and instance number confirmation module: When the container starts, the container name is resolved by the container hostname resolution engine to identify the scene, sub-scene and container number to which the current container belongs. Based on the container name resolution result, it is determined whether the container is a sharded container or a non-sharded container, and the sub-scene instance number is determined. Fault cascading module: After the container starts, the process management calculates the container health index based on the process health index of the sub-scenes within the container and synchronizes it to the container status. If the container health index is lower than a preset threshold, a container fault is triggered. The container fault is cascaded to the host machine sub-scenes and triggers corresponding fault handling.

Images