Digital Twin Event, Incident, and Alarm Sensing Methods and Systems for Distribution Network Operation

Abstract

This invention discloses a method and system for sensing events, matters, and alarms in a digital twin of distribution network operation, belonging to the field of power grid dispatching application technology. The method includes framework design, access cluster, registration management, storage service, and access service. This invention utilizes microservices and component technology to identify continuous time-based data from the digital twin of distribution network operation concurrently, sensing various events, matters, and alarm information. This information flows and is computed between microservices and between components within microservices in an asynchronous message manner, improving the accuracy of distribution network operation alarm information.

Description

Technical Field

[0001] This invention relates to the field of power grid dispatching application technology, and in particular to a method and system for sensing digital twin events, incidents and alarms in distribution network operation. Background Technology

[0002] The new distribution network operation and digital twin system connects to massive distributed resources by deploying a series of highly reliable and flexibly reusable intelligent distribution equipment. It also connects to the main distribution network dispatching system for grid models and operational data, to the metering system for metering data, to the new power load management system for controllable load data, to the GIS (Geographic Information System) for distribution network maps and geographic information, and to the emergency response system for disaster relief data. The system aggregates a large amount of multimodal heterogeneous data; identifying this data and enabling accurate generation of event tracing, incident reporting, and alarms has become a pressing issue.

[0003] In the current power grid dispatching system, event services or alarm services in a primary / backup mode are deployed. The message processing capacity is constrained by the resources of a single server, and only critical event signals and alarm signals affecting the operation of the power grid are processed during runtime. Summary of the Invention

[0004] This invention addresses the shortcomings of existing technologies by providing a method and system for sensing digital twin events, incidents, and alarms in power distribution network operation.

[0005] The technical solution of the present invention to solve the above-mentioned technical problems is as follows:

[0006] In a first aspect, the present invention provides a method for sensing digital twin events, incidents, and alarms in power distribution network operation, comprising:

[0007] Framework Design: Provides a general event stream computing framework based on microservice framework and component model, integrates event classification definition and component event tracing methods for scheduling and execution, coordinates multi-cluster processing of various scanning services, registration management services, storage services, and real-time and historical retrieval and maintenance services; provides message publishing and subscription interfaces for general events and alarms;

[0008] Cluster access: A containerized component is used to start scanning services for events, items, and alarms by configuring service type categories; the containerized component includes all components of a containerized scanning service, all components of a containerized registration management service, and all components of a containerized storage service.

[0009] Registration Management: Implements item / alarm caching based on shared pointers and JSON objects, synchronously maintaining related tables in the backend real-time database, including item tables and alarm tables;

[0010] Storage services: Collaborative object storage and various databases complete message storage for events, matters, and alarms;

[0011] Access services: Real-time event / alarm service accesses the distributed real-time database, providing real-time maintenance and various query services; historical event / event / alarm service accesses the object storage, time-series database or relational database in the running data center domain, providing various query services for stored historical data.

[0012] Furthermore, the cluster includes: a scanning service cluster, a registration management service cluster, a storage service cluster, and a real-time and historical access service cluster, which identify continuous time-based data of the digital twin of the power distribution network operation through concurrent operation, and perceive various events, matters, and alarm information.

[0013] Furthermore, in the scanning service cluster, messages are transmitted between components in an event-driven manner, refining component reuse methods; by parsing the service type configured in the YAML file of the scanning service container image startup, an event scanning service is started to access the operation log when it is an event; an event scanning service is started to access the operation and maintenance signals when it is an item, and the item or alarm is processed; an alarm scanning service is started to access the scheduling data when it is an alarm, to sense event or alarm information, and the message is classified and published to the registration management service cluster.

[0014] Furthermore, in the registration management service cluster, the item / alarm cache synchronously associates and maintains the item or alarm-related tables in the distributed real-time library through snapshot profile technology to realize message registration and management; the data processed by each component is cached in the profile library, and the cache publishing component publishes all cached known data when it runs.

[0015] Furthermore, in the aforementioned event storage service, the event stream subscription component starts the storage stream, periodically caches the time-series library storage component, and periodically stores a valid event set M: if the time-series library is normal, the interface performs a full-scale overwrite storage and deletes the event corresponding to M from the cache queue; if the returned storage result contains an error, the database alarm publishing component is called to publish the returned error information; whereby the validity of an event is distinguished by identifying the message structure (warnStruc) and its data type, such as if warnStruc.object identifier cannot find an object record in the real-time library parameters, it is an event that is not associated with the system and can be considered invalid;

[0016] In the alarm storage service, a timed cache relational database storage component is added on the basis of the event storage component function. When the relational database is normal, the function corresponding to the alarm batch storage interface first determines whether there is an alarm record in the relational database that matches the unique attribute of the alarm information. If there is, it is deleted, and then the batch insertion of the alarm set is performed.

[0017] Furthermore, in the real-time and historical retrieval and maintenance services, real-time event services and real-time alarm services are provided based on the real-time event / alarm service container image; historical event services, historical event services, and historical alarm services are provided based on the historical event / event / alarm service container image; among them, the real-time alarm service provides alarm generation, query, maintenance, confirmation, and deletion operations, while other services provide various query functions.

[0018] Furthermore, a component is encapsulated in a container, wherein the container is represented by a hexagon, wherein:

[0019] The top provides subscription / publishing for the running message bus; the top left provides distributed task scheduling, scheduling related services to run on appropriate nodes; the top right provides access to the distributed service bus; the bottom right provides services such as relational databases / time-series databases / object storage; the bottom provides basic resources; and the bottom left provides distributed real-time libraries and file services. The container is designed with components arranged in a tree structure, using the root component to distinguish the driver loading method of components within a service. Various messages can be distributed, concurrently processed, and aggregated among components within the microservice based on message queues.

[0020] Secondly, the present invention provides a digital twin event, incident, and alarm sensing system for power distribution network operation, comprising:

[0021] Framework design module: Provides a general event stream computing framework based on microservice framework and component model, integrates event classification definition and component event tracing method for scheduling and running, coordinates multi-cluster processing of various scanning services, registration management services, storage services, real-time and historical retrieval and maintenance services; provides message publishing and subscription interfaces for general events and alarms;

[0022] Cluster access module: It uses a container to encapsulate the scanning service component, and starts scanning services for events, items and alarms by configuring service type.

[0023] Registration Management Module: Implements event / alarm caching based on shared pointers and JSON objects, synchronously associates and maintains relevant tables in the backend real-time database; enables functions such as message listening, registration caching, hierarchical filtering, information fitting, batch extraction, category editing, and confirmation maintenance by configuring service type categories for events, events, and alarms.

[0024] Storage service module: Collaborates with object storage and various databases to complete message storage for events, matters, and alarms; Event storage service periodically stores events in object storage as small files; Matter storage service subscribes to matter messages and stores them in a time-series database; Alarm storage service subscribes to alarm messages and stores them in both a time-series database and a relational database.

[0025] Access Service Module: Real-time Event / Alarm Service accesses the distributed real-time database, providing real-time maintenance and various query services; Historical Event / Event / Alarm Service accesses the object storage, time-series database, or relational database in the running data center domain, providing various query services for stored historical data.

[0026] Furthermore, a general event stream computing framework based on a microservice framework and component model provides a method for large-scale clustered deployment and operation of scanning services, registration management services, storage services, and real-time and historical access services. It identifies continuous time-based data of the digital twin of the power distribution network operation through concurrent operation, and perceives various events, events and alarm information. This information is driven by asynchronous messages to flow and compute between microservices.

[0027] Furthermore, in the scanning service cluster, messages are transmitted between components in an event-driven manner, refining component reuse methods; by parsing the service type configured in the YAML file of the scanning service container image startup, an event scanning service is started to access the operation log when an event occurs; an item scanning service is started to access the operation and maintenance signal when an alarm occurs, and the item or alarm is processed; an alarm scanning service is started to access the scheduling data when an item occurs, and the event or alarm information is detected; messages are classified and published to the registration management service cluster.

[0028] In summary, compared with the prior art, the beneficial effects of the above technical solution are:

[0029] This invention utilizes microservice and component technologies to concurrently identify continuous time-based data from the digital twin of power distribution network operation, and to perceive various events, incidents, and alarm information. This information is driven by asynchronous messages to flow and compute between microservices and between components within microservices, thereby improving the accuracy of power distribution network operation alarm information. Attached Figure Description

[0030] Figure 1 This is a flowchart of a method for sensing digital twin events, incidents, and alarms in power distribution network operation in this embodiment;

[0031] Figure 2 This is a diagram of a general event flow calculation framework for flexible regulation in this embodiment;

[0032] Figure 3 This is a service component architecture diagram for defining an event classification in this embodiment;

[0033] Figure 4 This is a component architecture diagram of an event tracing service component in this embodiment;

[0034] Figure 5 This is an architecture diagram of a log / event / alarm scanning service component in this embodiment;

[0035] Figure 6This is an architecture diagram of an event / event / alarm registration management service component in this embodiment;

[0036] Figure 7 This is an architecture diagram of an event / event / alarm storage service component in this embodiment;

[0037] Figure 8 This is an architecture diagram of a real-time event / alarm service component in this embodiment;

[0038] Figure 9 This is an architecture diagram of a historical event / event / alarm service component in this embodiment. Detailed Implementation

[0039] The principles and features of the present invention are described below with reference to all the accompanying drawings. The examples given are only for explaining the present invention and are not intended to limit the scope of the present invention.

[0040] This invention discloses a method and system for sensing digital twin events, incidents, and alarms in power distribution network operation.

[0041] The events, incidents, and alarms processed by the general event service are important information for power distribution network operation and digital twin systems. The relevant definitions are as follows:

[0042] (1) An event is another name for a notification or alarm in the system, used to notify the dispatcher that an operation has been performed in the system or a notification that needs to be released externally during the four-remote processing. The four-remote processes refer to the implementation of remote signaling, remote measurement, remote control, and remote adjustment functions. The four-remote processing refers to the four core operations and data processing methods for remotely monitored objects, namely remote measurement, remote signaling, remote control, and remote adjustment. They are the foundation for realizing remote monitoring and automated dispatching, and are widely used in scenarios such as power dispatching, rail transit, and water conservancy projects.

[0043] (2) Events (warn) are events that system maintenance personnel need to pay attention to. Events with the same characteristics are grouped together by event class, such as state transition, operation tracking, etc. The data structure of an event is warnStruc, and the attributes are designed as follows: warnStruc = [ID, system code, application domain, plant, responsibility area, object identifier, object type (plant / interval / primary equipment / measuring point / secondary equipment / scheduling system equipment), equipment GID (can be null), content, number of times, type, subtype (including statistical type), mode (screen refresh / voice / short message / third party response), level, alarm time (absolute milliseconds), action type (alarm / recovery / accident protection type), statistical type, alarm category (normal / debugging / maintenance), delay in seconds, operation indicator, operation time, operation user, operation node, comment]; In the general event service cluster, events or alarm messages are processed in JSON format, and the data structure can be adjusted online according to scheduling needs.

[0044] (3) An alarm is an abnormal or unsafe event that business application personnel need to pay attention to. An alarm may be issued due to the operation of a physical device or an error state detected by software. An alarm class gathers alarms with some similar characteristics together, defines the behavior, information and some user attributes associated with the information of the alarm; the alarm data structure (alarmStructure) is consistent with the event by default.

[0045] (4) Elastic Event Queues is middleware used to handle the publishing and subscription of messages such as events, items, and alarms, and manages message delivery, routing, and parsing. Based on message queues (Kafka or RabbitMQ) or other communication mechanisms, Elastic Event Queues provides EventBroker event broker service for intra-domain event interaction and EventBridge bridging broker service for cross-domain event interaction, providing a component developer with methods for subscribing to and publishing messages on specific topics.

[0046] (5) Distributed Real-Time Library is a cloud-based distributed real-time database system of elastic control platform. It provides components with efficient snapshot data loading and maintenance tools and can maintain data consistency with relational database in real time.

[0047] (6) Distributed task scheduling is a task scheduling and control system that can schedule microservices running on the elastic control platform to run on suitable nodes, meeting the requirements of node load balancing and rapid migration of faulty services to nodes.

[0048] Reference Figure 1 A method for sensing digital twin events, incidents, and alarms in power distribution network operation includes the following steps:

[0049] S10, Framework Design: Provides a general event stream computing framework based on microservice framework and component model, integrates event classification definition and component event tracing method for scheduling and running, coordinates multi-cluster processing of various scanning services, registration management services, storage services, real-time and historical retrieval and maintenance services; provides message publishing and subscription interfaces for general events and alarms;

[0050] S20, access cluster: The scanning service component is encapsulated in a container, and the scanning service for events, items and alarms is started by configuring the service type.

[0051] S30, Registration Management: Implements event / alarm caching based on shared pointers and JSON objects, synchronously associates and maintains relevant tables in the backend real-time database; enables message listening, registration caching, hierarchical filtering, information fitting, batch extraction, category editing, and confirmation maintenance functions for events, matters, and alarms through service type configuration.

[0052] S40, Storage Service: Collaborates with object storage and various databases to complete message storage for events, items, and alarms; event messages are stored in object storage as small files; item messages are subscribed and stored in the time series database; alarm messages are stored in parallel in the time series database and relational database;

[0053] S50, Access Services: Real-time Events / Alarms Service: Access to the distributed real-time database, providing real-time maintenance and various query services; Historical Events / Events / Alarms Service: Access to object storage, time-series databases, or relational databases in the running data center domain, providing various query services for stored historical data.

[0054] This invention utilizes microservice and component technologies to concurrently identify continuous time-based data from the digital twin of power distribution network operation, and to perceive various events, incidents, and alarm information. This information is driven by asynchronous messages to flow and compute between microservices and between components within microservices, thereby improving the accuracy of power distribution network operation alarm information.

[0055] This invention provides a general event stream computing framework based on a microservice framework and component model, which can dynamically sense signals such as events, events, and alarms caused by multimodal heterogeneous data. It provides flexible event classification definitions and event tracing methods. Through a cluster of microservices such as scanning services, registration management services, storage services, real-time access services, and historical access services, it collaboratively processes event streams, event streams, and alarm streams, which can improve the accuracy of system alarms. It solves the problems of difficult event tracing and limited joint processing capabilities of events and alarms in urban distribution network digital twin systems. Through data identification component stream computing processing, it realizes the application of general event, event, and alarm services in the digital twin system of distribution network operation.

[0056] The microservice framework in this invention uses the microservice development framework disclosed in the invention titled "A Microservice Development Framework and Real-time Monitoring Implementation Method" (announcement number CN201911097910.5). The database system involved uses the database disclosed in the invention titled "A Cloud-based Distributed Real-time Database System" (announcement number CN201910508447.2). The specific details are not repeated in this embodiment.

[0057] The following is a detailed explanation of each of the above steps:

[0058] S10, Framework Design: Provides a general event stream computing framework based on microservice framework and component model, integrates event classification definition and component event tracing method for scheduling and running, coordinates multi-cluster processing of various scanning services, registration management services, storage services, real-time and historical retrieval and maintenance services; provides message publishing and subscription interfaces for general events and alarms.

[0059] This invention provides a general event flow computing framework based on a microservice framework and component model, see details. Figure 2 The diagram illustrates a general event stream computing framework for elastic control. It clarifies the access process for information such as data, signals, and logs. Measurement data is perceived and processed into JSON messages such as events, items, or alarms. According to the message flow methods shown in the streaming computing framework diagram, it coordinates and drives various scanning services, registration management services, storage services, real-time and historical access services to carry out high-concurrency message stream computing processing.

[0060] This invention achieves dynamic perception and identification of events, warnings, or alarms by classifying the service types (ServiceType) configured in the container startup YAML file. Figure 2 The 14 microservice clusters and their collaborative operation relationships are as follows:

[0061] Cluster C1: The event classification definition cluster, running the event classification definition service globally in master-slave mode. The event classification definition service is an API service that allows users to define event levels, event classes, and alarm classes through a user interface. It also supports online adjustment of the message structure for events and alarms. The definition results are stored in a distributed real-time database and a runtime data center relational database.

[0062] Cluster C2: A component event sourcing cluster where each application domain runs event classification services in master-slave mode. It subscribes to status messages from various microservices and their internal components on the running message bus, categorizing them into business platform components and business application components, and constructs event profiles for each component. After event information is aggregated, it can be pushed to the operation and maintenance awareness topic on the running message bus to facilitate the inspection of the real-time status of system components and realize event backtracking and auditing.

[0063] Cluster C3: Log scanning cluster (ServiceType=event), concurrently processing Syslog logs of Emergency, Alert, Critical and other levels as events.

[0064] Cluster C4: Event scanning cluster (ServiceType=warn), concurrently processes events, state transition signals, and operation signals as scheduled events or alarms.

[0065] Cluster C5: Alarm scanning cluster (ServiceType=alarm), concurrently calculates and schedules business data and operation and maintenance data to obtain alarm information.

[0066] Cluster C6: Event registration and management cluster, converts event messages into syslog format logs, and generates log files at configured time intervals.

[0067] Cluster C7: The event registration and management cluster, which processes events related to operation tracking, status transitions, and external requests by associating them with different event class cache tables in the distributed real-time library through the event cache.

[0068] Cluster C8: Alarm registration and management cluster, which distributes and processes alarm messages, alarm maintenance messages, alarm request messages, alarm confirmation messages, etc. It performs alarm processing by associating different alarm class cache tables with the distributed real-time library through alarm cache.

[0069] Cluster C9: Event Storage Cluster, which stores the log files generated by the event registration management cluster in object storage.

[0070] Cluster C10: Event storage cluster, which subscribes to event messages published by the event registration management cluster and stores them in the time series database.

[0071] Cluster C11: Alarm storage cluster. It subscribes to alarm messages published by the alarm registration management cluster and stores them in the time series database. A copy of each alarm message is also stored synchronously in the relational database to facilitate the analysis and processing of alarms and collected data.

[0072] Cluster C12: Real-time event service cluster, accesses information in the event table in the distributed real-time database, and provides various query services for real-time events.

[0073] Cluster C13: Real-time alarm service cluster, accesses information in the alarm table in the distributed real-time database, and provides real-time alarm maintenance and various query services.

[0074] Cluster C14: Historical Events / Events / Alarms Service Cluster. The historical events service provides an interface for querying event log files and their contents by time period; the historical events service accesses the time series database to provide query services for various events; and the historical alarms service accesses the relationship database to provide query services for various alarms.

[0075] The general event stream computation framework has the following characteristics:

[0076] (1) Microservice framework and component model, the components within the service are arranged in a tree structure, as can be seen Figure 3 The service component architecture diagrams and subsequent ones differentiate the driving methods of component loading in services through the root component: microservices based on the API service root component provide Restful API services; microservices based on the stream computing root component provide concurrent event-based message stream computing and processing based on elastic event queues; and microservices based on the stream computing service root component provide message stream computing and processing, and can also assist in providing Restful API services.

[0077] Restful API is an architectural style that defines a set of constraints for creating web services. It emphasizes the separation of client and server, uses stateless communication, and manipulates data through resource identifiers.

[0078] (2) Message passing between microservices is achieved through elastic event queues, and message flow distribution and transmission within microservices are achieved through event-driven methods between components. The end component of the event flow processing associated with the message subscription component within a microservice needs to publish messages to a specific topic of the elastic event queue to achieve message aggregation. The aggregated messages must be subscribed and processed by other microservices.

[0079] (3) Design a component status tracking and change status release instrumentation probe. The probe can be configured to be enabled or disabled through the microservice yaml file (enabled when troubleshooting defects, disabled when running smoothly). The component event tracing service subscribes to messages of the corresponding topic in the elastic event queue, parses and processes them to obtain component mapping information, and drives the maintenance of the collected numerical profiles in the distributed real-time library. The microservice monitoring interface can easily access the real-time library and display the detailed component running status within the service.

[0080] (4) Load the container images of each scanning service, registration management service, storage service, real-time and historical access service through the distributed task scheduling service to drive the deployment and operation of general event microservices in a large-scale cluster.

[0081] In S10 above, the general event stream computing framework of the present invention integrates an event classification definition method, realizing the definition of event level, event class, and alarm class. It supports online adjustment of the message structure of events and alarms, and the definition results can be encapsulated through a parameter library component and synchronized with a distributed real-time library in real time. An event classification definition service based on this method is described in reference [reference needed]. Figure 3 The following is an architecture diagram of an event classification definition service component:

[0082] (1) The root of the tree is the root component of the API service, which encapsulates the basic service methods of Restful API and supports various access components to extend application interfaces; it also encapsulates the driver methods of the component tree.

[0083] (2) The first-level components are associated with the root components, including the primary / standby detection component, the parameter library component, the configuration parsing component, the event definition component, the event definition component, and the alarm definition component. The parameter library component configures the real-time library backend component to perform operations such as adding, deleting, modifying, and querying the general event definition table of the real-time library. The tag recognition component in the second-level components analyzes the tags ("event", "warn", or "alarm") configured in the ServiceType in the service's YAML file and starts the functions of the relevant first-level components.

[0084] (3) Event level definition component, which defines the level (priority) of events, matters, and alarms:

[0085] A. Events can be categorized into three levels: abnormal events (Level 1), general events (Level 2), and important events (Level 3). Warnings have a limited impact (Level 4). Alarms need to be defined according to the differences in business operations. They can be further subdivided into alarms with a wide impact and relatively serious consequences (Level 5), important alarms that must be handled immediately (Level 6), and alarms that may lead to system unavailability or major accidents (Level 7).

[0086] B. Item classification level definition component, which provides a default status transition item class and an operation tracking item class. The item class can be further subdivided into three sub-item levels: general notification (level 4.1), notification that needs attention (level 4.2), and important notification that needs to be reminded to the user (level 4.3).

[0087] (3) The alarm category component is associated with components such as the alarm classification level definition component, the user attribute definition component, and the alarm version definition component. System maintenance personnel can define alarm categories through the interface according to the alarm handling methods for anomalies or accidents. The alarm category can be further defined into eight sub-alarm levels, such as 1-8 (levels 5.1, 5.2, 5.3, 6.4, 6.5, 6.6, 7.7, and 7.8). Typical alarm categories for distribution network dispatching include total accident, accident tripping, switch change, disconnector change, tap change, channel alarm, disk exceeding upper limit, cluster start / stop, intelligent alarm, alarm confirmation, and sign operation. The user attribute definition component maintains the voltage level configuration and responsibility area configuration of the distribution network dispatching associated with the alarm category. Only users with the configured responsibility area permissions can operate (alarm confirmation, alarm push) the alarm information of the corresponding alarm category.

[0088] (5) The unique identifier ID of a component in the system is a string concatenated with "domain name-tag-service name-component name configured in microservice". The component ID does not change with the running node of the microservice. The component state is a predefined integer from 1 to 8, with the processing priority increasing sequentially. The component state data structure EventJson={"id":"component ID", "value":"integer value", "time":"second value", "flag":"flag bit"}.

[0089] (6) Event classification definition service is generally used in the system commissioning phase and can deploy 6 services: event definition primary and backup service; event definition primary and backup service; alarm definition primary and backup service. These definition services can flexibly respond to different event definitions of State Grid, Southern Power Grid and local power companies. The parameters after definition can be deployed to the user site as a template.

[0090] (7) The event category definition editor allows you to define new events and alarm attributes. The main contents include:

[0091] Priority: Maintenance level, change priority.

[0092] Permission domain: Identify the user's permission domain based on the object's generic ID and the responsibility area to which the device's GID belongs.

[0093] Object properties: The general ID of the object is bound to the corresponding property, which is used to store or display information.

[0094] Display format: The display format for events and alarm messages.

[0095] Processing mode: The method used to process alarm messages, which can be a user processing routine, various user-defined sounds, etc.

[0096] In S10 above, the general event flow computing framework of the present invention integrates a component event sourcing method, which perceives the running status of microservices and components in services through the component event sourcing service, and refers to... Figure 4 The diagram shown illustrates a component architecture for an event sourcing service. This architecture uses a typical tree-like component relationship to assemble related microservices.

[0097] (1) The root of the tree is the root component of the stream computing service, which encapsulates the message subscription and publishing methods that interact with the running message bus; it encapsulates the basic service methods of the Restful API, supports various access component extended application interfaces; and it encapsulates the driver methods of the component tree.

[0098] (2) The first-level component is associated with the root component, including the parameter library component, message subscription splitter, configuration parsing component, event profile cache and event access request components.

[0099] (3) Message Subscription Splitter: Subscribes to component status messages in the microservice component running topics on the message bus, and splits them according to the component's attributes: Business Platform Component Status Processing Flow: First, the business platform component event consumer receives the split messages, the platform component event parser completes the parsing of each attribute in the event and the completion of component parameters, the component status mapping completes the event encapsulation containing the "component status data structure", and finally maintains the event profile. Business Application Component Status Processing Flow: First, the business application component event consumer receives the split messages, the application component event parser completes the parsing of each attribute in the event and the completion of component parameters, the component status mapping completes the event encapsulation containing the "component status data structure", and finally maintains the event profile.

[0100] (4) Event section caching, associated data collection library component associated with real-time library backend component, using shared pointer section caching technology of real-time library to construct memory data library table structure: define point as measurement point, point.id as the globally unique point ID of component state measurement point; JObject is a JSON type measurement point data object; table is the section data table name.

[0101] Cross-sectional snapshots are instantaneous records of real-time data from multiple measurement points in a system, organized in a hierarchical manner according to a memory database table structure: "cross-sectional snapshot library - point value table - numerical value". They preserve the complete data state at a specific moment ("snapshot" feature) and achieve efficient updates and queries through technologies such as shared pointers and mapping tables. They also support real-time push of changing data and are suitable for scenarios requiring high real-time monitoring.

[0102] The cross-sectional snapshot adopts a three-layer structure:

[0103] The lowest level: Values ​​(Record): Define Record = shared_ptr <jobject>It is a shared pointer to a JSON data object (JObject); used to store the specific data collected at a single measurement point at a certain moment (such as temperature, pressure, status code, etc.); JObject is converted from event JSON (JObject = jsonToObject(EventJson)) and contains the real-time value or status information of that measurement point;

[0104] Intermediate layer: ValueTable: Defined as ValueTable = map <point.id, shared_ptr <record>This refers to a mapping table from a globally unique ID of a measurement point to its corresponding value (Record); used to aggregate instantaneous data from all measurement points under the same data table. For example, if "table = Temperature Monitoring Table", then ValueTable will contain the real-time temperature values ​​(Records) of all sensors (point.id) under that table; it achieves fast querying through a map structure (indexed by point.id) and uses shared pointers (shared_ptr) to avoid data redundancy and improve memory efficiency; multiple point value tables can be declared, each corresponding to a set of measurement points, such as the feeder point value table, switch point value table, and transformer point value table for distribution network monitoring.

[0105] Top layer: Section Snap library: Defines SectionSnap = map <table, shared_ptr <valuetable>This refers to a mapping library from "table names" to "corresponding value tables"; it integrates the instantaneous states of all measurement points according to the "table" dimension to form a complete "data profile" of the system at a certain moment. For example, a snapshot of a power system profile may contain multiple tables such as "distribution network monitoring table", "photovoltaic monitoring value table", and "charging pile monitoring value table", with each table corresponding to its own measurement point data.

[0106] The changing numerical records are synchronously stored in the event filtering queue cache (FIFO), and the collected event messages are published to specific topics running the message bus every second through the second-level publishing component.

[0107] (5) Event access request component, analyzes the event retrieval conditions in the external request message, calls the event profile cache query component to obtain the results, and sends back the response message.

[0108] S20, Cluster Access: A container is used to encapsulate the scanning service component. When the service type is configured in the YAML file as "event", the event scanning service is started to access the operation log; when it is "warn", the event scanning service is started to access the operation and maintenance signals to handle events or alarms; when it is "alarm", the alarm scanning service is started to access the scheduling data to obtain event or alarm information.

[0109] In step S20 above, the data, signal, and log access service and collaborative processing method of the present invention are detailed in [link to relevant documentation]. Figure 2 Information input source on the left:

[0110] (1) Business data or operation and maintenance data published by the front-end data collection and exchange domain are transferred through the operation message bus and submitted to the alarm scanning cluster for access processing.

[0111] (2) The status transition signal or operation signal issued by the intelligent operation and maintenance perception domain is transferred through the operation message bus and submitted to the item scanning cluster for access processing.

[0112] (3) The running logs processed by the log service are submitted to the log scanning cluster access processing in the form of messages or files.

[0113] In S20 above, the general access information scanning service of the present invention is planned as a log / event / alarm scanning service, as referenced. Figure 5 The following is an architecture diagram of a log / event / alarm scanning service component:

[0114] (1) The root of the tree is the root component of the stream computing. The first-level component is associated with the root component, including the parameter library component, the value library component, the event / alarm cache, the log file transfer device, the event / signal multiplexer, the data stream splitter, etc. The data tables in the cross-sectional snapshot of the value library component include the digital quantity table diTable and the analog quantity aiTable, as well as the extended remote signaling yxTable, telemetry ycTable, remote control ykTable and remote adjustment ytTable, etc.; data object: JObject = jsonToObject(DataJson); DataJson={"id":"point ID", "value":"floating point number", "time":"second value time", "type":"type","object":"subject object","quality":"data quality code", "flags":"operation quality code"}; point.id = point ID. The configuration parsing component parses the service type in the yaml configuration file. ServiceType=event is the log scanning service, ServiceType=warn is the event scanning service, and ServiceType=alarm is the alarm scanning service.

[0115] (2) The item / alarm cache consists of two snapshot tables named warnTable and alarmTable in the cross-section snapshot. In the processing of the same batch of messages, there can be at most one valid item and one valid alarm for each component ID.

[0116] Data object in the snapshot table: JObject = strucToJsonObject(alarmStruc); point.id = alarm ID.

[0117] (3) Log file transfer unit: It aggregates subscribed log messages and log files, and stores them as small files in a disk array or distributed object storage through a file storage service. It also synchronously clears historical log files that have been stored for more than the configured number of days (default 31 days). After the files are transferred, the log parser is driven to parse the events in the logs. Events with a level greater than 3 are identified by the event filter and published to the running message bus through the event publishing component.

[0118] (4) Event / signal multiplexer, which splits the message into event message stream and signal message stream, and the processing is as follows:

[0119] (a) The event message subscription component receives event information, supplements parameters, and publishes events of levels 1-3 directly, while events of level 4 and above are passed to the alarm filter. The alarm filter identifies the level in the event message, organizes level 4 events according to the event message structure, and organizes events above level 4 according to the alarm message structure, and caches the results in the "Event / Alarm Cache". The event cache publishing component identifies the current event message in the cache, and publishes all messages if they are not empty; the alarm cache publishing component identifies the current alarm message in the cache, and publishes all messages if they are not empty.

[0120] (b) The signal message subscription component receives signals, the event filter supplements parameters to complete the event message encapsulation, and reuses the three components in the previous step, namely alarm filter, event cache publishing, and alarm cache publishing, to publish event messages and alarm messages in categories.

[0121] (5) Data stream splitter, which splits the message into digital message stream and analog message stream. The processing procedure is as follows:

[0122] A. Digital message stream processing.

[0123] (a) The digital quantity processing component accesses the parameter library component to check if the parameter of the input digital quantity measurement point ID exists. If it does not exist, the terminal calculates the parameter of the measurement point. If it exists, the parameter is completed and then the next component is processed.

[0124] (b) The data source identification component analyzes the time and content of the data source. Digital data points do not receive data from bypass alternative data sources. Upon receiving data from the preceding data source, it needs to determine whether the point is a data collection point. After successful verification, the data is saved to the data source table in the parameter library, the corresponding sending flag is set, and the process proceeds to the next component. If the source data status fails verification, the source is set to invalid, and the valid status bit of the point is removed.

[0125] (c) The data quality processor verifies the quality code of the digital measurement point itself. If the verification is successful, it proceeds to the next component for processing. Otherwise, it exits the processor's execution.

[0126] (d) The data change processor compares the previous value in the data library with the new data. If the value has not changed, the processor stops further processing. If the value has changed, the last change time is updated, and the corresponding sending flag is set. The data type of the current point is determined, and processing is categorized: changes caused by an operation enter the operation change processor; changes caused by remote control enter the remote control change processor. In the case of a two-position change, if the new state has not entered an intermediate state, it enters the remote control change processor; if the new state has entered an intermediate state, only the data library is modified; otherwise, it enters the two-position change processor. Changes not caused by operation or remote control enter the accident judgment processor.

[0127] (e) Operate the change processor, determine the operation type, generate an event message, and maintain the event cache.

[0128] (f) Remote control positioner processor, determines the remote control type, generates alarm messages, and maintains alarm cache.

[0129] (g) A dual-bit change processor generates alarm messages based on the new state of the two bits and maintains an alarm cache.

[0130] (h) Incident detection processor, which determines the incident type, generates alarm messages, and maintains the alarm cache.

[0131] (i) Item cache publishing: If the item cache is empty, then publish the existing item; Alarm cache publishing: If the alarm cache is empty, then publish the existing alarm.

[0132] B. Analog message stream processing.

[0133] (a) Analog signal processing component: verification and conversion of raw and raw data, comparison with the previous data in the numerical database, and handling of dead numbers if the value changes; after processing, maintain the data in the numerical database for subsequent processing by subsequent components.

[0134] (b) Data source type verification: Data collection points and calculation points may originate from manually assigned data or alternative data sources. The data types in the parameter library and the data sources are analyzed, as well as the point quality in the numerical database, and data source matching is performed. For multi-source matching, no additional checks are performed; data from other data sources is accepted by default and directly enters the multi-data source preprocessing stage. Based on the point type, matching rules are divided into multi-source matching and non-multi-source matching. Non-multi-source matching uses data type and data source matching. After successful multi-source matching, the data source information of the midpoint parameters in the parameter library is maintained.

[0135] (c) Message and point parameter verification: Verify the validity of the analog points, supplement valid analog data parameters, and interrupt the calculation if the points are invalid. If the message and parameter verification is successful, proceed to the next processor.

[0136] (d) Reasonableness judgment: Based on the parameter library settings, determine whether the data exceeds the reasonable limit. If it exceeds the reasonable limit, display the data as the reasonable limit value, generate an alarm for exceeding the reasonable limit, set the corresponding flag for exceeding the reasonable limit, and end the processing flow. If the value is within the upper or lower reasonable limit range, proceed to the next processor.

[0137] (e) Limit Exceedance Detection: The current limit value for the point is obtained from the parameter library to determine whether the point has entered a limit exceeding state. The point parameters are equipped with upper and lower limits for operation, emergency, and accident levels. After the operation limit exceeding state changes, a corresponding event needs to be generated; after the emergency or accident limit exceeding state changes, a corresponding alarm needs to be generated. Limit values ​​can be combined with different types for processing based on season and time period.

[0138] (f) Jump detection: Compare the data in the numerical library cache. If the value exceeds the set limit, a jump is considered to have occurred, a jump alarm is generated, and a quality code for the jump is set. If the jump conditions are not met in the point parameters or no jump rate is set for the point, it is considered a normal change.

[0139] (e) Gear detection, the measurement type is gear, generates an alarm for gear change.

[0140] (g) Peer substitution detection: Determine whether the data is bypassed based on the current state of the point. When a point is bypassing other points, and the peer is replacing other points, first determine whether it is a dead number, then retrieve the point being replaced and its partition from the memory table of that point, send the data to the replacement data stream according to the data stream format, and generate a bypass substitution event.

[0141] (h) Reuse the alert cache publishing and event cache publishing components.

[0142] S30, Registration Management: Implements event / alarm caching based on shared pointers and JSON objects, synchronously linking and maintaining the event table and alarm table in the backend real-time database; a container encapsulates all components of the registration management service, and enables management functions such as event, event and alarm message listening, registration caching, hierarchical filtering, information fitting, batch extraction, category editing and confirmation maintenance through service type configuration.

[0143] In step S30 above, the message streams of events, matters, and alarms published by the access information scanning service of the present invention are correspondingly transmitted to the log / matter / alarm registration management service cluster. For details of the processing method, please refer to [link to relevant documentation]. Figure 6 The following is an architecture diagram of an event / event / alarm registration management service component:

[0144] (1) The root of the tree is the root component of the stream computing. The first-level components are associated with the root component, including the log cache queue, configuration parsing component, event / alarm cache, event stream subscription component, event stream subscription component, and alarm stream subscription component. Among them, the event / alarm cache calls the real-time library backend event component to cache level 4 event messages, and calls the real-time library backend alarm component to cache alarm messages above level 4. The events and alarms are registered to the distributed real-time library to store all active event and alarm objects in the system, which can be accessed by the real-time event service and the real-time alarm service. The configuration parsing component parses the service type in the YAML configuration file. ServiceType=event is the event registration management service, ServiceType=warn is the event registration management service, and ServiceType=alarm is the alarm registration management service.

[0145] (2) The event stream subscription component subscribes to event messages, which are then processed by the log cache maintainer and submitted to the timed log message generator for further processing. The log cache maintainer converts the event messages into syslog format logs and stores them in the log cache queue. The timed log message generator generates log files at configured time intervals and temporarily stores them on the local disk where the service is running.

[0146] (3) Item flow subscription component: Subscribe to item messages, analyze item patterns, and process them in two message flows: new messages and requests.

[0147] A. Processing of new news items' message flow.

[0148] (a) The new message stream first passes through the validity identification component to determine the validity of the relevant parameters of the matter. Valid matter messages are then passed on for further processing.

[0149] (b) The hierarchical filtering component filters items at levels 4.1, 4.2 and 4.3. It can filter out items generated by non-core business operations based on the configured item filtering conditions.

[0150] (c) Categorize and register caches, and create event profiles in the event cache according to event class:

[0151] Transaction log: Record = shared_ptr<JObject(strucToJsonObject (warnStruc) )> ;

[0152] Event cache table: WarnTable = map <warnStruc.ID, shared_ptr <record>>;

[0153] Event Section Library: WarnSection = map <table, shared_ptr <warntable>>;

[0154] Where table is the name of the item class.

[0155] (d) Item statistics: Based on configuration parameters, including plants, responsibility areas, and equipment, the system counts the number of items in a real-time section and provides real-time statistical data.

[0156] (e) Fit duplicate items, count items with the same four attributes such as object identifier, content, type, and level, delete newly saved items, and increment the count of another item by 1.

[0157] (f) Reuse the item cache publishing component.

[0158] B. Message stream processing for event requests: For messages with a third-party request pattern, the event request component first queries the event cache to obtain the reduced event data structure to be forwarded: warnResponseStruc = [object identifier, object type, device GID, content, type, pattern (third-party response), level, alarm time, comment]. Then, it is submitted to the component that maintains sensitive attributes for desensitization processing. Finally, the event cache publishing component publishes the response event message to the external request.

[0159] (4) Alarm stream subscription component: Analyzes the operation identifiers in the subscribed alarm messages, and processes alarm messages, alarm maintenance messages, alarm request messages, alarm confirmation messages, etc. The message stream processing process is designed as follows:

[0160] A. Alarm message stream processing, identifying operation indicators to respond to messages that are new alarm signals.

[0161] (a) The alarm message stream first passes through the validity identification component to determine the validity of the alarm-related parameters. Valid alarm messages are then passed on for further processing.

[0162] (b) The hierarchical filtering component filters alarms at levels 5.1, 5.2, 5.3, 6.4, 6.5, 6.6, 7.7, and 7.8. It can filter alarms that are not of concern to the dispatcher based on the configured alarm filtering conditions.

[0163] (c) Categorize and register caches, and create alarm profiles in the alarm cache according to alarm class:

[0164] Alarm logging: Record = shared_ptr<JObject(strucToJsonObject (alarmStruc))> ;

[0165] Alarm cache table: AlarmTable = map <alarmStruc.ID, shared_ptr <record>>;

[0166] Alarm Section Library: AlarmSection = map <table, shared_ptr <alarmtable>>;

[0167] Where table is the alarm class name.

[0168] (d) The processing of components such as alarm statistics, fitting duplicate alarms and alarm cache release is similar to the processing of new reported items.

[0169] (d) The processing of components such as alarm statistics, fitting duplicate alarms and alarm cache release is similar to the processing of new reported items.

[0170] B. Alarm maintenance message flow processing: Identify operation indicators for messages that are maintenance signals, and provide functions such as alarm classification editing and alarm deletion.

[0171] (a) When editing alarm categories, the operation indicator of the received message is edit or delay. The category editing component locates the alarm cache table in the alarm cache according to the alarm category name, analyzes whether the alarm message is in the cache table, and if it exists, the attributes in the alarm message can be maintained. The alarm delay component can set the "delay second value" to retain only 1 alarm in the delay period to eliminate interference signals. The alarm cache publishing component is reused to publish the maintained alarm message.

[0172] (b) When deleting an alarm, the operation indicator of the received message is "delete". The alarm deletion component deletes the corresponding alarm information from the alarm cache and real-time database according to the ID. The alarm deletion component periodically scans the "Event / Alarm Cache" for alarm information whose alarm time value exceeds the configured constraint period (default 7 days) and deletes the confirmed alarm information.

[0173] C. Alarm request message stream processing: The message pattern is a third-party response message, which is an alarm message to be sent to the real-time alarm service.

[0174] (a) When the alarm request component receives the request message, it queries the alarm cache to obtain the alarm message, reduces the alarm data structure to be forwarded, alarmResponseStruc = [object identifier, object type, device GID, content, type, mode (third-party response), level, alarm time, comment], and then passes it to subsequent components for processing.

[0175] (b) The device disable verification component identifies whether the device is disabled in the alarm message to be responded to. If the device is not disabled, the message is passed on for further processing.

[0176] (c) Automatic verification component: Analyze whether the alarms awaiting response have been verified, and automatically verify those that have not been verified.

[0177] (d) Maintain sensitive attribute components and desensitize sensitive information in alarms to be responded to.

[0178] (e) Reuse the alarm cache publishing component to publish response alarm messages in response to external requests.

[0179] D. Alarm confirmation message stream processing.

[0180] (a) The alarm confirmation component periodically queries the alarm cache for alarm messages that have timed out and are awaiting confirmation, initiates automatic confirmation operations, and generates alarm confirmation messages; it identifies alarm messages whose operation indicators should be confirmation signals. These messages are alarm confirmation messages that are manually confirmed and transmitted.

[0181] (b) Maintain the operation attribute component, including the content of automatically confirmed attributes such as "operation identifier, operation time, operation user, and operation node". The operation user is the system default user, and the operation node is the name of the running node of this service.

[0182] (c) Reuse the alarm cache publishing component to publish alarm confirmation messages.

[0183] S40, Storage Services: Collaborates with object storage and various databases to store event, event, and alarm messages. Event storage services periodically store events as small files in object storage; event storage services subscribe to event messages and store them in a time-series database; alarm storage services subscribe to alarm messages and store them in a time-series database, as well as an alarm day partition table in the relational database.

[0184] In S40 above, the storage service of the present invention stores messages processed by the registration management service, including an event / event / alarm storage cluster. For details of the componentized structure of the storage service, please refer to [link to relevant documentation]. Figure 7 The following is an architecture diagram of an event / event / alarm storage service component:

[0185] (1) The root of the tree is the root component of the stream computing service. The first-level components are associated with the root component, including the configuration parsing component, the local disk log file scanner, the event stream subscription component, and the alarm stream subscription component. Among them, the configuration parsing component parses the service type in the YAML configuration file. ServiceType=event is the event storage service, ServiceType=warn is the event storage service, and ServiceType=alarm is the alarm storage service.

[0186] (2) Event storage starts processing through the local disk log file scanner, reads the log file name in a specific folder, and judges the validity of the file; the file object storage component calls the object storage service interface to store the valid log file; the local disk file deleter analyzes the storage result returned by the object storage service interface, and deletes the log file on the local disk according to the stored normal file name; if there is an error in the returned storage result, the object storage alarm publishing component is called to publish the returned error information.

[0187] (3) Item storage initiates processing through the item flow subscription component:

[0188] (a) The event flow subscription component subscribes to event messages and determines the validity of the event;

[0189] (b) Item caching component: valid items are cached in a queue;

[0190] (c) The time-series library storage component is cached periodically, and the time-series library storage service's batch storage interface is called periodically to store a valid set of events M. When the time-series library is functioning normally, the interface performs a full-scale overwrite storage. Event validity is determined by identifying the message structure (warnStruc) and its data type. For example, if the warnStruc.object identifier cannot be found in the real-time library parameters, it is an unrelated event in the system and can be considered invalid.

[0191] (d) The cache cleanup component analyzes the storage results returned by the time-series library storage service interface. If the storage is normal, the item corresponding to M is deleted from the cache queue.

[0192] (e) If there is an error in the stored result, the database alarm publishing component is invoked to publish the error information.

[0193] (4) Alarm storage is initiated through the alarm stream subscription component:

[0194] (a) Alarm stream subscription component: subscribes to alarm messages and determines the validity of alarms;

[0195] (b) Alarm caching component: valid alarms are cached in the queue;

[0196] (c) The time-based cache time-series library storage component periodically calls the alarm batch storage interface of the time-series library storage service to store the valid alarm set N; when the time-series library is normal, the interface performs full-coverage storage.

[0197] (d) The relational database storage component is cached periodically. The alarm batch storage interface of the relational database storage service is called periodically to store the valid alarm set N. When the relational database is normal, the function corresponding to the alarm batch storage interface first determines whether there is an alarm record in the relational database that matches the attributes such as "object identifier, type, level, alarm time" of the alarm information. If there is, it is deleted, and then the batch insertion of N is performed.

[0198] (e) The cache cleanup component analyzes the storage results returned by the time-series storage service interface and then analyzes the storage results returned by the relational storage service interface. If both are stored normally, the alarm corresponding to N is deleted from the cache queue.

[0199] (f) If there is an error in the stored result, the database alarm publishing component is invoked to publish the error information.

[0200] S50, Access Services: Real-time Events / Alarms Service: Access to the distributed real-time database, providing real-time maintenance and various query services; Historical Events / Events / Alarms Service: Access to object storage, time-series databases, or relational databases in the running data center domain, providing various query services for stored historical data.

[0201] In S50 above, the real-time event / alarm service of the present invention accesses information from alarm-related tables in a distributed real-time database, providing real-time alarm maintenance and various query services. The componentized structure of the service is detailed in [link to relevant documentation]. Figure 8 The following is an architecture diagram of a real-time event / alarm service component:

[0202] (1) The root component is the API service root component. The first-level components are associated with the root component and include components such as the primary / standby detection component, the configuration parsing component, and the service request permission verification component. Among them, the service request permission verification component analyzes the user information requesting the service (such as system code, application domain, plant, responsibility area, operating user, operating node, etc.) and verifies the user's responsibility area and alarm operation permissions. After the permissions are approved, query services and alarm-related operation and maintenance services are provided.

[0203] (2) When processing the query, the query component analyzes the query request specification, analyzes the query conditions of the real-time database through the query request filtering condition analysis component, and then calls the backend query component of the real-time database to query the result set of the items as needed. Finally, the query data is fed back through the item set response component.

[0204] (3) When processing alarm queries, the alarm query component analyzes the query request specifications, analyzes the query conditions of the real-time database through the alarm request filtering condition analysis component, and then calls the alarm query component of the real-time database backend to query the alarm result set as needed; finally, the query data is fed back through the alarm set response component.

[0205] (4) During alarm generation processing, the alarm generation component analyzes the request message and organizes the alarm message according to the alarm data structure.

[0206] (5) During alarm maintenance, the alarm maintenance component analyzes the attributes to be maintained in the request message and organizes the alarm maintenance message according to the alarm data structure.

[0207] (6) During alarm confirmation processing, the alarm confirmation component analyzes the alarm message to be confirmed in the request message, analyzes the unique constraint attribute set of the alarm, and organizes the alarm confirmation message.

[0208] (7) When deleting an alarm, the alarm confirmation component analyzes the alarm message to be confirmed in the request message, analyzes the unique constraint attribute set of the alarm, and organizes the alarm confirmation message.

[0209] (8) Finally, the message is published to the alarm topic of the elastic event queue through the alarm message publishing component, and the result of the event queue response is fed back through the feedback response component.

[0210] In S50 above, the historical event / event / alarm service of the present invention provides a general retrieval interface based on scheduling object and time limit; the historical event service provides an interface for querying event log files and file contents in the object storage by time period; the historical event service accesses the time series database to provide query services for various events; and the historical alarm service accesses the relationship database to provide query services for various alarms. For details on the componentized structure of the services, see [link to relevant documentation]. Figure 9 The diagram shown illustrates the component architecture of a historical event / event / alarm service.

[0211] (1) The root of the tree is the root component of the API service. The first-level components are associated with the root component, including the master / slave detection component, the configuration parsing component, the request service permission verification component, etc.

[0212] (2) When processing historical event queries, the event query component analyzes the validity of the request message and analyzes the query request time period specification, event type and event level through the event request filtering condition analysis component. Then, the object storage backend log download component downloads the corresponding log files according to the time period and event type. The specific event information in the request is filtered by the analysis, filtering and result log generation component and stored in a new query log file. The log file index response component feeds back the index information of the query result file in the object storage.

[0213] (3) When processing historical events queries, the event query component analyzes the query request specifications and analyzes the query conditions of the time series database through the event request filtering condition analysis component. These conditions include Tag query, TagValue query, single timeline query, multiple timeline query, aggregated timeline query, cross-sectional data query, multi-domain query, and other query conditions. Then, the backend event query component of the time series database is called to query the event result set as needed. Finally, the query data is fed back through the event set response component.

[0214] (4) During the historical alarm query processing, the alarm query component analyzes the query request specifications and, through the alarm request filtering condition analysis component, analyzes the query conditions of the relational database. The request parameter format is as follows:

[0215] "params":{"table": table class name, "filter": [{filter condition}, {filter condition}, ...], "fields": [record attribute name, record attribute name, ...], "order_fields": [record attribute name, record attribute name, ...]; add '-' before the attribute to DESC, "limit": maximum number of records per page (optional, default 0, returns all), "offset": data pagination offset (starts from 0 for which page to retrieve; if the range is exceeded, only the last page is displayed)}.

[0216] For example, to view the latest 60 switch action alarms (the switch action alarm class name is Switching) in the responsibility area aop="1000001" of the plant station r_station_id="10000B13000005", the request parameter format is as follows:

[0217] "params": {

[0218] "table": "Switching",

[0219] "fields": ["r_station_id","obj_id","obj_type","dev_gid","alm_text","priority","alm_time"],

[0220] "filter": [{"attr":"r_station_id", "operation":"=", "value":"10000B13000005"},{"attr":"aop", "operation":"=", "value":"1000001"}],

[0221] "order_fields": ["obj_id","-alm_time"],

[0222] "limit": 20,

[0223] "offset": 3

[0224] }

[0225] After verifying that the request parameters are compliant, the backend alarm query component of the relational database is called to query the alarm result set as needed; finally, the query data is fed back through the alarm set response component.

[0226] The Events / Alarms browser periodically accesses the real-time Events / Alarms service to refresh the data on the interface; the Events / Alarms history display interface allows access to historical Events / Alarms service to display queried alarm data.

[0227] Based on the same inventive concept, embodiments of the present invention also provide a digital twin event, incident, and alarm perception system for distribution network operation, to implement the aforementioned method for perceiving digital twin events, incidents, and alarms in distribution network operation, comprising:

[0228] Framework design module: Provides a general event stream computing framework based on microservice framework and component model, integrates event classification definition and component event tracing method for scheduling and running, coordinates multi-cluster processing of various scanning services, registration management services, storage services, real-time and historical retrieval and maintenance services; provides message publishing and subscription interfaces for general events and alarms;

[0229] Cluster access module: It uses a container to encapsulate the scanning service component, and starts scanning services for events, items and alarms by configuring service type.

[0230] Registration Management Module: Implements event / alarm caching based on shared pointers and JSON objects, synchronously associates and maintains relevant tables in the backend real-time database; enables functions such as message listening, registration caching, hierarchical filtering, information fitting, batch extraction, category editing, and confirmation maintenance by configuring service type categories for events, events, and alarms.

[0231] Storage service module: Collaborates with object storage and various databases to store event, event, and alarm messages. Event storage service periodically stores events as small files in object storage; event storage service subscribes to event messages and stores them in a time-series database; alarm storage service subscribes to alarm messages and stores them in both a time-series database and a relational database.

[0232] Access Service Module: Real-time Event / Alarm Service accesses the distributed real-time database, providing real-time maintenance and various query services; Historical Event / Event / Alarm Service accesses the object storage, time-series database, or relational database in the running data center domain, providing various query services for stored historical data.

[0233] This general event stream computing framework, based on a microservices framework and component model, provides a method for large-scale clustered deployment and operation of scanning services, registration management services, storage services, and real-time and historical access services. It identifies continuous time-based data from the digital twin of the power distribution network through concurrent operation, and senses various events, events, and alarm information. This information flows and is computed between microservices in an asynchronous message manner.

[0234] In the scanning service cluster, messages are transmitted between components in an event-driven manner, refining component reuse methods; by parsing the service type configured in the YAML file of the scanning service container image, an event scanning service is started to access the operation log when an event occurs; an item scanning service is started to access the operation and maintenance signal when an alarm occurs, and the item or alarm is processed; an alarm scanning service is started to access the scheduling data when an item occurs, and the event or alarm information is detected; messages are classified and published to the registration management service cluster.

[0235] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.< / alarmtable> < / record> < / warntable> < / record> < / valuetable> < / record> < / jobject>

Claims

1. A method for sensing digital twin events, incidents, and alarms in power distribution network operation, characterized in that, include: Framework Design: Provides a general event stream computing framework based on microservice framework and component model, integrates event classification definition and component event tracing methods for scheduling and execution, coordinates multi-cluster processing of various scanning services, registration management services, storage services, and real-time and historical retrieval and maintenance services; provides message publishing and subscription interfaces for general events and alarms; Based on a microservice framework and component model, the system concurrently identifies continuous time-based data from the digital twin of the power distribution network operation, and senses various events, events, and alarm information. The information flows and is computed between microservices and within microservice groups in an asynchronous message manner. The microservice framework internally uses a tree-structured orchestration of components. The general event stream computing framework is used to dynamically sense events, events, and alarm signals triggered by multimodal heterogeneous data. Cluster access: A containerized component is used to start scanning services for events, items, and alarms by configuring service type categories; the containerized component includes all components of a containerized scanning service, all components of a containerized registration management service, and all components of a containerized storage service. Registration Management: Implements item / alarm caching based on shared pointers and JSON objects, synchronously maintaining related tables in the backend real-time database, including item tables and alarm tables; Storage services: Collaborative object storage and various databases complete message storage for events, matters, and alarms; Access services: Real-time event / alarm service accesses the distributed real-time database, providing real-time maintenance and various query services; historical event / event / alarm service accesses the object storage, time-series database or relational database in the running data center domain, providing various query services for stored historical data.

2. The method for sensing digital twin events, incidents, and alarms in power distribution network operation according to claim 1, characterized in that, The cluster includes: a scanning service cluster, a registration management service cluster, a storage service cluster, and a real-time and historical access service cluster. Through concurrent operation, it identifies continuous time-based data of the digital twin of the power distribution network operation and senses various events, matters, and alarm information.

3. The method for sensing digital twin events, incidents, and alarms in power distribution network operation according to claim 2, characterized in that, In the scanning service cluster, messages are transmitted between components in an event-driven manner, refining component reuse methods. By parsing the service type configured in the YAML file of the scanning service container image, the event scanning service is started to access the operation log when it is an event; the event scanning service is started to access the operation and maintenance signals when it is an item, and the item or alarm is processed; the alarm scanning service is started to access the scheduling data when it is an alarm, to sense the event or alarm information, and the message is classified and published to the registration management service cluster.

4. The method for sensing digital twin events, incidents, and alarms in power distribution network operation according to claim 2, characterized in that, In the registration management service cluster, the item / alarm cache synchronously associates and maintains the item or alarm-related tables in the distributed real-time library through snapshot profile technology to realize message registration and management; the data processed by each component is cached in the profile library, and the cache publishing component publishes all cached known data when it runs.

5. The method for sensing digital twin events, incidents, and alarms in power distribution network operation according to claim 2, characterized in that, In the aforementioned event storage service, the event stream subscription component starts the storage stream, periodically caches the time series library storage component, and periodically stores the valid event set M: if the time series library is normal, the interface performs a full overwrite storage and deletes the event corresponding to M from the cache queue. If the stored result is incorrect, the database alarm publishing component is invoked to publish the error information. In the alarm storage service, a timed cache relational database storage component is added on the basis of the event storage component function. When the relational database is normal, the function corresponding to the alarm batch storage interface first determines whether there is an alarm record in the relational database that matches the unique attribute of the alarm information. If there is, it is deleted, and then the batch insertion of the alarm set is performed.

6. The method for sensing digital twin events, incidents, and alarms in power distribution network operation according to claim 2, characterized in that, The real-time and historical retrieval and maintenance services provide real-time event services and real-time alarm services based on the real-time event / alarm service container image; and provide historical event services, historical event services, and historical alarm services based on the historical event / event / alarm service container image. Among them, the real-time alarm service provides alarm generation, query, maintenance, confirmation, and deletion operations, while other services provide various query functions.

7. The method for sensing digital twin events, incidents, and alarms in power distribution network operation according to claim 1, characterized in that, A component is encapsulated in a container, which is represented by a hexagon, wherein: The top provides subscription / publishing for the running message bus; the top left provides distributed task scheduling; the top right provides access to the distributed service bus; the bottom right provides services for relational databases / time series databases / object storage; the bottom provides basic resources; and the bottom left provides distributed real-time libraries and file services. The container is designed with components arranged in a tree structure, and the root component distinguishes the driving mode of the components loaded in the service. Various messages can be distributed, concurrently processed, and aggregated among components in the microservice based on message queues.

8. A digital twin event, incident, and alarm sensing system for power distribution network operation, characterized in that, include: Framework design module: Provides a general event stream computing framework based on microservice framework and component model, integrates event classification definition and component event tracing method for scheduling and running, coordinates multi-cluster processing of various scanning services, registration management services, storage services, real-time and historical retrieval and maintenance services; provides message publishing and subscription interfaces for general events and alarms; Cluster access module: It uses a container to encapsulate the scanning service component, and starts scanning services for events, items and alarms by configuring service type. Registration management module: Implements event / alarm caching based on shared pointers and JSON objects, and synchronously maintains relevant tables in the backend real-time database; Configure service types to enable message listening, registration caching, hierarchical filtering, information fitting, batch extraction, category editing, and confirmation maintenance functions for events, matters, and alarms. Storage service module: Collaborates with object storage and various databases to complete message storage for events, matters, and alarms; Event storage service periodically stores events in small files to object storage; Event storage services subscribe to event messages and store them in a time-series database; Alarm storage service subscribes to alarm messages and stores them in a time-series database and a relational database; Access Service Module: Real-time Event / Alarm Service accesses the distributed real-time database, providing real-time maintenance and various query services; Historical Event / Event / Alarm Service accesses the object storage, time-series database, or relational database in the running data center domain, providing various query services for stored historical data.

9. A digital twin event, incident, and alarm perception system for power distribution network operation according to claim 8, characterized in that, This general event stream computing framework, based on a microservices framework and component model, provides a method for large-scale clustered deployment and operation of scanning services, registration management services, storage services, and real-time and historical access services. It identifies continuous time-based data from the digital twin of the power distribution network through concurrent operation, and senses various events, events, and alarm information. This information flows and is computed between microservices in an asynchronous message manner.

10. A digital twin event, incident, and alarm perception system for power distribution network operation according to claim 9, characterized in that, In the scanning service cluster, messages are passed between components in an event-driven manner, refining component reuse methods; by parsing the service type configured in the YAML file of the scanning service container image, an event scanning service is started to access the operation log when an event occurs; an item scanning service is started to access the operation and maintenance signals when an alarm occurs, and the item or alarm is processed; an alarm scanning service is started to access the scheduling data when an item occurs, and the event or alarm information is detected; messages are classified and published to the registration management service cluster.

Images