Behavior recognition method and system applied to power data cross-domain scene

Abstract

The invention discloses a behavior recognition method and system applied to an electric power data cross-domain scene, and relates to the technical field of electric power data.The behavior recognition method comprises the four steps that firstly, a data source, a service scene, an authority level and a data flow direction serve as cores, and a four-layer cross-domain service semantic map is constructed, receiving new business data in real time, judging whether verification is needed or not, and marking a semantic behavior to be verified; 2, collecting behavior, environment and equipment three-dimensional trusted root data, and fusing and outputting a fusion behavior vector; step 3, performing dual verification of semantic compliance and trusted root matching based on zero trust; and 4, according to the dynamic response of the verification result, the credible behavior is used to execute the label storage associated auditing, the suspicious behavior is dynamically controlled, and the illegal behavior risk is prevented and controlled. According to the scheme, the behavior recognition accuracy is improved, dynamic changes of scenes are adapted, full-period traceability is achieved, safety and efficiency are balanced, and cross-domain data safety is guaranteed.

Description

A behavior recognition method and system applied to cross-domain scenarios of power data Technical Field

[0001] This invention relates to the field of power data technology, and specifically to a behavior recognition method and system applied to cross-domain scenarios of power data. Background Technology

[0002] The construction of new power systems is accelerating, bringing about profound changes in power supply structure, power grid form, and business models. Cross-domain business scenarios such as tradable energy, clean energy consumption, and diversified load dispatch are becoming increasingly rich. Data interaction among multiple entities, including photovoltaic power plants, wind farms, trading platforms, and regional dispatch centers, is becoming more frequent. In this process, the entities connected to the power system are becoming more diverse, and edge devices are more widely distributed. Multiple types of data sources, such as photovoltaic power plant output data and electricity trading price data, need to flow across scenarios. Moreover, the sensitivity levels of different data sources vary significantly, which puts forward a demand for refined management of data access permissions and flow constraints. Therefore, a behavior recognition method and system for cross-domain scenarios of power data is needed.

[0003] Existing technologies, such as the invention application patent with announcement number CN120198166A, disclose a cross-platform power trading data interaction optimization method, specifically involving the field of digital twin technology for power trading data. This method generates simulated trading data of market participants based on an adversarial neural network model, identifies causal relationships between market variables from the simulated trading data of the digital twin using a causal discovery algorithm, and constructs a causal graph. It then uses a graph neural network model to model the spatial dependencies and causal transmission paths among market participants, and performs counterfactual reasoning under a single external shock scenario in the digital twin by intervening in key variables in the causal graph. Finally, it simulates the dynamic game behavior of market participants under extreme weather parameter distribution scenarios, combines causal transmission paths to conduct power market failure assessment, obtains power market failure assessment indicators, and provides early warnings based on these indicators, thereby improving the adaptability and stability of the power market under extreme weather scenarios.

[0004] Regarding the above-mentioned solutions, the inventors of this application have discovered at least the following technical problems: 1. In the prior art, semantic graphs related to power systems mostly adopt a static construction mode. Once the four core elements of the graph (data source, business scenario, permission level, and data flow direction) and association rules are initialized, they remain in a fixed state for a long time, lacking the ability to adapt to dynamic changes in business in real time. On the one hand, the data source level is unable to cope with the rapid access of new data sources such as virtual power plant transaction data and energy storage charging and discharging data in new power systems. Manual intervention is often required to complete node supplementation and attribute labeling, resulting in graph updates lagging behind business development. On the other hand, the fixed design of association rules and semantic constraints cannot respond to the permission adjustment needs brought about by changes in scenarios such as "increased proportion of clean energy consumption and enhanced interaction of diverse loads". At the same time, most existing graphs have not established risk feature defense mechanisms for cross-domain scenarios, making them vulnerable to security threats such as false node insertion and graph embedding attacks. Attackers can forge compliant data flow paths by tampering with the directed edge relationships of the "data flow direction layer", and static graphs lack real-time topology mutation monitoring capabilities, making it difficult to identify such malicious operations.

[0005] 2. Existing technologies often employ a fixed, "one-size-fits-all" data collection model, failing to differentiate their design based on the business characteristics and risk levels of cross-domain power system scenarios. Environmental fingerprint collection is mostly limited to basic parameters such as IP address and network latency, neglecting the physical environmental characteristics of the target power plant, such as the location division between maintenance and non-maintenance areas and equipment operating temperature thresholds. When attackers forge compliant IP network segments to initiate access around the power plant, verification mechanisms relying solely on network parameters are insufficient to identify anomalies. In the data fusion stage, existing technologies often use a simple, fixed-weight concatenation method, failing to consider the different needs for temporal and spatial features in various business scenarios. For example, in tradable energy scenarios, the operational sequence features of behavioral fingerprints are more critical for verification, such as transaction declaration - price confirmation - order generation. In clean energy consumption scenarios, the hardware credibility features of equipment fingerprints are more important. Fixed-weight fusion dilutes core features, reducing the discriminative power of the fused behavioral vector and ultimately affecting verification accuracy.

[0006] 3. In existing technologies, semantic compliance verification and trusted root matching verification are mostly executed independently in parallel processes, lacking a deep correlation and collaborative judgment mechanism between the two, which easily leads to misjudgments and omissions. Semantic compliance verification often only focuses on the surface rule matching of "permission-data source-scenario," without combining the environment and abnormal device characteristics in trusted root data for auxiliary judgment. For example, although a certain behavior conforms to semantic rules, if the device fingerprint shows an unauthorized device, it is easy to be misjudged as compliant based solely on semantic verification. Conversely, trusted root matching verification often ignores the scenario adaptability at the semantic level. Although a device is in the authorized list, if the access behavior initiated is completely unrelated to the business scenario, such as a scheduling platform device accessing electricity trading price data, it is difficult to identify such semantic violations based solely on trusted root verification. At the same time, the setting of verification thresholds is mostly based on empirical values, without dynamic optimization through cross-domain business data training. In addition, existing technologies lack a traceable design for the verification process. When there is a dispute over the verification results, it is impossible to reverse retrieve the complete link data of "feature extraction-rule comparison-result generation," making it difficult to locate the cause of misjudgment.

[0007] 4. Existing technologies exhibit "homogeneity" and "finality" in their responses to different types of behavior, failing to establish a layered closed-loop mechanism adapted to cross-domain scenarios within the power system. Regarding suspicious behavior handling, a uniform multi-factor authentication model is often employed, without risk grading based on data source sensitivity levels or anomaly types. Both high-risk suspicious behavior involving the power transaction floor price and low-risk suspicious behavior related to ordinary data queries require "SMS verification code + password" verification, which neither meets the stringent security requirements of high-risk scenarios nor imposes unnecessary operational burdens on low-risk scenarios. Authorization management often employs extreme models of "full open or full frozen," lacking the ability to dynamically allocate temporary permissions based on specific scenarios, making it difficult to balance security control and business continuity. Regarding the handling of violations, existing technologies mostly stop at the superficial level of "blocking the current operation + logging," failing to establish a risk propagation prevention and source tracing and accountability mechanism. When a device initiates illegal data tampering, only the current operation of that device is blocked, without investigating related behaviors with the same IP address and device identifier, which can easily lead to the spread of risks to other cross-domain platforms. At the same time, log records are mostly stored in local databases, which are at risk of being tampered with, and are not linked with compliance audit systems, making it difficult to support subsequent responsibility determination and regulatory verification. More importantly, the existing handling mechanism lacks a closed loop of "handling-learning-optimization," failing to feed back the verification results of suspicious behaviors and the abnormal characteristics of violations to the semantic graph and trusted root baseline library, resulting in the recurrence of similar problems and hindering the continuous iteration of security capabilities. Summary of the Invention

[0008] To address the aforementioned technical shortcomings, the present invention aims to provide a behavior recognition method and system applicable to cross-domain scenarios of power data.

[0009] To solve the above-mentioned technical problems, the present invention adopts the following technical solution: In the first aspect, the present invention provides a behavior recognition method applied to cross-domain scenarios of power data, including the following steps: Step 1: Constructing a cross-domain business semantic graph: Taking the data source, business scenario, permission level, and data flow direction in the cross-domain scenario as the core elements of the target power system, a four-layer cross-domain business semantic graph is constructed. The new business data of the cross-domain scenario are received in real time, thereby determining whether each new business data needs to be verified, and marking the new business data that needs to be verified as semantic behaviors to be verified.

[0010] Step 2: Collect and fuse 3D trust roots: Collect 3D trust root data of the initiating entity of each semantic behavior to be verified in a cross-domain scenario. The 3D trust root data includes behavioral fingerprint, environmental fingerprint and device fingerprint, and then output the fused behavioral vector corresponding to each semantic behavior to be verified.

[0011] Step 3: Zero-trust behavior credibility determination: Based on the fused behavior vector corresponding to each semantic behavior to be verified, perform double verification on each semantic behavior to be verified to determine whether each semantic behavior to be verified conforms to the consistency of association rules and semantic constraints and the trusted root baseline in the graph.

[0012] Step 4: Implement dynamic response strategy: If both checks of a semantic behavior to be verified pass, the semantic behavior to be verified is determined to be a trustworthy behavior, and signature and evidence-based auditing is performed; if only one check of the two checks of a semantic behavior to be verified passes, the semantic behavior to be verified is determined to be a suspicious behavior, and dynamic control is performed; if both checks of a semantic behavior to be verified fail, the semantic behavior to be verified is determined to be a violation, and risk prevention and control are performed.

[0013] In a second aspect, the present invention provides a behavior recognition system for cross-domain scenarios of power data, comprising the following modules: a cross-domain business semantic graph construction module: used to construct a four-layer cross-domain business semantic graph of the target power system with data source, business scenario, permission level and data flow direction in the cross-domain scenario as core elements, receive new business data of the cross-domain scenario in real time, thereby determining whether each new business data needs to be verified, and marking the new business data that needs to be verified as semantic behavior to be verified.

[0014] The module for collecting and fusing three-dimensional root of trust is used to collect three-dimensional root of trust data of the initiating subject of each semantic behavior to be verified in a cross-domain scenario. The three-dimensional root of trust data includes behavioral fingerprints, environmental fingerprints and device fingerprints, and then outputs the fused behavioral vectors corresponding to each semantic behavior to be verified.

[0015] The zero-trust behavior credibility determination module is used to perform dual verification on each semantic behavior to be verified based on the fused behavior vector corresponding to each semantic behavior to be verified, and to determine whether each semantic behavior to be verified conforms to the consistency of association rules, semantic constraints and credible root baseline in the graph.

[0016] The dynamic response strategy module is used to determine that if both checks of a semantic behavior to be verified pass, the semantic behavior to be verified is a trusted behavior, and signature and evidence storage-related audits are performed; if only one check of the two checks of a semantic behavior to be verified passes, the semantic behavior to be verified is a suspicious behavior, and dynamic control is performed; if both checks of a semantic behavior to be verified fail, the semantic behavior to be verified is a violation, and risk prevention and control are performed.

[0017] The beneficial effects of this invention are as follows: 1. This embodiment of the solution, through the collaborative design of "four-layer cross-domain business semantic graph + three-dimensional trusted root fusion + zero-trust dual verification", significantly improves the accuracy of power business data behavior identification in cross-domain scenarios, effectively making up for the shortcomings of existing technologies such as "poor static rule adaptation and single verification dimension". On the one hand, the four-layer semantic graph deeply associates data sources, business scenarios, permission levels, and data flow, and combined with dynamic rule matching logic, it can accurately identify semantic violations such as "permissions not matching data sources and flow not matching scenarios". On the other hand, the differentiated collection and weighted fusion of three-dimensional trusted root data (behavioral fingerprint, environmental fingerprint, and device fingerprint), combined with LSTM and CNN feature extraction algorithms, can capture underlying security risks such as device forgery and environmental anomalies. For example, the hardware serial number read by the TPM2.0 chip can accurately identify the access behavior of illegal devices. The dual verification mechanism further realizes cross-verification of "semantic compliance + trusted root matching", avoiding false judgments and missed judgments caused by single verification, effectively improving the accuracy of behavior recognition, building a solid security defense for sensitive information such as photovoltaic power output data and user load data, and effectively ensuring the security of cross-domain data interaction in the new power system.

[0018] 2. This embodiment of the solution, through the design of "dynamic response of semantic graph + scenario-based temporary authorization," achieves synergistic optimization of security control and business efficiency, effectively solving the business bottlenecks caused by the "lagging of static rules and rigid authorization models" in existing technologies. In the semantic graph construction stage, the solution supports real-time access to new business data and dynamic rule updates, clearly defining "business scenario" as the core element of the four-layer cross-domain business semantic graph, and requiring the graph to "receive new business data from various cross-domain scenarios in real time," providing a basic capability for the graph to perceive new scenarios and capture new business information. When new power systems add scenarios such as "virtual power plant trading" and "energy storage charging and discharging dispatching," the graph can automatically supplement business scenario nodes and associated rules, completing adaptation without manual intervention. This beneficial effect is reflected in the claims section. Specifically, when new power systems add scenarios such as "virtual power plant trading" and "energy storage charging and discharging dispatching," the graph can automatically supplement business scenario nodes and associated rules, completing adaptation without manual intervention, significantly shortening the security adaptation cycle after new business launches. In the suspicious behavior handling stage, the solution classifies risk levels based on the data source sensitivity level and anomaly type, implementing a differentiated control strategy of "high-risk triple verification and low-risk lightweight verification." This ensures strong security protection for extremely sensitive data while avoiding excessive control over ordinary business operations. Simultaneously, the scenario-based temporary authorization mechanism provides compliant entities with dynamic permissions of "least privileges + time-sensitive control," achieving the control objective of "no security degradation and no efficiency reduction."

[0019] 3. This embodiment of the solution, through the design of "blockchain evidence storage + compliance audit linkage," constructs a full lifecycle traceability system for cross-domain business behavior, encompassing "identification-verification-handling-auditing." This effectively addresses the problems of "easy log tampering and low audit efficiency" in existing technologies, significantly reducing the costs of compliance supervision and operation and maintenance in the power system. For trusted behaviors that pass dual verification, the solution generates structured tags with digital signatures and packages the tags, original three-dimensional root of trust data, and verification logs, uploading them to the power system consortium blockchain. Leveraging the "immutability and multi-node consensus" characteristics of blockchain, the authenticity and integrity of behavioral data are ensured, preventing traceability failures caused by log tampering. Simultaneously, the automatic association between the evidence storage data and the power compliance audit system transforms the audit process from "manual log retrieval and item-by-item verification" to "blockchain evidence storage retrieval and automatic comparison confirmation." Furthermore, the traceability capability of blockchain evidence storage can quickly locate the origin and data flow of violations, providing clear evidence for regulatory agencies to pursue accountability and significantly reducing the manpower costs of supervision and operation and maintenance in cross-domain scenarios.

[0020] 4. This implementation scheme, through a "multi-dimensional blocking + risk feature database iteration" design, forms a closed-loop mechanism of "violation handling - risk diffusion prevention and control - security capability optimization," effectively enhancing the anti-interference capability of the new power system to cope with cross-domain security risks and overcoming the shortcomings of existing technologies such as "single blocking and easy risk diffusion." In the violation handling stage, the scheme implements multi-dimensional collaborative blocking using "API channel suspension + device disabling + network blacklist," not only blocking the current violation but also cutting off the risk propagation path from the device and network ends. In the risk diffusion prevention and control stage, the scheme, through a same-source behavior investigation mechanism, can quickly identify related behaviors with "same IP, same device, and same operation characteristics" as the violation within the past 24 hours, containing the risk at its inception and preventing its spread to multiple scenarios such as photovoltaic power plants and dispatch platforms. Simultaneously, the abnormal characteristics of the violation are updated to the semantic graph risk feature database, and incremental GNN enables dynamic baseline iteration, significantly shortening the response time for identifying similar behaviors in the future, continuously improving the system's ability to resist new security risks, and providing reliable assurance for the stable operation of the new power system. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 is a schematic diagram of the implementation steps of the method of the present invention.

[0023] Figure 2 is a schematic diagram of the system structure connection of the present invention. Detailed Implementation

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

[0025] As shown in Figure 1, an embodiment of the present invention provides a behavior recognition method for cross-domain scenarios of power data, comprising the following steps: Step 1: Constructing a cross-domain business semantic graph: Using the data source, business scenario, permission level, and data flow direction in the cross-domain scenario as core elements, construct a four-layer cross-domain business semantic graph for the target power system. Receive new business data from the cross-domain scenario in real time, thereby determining whether each new business data needs to be verified, and mark the new business data that needs to be verified as semantic behaviors to be verified.

[0026] In a specific embodiment, the construction process of the four-layer cross-domain business semantic graph is as follows: A1. Specific content of the four core elements: The data source layer includes photovoltaic power plant output data, wind farm wind speed data, user load data, and electricity trading price data of the target power system, and marks the sensitivity level of each data source; The business scenario layer includes three core scenarios: tradable energy, clean energy consumption, and diversified load dispatch, and defines the core business actions of each scenario; The permission level layer includes administrator level, maintenance personnel level, and ordinary user level, and clarifies the operation permissions corresponding to each level; The data flow layer defines the flow relationship between each data source and business scenario, as well as the permission subject.

[0027] It should be noted that at the data source layer, the classification of sensitivity levels is based on specific thresholds: for example, "extremely sensitive data sources" are clearly defined as electricity trading price data (involving core market pricing information, the leakage of which would affect market order), "medium sensitive data sources" are photovoltaic power plant output data / wind farm wind speed data (involving power generation planning, access needs to be restricted), and "low sensitive data sources" are user load data (which can be used for load forecasting after de-identification, and has a wider scope of access). At the same time, the "data format" (e.g., electricity trading price data is in JSON format, with a sampling frequency of 5 minutes / time) and "storage location" of each data source are marked (e.g., extremely sensitive data is stored in the core database of the power grid company, and low sensitive data is stored in regional edge nodes), to ensure that the attributes of the data sources are quantifiable and identifiable.

[0028] At the business scenario layer, the specific operation sequence of the core business actions in each scenario is defined as follows: For example, the core business actions of the "tradable energy scenario" are defined as "trading entity registration → electricity declaration → price matching → order generation → transaction settlement". Each action is associated with the corresponding "data input requirements" (such as "electricity declaration" which requires input of power plant output forecast data and user electricity purchase demand data) and "operation timeliness requirements" (such as "price matching" which needs to be completed within 10 minutes). At the same time, the default association relationship between the scenario and the data source is supplemented (such as "clean energy consumption scenario" which is associated with photovoltaic / wind power output data and user consumption data by default), providing a foundation for subsequent rule initialization.

[0029] At the permission level, the specific scope and restrictions of operation permissions at each level are defined: for example, "administrator level" allows "modifying the sensitivity level of data sources, adding business scenario nodes, and configuring the flow of all data", "operation and maintenance personnel level" only allows "viewing low-to-medium sensitivity data sources, modifying the operation logs of equipment in the operation and maintenance area, and applying for temporary data download permissions", and "ordinary user level" only allows "querying personal electricity load data and viewing publicly available clean energy consumption statistics". At the same time, the "effective scope" of permissions is clearly defined (e.g., operation and maintenance personnel level permissions are only effective on the platform of their respective power plants, and cross-platform access requires additional approval) to avoid ambiguity in permission boundaries.

[0030] At the data flow layer, the "scenario constraints" and "priority rules" for flow relationships are as follows: For example, the flow of "photovoltaic power plant output data → regional dispatch platform" is only effective in the "clean energy consumption scenario" and has a "high" priority (prioritizing the data transmission bandwidth of this flow); the flow of "user load data → third-party data analysis platform" must meet the constraints of "data anonymization processing (removing user identity information)" and "only open in the multi-load dispatch scenario", and at the same time mark the "transmission protocol" of the flow (such as using the MQTT protocol to ensure real-time performance) to ensure that the data flow complies with the power system security specifications.

[0031] A2. Initialize association rules and semantic constraints: Define the mapping relationship between data source, business scenario, permission level and data flow by associating graph nodes.

[0032] It should be noted that the quantitative matching thresholds for the association rules of "data source-business scenario-permission level" are as follows: for example, the association rule for "administrator-level permission to access electricity trading price data in a tradable energy scenario" is defined as "access allowed, constraint weight 1.0", the rule for "maintenance operator-level permission to access photovoltaic output data in a clean energy consumption scenario (Sc_002)" is defined as "access allowed, constraint weight 0.9", and the rule for "ordinary user-level permission to access electricity trading price data" is defined as "access prohibited, constraint weight 0". At the same time, the basis for determining the weight is clearly defined (such as calculation based on the product of "permission level × data source sensitivity level × scenario correlation", with a weight ≥ 0.8 indicating access allowed and < 0.8 indicating access restricted), so that the rules can be quantitatively executed.

[0033] Conflict resolution mechanism for semantic constraints on data flow: For example, when the "data source-target node" flow of a new business data matches both "allowed flow" and "prohibited flow" rules (such as user load data simultaneously satisfying "flow to regional dispatch platform (allowed)" and "flow to third-party platform (prohibited)"), the conflict principle of "prohibited flow takes precedence over allowed flow" is defined; when different business scenarios have conflicting flow requirements for the same data source, such as the tradable energy scenario requiring photovoltaic power output data to flow to the trading platform, and the clean energy consumption scenario requiring flow to the dispatch platform, the resolution logic of "allocating flow permissions according to scenario priority (dispatch platform scenario priority > trading platform scenario)" is defined to avoid the failure of flow determination due to rule conflicts.

[0034] Dynamic adjustment of rules is triggered by the following conditions: For example, when the sensitivity level of a data source is increased due to policy requirements (such as user load data being adjusted from "low sensitivity" to "medium sensitivity"), the weight of the "permission-data source" association rule is automatically updated (such as the weight of ordinary users accessing the data being reduced from 0.8 to 0.5); when the business volume of a certain business scenario increases beyond a threshold (such as the daily transaction volume of tradable energy exceeding 100,000 transactions), the "data source-scenario" association weight corresponding to that scenario is automatically adjusted (such as increasing from 0.9 to 1.0, prioritizing the data source access efficiency of that scenario), ensuring that the rules can be dynamically adapted to changes in business.

[0035] A3. Building the graph structure: A four-layer node and edge association structure is constructed using a graph database. Nodes are represented by feature ID + feature attribute, and edges are represented by association type + constraint weight, thus completing the initial construction of the four-layer cross-domain business semantic graph.

[0036] It should be noted that the selection criteria and technical parameters for the graph database are as follows: For example, based on the requirements of the new power system cross-domain scenario of "large data volume (tens of millions of business data per day), complex relationships (four-layer many-to-many relationships of elements), and high real-time query requirements (verification response time ≤ 100ms)," Neo4j 5.0 and above are selected as the graph database. It needs to support "distributed deployment (to meet the data synchronization requirements of cross-regional power plants), ACID transactions (to ensure the consistency of node / edge addition and deletion), and Cypher query language (to simplify the writing of rule matching statements)." At the same time, the database's "storage capacity configuration" (e.g., storage capacity ≥ 10TB for each regional node, supporting 3 years of data retention) and "backup strategy" (daily incremental backup + weekly full backup, with backup data stored in an off-site disaster recovery center) are clearly defined to ensure the security and reliability of the graph data.

[0037] Unified Representation Standards for Nodes and Edges: Regarding node representation, the coding rules for "feature IDs" are clearly defined (e.g., the format for data source node IDs is "DS_XX", where XX is a two-digit number; the format for business scenario node IDs is "Sc_XX"), and the required and optional fields for "feature attributes" are defined (e.g., the required fields for data source nodes are "ID, Name, Sensitivity Level, Data Format, Storage Location", and the optional fields are "Sampling Frequency, Data Size"; the required fields for business scenario nodes are "ID, Name, Core Business Action, List of Related Data Sources", and the optional fields are "Scenario Priority, Average Daily Business Volume"), ensuring consistent representation for different types of nodes. Regarding edge representation, the enumeration values ​​of "association type" are clearly defined (e.g., the association types of the data source-permission level edge include "allowed access, restricted access, and prohibited access", and the association types of the data source-business scenario edge include "core association, secondary association, and no association"), the value range and precision of "constraint weight" (0-1.0, with 1 decimal place), and attributes such as "effective time" and "expiration condition" of the edge are supplemented (e.g., the effective time of an edge is "2025-01-01 to 2025-12-31", and the expiration condition is "data source sensitivity level adjustment") to ensure that the association relationship of the edge can be accurately controlled.

[0038] In a specific embodiment, the determination of whether each new business data needs to be verified is carried out as follows: B1. Extract four types of attributes from each received new business data: data source identifier, business scenario tag, initiating entity permission level, and data flow description, and match the four types of attributes corresponding to each new business data with the association rules in the cross-domain business semantic graph.

[0039] It should be noted that when extracting the four types of attributes from the received new business data, the data format (such as JSON, XML) and preset field rules are combined for accurate identification: When extracting the data source identifier, the "data_source_id" field in the data header is read first (such as "data_source_id:DS_001" in JSON format). If the field is missing, data content feature matching is used (such as data containing the keyword "photovoltaic output" corresponding to the identifier DS_001, and data containing the keyword "electricity trading price" corresponding to DS_003), ensuring that each data source identifier is completely consistent with the node ID of the data source layer of the cross-domain business semantic graph; When extracting business scenario tags, the "business_scene" field is read (such as "business_scene: clean energy consumption"). If the data is an unstructured log, it is determined by the operation action features (such as those containing "transaction declaration" and "order generation" actions are classified as "tradable energy" scenarios, and those containing "output reporting" and "consumption statistics" are classified as "tradable energy" scenarios). The action should be categorized under the "Clean Energy Consumption" scenario, and the tag must strictly correspond to the node name in the graph's business scenario layer. When extracting the initiating entity's permission level, read the "user_permission" field (e.g., "user_permission: Operations and Maintenance Personnel Level"), or identify it through the entity's account prefix (e.g., account prefix "ADM_" corresponds to administrator level, "OPE_" corresponds to operations and maintenance personnel level, and "USR_" corresponds to ordinary user level), ensuring that the level classification is consistent with the node category in the graph's permission level layer. When extracting the data flow description, read the "data_flow" field (e.g., "data_flow: Wind Farm → Regional Dispatch Platform"). If the field is in encoded form (e.g., "flow_code: F_002"), it should be parsed through a preset encoding mapping table (F_002 corresponds to "Wind Farm → Regional Dispatch Platform"). After being broken down into source node and target node identifiers, it needs to be matched with the node ID in the graph's data flow layer to ensure that the flow description accurately reflects the data flow path.

[0040] B2. After extracting the initiating entity's permission level ID and data source ID from each new business data, locate the corresponding permission level layer node and data source layer node in the cross-domain business semantic graph. Query the type of the associated edge between the two nodes to determine whether access is allowed or prohibited, and the constraint weight, where 1.0 represents fully allowed and 0 represents fully prohibited. If the associated edge type of a new business data is allowed and the constraint weight is ≥0.8, then it is determined that the initiating entity's permission level of the new business data allows access to the corresponding data source. If the associated edge type of a new business data is prohibited, or although it is allowed but the constraint weight is <0.8, then it is determined that the initiating entity's permission level of the new business data does not allow access to the corresponding data source.

[0041] B3. Extract data flow descriptions from each new business data and decompose them into source node IDs and target node IDs. In the data flow layer of the cross-domain business semantic graph, query whether there is a directed edge from the source node to the target node. If a new business data does not have such a directed edge, or the edge attribute explicitly marks a prohibited flow direction, then directly determine that the data flow direction of the new business data does not conform to the graph constraints. If a new business data has a directed edge with a permitted flow direction, further verify whether the business scenario label of the new business data is consistent with the permitted flow scenario in the edge attribute. If it is consistent with the permitted scenario, then determine that the data flow direction of the new business data conforms to the graph constraints. If it is inconsistent with the permitted scenario, then determine that the data flow direction of the new business data does not conform to the graph constraints.

[0042] B4. Extract business scenario tags and data source IDs from each new business data. Locate business scenario layer nodes and data source layer nodes in the cross-domain business semantic graph. Query the type and scenario adaptation weight of the associated edge between the two nodes. Here, 1.0 is the core association, 0.5 is the secondary association, and 0 is the no association. If the scenario adaptation weight of the associated edge of a new business data is ≥0.5, it is determined whether the business scenario of the new business data matches the data source. If the scenario adaptation weight of a new business data is <0.5, or there is no associated edge between the two nodes, it is determined that the business scenario of the new business data does not match the data source.

[0043] B5. If a new business data meets the criteria in all three dimensions—the initiating entity's permission to access the data source, the data flow conforming to the graph constraints, and the business scenario matching the data source—and all four core attributes are present, then the new business data is deemed to require no verification and can be directly marked as a trustworthy behavior. If a new business data has any missing attribute among the four categories, or at least one of the three dimensions is deemed to be inconsistent, then the new business data is deemed to require verification and is marked as a semantic behavior to be verified.

[0044] Step 2: Collect and fuse 3D trust roots: Collect 3D trust root data of the initiating entity of each semantic behavior to be verified in a cross-domain scenario. The 3D trust root data includes behavioral fingerprint, environmental fingerprint and device fingerprint, and then output the fused behavioral vector corresponding to each semantic behavior to be verified.

[0045] In a specific embodiment, the collection of three-dimensional trusted root data of the initiating entity of each semantic behavior to be verified in a cross-domain scenario is carried out as follows: C1. The API call logs of the initiating entity are captured in real time through the Flink streaming engine, and the operation sequence, interaction frequency and data access range in the logs are extracted to form a behavior fingerprint dataset.

[0046] C2. Obtain the physical location of the initiating entity, the ambient temperature and humidity of the device by using edge sensors deployed at the target power station, and obtain network latency, IP address and MAC address by using SD-WAN monitoring, and integrate them to form an environmental fingerprint dataset.

[0047] C3. By reading the hardware serial number and trusted certificate number through the TPM2.0 chip built into the behavior initiating device, the device status inspection module of the target power station platform is used to obtain the number of abnormal restarts, the reason for restarts and the operating system version of the device, and the data are summarized to form a device fingerprint dataset.

[0048] In a specific embodiment, the output of the fused behavior vector corresponding to each semantic behavior to be verified is specifically output as follows: D1. Use an LSTM neural network to extract temporal features from the operation sequence and interaction frequency in the behavior fingerprint dataset, and output a 128-dimensional temporal feature vector; use a CNN convolutional neural network to extract spatial features from the physical location and network latency of the environmental fingerprint, as well as the hardware serial number and trusted certificate number of the device fingerprint, and output a 64-dimensional spatial feature vector.

[0049] It should be noted that for temporal feature extraction, the specific configuration of the LSTM neural network is as follows: 3 hidden layers are set, with 256, 128, and 64 neurons in each layer, respectively. The activation function is tanh, the dropout rate is set to 0.2 (to prevent overfitting), and the sequence length is fixed at 30 (taking the 30 most recent operation sequences in the row fingerprint as input). The operation sequences need to be converted into numerical vectors through one-hot encoding, and the interaction frequency is normalized by Z-score (to eliminate dimensional differences) to ensure that the input data meets the requirements of the LSTM network. For spatial feature extraction, the CNN network structure is supplemented: 2 convolutional layers are set (with kernel sizes of 3×3 and 2×2, and stride of 1 for both), 1 pooling layer (max pooling, with a kernel size of 2×2), and the number of neurons in the output layer is 64. The physical location is converted into normalized values ​​of latitude and longitude coordinates (range [0,1]), the network latency is normalized by min-max, and the hardware serial number and trusted certificate number are converted into fixed-length numerical vectors through a hash function (such as SHA-256) to ensure that different types of spatial features can be uniformly input into the CNN for extraction.

[0050] D2. Based on the weights of the business scenarios corresponding to the semantic behaviors to be verified in the cross-domain business semantic graph, assign weights α to the temporal feature vectors and β to the spatial feature vectors.

[0051] D3. Vector Fusion: The temporal feature vector and the spatial feature vector are weighted and summed to obtain a fused behavior vector with a dimension of 128. The formula is: Fusion behavior vector = α × temporal feature vector + β × spatial feature vector.

[0052] Step 3: Zero-trust behavior credibility determination: Based on the fused behavior vector corresponding to each semantic behavior to be verified, perform double verification on each semantic behavior to be verified to determine whether each semantic behavior to be verified conforms to the consistency of association rules and semantic constraints and the trusted root baseline in the graph.

[0053] In a specific embodiment, the determination of whether each semantic behavior to be verified conforms to the consistency of association rules, semantic constraints and trusted root baseline in the graph is specifically performed as follows: E1. The fused behavior vector corresponding to each semantic behavior to be verified is imported into the rule matching database of the cross-domain business semantic graph through the power system security data interface. The rule matching database extracts three types of core information from the fused behavior vector through feature mapping: the initiating subject's permission, the data source access requirement and the business scenario type. It also retrieves the preset permission-data source-scenario association rule library in the cross-domain business semantic graph. The three types of information extracted from each semantic behavior to be verified are compared with the association rules one by one. If all the information of a certain semantic behavior to be verified conforms to the rules, the semantic compliance verification is marked as passed; otherwise, the semantic compliance verification is marked as failed.

[0054] It should be noted that the association weights of each dimension of the integrated behavior vector with the three types of core information are as follows: for example, dimensions 3-8 of the vector are the initiating entity's permission feature dimension (weight accounting for 25%), dimensions 15-22 are the data source access requirement feature dimension (weight accounting for 35%), and dimensions 40-45 are the business scenario type feature dimension (weight accounting for 40%). During the mapping process, the model first normalizes the 128-dimensional fused behavior vector, then calculates the attention weights of each dimension using the softmax function, and selects the top-5 dimensions for feature aggregation. For the initiating entity's permissions, the model matches the feature dimension values ​​with the permission level mapping table (e.g., 0.8-1.0 corresponds to administrator level, 0.5-0.7 corresponds to maintenance personnel level, and 0.1-0.4 corresponds to ordinary user level). For data source access requirements and business scenario types, the model accurately matches the feature dimension values ​​with the graph node ID mapping table (e.g., 0.7-1.0 corresponds to DS_003 electricity trading price data, and 0.6-0.8 corresponds to Sc_001 tradable energy scenario), ensuring that the extracted three types of information are completely consistent with the graph node attributes.

[0055] The association rule base is built upon a four-layer node relationship based on a cross-domain business semantic graph, employing a structured storage format of "triples + constraints." Each rule entry contains core information in the form of a triple: "permission level ID - data source ID - business scenario ID," along with additional attributes such as constraint weight, effective time, and scenario adaptation conditions. For example, a rule entry might be "P_001 (administrator level) - DS_003 (electricity trading price data) - Sc_001 (tradable energy scenario), constraint weight 1.0, effective time from 2025-01-01 to 2025-12-31, adaptation condition: trading hours are 9:00-17:00." The rule base uses Redis distributed caching for storage, with partitioned indexing by business scenario ID (e.g., rules for scenario Sc_001 are stored in a separate partition). During retrieval, the target rule set is quickly located using a bidirectional index of "business scenario ID + permission level ID," with a retrieval response time ≤50ms, meeting the high-concurrency verification requirements of cross-domain scenarios.

[0056] E2. Pre-build a trusted root baseline library to store standard behavioral fingerprint templates, compliant environment fingerprint ranges, and authorized device fingerprint lists for all compliant entities in the target power system. Compare the collected three-dimensional trusted root data of each semantic behavior to be verified with the baseline library data. If the behavioral fingerprint matching degree of a semantic behavior to be verified is ≥90%, the environment fingerprint is within the compliant range, and the device fingerprint is in the authorized list, then mark the trusted root matching verification as passed; otherwise, mark the trusted root matching verification as failed.

[0057] It should be noted that the comparison is performed in the following order: "Business Scenario Type → Data Source Access Requirement → Initiating Entity Permissions": First, it verifies whether the extracted business scenario type matches the business scenario ID associated with "Permissions-Data Source" in the rule base. If they do not match, it is directly determined to be non-compliant. Second, it verifies whether the data source ID corresponding to the data source access requirement is in the list of authorized data sources under this business scenario. If it is not in the list, it is determined to be non-compliant. Finally, it verifies whether the permission ID corresponding to the initiating entity's permission level meets the constraint weight requirements of the rule (constraint weight ≥ 0.8 is considered compliant). Additionally, the processing logic for multi-rule matching is supplemented: if the three types of information for a behavior to be verified match multiple rule entries simultaneously (such as the same permission level being able to access multiple data sources in the same scenario), the rule with the highest constraint weight is taken as the judgment basis; if the extracted information does not match any rule entries, it is determined that the semantic compliance verification fails, ensuring that the comparison process is rigorous and quantifiable.

[0058] E3. Record the pass / fail status of the two checks for each semantic behavior to be verified, forming a binary result of pass or fail.

[0059] Step 4: Implement dynamic response strategy: If both checks of a semantic behavior to be verified pass, the semantic behavior to be verified is determined to be a trustworthy behavior, and signature and evidence-based auditing is performed; if only one check of the two checks of a semantic behavior to be verified passes, the semantic behavior to be verified is determined to be a suspicious behavior, and dynamic control is performed; if both checks of a semantic behavior to be verified fail, the semantic behavior to be verified is determined to be a violation, and risk prevention and control are performed.

[0060] In a specific embodiment, the execution of the signature storage association audit is carried out as follows: F1. Generate signed labels: Generate structured labels for trusted behaviors. The structured labels include behavior ID, initiating entity ID, business scenario type, verification pass timestamp and semantic graph matching degree, and digitally sign the structured labels with the private key of the target power station platform.

[0061] F2. Blockchain Evidence Preservation: The signed tag, the original data of the three-dimensional root of trust, and the double verification log are packaged into an evidence preservation data package and uploaded to the target power system consortium blockchain. The nodes include the power grid company, the target power plant, and the power regulatory agency. After the blockchain nodes complete the consensus, they write the data into the block and generate the evidence preservation hash value and the block height.

[0062] F3. Related Compliance Audit: Synchronize the evidence hash value and behavior ID to the power compliance audit system, and mark the trusted behavior as an audit pass item; during subsequent audits, the audit system directly retrieves the data packet from the blockchain through the evidence hash value.

[0063] In a specific embodiment, the execution of dynamic control is carried out as follows: G1, Risk level classification: Based on the sensitivity level of the data source and the anomaly type of the trusted root involved in the semantic behavior to be verified, the suspicious behavior is classified into three levels: high, medium and low. Among them, high risk is: extremely sensitive data + device fingerprint anomaly, medium risk is: medium sensitive data + environmental fingerprint anomaly, and low risk is: low sensitive data + slight behavioral fingerprint anomaly.

[0064] G2. Differentiated verification: High-risk suspicious behavior triggers triple verification of hardware key + face + business supervisor approval; medium-risk behavior triggers dual verification of face + historical behavior password; low-risk behavior triggers lightweight verification of SMS verification code + device binding confirmation.

[0065] G3. Scenario-based temporary authorization: After verification, a temporary permission is generated with a validity period of: high risk ≤ 2 hours, medium risk ≤ 8 hours, low risk ≤ 24 hours. It is limited to accessing only the smallest subset of data involved in the behavior to be verified, and only allows viewing and downloading operations. The permission will be automatically revoked when the validity period expires.

[0066] In a specific embodiment, the risk prevention and control is implemented as follows: H1, Multi-dimensional blocking: Immediately suspend the API call channel corresponding to the violation, freeze the account of the behavior initiator on all cross-domain platforms of the target power system; send a disable command to the behavior initiating device to close the device's network port and USB interface; add the device's IP and MAC address to the regional power system blacklist to prohibit access to any associated platforms.

[0067] H2. Source Tracing and Accountability: Retrieve the three-dimensional trusted root data of the violation from the blockchain, trace the origin of the violation and the data flow in reverse, and generate a source tracing report; if it is an internal entity, push the report to the power plant management department; if it is an external entity, synchronize it to the power regulatory agency and the public security organ.

[0068] H3. Risk Diffusion Prevention and Control: Investigate related behaviors that share the same origin as the violation within the past 24 hours and mark them as high-risk pending review; update the risk feature library of the cross-domain business semantic graph, incorporate the abnormal features of the violation into the baseline, and directly determine the subsequent similar behaviors as violations.

[0069] As shown in Figure 2, an embodiment of the present invention provides a behavior recognition system for cross-domain scenarios of power data, comprising the following modules: a cross-domain business semantic graph construction module: used to construct a four-layer cross-domain business semantic graph of the target power system with data source, business scenario, permission level, and data flow direction in the cross-domain scenario as core elements, receive new business data of the cross-domain scenario in real time, thereby determining whether each new business data needs to be verified, and marking the new business data that needs to be verified as semantic behavior to be verified.

[0070] The module for collecting and fusing three-dimensional root of trust is used to collect three-dimensional root of trust data of the initiating subject of each semantic behavior to be verified in a cross-domain scenario. The three-dimensional root of trust data includes behavioral fingerprints, environmental fingerprints and device fingerprints, and then outputs the fused behavioral vectors corresponding to each semantic behavior to be verified.

[0071] The zero-trust behavior credibility determination module is used to perform dual verification on each semantic behavior to be verified based on the fused behavior vector corresponding to each semantic behavior to be verified, and to determine whether each semantic behavior to be verified conforms to the consistency of association rules, semantic constraints and credible root baseline in the graph.

[0072] The dynamic response strategy module is used to determine that if both checks of a semantic behavior to be verified pass, the semantic behavior to be verified is a trusted behavior, and signature and evidence storage-related audits are performed; if only one check of the two checks of a semantic behavior to be verified passes, the semantic behavior to be verified is a suspicious behavior, and dynamic control is performed; if both checks of a semantic behavior to be verified fail, the semantic behavior to be verified is a violation, and risk prevention and control are performed.

[0073] The examples described in this invention are not limited to the specific embodiments listed above. The examples are merely illustrative to facilitate understanding of the invention and do not constitute a limitation on the scope of protection of this invention. Any modifications, equivalent substitutions, etc., made within the spirit and principles of this invention should be included within the scope of protection.

[0074] The above description is merely an example and illustration of the concept of the present invention. Those skilled in the art can make various modifications or additions to the specific embodiments described or use similar methods to replace them, as long as they do not deviate from the concept of the invention or exceed the scope defined in this specification, they should all fall within the protection scope of the present invention.

Claims

1. A behavior recognition method applied to cross-domain scenarios of power data, characterized in that, The process includes the following steps: Step 1: Constructing a cross-domain business semantic graph: Using data sources, business scenarios, permission levels, and data flow directions in cross-domain scenarios as core elements, construct a four-layer cross-domain business semantic graph for the target power system. Receive new business data from cross-domain scenarios in real time to determine whether each new business data needs verification, and mark the new business data requiring verification as semantic behaviors to be verified. Step 2: Collecting and fusing three-dimensional trust roots: Collect three-dimensional trust root data of the initiating entity of each semantic behavior to be verified in the cross-domain scenario. The three-dimensional trust root data includes behavioral fingerprints, environmental fingerprints, and device fingerprints, and then output the fused behavioral vector corresponding to each semantic behavior to be verified. Step 3: Zero-trust behavior trust determination: Based on the fused behavioral vector corresponding to each semantic behavior to be verified, perform dual verification on each semantic behavior to be verified to determine whether each semantic behavior to be verified conforms to the consistency of association rules and semantic constraints and trust root baseline in the graph. Step 4: Executing a dynamic response strategy: If both dual verifications of a semantic behavior to be verified pass, the semantic behavior to be verified is determined to be a trustworthy behavior, and signature-based evidence-based auditing is performed. If only one of the two checks of a semantic behavior to be verified passes, the semantic behavior to be verified is determined to be a suspicious behavior, and dynamic control is implemented. If both checks for a semantic behavior to be verified fail, the semantic behavior to be verified is determined to be a violation, and risk control measures are implemented.

2. The behavior recognition method applied to cross-domain scenarios of power data according to claim 1, characterized in that, The construction process of the four-layer cross-domain business semantic graph is as follows: A1. Specific content of the four core elements: The data source layer includes the output data of photovoltaic power plants, wind speed data of wind farms, user load data and electricity transaction price data of the target power system, and marks the sensitivity level of each data source; The business scenario layer includes three core scenarios: tradable energy, clean energy consumption, and diversified load scheduling, and defines the core business actions for each scenario; the permission level layer includes administrator level, operation and maintenance level, and ordinary user level, and clearly defines the operation permissions corresponding to each level. The data flow layer defines the flow relationship between each data source and business scenario, as well as the permission subject; A2, Initialize association rules and semantic constraints: Define the mapping relationship between data source - business scenario - permission level - data flow through graph node association; A3, Build graph structure: Use graph database to build a four-layer node and edge association structure, where nodes are represented by feature ID + feature attribute, and edges are represented by association type + constraint weight, completing the initial construction of the four-layer cross-domain business semantic graph.

3. The behavior recognition method applied to cross-domain scenarios of power data according to claim 2, characterized in that, The specific process for determining whether new business data needs to be validated is as follows: B1. Extract four types of attributes from the received new business data: data source identifier, business scenario tag, initiating entity permission level, and data flow description. Match these four types of attributes for each new business data with the association rules in the cross-domain business semantic graph. B2. After extracting the initiating entity permission level ID and data source ID from each new business data, locate the corresponding permission level layer node and data source layer node in the cross-domain business semantic graph. Query the type of the association edge between the two nodes: allowed access or prohibited access, and the constraint weight, where 1.0 represents fully allowed access and 0 represents fully prohibited access. If the type of the association edge of a new business data is... If access is allowed and the constraint weight is ≥0.8, then the initiating entity of the new business data is deemed to have permission to access the corresponding data source. If the associated edge type of a new business data is "inaccessible," or if access is allowed but the constraint weight is <0.8, then the initiating entity of the new business data is deemed to have permission to disallow access to the corresponding data source. B3. Extract the data flow description from each new business data and decompose it into source node ID and target node ID. In the data flow layer of the cross-domain business semantic graph, query whether the directed edge from the source node to the target node exists. If the new business data does not have the directed edge, or the edge attribute explicitly marks the prohibited flow direction, then the data flow direction of the new business data is directly determined to be inconsistent with the graph constraints. If a new business data does not have the directed edge, or the edge attribute explicitly marks the prohibited flow direction, then the data flow direction of the new business data is directly determined to be inconsistent with the graph constraints. The data contains directed edges with allowed flow directions. Further verification is needed to check if the business scenario label of the new business data matches the allowed flow scenario in the edge attributes. If they match, the data flow direction of the new business data is determined to conform to the graph constraints; otherwise, it is determined that the data flow direction of the new business data does not conform to the graph constraints. B4. Extract business scenario labels and data source IDs from each new business data set. Locate the business scenario layer nodes and data source layer nodes in the cross-domain business semantic graph. Query the type and scenario adaptation weight of the associated edges between the two nodes. Here, 1.0 represents a core association, 0.5 a secondary association, and 0 no association. If the scenario adaptation weight of an associated edge of a new business data set is ≥0.5, then the new business data is determined to conform to the graph constraints. If the business scenario of a new business data is mismatched with the data source, and the scenario adaptation weight of a new business data is less than 0.5, or there is no related edge between two nodes, then the business scenario of the new business data is determined to be mismatched with the data source. B5. If the judgment results of the three dimensions of business scenario matching between a new business data and the data source are all in compliance with the initiating entity's permission to access the data source, the data flow conforms to the graph constraints, and there are no missing four core attributes, then the new business data is determined to be without verification and can be directly marked as a trustworthy behavior. If any attribute of a new business data is missing, or the judgment result of at least one of the three dimensions is not in compliance, then the new business data is determined to be required to be verified and marked as a semantic behavior to be verified.

4. The behavior recognition method applied to cross-domain scenarios of power data according to claim 3, characterized in that, The specific collection process for the three-dimensional trusted root data of the initiating entity of each semantic behavior to be verified in a cross-domain scenario is as follows: C1. Capture the API call logs of the initiating entity in real time through the Flink streaming engine, extract the operation sequence, interaction frequency and data access range in the logs, and form a behavior fingerprint dataset. C2. Obtain the physical location of the behavior initiator, the ambient temperature and humidity of the device through the edge sensors deployed in the target power station, and obtain network latency, IP address and MAC address through SD-WAN monitoring, and integrate them to form an environmental fingerprint dataset; C3. Read the hardware serial number and trusted certificate number through the TPM2.0 chip built into the behavior initiator device, and obtain the number of abnormal restarts, restart reasons and operating system version of the device through the device status inspection module of the target power station platform, and summarize them to form a device fingerprint dataset.

5. The behavior recognition method applied to cross-domain scenarios of power data according to claim 4, characterized in that, The output of the fused behavior vector corresponding to each semantic behavior to be verified is as follows: D1. Use an LSTM neural network to extract temporal features from the operation sequence and interaction frequency in the behavior fingerprint dataset, and output a 128-dimensional temporal feature vector; use a CNN convolutional neural network to extract spatial features from the physical location and network latency of the environmental fingerprint, as well as the hardware serial number and trusted certificate number of the device fingerprint, and output a 64-dimensional spatial feature vector. D2. Based on the weights of the business scenarios corresponding to the semantic behaviors to be verified in the cross-domain business semantic graph, assign weights α to the temporal feature vectors and weights β to the spatial feature vectors. D3. Vector Fusion: The temporal feature vector and the spatial feature vector are weighted and summed to obtain a fused behavior vector with a dimension of 128. The formula is: Fusion behavior vector = α × temporal feature vector + β × spatial feature vector.

6. The behavior recognition method applied to cross-domain scenarios of power data according to claim 5, characterized in that, The specific judgment process for determining whether each semantic behavior to be verified conforms to the association rules, semantic constraints, and trusted root baseline in the graph is as follows: E1. The fused behavior vector corresponding to each semantic behavior to be verified is imported into the rule matching database of the cross-domain business semantic graph through the power system security data interface. The rule matching database extracts three core information types from the fused behavior vector through feature mapping: the initiating entity's permission, data source access requirements, and business scenario type. It also retrieves the preset permission-data source-scenario association rule library in the cross-domain business semantic graph. The three types of information extracted from each semantic behavior to be verified are compared with the association rules one by one. If all the information of a certain semantic behavior to be verified conforms to the rules, the semantic compliance verification is marked as passed; otherwise, the semantic compliance verification is marked as failed. E2. A trusted root baseline library is pre-built to store the standard behavior fingerprint templates, compliance environment fingerprint ranges, and authorized device fingerprint lists of all compliant entities in the target power system. The three-dimensional trusted root data of each semantic behavior to be verified is compared with the baseline library data. If the behavior fingerprint matching degree of a certain semantic behavior to be verified is ≥90%, the environment fingerprint is within the compliance range, and the device fingerprint is in the authorized list, the trusted root matching verification is marked as passed. Otherwise, mark the trusted root matching check as failed; E3, record the pass status of the two checks for each semantic behavior to be verified, forming a binary result of pass or fail.

7. The behavior recognition method applied to cross-domain scenarios of power data according to claim 6, characterized in that, The specific execution process of the signature storage association audit is as follows: F1. Generate signed labels: Generate structured labels for trusted behaviors. The structured labels include behavior ID, initiating entity ID, business scenario type, verification pass timestamp and semantic graph matching degree, and digitally sign the structured labels with the private key of the target power station platform. F2. Blockchain Evidence Preservation: Package the signed tag, the original data of the three-dimensional root of trust, and the double verification log into an evidence preservation data package, and upload it to the target power system alliance blockchain. The nodes include the power grid company, the target power plant, and the power regulatory agency. After the blockchain nodes complete the consensus, they write the block and generate the evidence preservation hash value and the block height. F3. Related Compliance Audit: Synchronize the evidence hash value and behavior ID to the power compliance audit system, and mark the trusted behavior as an audit pass item; during subsequent audits, the audit system directly retrieves the data packet from the blockchain through the evidence hash value.

8. The behavior recognition method applied to cross-domain scenarios of power data according to claim 7, characterized in that, The execution of dynamic control is as follows: G1. Risk Level Classification: Based on the sensitivity level of the data source and the anomaly type of the trusted root involved in the semantic behavior to be verified, suspicious behaviors are classified into three levels: high, medium, and low. High risk is: extremely sensitive data + device fingerprint anomaly; medium risk is: medium sensitive data + environmental fingerprint anomaly; low risk is: low sensitive data + slight behavioral fingerprint anomaly. G2. Differentiated Verification: High-risk suspicious behaviors trigger triple verification of hardware key + face + business supervisor approval; medium risk triggers dual verification of face + historical behavior password; low risk triggers lightweight verification of SMS verification code + device binding confirmation. G3. Contextualized Temporary Authorization: After verification, temporary permissions are generated with a validity period of: high risk ≤ 2 hours, medium risk ≤ 8 hours, low risk ≤ 24 hours. Access is limited to the smallest subset of data involved in the behavior to be verified, and only viewing and download operations are allowed. Permissions are automatically revoked when the validity period expires.

9. The behavior recognition method applied to cross-domain scenarios of power data according to claim 8, characterized in that, The specific execution process for risk prevention and control is as follows: H1. Multi-dimensional blocking: Immediately suspend the API call channel corresponding to the violation, freeze the account of the initiating entity on all cross-domain platforms of the target power system; send a disable command to the device initiating the violation, and shut down the device's network port and USB interface; add the device's IP and MAC address to the regional power system blacklist, prohibiting access to any associated platforms; H2. Source tracing and accountability: retrieve the three-dimensional trusted root data of the violation from the blockchain, trace the origin of the violation and the data flow in reverse, and generate a source tracing report; if it is an internal entity, push the report to the power plant management department; if it is an external entity, synchronize it to the power regulatory agency and the public security organ; H3. Risk Diffusion Prevention and Control: Investigate related behaviors that originate from the same source as the violation within the past 24 hours and mark them as high-risk pending review; Update the risk feature library of the cross-domain business semantic graph, incorporate the abnormal features of violations into the baseline, and directly determine similar behaviors as violations in the future.

10. A system that utilizes the behavior recognition method according to any one of claims 1-9 applied to cross-domain scenarios of power data, characterized in that, It includes the following modules: The cross-domain business semantic graph construction module is used to construct a four-layer cross-domain business semantic graph of the target power system with data sources, business scenarios, permission levels and data flow in cross-domain scenarios as core elements. It receives new business data from cross-domain scenarios in real time, thereby determining whether each new business data needs to be verified, and marking the new business data that needs to be verified as semantic behaviors to be verified. The module for collecting and fusing three-dimensional root of trust is used to collect three-dimensional root of trust data of the initiating subject of each semantic behavior to be verified in a cross-domain scenario. The three-dimensional root of trust data includes behavioral fingerprint, environmental fingerprint and device fingerprint, and then outputs the fused behavioral vector corresponding to each semantic behavior to be verified. The zero-trust behavior credibility determination module is used to perform dual verification on each semantic behavior to be verified based on the fused behavior vector corresponding to each semantic behavior to be verified, and to determine whether each semantic behavior to be verified conforms to the consistency of association rules and semantic constraints and the trust root baseline in the graph. The dynamic response strategy module is used to determine that a semantic behavior to be verified is a trustworthy behavior if both checks of a certain semantic behavior to be verified pass, and to perform a signature and evidence association audit. If only one of the two checks of a semantic behavior to be verified passes, the semantic behavior to be verified is determined to be a suspicious behavior, and dynamic control is implemented. If both checks for a semantic behavior to be verified fail, the semantic behavior to be verified is determined to be a violation, and risk control measures are implemented.

Images