Cross-regional data intercommunication method, device and equipment for power internet of things, and medium

Abstract

The invention discloses a cross-regional data intercommunication method, device, equipment and medium for the electric power Internet of Things, and the method comprises the steps: carrying out the layer-by-layer splitting of a target database table according to a preset multi-level business logic, obtaining a plurality of sub-tables and a sub-table splitting list, and carrying out the layer-by-layer splitting of a plurality of sub-tables according to the sub-table splitting list, sequentially generating a sub-table subordinate hierarchy list and a sub-table dependency list; monitoring the arrival state of each sub-table transmitted to the target safety area so as to calculate the proportion of the sub-tables arriving in the waiting period; if the sub-table proportion is greater than a preset threshold value, judging whether each arrived sub-table meets an independent processing condition or not according to a sub-table dependency list; and according to the subordinate hierarchical list of the sub-tables, merging the sub-tables capable of being processed independently to obtain a plurality of new database tables, and executing business processing of the power internet of things according to the new database tables. According to the invention, the problem of slow service processing response speed for waiting for complete data due to asynchronous arrival of the data in the data intercommunication process can be solved.

Description

Technical Field

[0001] This invention relates to the field of power Internet of Things (IoT) technology, and in particular to a method, apparatus, equipment and medium for cross-regional data interoperability for power IoT. Background Technology

[0002] With the deepening development of the power Internet of Things (IoT), power monitoring systems are divided into production control zones (Zone I and Zone II) and management information zones (Zone III) based on the protection principles of "security zoning, dedicated networks, horizontal isolation, and vertical authentication." To ensure the safe and stable operation of the power grid, monitoring and control services with high real-time requirements are deployed in the production control zone, while big data analysis, advanced applications, and external services are deployed in the management information zone. Therefore, data interoperability across security zones has become a key technological link in achieving comprehensive perception of the power grid status and intelligent business collaboration. It undertakes the important mission of safely, reliably, and efficiently transmitting production control data from Zone I to Zones II / III to support advanced applications such as status assessment, load forecasting, and fault diagnosis, playing an irreplaceable role in improving the intelligence level and operational efficiency of the power system.

[0003] Currently, in cross-security zone data interoperability, to ensure business integrity and strong data consistency, existing technologies typically employ batch processing synchronization strategies based on complete transactions or business units. Specifically, when the source database distributes the data of a complete business logic across multiple physical sub-tables due to horizontal partitioning, the target security zone (such as Zone III) must wait for all related sub-tables constituting the complete business logic to arrive before data reorganization and business processing can proceed. This "all or nothing" waiting mechanism reveals significant flaws in the real-world environment of the power IoT, characterized by large data traffic, complex network links, and differences in sub-table transmission paths and time consumption. If some sub-tables fail to arrive in time due to network latency, scheduling order issues, or processing anomalies, even if other related sub-tables are ready in advance, the entire business processing flow will be blocked for a long time, resulting in idle data resources and severely delayed business responses, failing to meet the urgent needs of the power system for real-time status awareness and rapid decision-making. Summary of the Invention

[0004] This invention provides a method, apparatus, device, and medium for cross-regional data interoperability in the power Internet of Things (IoT), which can solve the problem of slow business processing response speed due to asynchronous data arrival during cross-security zone data interoperability in the power IoT, while waiting for complete business data.

[0005] In a first aspect, embodiments of the present invention provide a method for cross-regional data interoperability for the power Internet of Things, applicable to the security protection system of power monitoring systems, including: Based on the preset multi-level business logic, the database tables stored in the preset database are split layer by layer to obtain several sub-tables and a sub-table split list. Based on the sub-table split list, a sub-table hierarchy list and a sub-table dependency list are generated in sequence. Monitor the arrival status of data transmitted from each sub-table in the sub-table hierarchy list to the target security zone, and calculate the proportion of sub-tables that arrive at the target security zone within a preset waiting period based on the data arrival status; wherein, the proportion of sub-tables refers to the ratio of the number of sub-tables that arrive within the current waiting period to the actual number of sub-tables transmitted. If the proportion of the sub-tables is greater than the preset complete boundary threshold, then according to the sub-table dependency list, it is determined whether each reached sub-table meets the preset independent processing condition, and the reached sub-tables that meet the independent processing condition are determined to be independent processing sub-tables; wherein, the independent processing condition is that all associated sub-tables pointed to by the foreign key constraints of the reached sub-tables have been reached. Based on the sub-table hierarchy list, the business logic between each independently processable sub-table is identified. Based on each business logic, each independently processable sub-table is logically merged to obtain several new database tables. The new database tables are then stored in the database of the target security zone, so that corresponding power Internet of Things business processing operations can be performed based on the new database tables.

[0006] This invention, through obtaining a list of sub-table hierarchies, clarifies the data's ownership and hierarchy in business logic (e.g., device table -> ammeter -> voltmeter). It also obtains a list of sub-table dependencies (primarily foreign key constraints) to characterize the referential integrity requirements between data. These two lists together constitute a knowledge graph for determining whether data "can be processed independently" and "how to merge," providing a basis for subsequent operations. By calculating the proportion of sub-tables and comparing it with the integrity boundary threshold, it avoids inefficient judgment processes when data arrival is severely insufficient, optimizing the allocation of system computing resources. A sub-table must wait for all its directly and indirectly dependent "child tables" to arrive before it can proceed. Only by ensuring business integrity can this invention, by judging the independent processing conditions of each reached sub-table, ensure that even if only partial data is processed, this data is self-consistent and complete within its own business context, and will not cause subsequent business logic errors due to missing foreign key references. By identifying business logic (such as belonging to the same device), scattered processable sub-tables are clustered, providing semantic guidance for merging. Logical merging then reorganizes the clustered sub-table data according to their business relationships into a new structured database table that can be directly used by upper-layer applications. This allows applications in the target security zone to directly operate on these complete "business data blocks," improving data query efficiency during subsequent business processing. Compared with existing technologies, this invention can significantly improve the business processing response speed in cross-security zone data interoperability scenarios of the power Internet of Things while ensuring the integrity of data business logic.

[0007] In some preferred embodiments of the first aspect, based on the sub-table splitting list, a sub-table hierarchy list and a sub-table dependency list are generated sequentially, specifically as follows: The naming of each sub-table in the sub-table split list is parsed, the original database table to which each sub-table belongs is identified according to the preset naming rules, and the database metadata is queried to obtain the level value of each sub-table in the multi-level business logic split, so as to generate the sub-table subordinate level list according to the original database table to which each sub-table belongs and the corresponding level value. Based on the list of sub-table hierarchies, traverse the field definitions of each sub-table to extract foreign key constraints, and construct a dependency path graph representing the reference relationship between sub-tables based on the foreign key constraints. By analyzing the dependency path graph, the direct and indirect dependencies between sub-tables are determined, and the association depth value is calculated. Based on the direct and indirect dependencies between the sub-tables and the corresponding association depth values, a list of sub-table dependencies is generated.

[0008] This invention generates a list of sub-table hierarchies to clarify the splitting logic of each sub-table, providing an accurate basis for subsequent identification of business logic between sub-tables. Furthermore, by clarifying direct and indirect dependencies between tables and calculating the association depth value to quantify the degree of indirectness of dependencies, it provides accurate data support for subsequent independent processing condition judgments.

[0009] In some preferred embodiments of the first aspect, generating the list of sub-table dependencies further includes: The dependency strength of each dependency is determined based on the cascading operation rules of the foreign key constraints and the nullability attribute of the fields.

[0010] This invention introduces the concept of dependency weights. Strong dependencies (such as ON DELETE CASCADE or NOT NULL fields) mean that the data is tightly coupled and must wait; weak dependencies (such as fields that allow NULL fields) mean that the coupling is loose and may not require strict waiting. This leaves room for future more flexible decision-making strategies (e.g., relaxing weak dependencies in specific scenarios) and improves applicability.

[0011] In some preferred embodiments of the first aspect, based on the sub-table dependency list, it is determined whether each reached sub-table meets the preset independent processing conditions, specifically as follows: For each reached sub-table, using the current sub-table as the source, query the list of dependencies of the sub-table to obtain all related sub-tables that the foreign key constraints of the current sub-table directly or indirectly point to, and obtain the set of dependent sub-tables of the current sub-table. Determine whether each associated sub-table in the dependent sub-table set has been reached. If the dependent sub-table set is empty or all associated sub-tables in the dependent sub-table set have been reached, then determine that the current sub-table meets the independent processing condition.

[0012] This invention ensures the accuracy of independent judgment by obtaining the set of dependent tables and checking whether all tables in it have been reached, and by considering the special case that the set of dependent tables is empty (i.e., the sub-table has no dependencies).

[0013] In some preferred embodiments of the first aspect, the business logic between independently processable sub-tables is identified based on the sub-table hierarchy list, specifically as follows: Based on the sub-table hierarchy list, identify the sub-tables in the independently processable sub-tables that belong to the same original database table and determine them to be in the same business group; For each business group, the hierarchical relationship between the sub-tables within each business group is determined based on the hierarchical values ​​recorded in the sub-table hierarchy list, so as to determine the business logic between the sub-tables within each business group.

[0014] This invention provides a basis for determining whether data belongs to the same business group based on the original database tables, and indicates the primary or secondary or aggregation relationship of data within the group (such as master table - detail table) through hierarchical numerical values, thus providing a basis for the merging order.

[0015] In some preferred solutions of the first aspect, based on the various business logics, the independently processable sub-tables are logically merged to obtain several new database tables, specifically: For each business group, each independently processable sub-table within the current business group is identified as the current merging unit, and based on the hierarchical relationship between the sub-tables within the current business group, the sub-table with the highest hierarchical value is identified as the base sub-table in the current merging unit. Starting from the base sub-table, according to the association path pre-stored in the sub-table hierarchy list, the other sub-tables in the current merging unit are merged with the base sub-table layer by layer to obtain the intermediate wide table record set of the current business group; Based on the results of field integration in the intermediate wide table record set, a blank database table with the corresponding table structure is generated, and the records in the intermediate wide table record set are written into the blank database table to obtain a new database table corresponding to the current business group.

[0016] This invention ensures the orderly integration of data by determining a baseline table and merging sub-tables layer by layer starting from the baseline table.

[0017] In some preferred embodiments of the first aspect, the corresponding power Internet of Things (IoT) business processing operations are performed based on the new database table, specifically as follows: Based on the preset view mapping rules, a structure mapping view with a preset fixed logical table structure is generated for each new database table; When a power IoT business data query request is received, the corresponding business data in the database is obtained by accessing the corresponding structure mapping view, and the corresponding power IoT business processing operation is executed based on the business data.

[0018] This invention adapts new database tables by constructing a structure mapping view. The view is a logical abstraction of the physical table and can be presented as a fixed structure expected by the application. This decouples the underlying data reorganization from the upper-level application logic. Regardless of how the structure of the underlying new database table changes, the application always accesses data through a fixed view interface, achieving "zero-modification" adaptation of business processing procedures and greatly improving feasibility and maintainability.

[0019] Secondly, embodiments of the present invention provide a cross-regional data interoperability device for the power Internet of Things, applicable to the security protection system of a power monitoring system, including a table relationship acquisition module, a sub-table ratio acquisition module, an independent sub-table identification module, and a sub-table merging module, wherein... The inter-table relationship acquisition module is used to split the database tables stored in the preset database layer by layer according to the preset multi-level business logic, to obtain several sub-tables and a sub-table split list, and to generate a sub-table subordinate hierarchy list and a sub-table dependency relationship list in sequence according to the sub-table split list. The sub-table ratio acquisition module is used to monitor the data arrival status of each sub-table in the sub-table subordinate hierarchy list transmitted to the target security zone, and calculate the sub-table ratio that arrives in the target security zone within a preset waiting period based on the data arrival status; wherein, the sub-table ratio refers to the ratio of the number of sub-tables arriving in the current waiting period to the actual number of sub-tables transmitted. The independent sub-table identification module is used to determine whether each reached sub-table meets the preset independent processing condition based on the sub-table dependency list if the proportion of the sub-tables is greater than the preset complete boundary threshold, and to determine that the reached sub-tables that meet the independent processing condition are independent processing sub-tables; wherein, the independent processing condition is that all associated sub-tables pointed to by the foreign key constraints of the reached sub-tables have been reached. The sub-table merging module is used to identify the business logic between each independently processable sub-table according to the sub-table hierarchy list, and to logically merge each independently processable sub-table according to each business logic to obtain several new database tables. The new database tables are then stored in the database of the target security zone, so as to perform corresponding power Internet of Things business processing operations based on the new database tables.

[0020] This invention employs a table relationship acquisition module to obtain a list of sub-table hierarchies, clarifying the data's ownership and hierarchy in business logic (e.g., device table -> ammeter -> voltmeter). It also acquires a list of sub-table dependencies (primarily foreign key constraints) to characterize the referential integrity requirements between data. These two lists together constitute a knowledge graph for determining whether data "can be processed independently" and "how to merge," providing a basis for subsequent operations. A sub-table ratio acquisition module calculates the sub-table ratio and compares it with a complete boundary threshold, avoiding inefficient judgment processes when data is severely insufficient and optimizing the allocation of system computing resources. An independent sub-table identification module further enhances this functionality. The system determines the independent processing conditions of each reached sub-table, ensuring that even if only partial data is processed, this data is self-consistent and complete within its own business context, and will not cause subsequent business logic errors due to missing foreign key references. Through the sub-table merging module, the system identifies business logic (such as belonging to the same device) and clusters the scattered processable sub-tables, providing semantic guidance for merging. Logical merging then reorganizes the clustered sub-table data according to their business relationships into a new structured database table that can be directly used by upper-layer applications. This allows applications in the target security zone to directly operate on these complete "business data blocks," improving the data query efficiency during subsequent business processing.

[0021] Thirdly, embodiments of the present invention provide a terminal device applicable to the security protection system of a power monitoring system, comprising: a processor, a memory, a communication interface, and a communication bus, wherein the processor, the memory, and the communication interface communicate with each other through the communication bus; The memory is used to store at least one executable instruction that causes the processor to perform operations as described in any of the above-described methods for cross-regional data interoperability in the power Internet of Things.

[0022] Fourthly, embodiments of the present invention provide a computer-readable storage medium applicable to the security protection system of a power monitoring system. The computer-readable storage medium includes a stored computer program, wherein, when the computer program is running, it controls the device or apparatus where the computer-readable storage medium is located to execute the cross-regional data interoperability method for the power Internet of Things as described above.

[0023] The above description is merely an overview of the technical solutions of the embodiments of the present invention. In order to better understand the technical means of the embodiments of the present invention and to implement them in accordance with the contents of the specification, and to make the above and other objects, features and advantages of the embodiments of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0024] Figure 1This is a schematic diagram of a cross-regional data interoperability method for the power Internet of Things provided in an embodiment of the present invention; Figure 2 This is a structural diagram of a cross-regional data interoperability device for the power Internet of Things, provided as an embodiment of the present invention. Detailed Implementation

[0025] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0026] Example 1: like Figure 1 As shown in the figure, a cross-regional data interoperability method for the power Internet of Things is provided by an embodiment of the present invention, applicable to the security protection system of power monitoring systems, and includes the following steps: S101, according to the preset multi-level business logic, the database tables stored in the preset database are split layer by layer to obtain several sub-tables and a sub-table split list, and according to the sub-table split list, a sub-table subordinate hierarchy list and a sub-table dependency relationship list are generated in sequence. It should be noted that Zone I, Zone II, and Zone III (sometimes also referred to as Zone 1, Zone 2, and Zone 3) mentioned in this manual are proprietary terms in the power system security zoning and are core concepts in the power monitoring system security protection system. These zones are divided according to relevant regulations in the field and the protection principles of "security zoning, dedicated network, horizontal isolation, and vertical authentication," with the aim of achieving effective isolation between services of different security levels.

[0027] It should be noted that this invention is mainly applicable to the security protection system of power monitoring systems.

[0028] In one specific embodiment, based on preset multi-level business logic, the database tables pre-stored in the preset database are split layer by layer to obtain several sub-tables and a sub-table split list, specifically as follows: (1) Input and preset conditions are: A. Original Database Table: Assume that in the database of the production control area (Area I), there exists a master table for power equipment monitoring named T_Device_Monitor_All. This table structure includes, but is not limited to, the following key fields: station_id (substation number), device_type (equipment type, such as transformer, circuit breaker, disconnector), device_id (unique equipment identifier), monitor_time (monitoring timestamp), current (current value), voltage (voltage value), temperature (temperature value), and other monitoring data fields.

[0029] B. Pre-defined multi-level business logic: To improve query and management efficiency, a three-level splitting logic is pre-defined: Level 1 Logical (Geographic / Management Zone): Split by station_id (substation number). Data for each substation is managed independently.

[0030] Second-level logic (device type partitioning): Based on the first-level partitioning, a second partitioning is performed according to device_type (device type). This separates data for different types of devices within the same substation.

[0031] The third level of logic (time partitioning): Based on the second level of partitioning, it further partitions the data by month according to monitor_time (monitoring time). This implements time-series data sharding, facilitating the management of historical data.

[0032] (2) The process of splitting the layers is as follows: First, the first level of logical splitting (by substation) is performed: The system reads the T_Device_Monitor_All table and, based on the different values ​​of the station_id field (e.g., 'ST001', 'ST002', 'ST003'), physically splits the original table data into different sub-tables, generating, for example: T_Device_Monitor_ST001 (stores data for all devices in ST001 substation); T_Device_Monitor_ST002 (stores data for all equipment in ST002 substation); T_Device_Monitor_ST003 (stores data for all equipment in the ST003 substation)... and so on.

[0033] Furthermore, a second level of logical decomposition (by device type) is performed: For each first-level sub-table (such as T_Device_Monitor_ST001), the system further decomposes it according to the value of the device_type field, outputting (second-level sub-tables): Taking the aforementioned sub-table as an example, the following is generated: T_Device_Monitor_ST001_Transformer (stores data for all transformers in the ST001 substation); T_Device_Monitor_ST001_Breaker (stores data for all circuit breakers in the ST001 substation); T_Device_Monitor_ST001_Isolator (stores data for all disconnect switches in ST001 substation)... and so on.

[0034] Furthermore, a third-level logical split (by time) is performed: For each second-level sub-table (such as T_Device_Monitor_ST001_Transformer), the system performs a final split based on the month to which the monitor_time field belongs, and outputs (the third-level sub-table, i.e., the final sub-table). Taking the aforementioned sub-table as an example, the following is generated: T_Device_Monitor_ST001_Transformer_202307 (stores data for the ST001 substation transformer in July 2023); T_Device_Monitor_ST001_Transformer_202308 (stores data for the ST001 substation transformer in August 2023); T_Device_Monitor_ST001_Transformer_202309 (stores data of the ST001 substation transformer in September 2023)... and so on.

[0035] (3) Generate a list of sub-table splits After the physical splitting process described above is completed (or as part of a splitting transaction), the system automatically traverses the database, collecting the table names, original table names (T_Device_Monitor_All), and splitting path information (e.g., station_id=ST001 -> device_type=Transformer -> month=202307) of all new sub-tables created through this multi-level splitting process, and records them in a structured list, outputting a sub-table splitting list. This list is core metadata, and each record contains at least the following information: Sub-table name (e.g., T_Device_Monitor_ST001_Transformer_202307); Original table name (T_Device_Monitor_All); Separate hierarchical levels from logical values ​​(e.g., {"L1": "ST001", "L2": "Transformer", "L3": "202307"}). (Optional) Auxiliary information such as the physical storage location of the sub-table and the estimated data volume.

[0036] In this embodiment, based on the sub-table splitting list, a sub-table hierarchy list and a sub-table dependency list are generated sequentially. Specifically, the naming of each sub-table in the sub-table splitting list is parsed, the original database table to which each sub-table belongs is identified according to a preset naming rule, and the database metadata is queried to obtain the corresponding hierarchy value of each sub-table in the multi-level business logic splitting. Based on the original database table to which each sub-table belongs and the corresponding hierarchy value, the sub-table hierarchy list is generated. Based on the sub-table hierarchy list, the field definitions of each sub-table are traversed to extract foreign key constraints, and a dependency path graph representing the reference relationship between sub-tables is constructed based on the foreign key constraints. By analyzing the dependency path graph, the direct and indirect dependencies between sub-tables are determined, and the association depth value is calculated. Based on the direct and indirect dependencies between sub-tables and the corresponding association depth value, the sub-table dependency list is generated.

[0037] In this embodiment, generating the list of dependencies for the sub-tables further includes: determining the dependency strength of each dependency based on the cascading operation rules of the foreign key constraints and the nullability attribute of the fields.

[0038] In one specific embodiment, based on the sub-table splitting list, a sub-table hierarchy list and a sub-table dependency list are generated sequentially, specifically as follows: First, obtain the sub-table split list, which is a list recording the names of all sub-tables after logical splitting, as well as database metadata. This metadata stores system data of database table structure, field definitions, and constraint information (for example, obtained by querying the database's INFORMATION_SCHEMA system view).

[0039] Furthermore, generate a list of sub-table hierarchies, traverse the sub-table split list, and perform the following operations for each sub-table: Parse the sub-table name and identify the original logical table to which the sub-table belongs according to the preset naming convention (e.g., including the prefix of the original table identifier); based on the sub-table name or identifier, query the database metadata to obtain the level value of the sub-table in the preset multi-level business logic decomposition; integrate the "sub-table name-original table identifier-level value" correspondence of all sub-tables to generate a list of sub-table subordinate levels.

[0040] Furthermore, a list of sub-table dependencies is generated. Based on all sub-tables in the sub-table hierarchy list, the following operations are performed: The process iterates through the metadata of each sub-table's fields, identifies fields with defined foreign key constraints, and extracts the target table name and target field name referenced by these foreign keys to form initial direct dependency pairs. Using all sub-tables as nodes and the direct dependencies as directed edges, an initial dependency graph is constructed. This graph is analyzed using a graph traversal algorithm (such as depth-first search) to identify indirect dependencies between sub-tables caused by pass-through references, and the association depth from the source table to the target table (i.e., the number of intermediate sub-tables traversed along the path) is calculated. For each identified dependency (including direct and indirect), its dependency strength (e.g., strong or weak dependency) is determined according to the rules in the foreign key constraint definition (e.g., ON DELETE CASCADE, whether the field allows NULL values). All dependencies between sub-tables are summarized, and each relationship record contains information such as "source sub-table, target sub-table, associated field, dependency type (direct / indirect), association depth value, and dependency strength," generating a sub-table dependency list.

[0041] S102, monitor the arrival status of data transmitted from each sub-table in the sub-table subordinate hierarchy list to the target security zone, and calculate the proportion of sub-tables that arrive at the target security zone within a preset waiting period based on the data arrival status; wherein, the proportion of sub-tables refers to the ratio of the number of sub-tables that arrive within the current waiting period to the actual number of sub-tables transmitted. In one specific embodiment, the arrival status of data transmitted from each sub-table in the sub-table hierarchy list to the target security zone is monitored, and based on the data arrival status, the proportion of sub-tables arriving at the target security zone within a preset waiting period is calculated, specifically as follows: Specifically, the system detects whether the arrival timestamp exists to determine whether the corresponding sub-table has been synchronized, then counts the number of arrived sub-tables, and determines the sub-table group coverage ratio based on the number of arrived sub-tables.

[0042] Obtain the data synchronization records of each sub-table, extract the completion timestamp of each sub-table data block arriving in Zone II, and calculate the ratio of the number of sub-tables that have arrived in each batch to the expected total number of sub-tables to obtain the sub-table group coverage ratio.

[0043] Specifically, in order to monitor the number of sub-tables that have arrived, this embodiment queries the data synchronization log table to obtain all synchronization records of the current batch, and iterates through the synchronization records to check the completion timestamp and status identifier of each sub-table, thereby counting the sub-table data that meet the arrival conditions.

[0044] Specifically, by querying the data synchronization log table of the Zone II database, all synchronization records corresponding to the current batch number are filtered out. If a synchronization record of a certain sub-table has a completion timestamp and the status is marked as successful synchronization, it is determined that the sub-table has arrived, and the number of sub-tables that have arrived is counted cumulatively.

[0045] Specifically, when a sub-table arrives, it must have a corresponding record in the data synchronization log table, the record's completion timestamp field (timestamp_complete) must be non-empty, and the record's status field (status) must be "SUCCESS" or "COMPLETED". Only when all three conditions are met will the sub-table be counted in the number of arrived sub-tables N_arrived.

[0046] The formula for calculating the coverage ratio of sub-table groups is: R = N_arrived / N_total × 100% Where R is the sub-table group coverage ratio, N_arrived is the number of sub-tables that have arrived in the current batch, and N_total is the total number of sub-tables expected to be transmitted in the current batch.

[0047] The calculation process for N_arrived is as follows: Initialize the counter count=0, traverse all child table synchronization records in the current batch, and for each child table that meets the arrival criteria, execute count=count+1. After the traversal is complete, N_arrived=count. N_total is the total number of child tables pre-configured or read from the batch metadata.

[0048] In one optional embodiment, the calculation of the sub-table group coverage ratio adopts a dynamic weight allocation mechanism. The system determines the data type based on the batch data tags, assigning higher importance weights to batches containing real-time data of critical equipment and lower weights to batches containing historical data of auxiliary equipment. By weighted calculation of the arrival completeness of each batch, the overall coverage ratio is obtained, which reflects the actual impact of the current data integrity on the safe operation of the power system. When the coverage ratio reaches 0.8, the system determines that the basic conditions for subsequent data reassembly are met.

[0049] S103, if the proportion of the sub-tables is greater than the preset complete boundary threshold, then according to the sub-table dependency list, it is determined whether each reached sub-table meets the preset independent processing condition, and the reached sub-tables that meet the independent processing condition are determined to be independently processable sub-tables; wherein, the independent processing condition is that all associated sub-tables pointed to by the foreign key constraints of the reached sub-tables have been reached. In this embodiment, based on the sub-table dependency list, it is determined whether each reached sub-table meets the preset independent processing condition. Specifically, for each reached sub-table, taking the current sub-table as the source, the sub-table dependency list is queried to obtain all related sub-tables directly or indirectly pointed to by the foreign key constraints of the current sub-table, thus obtaining the set of dependent sub-tables of the current sub-table; it is determined whether each related sub-table in the set of dependent sub-tables has been reached. If the set of dependent sub-tables is empty or all related sub-tables in the set of dependent sub-tables have been reached, then it is determined that the current sub-table meets the independent processing condition.

[0050] In one specific embodiment, based on the sub-table dependency list, it is determined whether each reached sub-table meets the preset independent processing conditions, specifically as follows: First, obtain the list of sub-tables that have arrived, record the identifiers of the sub-tables that have been successfully transferred to the target security zone in the current batch, and the list of sub-table dependencies, recording all dependencies between sub-tables (including foreign key constraints).

[0051] Furthermore, iterate through each of the reached sub-tables in the list (denoted as the current sub-table) and perform the following checks: Starting with the current sub-table as the source, query the sub-table's dependency list to obtain the set of all related sub-tables directly or indirectly pointed to by its foreign key constraints, denoted as the dependent sub-table set. Determine whether each related sub-table in the dependent sub-table set exists in the reached sub-table list. If the dependent sub-table set is empty, or all related sub-tables in the dependent sub-table set exist in the reached sub-table list, then the current sub-table is determined to meet the independent processing condition. Otherwise, it is determined not to meet the condition. Based on the above determination results, generate a list of sub-tables marked as independently processable.

[0052] S104. Based on the sub-table hierarchy list, identify the business logic between each independently processable sub-table, and logically merge each independently processable sub-table according to each business logic to obtain several new database tables. Store the new database tables in the database of the target security zone, and perform corresponding power Internet of Things business processing operations based on the new database tables.

[0053] In this embodiment, the business logic between independently processable sub-tables is identified based on the sub-table hierarchy list. Specifically, the sub-tables belonging to the same original database table in the independently processable sub-tables are identified and determined to be in the same business group based on the sub-table hierarchy list. For each business group, the hierarchical relationship between sub-tables within each business group is determined based on the hierarchy values ​​recorded in the sub-table hierarchy list, so as to determine the business logic between sub-tables within each business group.

[0054] In one specific embodiment, based on the sub-table hierarchy list, the business logic between each independently processable sub-table is identified, specifically as follows: First, obtain the list of sub-tables that can be processed independently, which is a list of sub-table identifiers that have been determined to meet the independent processing conditions, a list of sub-table hierarchies, which records the original logical tables to which each sub-table belongs and their hierarchical information in the business decomposition, and a list of sub-table dependencies (optional, used to enhance judgment), which records information on dependencies such as foreign key references between sub-tables.

[0055] Furthermore, based on the aforementioned list, the sub-tables in the list of independently processable sub-tables are associated, grouped, and logically identified: according to the sub-table hierarchy list, all sub-tables in the list of independently processable sub-tables that belong to the same original logical table are divided into a candidate business group; within each candidate business group, the business status of each sub-table is analyzed based on its hierarchy value. Sub-tables with higher hierarchy values ​​(closer to the root node of the original table) typically represent more core or more summarized business entities; sub-tables with lower hierarchy values ​​(closer to the leaf node) typically represent more detailed or more specific business entities. Dependency verification (if applicable): Verify the relationships inferred in the above steps by referring to the list of dependencies for the sub-tables. For example, if a sub-table inferred as a "dependent table" does indeed have a foreign key pointing to a sub-table inferred as a "master table," then the master-dependent relationship is confirmed. If there are no supporting dependencies, it may be a parallel relationship (like same-level sharding).

[0056] Finally, a business logic relationship description set is generated, which clarifies the grouping of each independently processable sub-table (which sub-tables belong to the same business entity) and the specific business logic relationship between sub-tables within the group (e.g., "Table A (master table) and Table B (slave table) constitute master-slave logic", "Table C and Table D are parallel sharding logic based on geographical region").

[0057] In this embodiment, based on each business logic, each independently processable sub-table is logically merged to obtain several new database tables. Specifically, for each business group, each independently processable sub-table within the current business group is determined as the current merging unit, and based on the hierarchical relationship between the sub-tables within the current business group, the sub-table with the highest hierarchical value is determined as the base sub-table in the current merging unit. Starting from the base sub-table, according to the pre-stored association paths in the sub-table subordinate hierarchy list, other sub-tables in the current merging unit are merged with the base sub-table layer by layer to obtain the intermediate wide table record set of the current business group. Based on the field integration results in the intermediate wide table record set, a blank database table with the corresponding table structure is generated, and the records in the intermediate wide table record set are written into the blank database table to obtain the new database table corresponding to the current business group.

[0058] In one specific embodiment, based on each business logic, the independently processable sub-tables are logically merged to obtain several new database tables. Specifically, each business group defined in the business logic association description set is processed sequentially: For the business group currently being processed, based on the hierarchical relationship of the sub-tables within the group, the sub-table with the highest hierarchical value is determined as the base table (representing the core of the business entity). Based on the sub-table dependency list, the record association paths between other sub-tables within the group and the base table or other sub-tables are clarified.

[0059] Starting with records in the base table, and following the association path, the corresponding records from other sub-tables within the group are horizontally appended to the extended fields of the base table records by matching the values ​​of the association fields (e.g., using a JOIN operation). This process generates a middle-width table record set corresponding to the business group, containing all the necessary business fields.

[0060] Based on the field integration results from the above steps, a predefined new database table structure is dynamically generated or matched for this business group. The record set of the intermediate wide table for this business group is then written into this structure, resulting in a new database table corresponding to this business logic.

[0061] Repeat the above steps for the next business group until all business groups have been processed.

[0062] This results in several new database tables, the number of which is the same as the number of business groups defined in the business logic association description set. Each new table carries the complete data of an independent business group after merging.

[0063] In this embodiment, the corresponding power IoT business processing operation is performed according to the new database table. Specifically, a structure mapping view with a preset fixed logical table structure is generated for each new database table according to the preset view mapping rules. When a power IoT business data query request is received, the corresponding business data in the database is obtained by accessing the corresponding structure mapping view, and the corresponding power IoT business processing operation is performed based on the business data.

[0064] In one specific embodiment, based on the new database table, corresponding power Internet of Things (IoT) business processing operations are performed, specifically as follows: First, obtain the new database tables and their structure definitions, view mapping configuration rules, etc. The view mapping configuration rules define which views need to be created, and how the "logical structure" of each view (i.e., the field names and types expected by the business code) is mapped to the physical fields of the "new database tables". For example, create a view named v_device_monitor, whose logical field id is mapped to the physical field merged_id of the new table t_merged_monitor_001, and (optionally) the original business table structure definition, as a template for generating the view logical structure.

[0065] Furthermore, based on the view mapping configuration rules, corresponding Structured Query Language (CREATE VIEW) statements are generated for one or more logical structures that need to be exposed to the business layer. The core of this statement is a SELECT clause, which renames (AS) the physical fields (such as equipment_code, actual_voltage_value) of the new database table to logical field names (such as device_id, voltage), and can handle necessary calculations or type conversions.

[0066] Furthermore, in the target security zone database, execute the aforementioned CREATE VIEW statement to create a structure-mapped view. The name of this view is typically designed to be the same as or have a pre-defined prefix / suffix as the original table name that the business code expects to access. The business logic requires no modification; it continues to operate according to its original data access logic (whether via SELECT * FROM original_table or via the ORM entity OriginalTable.findAll()), except that its joins or mappings have seamlessly switched from pointing to the physical table to the newly created view.

[0067] It should be noted that when business code performs operations such as querying, inserting (if the view is updatable), and updating on the view, the database management system will automatically convert these operations into corresponding operations on the underlying new database table based on the view definition.

[0068] Ultimately, the business logic process obtains a query result whose data structure matches its original expectations, thereby driving the subsequent business logic to execute normally. Throughout the entire process, the data model perceived by the business code remains unchanged.

[0069] It should be noted that this invention mainly addresses the situation of asynchronous and batch data transmission across security zones in the security protection system of power monitoring systems. More specifically, it describes the situation within a certain waiting period. For sub-tables that do not arrive in the current waiting period, logical merging operations will continue to be performed when they arrive in subsequent waiting periods, and they will be written to the database of the target security zone. Sub-tables that fail to be merged can be processed independently and written to the database of the target security zone separately, so there will be no data loss during transmission.

[0070] It should be noted that this invention is primarily applicable to relational databases such as MySQL.

[0071] This invention, through obtaining a list of sub-table hierarchies, clarifies the data's ownership and hierarchy in business logic (e.g., device table -> ammeter -> voltmeter). It also obtains a list of sub-table dependencies (primarily foreign key constraints) to characterize the referential integrity requirements between data. These two lists together constitute a knowledge graph for determining whether data "can be processed independently" and "how to merge," providing a basis for subsequent operations. By calculating the proportion of sub-tables and comparing it with the complete boundary threshold, it avoids inefficient judgment processes when data arrival is severely insufficient, optimizing the allocation of system computing resources. A sub-table must wait for all its directly and indirectly dependent "child tables" to arrive before it becomes independent. To ensure business integrity, this invention assesses the independent processing conditions of each reached sub-table, ensuring that even if only partial data is processed, this data remains consistent and complete within its own business context, preventing errors in subsequent business logic due to missing foreign key references. By identifying business logic (e.g., belonging to the same device), scattered processable sub-tables are clustered, providing semantic guidance for merging. Logical merging then reorganizes the clustered sub-table data according to their business relationships into a new, structured database table directly usable by upper-layer applications. This allows applications in the target security zone to directly operate on these complete "business data blocks," improving data query efficiency during subsequent business processing. Compared to existing technologies, this invention significantly improves the business processing response speed in cross-security zone data interoperability scenarios for the power Internet of Things while ensuring the integrity of data business logic.

[0072] Example 2: like Figure 2As shown, this embodiment provides a cross-regional data interoperability device for the power Internet of Things, including a meter relationship acquisition module 201, a sub-meter ratio acquisition module 202, an independent sub-meter identification module 203, and a sub-meter merging module 204, wherein... The inter-table relationship acquisition module 201 is used to split the database tables stored in the preset database layer by layer according to the preset multi-level business logic, to obtain several sub-tables and a sub-table split list, and to generate a sub-table subordinate hierarchy list and a sub-table dependency relationship list in sequence according to the sub-table split list. In this embodiment, the inter-table relationship acquisition module 201 generates a sub-table hierarchy list and a sub-table dependency list sequentially based on the sub-table splitting list. Specifically, the inter-table relationship acquisition module 201 parses the names of each sub-table in the sub-table splitting list, identifies the original database table to which each sub-table belongs according to preset naming rules, queries the database metadata, and obtains the corresponding hierarchy value of each sub-table in the multi-level business logic splitting. Based on the original database table to which each sub-table belongs and the corresponding hierarchy value, the sub-table hierarchy list is generated. Based on the sub-table hierarchy list, the field definitions of each sub-table are traversed to extract foreign key constraints, and a dependency path graph representing the reference relationship between sub-tables is constructed based on the foreign key constraints. By analyzing the dependency path graph, the direct and indirect dependencies between sub-tables are determined, and the association depth value is calculated. Based on the direct and indirect dependencies between sub-tables and the corresponding association depth value, the sub-table dependency list is generated.

[0073] The sub-table ratio acquisition module 202 is used to monitor the data arrival status of each sub-table in the sub-table subordinate hierarchy list transmitted to the target security zone, and calculate the sub-table ratio that arrives in the target security zone within a preset waiting period based on the data arrival status; wherein, the sub-table ratio refers to the ratio of the number of sub-tables arriving in the current waiting period to the actual number of sub-tables transmitted. The independent sub-table identification module 203 is used to determine whether each reached sub-table meets the preset independent processing condition according to the sub-table dependency list if the proportion of the sub-tables is greater than the preset complete boundary threshold, and to determine that the reached sub-tables that meet the independent processing condition are independent processing sub-tables; wherein, the independent processing condition is that all associated sub-tables pointed to by the foreign key constraints of the reached sub-tables have been reached. In one specific embodiment, the independent sub-table identification module 203 determines whether each reached sub-table meets the preset independent processing condition based on the sub-table dependency relationship list. Specifically, for each reached sub-table, the independent sub-table identification module 203 queries the sub-table dependency relationship list with the current sub-table as the source to obtain all related sub-tables directly or indirectly pointed to by the foreign key constraints of the current sub-table, thus obtaining the dependent sub-table set of the current sub-table; it then determines whether each related sub-table in the dependent sub-table set has been reached. If the dependent sub-table set is empty or all related sub-tables in the dependent sub-table set have been reached, then the current sub-table is determined to meet the independent processing condition.

[0074] The sub-table merging module 204 is used to identify the business logic between each independently processable sub-table according to the sub-table hierarchy list, and to logically merge each independently processable sub-table according to each business logic to obtain several new database tables, and store the new database tables in the database of the target security zone, so as to perform corresponding power Internet of Things business processing operations according to the new database tables.

[0075] In one specific embodiment, the sub-table merging module 204 identifies the business logic between each independently processable sub-table according to the sub-table hierarchy list. Specifically, the sub-table merging module 204 identifies sub-tables belonging to the same original database table in the independently processable sub-tables according to the sub-table hierarchy list and determines them as the same business group. For each business group, the hierarchical relationship between sub-tables within each business group is determined according to the hierarchical values ​​recorded in the sub-table hierarchy list of each sub-table in the group, so as to determine the business logic between each sub-table in each business group.

[0076] In one specific embodiment, the sub-table merging module 204 performs logical merging on each independently processable sub-table according to each business logic to obtain several new database tables. Specifically, for each business group, the sub-table merging module 204 determines each independently processable sub-table within the current business group as the current merging unit, and determines the sub-table with the highest level value as the base sub-table in the current merging unit based on the hierarchical relationship between the sub-tables within the current business group. Starting from the base sub-table, according to the pre-stored association paths in the sub-table subordinate hierarchy list, the other sub-tables in the current merging unit are merged with the base sub-table layer by layer to obtain the intermediate wide table record set of the current business group. Based on the field integration results in the intermediate wide table record set, a blank database table with the corresponding table structure is generated, and the records in the intermediate wide table record set are written into the blank database table to obtain the new database table corresponding to the current business group.

[0077] For a more detailed explanation of the working principle and procedures of this embodiment, please refer to the relevant description in Embodiment 1.

[0078] This invention employs a table relationship acquisition module 201 to obtain a list of sub-table hierarchies, clarifying the data's ownership and hierarchy in business logic (e.g., device table -> ammeter -> voltmeter). It also acquires a list of sub-table dependencies (primarily foreign key constraints) to characterize the referential integrity requirements between data. These two lists together constitute a knowledge graph for determining whether data "can be processed independently" and "how to merge," providing a basis for subsequent operations. A sub-table proportion acquisition module 202 calculates the sub-table proportion and compares it with a complete boundary threshold, avoiding inefficient judgment processes when data is severely insufficient and optimizing the allocation of system computing resources. An independent sub-table identification module... 203. Determine the independent processing conditions of each reached sub-table to ensure that even if only part of the data is processed, this data is self-consistent and complete within its own business context, and will not cause subsequent business logic errors due to missing foreign key references. Through the sub-table merging module 204, identify business logic (such as belonging to the same device) and cluster the scattered processable sub-tables to provide semantic guidance for merging. Logical merging then reorganizes the clustered sub-table data according to their business relationships into a new structured database table that can be directly used by upper-layer applications, so that applications in the target security zone can directly operate on these complete "business data blocks" and improve the data query efficiency during subsequent business processing.

[0079] Example 3: This embodiment provides a terminal device, including: a processor, a memory, a communication interface, and a communication bus, wherein the processor, the memory, and the communication interface communicate with each other through the communication bus; The memory is used to store at least one executable instruction that causes the processor to perform operations as described in any of the above-described methods for cross-regional data interoperability in the power Internet of Things.

[0080] Example 4: This invention provides a computer-readable storage medium including a stored computer program, wherein the computer program, when running, controls the device or apparatus containing the computer-readable storage medium to execute the cross-regional data interoperability method for the power Internet of Things as described above.

[0081] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0082] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. In particular, it should be noted that any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention for those skilled in the art.

Claims

1. A cross-region data intercommunication method for power Internet of Things, suitable for a security protection system of a power monitoring system, characterized in that, include: Based on the preset multi-level business logic, the database tables stored in the preset database are split layer by layer to obtain several sub-tables and a sub-table split list. Based on the sub-table split list, a sub-table hierarchy list and a sub-table dependency list are generated in sequence. Monitor the arrival status of data transmitted from each sub-table in the sub-table hierarchy list to the target security zone, and calculate the proportion of sub-tables that arrive at the target security zone within a preset waiting period based on the data arrival status; wherein, the proportion of sub-tables refers to the ratio of the number of sub-tables that arrive within the current waiting period to the actual number of sub-tables transmitted. If the proportion of the sub-tables is greater than the preset complete boundary threshold, then according to the sub-table dependency list, it is determined whether each reached sub-table meets the preset independent processing condition, and the reached sub-tables that meet the independent processing condition are determined to be independent processing sub-tables; wherein, the independent processing condition is that all associated sub-tables pointed to by the foreign key constraints of the reached sub-tables have been reached. Based on the sub-table hierarchy list, the business logic between each independently processable sub-table is identified. Based on each business logic, each independently processable sub-table is logically merged to obtain several new database tables. The new database tables are then stored in the database of the target security zone, so that corresponding power Internet of Things business processing operations can be performed based on the new database tables.

2. The cross-region data intercommunication method for power Internet of Things according to claim 1, wherein, Based on the sub-table splitting list, a sub-table hierarchy list and a sub-table dependency list are generated sequentially, as follows: The naming of each sub-table in the sub-table split list is parsed, the original database table to which each sub-table belongs is identified according to the preset naming rules, and the database metadata is queried to obtain the level value of each sub-table in the multi-level business logic split, so as to generate the sub-table subordinate level list according to the original database table to which each sub-table belongs and the corresponding level value. Based on the list of sub-table hierarchies, traverse the field definitions of each sub-table to extract foreign key constraints, and construct a dependency path graph representing the reference relationship between sub-tables based on the foreign key constraints. By analyzing the dependency path graph, the direct and indirect dependencies between sub-tables are determined, and the association depth value is calculated. Based on the direct and indirect dependencies between sub-tables and the corresponding association depth values, a list of sub-table dependencies is generated.

3. A method for cross-regional data interoperability for the power Internet of Things as described in claim 2, characterized in that, The process of generating the sub-table dependency list also includes: The dependency strength of each dependency is determined based on the cascading operation rules of the foreign key constraints and the nullability attribute of the fields.

4. The method for cross-regional data interoperability for the power Internet of Things as described in claim 1, characterized in that, Based on the sub-table dependency list, determine whether each reached sub-table meets the preset independent processing conditions, specifically: For each reached sub-table, using the current sub-table as the source, query the list of dependencies of the sub-table to obtain all related sub-tables that the foreign key constraints of the current sub-table directly or indirectly point to, and obtain the set of dependent sub-tables of the current sub-table. Determine whether each associated sub-table in the dependent sub-table set has been reached. If the dependent sub-table set is empty or all associated sub-tables in the dependent sub-table set have been reached, then determine that the current sub-table meets the independent processing condition.

5. A method for cross-regional data interoperability for the power Internet of Things as described in claim 1, characterized in that, Based on the sub-table hierarchy list, identify the business logic between each independently processable sub-table, specifically: Based on the sub-table hierarchy list, identify the sub-tables in the independently processable sub-tables that belong to the same original database table and determine them to be in the same business group; For each business group, the hierarchical relationship between the sub-tables within each business group is determined based on the hierarchical values ​​recorded in the sub-table hierarchy list, so as to determine the business logic between the sub-tables within each business group.

6. A method for cross-regional data interoperability for the power Internet of Things as described in claim 5, characterized in that, Based on the various business logics, the independently processable sub-tables are logically merged to obtain several new database tables, specifically: For each business group, each independently processable sub-table within the current business group is identified as the current merging unit, and based on the hierarchical relationship between the sub-tables within the current business group, the sub-table with the highest hierarchical value is identified as the base sub-table in the current merging unit. Starting from the base sub-table, according to the association path pre-stored in the sub-table hierarchy list, the other sub-tables in the current merging unit are merged with the base sub-table layer by layer to obtain the intermediate wide table record set of the current business group; Based on the results of field integration in the intermediate wide table record set, a blank database table with the corresponding table structure is generated, and the records in the intermediate wide table record set are written into the blank database table to obtain a new database table corresponding to the current business group.

7. A method for cross-regional data interoperability for the power Internet of Things as described in claim 1, characterized in that, Based on the new database table, perform the corresponding power Internet of Things (IoT) business processing operations, specifically: Based on the preset view mapping rules, a structure mapping view with a preset fixed logical table structure is generated for each new database table; When a power IoT business data query request is received, the corresponding business data in the database is obtained by accessing the corresponding structure mapping view, and the corresponding power IoT business processing operation is executed based on the business data.

8. A cross-regional data interoperability device for the power Internet of Things, applicable to the security protection system of power monitoring systems, characterized in that, This includes modules for obtaining inter-table relationships, obtaining sub-table ratios, identifying independent sub-tables, and merging sub-tables. The inter-table relationship acquisition module is used to split the database tables stored in the preset database layer by layer according to the preset multi-level business logic, to obtain several sub-tables and a sub-table split list, and to generate a sub-table subordinate hierarchy list and a sub-table dependency relationship list in sequence according to the sub-table split list. The sub-table ratio acquisition module is used to monitor the data arrival status of each sub-table in the sub-table subordinate hierarchy list transmitted to the target security zone, and calculate the sub-table ratio that arrives in the target security zone within a preset waiting period based on the data arrival status; wherein, the sub-table ratio refers to the ratio of the number of sub-tables arriving in the current waiting period to the actual number of sub-tables transmitted. The independent sub-table identification module is used to determine whether each reached sub-table meets the preset independent processing condition based on the sub-table dependency list if the proportion of the sub-tables is greater than the preset complete boundary threshold, and to determine that the reached sub-tables that meet the independent processing condition are independent processing sub-tables; wherein, the independent processing condition is that all associated sub-tables pointed to by the foreign key constraints of the reached sub-tables have been reached. The sub-table merging module is used to identify the business logic between each independently processable sub-table according to the sub-table hierarchy list, and to logically merge each independently processable sub-table according to each business logic to obtain several new database tables. The new database tables are then stored in the database of the target security zone, so as to perform corresponding power Internet of Things business processing operations based on the new database tables.

9. A terminal device, applicable to the security protection system of a power monitoring system, characterized in that, include: The processor, memory, communication interface, and communication bus are provided, wherein the processor, memory, and communication interface communicate with each other via the communication bus. The memory is used to store at least one executable instruction that causes the processor to perform the operation of the cross-regional data interoperability method for the power Internet of Things as described in any one of claims 1 to 7.

10. A computer-readable storage medium suitable for a security protection system of a power monitoring system, characterized in that, The computer-readable storage medium includes a stored computer program, wherein, when the computer program is executed, it controls the device or apparatus containing the computer-readable storage medium to perform the cross-regional data interoperability method for the power Internet of Things as described in any one of claims 1 to 7.

Images