Relay protection tester safety system based on power gap system

Abstract

The invention relates to the technical field of relay protection, in particular to a relay protection tester safety system based on a power gap system, which is characterized in that a data extraction module determines a to-be-tested power grid scene, acquires basic information data from the power gap system, and extracts equipment identity authentication information from a hardware trust root; and the data verification module collects test data and judges the security of the test data in combination with basic information and a trust root verification result. And if the data is not safe, the risk assessment module extracts safety risk data, assesses a risk level and generates a safety risk degree. And the scheme generation module extracts risk factors and matches historical protection data to generate a protection scheme. And the information pushing module sends the risk degree and the scheme to an operation and maintenance terminal to remind personnel of protection. And the secure storage module encrypts and stores the secure data and continuously monitors and updates the secure data. According to the system, the whole process is credible and controllable, and the data protection capability and the operation and maintenance efficiency are improved.

Description

Technical Field

[0001] This invention relates to the field of relay protection technology, and in particular to a safety system for a relay protection tester based on the HarmonyOS power system. Background Technology

[0002] With the rapid development of smart grids, relay protection testing, as a crucial link in ensuring the safe and stable operation of power systems, has seen increasing emphasis on the security, integrity, and reliability of its test data. Traditional relay protection testers commonly face security threats such as device identity forgery, data tampering, and unauthorized access during data acquisition, transmission, and storage. Furthermore, they lack system-level security protection mechanisms and struggle to adapt to complex and ever-changing field testing environments. In existing technologies, most test equipment relies on external encryption modules or independent security protocols for data protection, resulting in low system coupling, delayed response, and incomplete trust chains, failing to achieve end-to-end security and trustworthiness from the hardware layer to the application layer.

[0003] In recent years, the HarmonyOS power system, with its microkernel architecture, distributed security, and trusted execution environment, has been gradually adopted in power terminal equipment, providing a technological foundation for building intrinsic security mechanisms. Meanwhile, hardware roots of trust, as trusted sources for device authentication and firmware integrity verification, have been deployed in high-security devices. However, a systematic solution is still lacking for how to deeply integrate the built-in security capabilities of the HarmonyOS power system with the hardware roots of trust in relay protection testers to achieve reliable and controllable test data throughout the entire process of acquisition, verification, and storage.

[0004] The above content is only used to help understand the technical solution of the present invention and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main objective of this invention is to provide a security system for a relay protection tester based on the Power HarmonyOS system. This system aims to solve the technical problem that existing relay protection testers lack a full-link security protection system that deeply integrates the inherent security mechanism of the Power HarmonyOS system with the hardware root of trust, making it difficult to achieve reliable and controllable test data throughout the entire process of acquisition, verification, and storage.

[0006] To achieve the above objectives, the present invention provides a safety system for a relay protection tester based on the HarmonyOS power system. The system includes a data extraction module, a data verification module, a risk assessment module, a scheme generation module, an information push module, and a secure storage module. The data extraction module is used to determine the power grid test scenario and record it as the test scenario to be tested. It extracts the basic power grid information data of the test scenario to be tested from the power HarmonyOS system and extracts the device identity authentication information from the hardware trust root of the relay protection tester. The data verification module is used to collect power grid test data of the test scenario under test, and combine the power grid basic information data and hardware root of trust verification results to determine whether the power grid test data is safe. The risk assessment module is used to extract security risk data from power grid basic information data and hardware trust root information if the test data is not secure, and to assess the security risk level of the test data based on the security risk data and record it as the security risk degree. The solution generation module is used to extract risk factors that affect the security of test data based on the security risk level, obtain historical protection data of the risk factors, and generate protection solutions based on the historical protection data. The information push module is used to send the security risk level and corresponding protection plan to the operation and maintenance terminal, reminding operation and maintenance personnel to protect the security of power grid test data; The secure storage module is used to encrypt and store the power grid test data if the test data is secure, and to continuously monitor and update the power grid test data.

[0007] Optionally, the step of collecting power grid test data from the test scenario under test, and determining whether the power grid test data is secure by combining power grid basic information data and hardware root of trust verification results, specifically includes: Extract standard test data features of the test scenario to be tested from the basic information data of the power grid and record them as standard data features; calculate the hash similarity between the power grid test data and the standard data features to obtain the data integrity similarity; Set a data integrity standard threshold, determine whether the data integrity similarity reaches the data integrity standard threshold, and if it does, verify the device identity through the hardware root of trust of the relay protection tester to determine whether it is a trusted test device; If it is a trusted testing device, the access control log is extracted according to the built-in security mechanism of the Power HarmonyOS system to check for unauthorized access records. If no unauthorized access records are found, the encrypted transmission protocol of the Power HarmonyOS system is checked during the test data transmission process. If the encrypted transmission protocol is used, the test data is deemed secure. If the data integrity similarity does not reach the data integrity standard threshold, or the device identity is untrustworthy, or there are unauthorized access records, or an encrypted transmission protocol is not used, then the test data is deemed insecure.

[0008] Optionally, the step of extracting security risk data from power grid basic information data and hardware trust root information if the test data is insecure, and assessing the security risk level of the test data based on the security risk data and recording it as the security risk degree, specifically includes: Based on the safety risk data, the affected test data in the power grid test environment are extracted, and the standard safety status of the affected test data is obtained. The real-time safety status is extracted from the power grid test data. The degree of environmental interference on the affected test data is obtained based on the standard safety status and the real-time safety status and recorded as the data safety interference degree. The device trust level of the relay protection tester is extracted based on the hardware trust root information. Assess the sensitivity of the affected test data in power grid security testing and record it as data sensitivity. The risk level of the affected test data is obtained by combining the data security interference level, equipment trust level, and data sensitivity, and recorded as the basic risk level; the basic risk level of all affected test data is added together to obtain the security risk level of the power grid test data.

[0009] Optionally, the step of obtaining the degree of environmental interference on the affected test data based on the standard security state and the real-time security state and recording it as the data security interference degree specifically includes: Calculate the deviation values ​​of different security parameters in the standard security state and the real-time security state and record them as security deviation values, wherein the security parameters include data integrity, transmission confidentiality and access controllability; The sensitivity coefficients of the data to different security parameters are obtained based on the type of test data affected. The parameter interference degree is obtained by multiplying the safety deviation value by the corresponding sensitivity coefficient; the data safety interference degree of the affected test data is obtained by summing the parameter interference degrees of all safety parameters.

[0010] Optionally, the step of extracting the device trust level of the relay protection tester based on the hardware trust root information specifically includes: Determine whether the relay protection tester is a trusted device certified by the Power HarmonyOS system. If it is a certified trusted device, obtain the certification level of the hardware root of trust. The corresponding device trust level is obtained by looking up the preset authentication level-device trust level mapping table; If it is not a certified trusted device, then determine whether the device has a history of security violations; If there are historical security violations, the initial trust level will be lowered based on the number and severity of the violations; if there are no historical security violations, the device trust level will be set to the basic trust level.

[0011] Optionally, the step of assessing the sensitivity of the affected test data in power grid security testing and recording it as data sensitivity specifically includes: Determine whether the affected test data is classified test data; if it is classified test data, obtain the data classification level. The corresponding basic sensitivity coefficient is obtained by looking up the pre-set classification level-sensitivity coefficient comparison table; If the test data is not classified, then determine whether the data involves key power grid parameters, including relay protection settings, power grid topology, and equipment operating thresholds. If key parameters are involved, the weighted values ​​of the key parameters are added to the basic sensitivity coefficient; if no key parameters are involved, the basic sensitivity coefficient is used as the data sensitivity level.

[0012] Optionally, the step of combining data security interference level, device trust level, and data sensitivity to obtain the risk level of the affected test data and recording it as the basic risk level specifically includes: Obtain the importance weight of the affected test data in the power grid testing process and record it as the data importance, where the importance of key test items is higher than that of regular test items; The attack threat level is determined based on the type of threat detected by the built-in security mechanism of the HarmonyOS power system; Set risk weight coefficients for data security interference level, device trust level, data sensitivity, data importance, and attack threat level; multiply each parameter by its corresponding weight coefficient and sum them to obtain the basic risk level of the affected test data.

[0013] Optionally, the key test items include relay protection action characteristic test data, and the threat types include data tampering, man-in-the-middle attacks, and unauthorized access.

[0014] Optionally, the steps of extracting risk factors affecting the security of test data based on the security risk level, obtaining historical protection data for the risk factors, and generating a protection scheme based on the historical protection data are as follows: The dominant risk factors are selected from the risk factors based on the degree of safety risk; Historical protection cases matching the dominant risk factors are extracted from historical protection data, and the protection measures and their implementation effectiveness scores in the cases are obtained. The implementation effectiveness scores are weighted and ranked according to the level of security risk, and the combination of protection measures with the highest score is selected. By combining the built-in security mechanisms of the power HarmonyOS system and the hardware root of trust of the relay protection tester, a protection scheme adapted to the current test scenario is generated based on the combination of the highest-scoring protection measures.

[0015] Optionally, the dominant risk factors include device authentication failure, transmission encryption vulnerability, and abnormal access permissions; the built-in security mechanisms include secure boot, data encryption, and access control; and the hardware root of trust includes device authentication and firmware integrity verification.

[0016] In this invention, a security system for a relay protection tester based on the HarmonyOS power system is constructed by integrating the inherent security mechanism of HarmonyOS with the hardware root of trust of the relay protection tester. This system establishes a complete security protection framework encompassing device authentication, data integrity verification, dynamic risk assessment, and intelligent protection response. It achieves reliable and controllable test data throughout the entire process of acquisition, verification, and storage, significantly improving data tamper-proofing, leakage prevention, and attack resistance. The risk assessment module accurately quantifies security risks, the solution generation module intelligently matches historical protection strategies, and the information push module provides timely alarms, effectively enhancing the system's proactive defense capabilities and operational response efficiency. Furthermore, the system's modular design structure is clear, combining security, intelligence, and scalability, making it suitable for complex and ever-changing power grid testing scenarios and providing highly reliable security assurance for power system relay protection testing. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of the first embodiment of the safety system of the relay protection tester based on the HarmonyOS power system of the present invention; Figure 2 This is a flowchart illustrating the specific steps involved in determining the safety of power grid test data within the safety system of the relay protection tester based on the HarmonyOS power system, as described in this invention.

[0018] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0019] 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 a part of the embodiments of the present invention, and not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0020] In one embodiment, such as Figure 1 As shown, a safety system for a relay protection tester based on the HarmonyOS power system is provided. The system includes a data extraction module, a data verification module, a risk assessment module, a scheme generation module, an information push module, and a secure storage module. The data extraction module is used to determine the power grid test scenario and record it as the test scenario to be tested. It extracts the basic power grid information data of the test scenario to be tested from the power HarmonyOS system and extracts the device identity authentication information from the hardware trust root of the relay protection tester. The power system, HarmonyOS, can be a power-specific operating system based on a microkernel architecture, possessing distributed security mechanisms and a trusted execution environment. It can provide inherent security capabilities for relay protection testers, including process isolation, secure communication, access control, and trusted execution environment support. In this embodiment, HarmonyOS can minimize resource exposure through a system-level microkernel and ensure secure cross-device interaction using distributed identity authentication and end-to-end encryption. Furthermore, HarmonyOS can include, but is not limited to, one or more of the following: a microkernel security subsystem, a distributed device authentication module, and a trusted execution environment (TEE) manager. The hardware root of trust for the relay protection tester can be an immutable secure element integrated into the tester hardware, providing unique device identification and firmware integrity verification capabilities. For example, the hardware root of trust for the relay protection tester can achieve key generation and storage through a physically unclonable function (PUF) or a security chip, supporting secure boot and remote authentication. In an exemplary embodiment, the hardware root of trust for the relay protection tester can include, but is not limited to, a secure boot controller, a device identity key storage unit, and a firmware integrity measurement engine.

[0021] The data extraction module can be a logical functional unit used to synchronously obtain test scenario context and device identity information from the power system's core and hardware trust root. It can be used to ensure that subsequent security verification is based on real and trustworthy input sources, establishing an initial trust anchor for data processing. In one specific embodiment, the data extraction module can provide the data verification module with basic power grid information and device identity authentication information. The power grid test scenario can be the specific power system operating environment and test task context in which the relay protection tester is located, which can be used as the environmental basis for test data acquisition and security strategy formulation. Furthermore, the power grid test scenario can include, but is not limited to, local substation test scenarios, remote transmission line test scenarios, and distributed energy access test scenarios. The test scenario to be tested can be the currently selected power grid test scenario instance used to perform relay protection testing, which can be used as the target object for data extraction and verification operations. In an exemplary embodiment, the test scenario to be tested can be determined by the data extraction module based on the current test task.

[0022] Basic power grid information data can be a set of metadata describing the topology, equipment parameters, and operating status of the test scenario under test. It can be used to verify whether the test data conforms to the physical and logical constraints of the scenario. For example, basic power grid information data can be extracted from the device management or SCADA interface of the power system. Device authentication information can be a unique device identifier and authentication credential generated and signed by the hardware root of trust. It can be used to verify the authenticity of the test instrument and prevent device forgery. In one specific embodiment, device authentication information can be read through the secure interface of the hardware root of trust and typically includes a public key certificate or device ID signature.

[0023] Identifying and designating a power grid test scenario as a test scenario to be tested can be achieved by selecting a specific power grid test scenario as the processing object based on the current test task. Furthermore, identifying and designating a power grid test scenario as a test scenario to be tested can be accomplished by manually selecting test sites through a user interface or by automatically issuing test task identifiers through the scheduling system, thus clarifying the context boundaries for safe processing. Extracting the basic power grid information data of the test scenario to be tested from the Power HarmonyOS system can be achieved by calling the data interface of the Power HarmonyOS system to obtain topology and parameter information related to the test scenario. For example, the basic power grid information data of the test scenario to be tested can be extracted from the Power HarmonyOS system by subscribing to real-time SCADA data through the system service bus or querying from a locally cached power grid model, thereby providing a scenario consistency benchmark for data verification.

[0024] Extracting device authentication information from the hardware root of trust of a relay protection tester can be achieved by reading the device identity credentials stored in the hardware root of trust through a secure channel. In one specific embodiment, extracting device authentication information from the hardware root of trust of the relay protection tester can be achieved by calling the read command of the TPM / SE chip or triggering the PUF circuit to generate a dynamic identity identifier, thereby establishing a foundation for device identity trustworthiness.

[0025] The data verification module is used to collect power grid test data of the test scenario and combine it with the power grid basic information data and hardware root of trust verification results to determine whether the test data is safe. The data verification module is a functional module used to perform dual verification of the source legality and content integrity of the collected power grid test data. It can be used to determine in real time whether the test data has been tampered with or comes from unauthorized devices, blocking abnormal data from entering subsequent processes. In an exemplary embodiment, the data verification module can receive the output of the data extraction module and make a joint judgment based on the hardware root of trust verification result and the power grid basic information data; if it is insecure, the risk assessment module is triggered. Power grid test data can be protection performance indicators such as current, voltage, and action time collected by the relay protection tester in the test scenario. It can be used to reflect the actual response characteristics of the relay protection device under test and is the core object of security protection. Furthermore, power grid test data can include, but is not limited to, analog quantity sampling data, switch quantity action records, and fault waveform segments. The hardware root of trust verification result can be a true / false or credibility score output after verifying the device's identity authentication information, which can be used as one of the bases for the data verification module to determine the legality of the data source. For example, the hardware root of trust verification result can be obtained by the data verification module calling the hardware root of trust verification interface.

[0026] Collecting power grid test data for the test scenario can be achieved by acquiring response signals from relay protection devices through the analog / switching input channels of the tester. In one specific embodiment, collecting power grid test data for the test scenario can be achieved by synchronously sampling multiple channels of electrical quantities or triggering fault simulation and recording the timing of actions, thereby obtaining the raw test results to be verified. Determining the security of the test data by combining basic power grid information data and hardware root of trust verification results can be done by comparing the test data with the expected range of the scenario and verifying the legitimacy of the device identity. Furthermore, determining the security of the test data by combining basic power grid information data and hardware root of trust verification results can be achieved through rule engine matching + digital signature verification or machine learning anomaly detection + remote verification, thereby enabling dual trust determination of both source and content.

[0027] The risk assessment module is used to extract security risk data from power grid basic information data and hardware trust root information if the test data is not secure, and to assess the security risk level of the test data based on the security risk data and record it as the security risk degree. The risk assessment module can be a functional module used to structurally extract risk features from multi-source security information and quantify the security threat level. It can be used to transform abstract security threats into measurable security risk levels, providing a basis for strategy matching. In an exemplary embodiment, the risk assessment module can rely on the anomaly judgment results of the data verification module to output the security risk level to the scheme generation module. Security risk data can be a set of structured features related to security threats extracted from power grid basic information data and hardware trust root information, which can be used to support the quantitative assessment of security risk levels. For example, security risk data can include, but is not limited to, abnormal device identity features, data deviation from normal range features, and abnormal communication link features. The security risk level can be a quantitative representation value or level identifier of the security risk of test data, which can be used as an input parameter for protection strategy matching. In a specific embodiment, the security risk level can be calculated by the risk assessment module based on the security risk data.

[0028] Security risk data is extracted from basic power grid information and hardware root of trust information. This can involve structured analysis of anomalies and authentication failures to extract risk features. Furthermore, extracting security risk data from these data can be achieved by extracting fields based on a preset risk template or by using graph neural networks to identify associated anomalies, thus transforming security events into manageable risk elements. Assessing the security risk level of test data based on this data and recording it as a security risk degree can be done by weighting or classifying the security risk data and outputting the risk level. For example, assessing the security risk level of test data and recording it as a security risk degree can be achieved through expert rule-based scoring or by using a trained risk assessment model to predict the level, thereby enabling a quantitative expression of security threats.

[0029] The solution generation module is used to extract risk factors that affect the security of test data based on the security risk level, obtain historical protection data of the risk factors, and generate protection solutions based on the historical protection data. The solution generation module is a functional module that intelligently matches current risk response strategies based on historical protection experience. It can be used to evolve from passive response to proactive intelligent protection, improving the adaptability and effectiveness of protection strategies. In one specific embodiment, the solution generation module can receive the security risk level, call historical protection data to generate a protection solution, and transmit it to the information push module. Risk factors can be specific factors or variables affecting the security of test data, which can be used to locate the root cause of security problems and guide strategy generation. Further, risk factors can include, but are not limited to, device identity failure, data integrity corruption, and scenario context mismatch. Historical protection data can be records of effective protection measures and their effects previously adopted by the system for similar risk factors, which can be used to provide a basis for strategy matching for current risks. For example, historical protection data can be retrieved from a local or cloud-based security knowledge base. The protection solution can be a set of specific security response measures generated based on the current security risk level, which can be used to guide operations and maintenance or the system to automatically execute protection actions. In an exemplary embodiment, the protection solution can include, but is not limited to, isolating the test channel, resetting device identity binding, and enabling enhanced encryption mode.

[0030] Extracting risk factors affecting test data security based on security risk levels can involve analyzing the dominant risk causes corresponding to the security risk level. Furthermore, extracting risk factors affecting test data security based on security risk levels can be achieved by mapping risk levels to a factor set through table lookup or by backtracking key features through decision trees, thereby locating specific security vulnerabilities. Obtaining historical protection data for risk factors can be achieved by retrieving historical response records matching the current risk factor from a security knowledge base. For example, obtaining historical protection data for risk factors can be achieved by searching a strategy library based on vector similarity or indexing historical cases by risk factor tags, thereby reusing effective protection experience. Generating protection schemes based on historical protection data can be achieved by adapting historically effective strategies to the current context to form an executable scheme. In a specific embodiment, generating protection schemes based on historical protection data can be achieved by filling parameters into a strategy template to generate a new scheme or by fusing multiple strategies to generate a composite response, thereby achieving intelligent and adaptive protection responses.

[0031] The information push module is used to send the security risk level and corresponding protection plan to the operation and maintenance terminal, reminding operation and maintenance personnel to protect the security of power grid test data; The information push module can be a communication function unit responsible for transmitting security risk information and corresponding protective measures to the operation and maintenance terminal in real time. This can shorten security incident response time and improve the intervention efficiency of operation and maintenance personnel. In an exemplary embodiment, the information push module can receive the output of the solution generation module and send alarm and policy information to the operation and maintenance terminal. The operation and maintenance terminal can be a human-machine interface device for operation and maintenance personnel to receive alarm information and perform intervention operations, enabling a closed-loop security response through human-machine collaboration. Furthermore, the operation and maintenance terminal can include, but is not limited to, mobile inspection terminals, main control room monitoring workstations, and remote operation and maintenance tablets.

[0032] Sending security risk levels and corresponding protection schemes to the operation and maintenance terminal can be achieved by pushing alarm and policy information to a designated terminal through a secure communication channel. For example, sending security risk levels and corresponding protection schemes to the operation and maintenance terminal can be achieved through MQTT secure message push or power-dedicated APN channel SMS alarms, thereby enabling human-machine collaborative response. Reminding operation and maintenance personnel to protect the security of power grid test data can be achieved by displaying or broadcasting security alarm information on the operation and maintenance terminal. In a specific embodiment, reminding operation and maintenance personnel to protect the security of power grid test data can be achieved through pop-up prompts + sound alarms or automatic generation of handling tasks by the work order system, thereby prompting timely human intervention.

[0033] The secure storage module is used to encrypt and store the power grid test data if the test data is secure, and to continuously monitor and update the power grid test data.

[0034] The secure storage module can be a storage management unit that performs encrypted storage only on verified power grid test data and continuously monitors its status. It can be used to ensure the confidentiality and integrity of test data during the static storage phase, preventing leakage and subsequent tampering. In an exemplary embodiment, the secure storage module can receive the security judgment result from the data verification module and perform encrypted storage and status monitoring only on legitimate data. The encrypted power grid test data can be a copy of the power grid test data protected by an encryption algorithm after security verification, which can be used to ensure the confidentiality and tamper-proof nature of the data during the storage phase. For example, the encrypted storage of power grid test data can be completed by the secure storage module calling the encryption service interface of the Power HarmonyOS system.

[0035] Encrypting and storing power grid test data can be achieved by applying an encryption algorithm to the verified test data before writing it to a storage medium. In one specific embodiment, encrypting and storing power grid test data can be implemented using AES encryption with a hardware root of trust derived key or by calling the encryption service in the Power HarmonyOS TEE, thereby ensuring the security of static data. Continuously monitoring and updating power grid test data can be achieved by periodically verifying the integrity of the stored test data and recording changes. Furthermore, continuous monitoring and updating of power grid test data can be achieved by periodically calculating hash values ​​and comparing them with the original values ​​or by enabling file system-level integrity monitoring, thereby preventing the stored data from being tampered with or corrupted.

[0036] Taking the relay protection setting verification test in a substation as an example, the safety system of the relay protection tester based on the power system in this embodiment can be as follows: When carrying out the setting verification task of line protection device in a 220kV substation, the data extraction module determines that the current scenario is a line differential protection test scenario, and obtains basic information such as the CT ratio and protection setting of the line from the power system, while reading the tester's equipment certificate from the hardware root of trust; after the tester collects differential current data, the data verification module compares whether the measured value is within the allowable range of the setting and verifies the validity of the equipment certificate; if it is found that the test data exceeds the threshold and the equipment certificate is invalid, the risk assessment module extracts two types of risk factors: abnormal equipment identity and data exceeding the limit, and assesses it as a high-risk level; the scheme generation module searches for similar situations in history that have used the strategy of terminating the test and locking the equipment, and generates the same protection scheme; the information push module immediately sends the high-risk alarm and handling suggestions to the substation main control room operation and maintenance terminal; if the data verification is successful, the security storage module uses the hardware derived key to encrypt and archive the test waveform data, and verifies the integrity of the file daily.

[0037] In one embodiment, the step of collecting power grid test data from the test scenario under test and determining whether the test data is secure by combining power grid basic information data and hardware root of trust verification results is as follows: Extract standard test data features of the test scenario to be tested from the basic information data of the power grid and record them as standard data features; calculate the hash similarity between the power grid test data and the standard data features to obtain the data integrity similarity; The standard test data features can be a set of typical patterns or statistical characteristics that relay protection test data should possess under the test scenario, derived from basic power grid information data. These features can be used as an integrity benchmark to determine whether the actual collected data has been tampered with or is abnormal. In this embodiment, the standard test data features can be generated from basic power grid information data (such as protection settings, CT ratios, system impedance, etc.) through a rule engine or simulation model. Furthermore, the standard test data features can include, but are not limited to, one or more of the following: electrical quantity amplitude distribution characteristics, action timing logic characteristics, and fault response phase relationship characteristics. The standard data features can be a simplified form of the standard test data features, representing the same object as the standard test data features, and can be used for similarity comparison with measured data. In an exemplary embodiment, the method of obtaining the standard data features is consistent with that of obtaining the standard test data features.

[0038] Hash similarity is a measure of the degree of similarity between two sets of data after mapping them to a feature space using a hash algorithm. It can be used to quantify the structural or content-related similarity between power grid test data and standard data features. For example, hash similarity can be obtained by calculating Hamming distance or cosine similarity after performing perceptual hashing or locality-sensitive hashing on the two sets of data respectively. In a specific embodiment, hash similarity may include, but is not limited to, one or more of perceptual hash similarity, MinHash similarity, and SimHash similarity. Data integrity similarity is a specific numerical result obtained by hash similarity calculation between power grid test data and standard data features. It can be used as a core basis for determining whether test data has been tampered with. In this embodiment, data integrity similarity is directly output by the hash similarity calculation operation. The data integrity standard threshold can be a preset similarity threshold used to determine whether data integrity is acceptable, and can be used to provide a decision boundary for integrity verification. Furthermore, the data integrity standard threshold can be set according to the statistical similarity distribution of historical normal test data, or configured by a security policy.

[0039] Extracting standard test data features from the power grid basic information data for the test scenario to be tested and recording them as standard data features can be achieved by parsing the topology and parameters in the power grid basic information data to generate theoretical or expected test data patterns for that scenario. Further, this operation can be implemented by generating feature templates through rule-based reasoning based on protection settings and system parameters, or by calling a digital twin simulation engine to generate typical response curves, thereby establishing an objective benchmark for data integrity verification. Calculating the hash similarity between the power grid test data and the standard data features yields the data integrity similarity. This can be achieved by hashing the measured data and the standard features separately and then calculating the similarity. Further, this operation can be implemented by using perceptual hashing to generate fingerprints from waveform data and then comparing them, or by projecting multi-dimensional test vectors onto the LSH space to calculate approximate similarity, thereby enabling automated identification of data tampering or abnormal acquisition.

[0040] Set a data integrity standard threshold, determine whether the data integrity similarity reaches the data integrity standard threshold, and if it does, verify the device identity through the hardware root of trust of the relay protection tester to determine whether it is a trusted test device; Setting a data integrity standard threshold can be achieved by configuring a lower limit for similarity used to determine whether data integrity is acceptable. Furthermore, this operation can be dynamically set based on the 95th percentile of historical normal data, or implemented by a fixed threshold uniformly issued by the security policy center, thus providing a quantitative basis for integrity verification decisions. Determining whether the data integrity similarity reaches the data integrity standard threshold can be achieved by comparing the data integrity similarity with a preset threshold. Further, this operation can be implemented by triggering Boolean judgment through real-time threshold comparison, or by using fuzzy matching to support tolerance range judgment, thereby initially screening potentially tampered data. The trusted testing device can be a relay protection tester that has been authenticated through a hardware root of trust and has not been revoked or tampered with, which can be used to ensure the authenticity and legitimacy of the test data source device. In this embodiment, the trusted testing device is determined by the device state corresponding to a true hardware root of trust verification result.

[0041] Verifying device identity through the hardware root of trust of the relay protection tester can be achieved by calling the hardware root of trust interface to sign and verify the device identity credentials or by remotely authenticating them. Furthermore, this operation can be implemented by verifying the validity of the device certificate chain or by executing a challenge-response protocol to complete device liveness detection, thereby confirming the physical authenticity of the test device. Determining whether a device is a trusted test device can be done by outputting a Boolean judgment based on the hardware root of trust verification result. Furthermore, this operation can be achieved by directly mapping the verification result to a trusted / untrusted state, or by combining it with a comprehensive judgment based on the device's lifecycle state, thereby filtering data generated by forged or cloned devices.

[0042] If it is a trusted testing device, the access control log is extracted according to the built-in security mechanism of the Power HarmonyOS system to check for unauthorized access records. If no unauthorized access records are found, the encrypted transmission protocol of the Power HarmonyOS system is checked during the test data transmission process. If the encrypted transmission protocol is used, the test data is deemed secure. If the data integrity similarity does not reach the data integrity standard threshold, or the device identity is untrustworthy, or there are unauthorized access records, or an encrypted transmission protocol is not used, then the test data is deemed insecure.

[0043] Access control logs can be a collection of information recorded by the Power HarmonyOS system regarding the access subjects, times, permissions, and operation types to resources related to test data. They can be used to trace and detect unauthorized or illegal access behaviors. In this embodiment, the access control logs are automatically recorded and stored in the protected log area by the security audit subsystem of the Power HarmonyOS system. For example, access control logs can include, but are not limited to, one or more of file access logs, process call logs, and network interface call logs. Unauthorized access records can be operation entries in the access control logs that are identified as exceeding the current subject's permission scope, and can be used as an important negative condition for determining the security of test data. In this embodiment, unauthorized access records are identified by comparing the access subject's permission policy with the actual operation behavior.

[0044] Extracting access control logs based on the built-in security mechanisms of the Power HarmonyOS system can be achieved by calling the Power HarmonyOS security audit interface to obtain access records related to test data. Furthermore, this operation can be implemented by subscribing to access log streams in the security event bus or by batch pulling protected log files by time window, thereby obtaining complete audit clues of data access behavior. Detecting the existence of unauthorized access records can be achieved by analyzing whether there are permission violation entries in the access control logs. Furthermore, this operation can be implemented by matching access subjects and resource permissions based on RBAC policies or by using anomaly detection models to identify unusual access patterns, thereby identifying potential data leakage or injection risks.

[0045] The encrypted transmission protocol can be a secure communication protocol built into the Power HarmonyOS system to ensure the confidentiality and integrity of data during network transmission. It can prevent test data from being illegally obtained, tampered with, or replayed during transmission. In this embodiment, the encrypted transmission protocol is implemented based on Chinese national cryptographic algorithms or TLS 1.3+ and integrated into the distributed soft bus security layer of Power HarmonyOS. For example, the encrypted transmission protocol can include, but is not limited to, one or more of the following: a point-to-point encrypted channel based on SM4, a secure multicast protocol based on DTLS, and a certificate-based two-way authentication RPC security protocol. Detecting whether the test data transmission process uses the encrypted transmission protocol of the Power HarmonyOS system can be done by checking whether the data transmission session has enabled a system-level encrypted channel. Furthermore, this operation can be performed by parsing the network packet header to identify the protocol identifier or verifying whether the session key is derived from the Power HarmonyOS security service, thereby ensuring the security and compliance of the transmission link.

[0046] Determining the security of test data can be achieved by outputting a security judgment when all four checks—data integrity, device identity, access compliance, and transmission encryption—pass. Furthermore, this operation can be implemented using a four-way conditional AND gate or a threshold judgment based on accumulated confidence levels at different stages, thus confirming the end-to-end trustworthiness of the test data. Determining the insecurity of test data can be achieved by outputting an insecurity judgment when any check fails. Furthermore, this operation can be implemented using short-circuit logic, where the first failure results in an insecurity judgment, or by recording all failures for risk factor extraction, thereby triggering subsequent risk assessment processes.

[0047] Taking the distance protection test of a transmission line as an example, the security system of the relay protection tester based on the Power Harmony System in this embodiment can extract the line impedance, CT / PT ratio, and protection settings from the basic information data of the power grid when conducting distance II protection tests on a 500kV line, and generate standard test data characteristics, such as the fault current phase angle should be between -85° and -95°. After the tester collects the actual fault waveform, it calculates the hash similarity between the waveform and the standard characteristics, which is 0.92, higher than the preset threshold of 0.85. Then, the device certificate is verified to be valid through the hardware root of trust, confirming it as a trusted test device. Next, the access control log is extracted from the Power Harmony System, and no unauthorized process is found to read the test cache. Then, the data upload process is checked to see if the SM4-based encrypted transmission protocol is used. If all four checks pass, the test data is determined to be secure and enters the encrypted storage process. If any step fails, such as a similarity of only 0.7, an expired device certificate, log showing that the debugging tool has unauthorized access, or plaintext HTTP transmission, it is immediately determined to be insecure and a risk assessment is initiated.

[0048] In one embodiment, if the test data is insecure, the step of extracting security risk data from the power grid basic information data and hardware trust root information, assessing the security risk level of the test data based on the security risk data, and recording it as the security risk degree is as follows: Based on the safety risk data, the affected test data in the power grid test environment are extracted, and the standard safety status of the affected test data is obtained. The affected test data can be a subset of power grid test data identified as being affected by security threats after security verification failure. This subset can be used as a specific object for risk assessment, avoiding indiscriminate assessment of all test data. In an exemplary embodiment, the affected test data can be located by anomaly fields or timestamps associated with the security risk data. Furthermore, the affected test data can include, but is not limited to, one or more of the following: abnormal amplitude electrical quantity data, waveform recordings during periods of authentication failure, and unencrypted transmission of switch action records. The standard security state can be the ideal operating state of the affected test data under conditions of no interference, trusted equipment, and compliant access, derived from basic power grid information data. It can be used as a benchmark to measure the deviation of actual data. In a specific embodiment, the standard security state can be generated through a power system simulation model or protection logic rules, related to the characteristics of the standard test data but emphasizing security attributes. For example, the standard security state can include the theoretical fault response phase angle range, the expected action timing window, and the set of compliant access permissions.

[0049] The real-time safety status is extracted from the power grid test data. The degree of environmental interference on the affected test data is obtained based on the standard safety status and the real-time safety status and recorded as the data safety interference degree. The real-time security status can be the current security-related status characteristics extracted from the actual collected power grid test data, reflecting the security performance of the test data in a real environment. In this embodiment, the real-time security status can be obtained by parsing security context fields (such as timestamps, source identifiers, integrity verification flags, etc.) in the power grid test data. Further, the real-time security status may include measured phase angle deviation values, device authentication result flags, transmission protocol type identifiers, etc. The data security interference degree can be a quantified value of the difference between the standard security status and the real-time security status, characterizing the intensity of interference from the external environment on the test data, and can be used to measure the degree to which the test data is affected by tampering, forgery, or environmental anomalies. In a specific embodiment, the data security interference degree can be calculated using methods such as state vector distance, rule violation count, or probability distribution KL divergence. For example, the data security interference degree may include state deviation index, rule violation degree, distribution offset, etc.

[0050] The operation of extracting real-time security status from power grid test data can be achieved by parsing security-related attributes (such as source, integrity flags, and transmission methods) from the actually collected power grid test data. Furthermore, this operation can be implemented by parsing security tags in the test data metadata or reconstructing the real-time security context by combining log context, thereby obtaining security performance characteristics under real-world conditions. The operation of obtaining the degree of environmental interference on affected test data based on the standard security status and real-time security status, and recording it as the data security interference degree, can be achieved by calculating the difference between the standard and real-time security statuses. Furthermore, this operation can be implemented by calculating the Euclidean distance of the multidimensional state vector or the number of statistical rule violations and normalizing it, thereby quantifying the impact of external interference on data reliability.

[0051] The device trust level of the relay protection tester is extracted based on the hardware trust root information. The device trust level of the relay protection tester can be a graded representation of the overall trust level of the device based on hardware trust root information assessment. It can reflect the contribution weight of the device's own anti-counterfeiting and anti-tampering capabilities to the trustworthiness of the test data. In this embodiment, the device trust level of the relay protection tester can be comprehensively evaluated based on factors such as the integrity verification results of the hardware trust root, certificate validity period, and whether it is listed on the revocation list. For example, the device trust level of the relay protection tester can include high trust level (complete startup chain + valid certificate), medium trust level (partial verification passed), and low trust level (verification failed or unknown device).

[0052] The operation of extracting the device trust level of a relay protection tester based on hardware trust root information can be achieved by analyzing the verification results, certificate status, and integrity metric values ​​of the hardware trust root and mapping them to a trust level. Furthermore, this operation can be implemented based on preset rule mapping (e.g., verification passed = high trust) or by using a trust assessment model to output continuous trust scores, thereby converting the physical trustworthiness of the device into a numerical value that can participate in risk calculations.

[0053] Assess the sensitivity of the affected test data to power grid security testing and record it as data sensitivity. Data sensitivity can be defined as the criticality of affected test data to power grid security decisions within relay protection logic, reflecting the potential system-level harm caused by data tampering or leakage. In an exemplary embodiment, data sensitivity can be semantically assessed based on power business rules (such as whether it involves main protection or triggers circuit breaker tripping). Furthermore, data sensitivity can include main protection action criteria data, backup protection setting value related data, and non-critical monitoring auxiliary data. Assessing the sensitivity of affected test data in power grid security testing and recording it as data sensitivity can be achieved by determining the criticality of the data to system security based on power protection business logic. Further, this operation can be implemented by matching data types with sensitivity levels through table lookups or by analyzing data impact paths based on protection logic graphs, thereby introducing business semantics to enhance the relevance of risk assessment.

[0054] The risk level of the affected test data is determined by combining the data security interference level, the device trust level, and the data sensitivity, and recorded as the basic risk level. The basic risk level can be a local risk quantification value calculated for a single affected test data by integrating data security interference level, device trust level, and data sensitivity. It can serve as the basic unit for global risk aggregation. In this embodiment, the basic risk level can be fused using a weighted function (such as product, weighted sum, or fuzzy inference) to integrate the three dimensions. For example, the basic risk level can include high basic risk level (high interference + low trust + high sensitivity), medium basic risk level (any medium item), and low basic risk level (all three items are low). The operation of combining data security interference level, device trust level, and data sensitivity to obtain the risk level of the affected test data and recording it as the basic risk level can be achieved by calculating a local risk value from the three dimensions using a fusion function. Furthermore, this operation can be implemented by a weighted product (interference level × (1 - trust level) × sensitivity) or by fusing the three inputs using a fuzzy inference system, thereby enabling multi-factor collaborative risk characterization.

[0055] The basic risk level of all affected test data is superimposed to obtain the safety risk level of the power grid test data.

[0056] The security risk level of the power grid test data can be the overall risk quantification result of the sum of the basic risk levels of all affected test data. This can be used as input to the scheme generation module to match protection strategies. In one specific embodiment, the security risk level of the power grid test data can be aggregated by summing, weighting, or selecting the maximum value from all basic risk levels. For example, the security risk level of the power grid test data can include the cumulative risk sum, the weighted aggregated risk index, and the peak basic risk level.

[0057] The operation of aggregating the base risk levels of all affected test data to obtain the safety risk level of the power grid test data can be achieved by performing an aggregation operation on all base risk levels. Furthermore, this operation can be implemented by linearly summing all base risk levels or taking the maximum base risk level as a representative value, thereby generating a globally unified risk output and supporting strategy matching.

[0058] Taking a data transmission anomaly encountered during the differential protection test of a main transformer as an example, the safety system of the relay protection tester based on the power HarmonyOS system in this embodiment can be described as follows: During the test of a 220kV main transformer, the data verification module discovers that some differential current data does not use an encrypted transmission protocol, and determines it to be unsafe. The risk assessment module extracts the affected test data as the sampled value of the A-phase current on the high-voltage side from the safety risk data. The system generates its standard safety status based on the basic grid information (CT ratio, rated current): the amplitude should be between 0.95 and 1.05 pu, the phase angle is -30° ± 2°, and it must come from a trusted device and be transmitted encrypted. The real-time safety status display shows: the amplitude is normal, but the phase angle is -45°, and although the source device has a valid identity, the transmission is not encrypted. The calculated data security interference degree is 0.6; the device trust level is medium (downgraded due to transmission violation); this data belongs to the core criterion of the main protection, and the sensitivity is high. The three factors combined result in a basic risk degree of 0.72. Since only this one item is affected, the global security risk level is 0.72, triggering the scheme generation module to match the high-risk - main protection data anomaly strategy.

[0059] In one embodiment, the step of obtaining the degree of environmental interference on the affected test data based on the standard security state and the real-time security state and recording it as the data security interference degree is specifically as follows: Calculate the deviation values ​​of different security parameters in the standard security state and the real-time security state and record them as security deviation values. The security parameters include data integrity, transmission confidentiality and access controllability. The sensitivity coefficients of the data to different security parameters are obtained based on the type of test data affected. The parameter interference degree is obtained by multiplying the safety deviation value by the corresponding sensitivity coefficient; the data safety interference degree of the affected test data is obtained by summing the parameter interference degrees of all safety parameters.

[0060] Security parameters can be quantifiable indicators characterizing the compliance status of test data on a specific security dimension, and can be used as a basic dimension to measure the difference between standard security status and real-time security status. In this embodiment, security parameters can include, but are not limited to, one or more of data integrity, transmission confidentiality, and access controllability. Data integrity can be the attribute of test data not being tampered with or damaged during collection, storage, or transmission, and can be used to reflect anti-tampering capabilities, and is one of the security parameters. Further, data integrity can be verified through hash verification, digital signatures, or integrity measurement mechanisms in a Trusted Execution Environment (TEE). Transmission confidentiality can be the ability of test data to prevent eavesdropping or leakage during communication, and can be used to reflect leakage prevention capabilities, and is one of the security parameters. In an exemplary embodiment, transmission confidentiality is determined by whether the encryption transmission protocol of the dedicated power operating system is used and the validity of the key. Access controllability can be the attribute of whether the reading, modification, or deletion operations of test data are strictly restricted to authorized subjects, and can be used to reflect the ability to prevent unauthorized access, and is one of the security parameters. Exemplarily, access controllability is determined based on the access control policy and audit logs of the dedicated power operating system.

[0061] The security deviation value can be the numerical difference between the standard security state and the real-time security state on a certain security parameter, and can be used to quantify the degree of anomaly in that security dimension. In a specific embodiment, the security deviation value is calculated through state comparison, such as converting Boolean differences to 0 / 1, or taking the absolute difference of continuous values. Further, the security deviation value can include, but is not limited to, integrity deviation values ​​(such as hash mismatch = 1), confidentiality deviation values ​​(plaintext transmission = 1), and controllability deviation values ​​(existence of unauthorized access = 1), etc. The type of affected test data can be a functional classification of the affected test data according to the semantics of relay protection services, which can be used to determine its sensitivity coefficient to each security parameter. In this embodiment, the type of affected test data can include, but is not limited to, one or more of the following: setting value verification data, fault recording data, GOOSE / SV communication message data, etc.

[0062] Sensitivity coefficients can be weighting factors reflecting the importance of a specific type of test data to a certain security parameter, and can be used to implement business semantic-driven risk weighting. Furthermore, sensitivity coefficients are derived from a preset rule base or business knowledge graph and are jointly determined by the data type and security parameter. For example, sensitivity coefficients can include, but are not limited to, high sensitivity coefficients (e.g., primary protection recording for integrity), medium sensitivity coefficients (e.g., backup settings for confidentiality), and low sensitivity coefficients (e.g., auxiliary monitoring for access controllability). Parameter interference degree can be the product of the deviation value of a security parameter and its corresponding sensitivity coefficient, and can be used to reflect the actual contribution of that security dimension to the overall interference degree. In a specific embodiment, parameter interference degree is obtained by calculating the security deviation value × sensitivity coefficient item by item. Furthermore, parameter interference degree can include, but is not limited to, integrity interference degree, confidentiality interference degree, and controllability interference degree. Data security interference degree can be the sum of the parameter interference degrees of all security parameters, characterizing the comprehensive interference intensity of the environment on a single affected test data, and can be used as a key input for calculating the basic risk degree. In this embodiment, data security interference degree is obtained by linearly summing the parameter interference degrees.

[0063] The deviation values ​​of different security parameters in the standard security state and the real-time security state are calculated and recorded as security deviation values. This can be achieved by comparing the deviation values ​​of three security parameters—data integrity, transmission confidentiality, and access controllability—to the standard and real-time states, and outputting the degree of deviation. Furthermore, this operation can be implemented using Boolean parameters: a deviation value of 1 for inconsistency and 0 otherwise; or continuous parameters: taking the absolute difference. This allows the multi-dimensional security state differences to be structured into calculable numerical values. The sensitivity coefficients of the affected test data to different security parameters are obtained based on the data type. This can be achieved by querying a preset mapping table or a rule engine, outputting the sensitivity coefficients for each of the three security parameters according to the data type. For example, this operation can be implemented by loading a type-parameter sensitivity matrix from a configuration file or by inferring sensitivity weights from a power business knowledge graph, thereby introducing business semantics and ensuring that the risk assessment aligns with actual protection logic requirements.

[0064] The parameter interference degree is obtained by multiplying the security deviation value by the corresponding sensitivity coefficient. This can be achieved by performing the operation of security deviation value × sensitivity coefficient for each security parameter. In an exemplary embodiment, this operation can be achieved by directly multiplying scalars or introducing nonlinear functions (such as exponential weighting) to enhance the influence of highly sensitive terms, thereby amplifying the abnormal impact of key security dimensions and suppressing noise in non-key dimensions. The data security interference degree of the affected test data is obtained by summing the parameter interference degrees of all security parameters. This can be achieved by adding the interference degrees of integrity, confidentiality, and controllability parameters. Furthermore, this operation can be achieved by simple arithmetic summation or weighted summation (if more parameters are added in the future), thereby generating a single comprehensive interference index to support subsequent risk fusion calculations.

[0065] Taking the unauthorized access encountered during the GOOSE trip command test as an example, the security system of the relay protection tester based on the power HarmonyOS system in this embodiment can be as follows: When testing the GOOSE trip function of the main transformer protection in a smart substation, the data verification module finds that an unauthorized process is reading the test cache. The affected test data type is GOOSE communication message data. The system defines its sensitivity coefficients for three types of security parameters as follows: data integrity 0.8, transmission confidentiality 0.6, and access controllability 0.95 (access control is extremely critical because GOOSE involves tripping). The standard security status requirements are: integrity verification passed (value 1), encrypted transmission (value 1), no unauthorized access (value 1); the real-time status is: integrity passed (1), encrypted transmission (1), but unauthorized access exists (0). The calculated security deviation values ​​are: integrity 0, confidentiality 0, and controllability 1. The parameter interference values ​​are: 0×0.8=0, 0×0.6=0, 1×0.95=0.95. The data security interference level is 0 + 0 + 0.95 = 0.95, which is significantly higher than other scenarios, triggering a high-risk response strategy.

[0066] In one embodiment, the step of extracting the device trust level of the relay protection tester based on the hardware trust root information is specifically as follows: Determine whether the relay protection tester is a trusted device certified by the Power HarmonyOS system.

[0067] In this system, trusted devices certified by the Power HarmonyOS system can be relay protection testers that have passed the Power HarmonyOS system's device access mechanism verification and are included in the trusted device directory. These can be used as a prerequisite for determining high-trust-level devices and enjoy trust assignment based on hardware authentication levels. In this embodiment, the identity binding and certificate issuance for trusted devices certified by the Power HarmonyOS system can be completed by the Power HarmonyOS system's distributed device authentication service. Determining whether a relay protection tester is a trusted device certified by the Power HarmonyOS system can be done by querying the Power HarmonyOS system's trusted device registry or verifying the validity of the device certificate chain. Furthermore, this determination can be achieved by verifying whether the device's digital certificate was issued by the Power HarmonyOS CA or checking whether the device ID exists in the local trusted device whitelist, thereby distinguishing whether the device possesses authoritative authentication status and determining the subsequent trust assessment path.

[0068] If it is an authenticated trusted device, then obtain the authentication level of the hardware root of trust.

[0069] The authentication level of the hardware root of trust can be a security level identifier assigned to the hardware root of trust based on its security capabilities (such as chip type, key protection strength, and remote proof support). This level can reflect the strength of the device's underlying security capabilities and serve as input for trust level mapping. In an exemplary embodiment, the authentication level of the hardware root of trust can be written and signed by the hardware root of trust itself or by the Power HarmonyOS system during device registration. For example, the authentication level of the hardware root of trust can include, but is not limited to, one or more of the following: high security level (supporting PUF + Secure Boot + Remote Proof), medium security level (having SE but no remote proof), and basic security level (only software-simulated root of trust). Obtaining the authentication level of the hardware root of trust can be achieved by reading the authentication level field from the secure storage area of ​​the hardware root of trust or from the Power HarmonyOS device metadata. Furthermore, this operation can be implemented by calling the attribute read command of the TPM / SE chip or parsing the authentication statement uploaded during device registration, thereby obtaining a quantitative identifier of the device's underlying security capabilities.

[0070] The corresponding device trust level can be found by looking up the preset authentication level-device trust level mapping table.

[0071] The authentication level-device trust level mapping table can be a pre-defined rule-based lookup table that converts hardware trust root authentication levels into numerical or hierarchical device trust levels. This table can be used to standardize the mapping from hardware security capabilities to business-understandable trust values. In one specific embodiment, the authentication level-device trust level mapping table can be configured by the system security policy center and permanently stored in a secure storage area, supporting dynamic updates. For example, the authentication level-device trust level mapping table can include, but is not limited to, one or more of the following: linear mapping tables (e.g., high → 0.9, medium → 0.6, basic → 0.3), non-linear decay mapping tables, and multi-dimensional conditional mapping tables (combining device model and authentication level). The corresponding device trust level can be found by using the authentication level as the key and retrieving the corresponding trust level value from the mapping table. Furthermore, this operation can be implemented through direct table lookup or interpolation (if the authentication level is a continuous value), thereby converting hardware security capabilities into trust factors usable for risk assessment.

[0072] If it is not a certified trusted device, then determine whether the device has a history of security violations.

[0073] Historical security violation records can be a collection of security event logs recorded by the system during the past operation of the relay protection tester, which can be used to assess the reliability of the dynamic behavior of uncertified devices. In this embodiment, historical security violation records can be continuously collected and stored in the protected database by the security audit module of the Power HarmonyOS system. For example, historical security violation records can include, but are not limited to, one or more of the following: data leakage event records, unauthorized access attempt records, and abnormal firmware update records. Determining whether a device has historical security violation records can be done by querying the violation event logs associated with the device ID in the security audit database. Furthermore, this operation can be achieved by indexing the log library by the device's unique identifier or by calling the Security Information and Event Management (SIEM) interface, thereby identifying the historical risk behaviors of uncertified devices.

[0074] If there is a history of security violations, the initial trust level will be lowered based on the number and severity of the violations.

[0075] The number of violations can be the frequency of similar or all events in historical security violation records, reflecting the stability of device security behavior and serving as one of the quantitative factors for trust downgrade. In an exemplary embodiment, the number of violations can be statistically derived from historical security violation records by time window or event type. Severity can be the potential harm level of a single security violation event to system security, reflecting the quality of violations rather than just the quantity, and affecting the extent of trust downgrade. In this embodiment, the severity level can be preset based on event type (e.g., data tampering > configuration privilege escalation > log anomalies). For example, severity can include, but is not limited to, one or more of the following: high risk (causing protection malfunction / refusal to activate), medium risk (sensitive data leakage), low risk (abnormal opening of debugging interface). The initial trust level can be the default trust starting point value for uncertified devices in the absence of historical violations, serving as a benchmark for downgrade calculation when violations exist. In a specific embodiment, the initial trust level can be preset by the system security policy, typically slightly higher than the base trust level to retain observation space. Reducing the initial trust level based on the number of violations and severity can be done by adjusting the initial trust level based on a preset decay function (e.g., linear deduction, exponential decay). Furthermore, this operation can be achieved by deducting 0.3 for each high-risk event and 0.15 for each medium-risk event, with the total amount not exceeding the threshold, or by using a credit scoring model to dynamically calculate the remaining trust value. This allows for dynamic negative adjustment of trust, reflecting behavioral accountability.

[0076] If there are no historical security violations, the device trust level will be set to the basic trust level.

[0077] The basic trust level can be a conservative trust value assigned to devices that have not passed the HarmonyOS certification and have no historical violation records. This can be used to prevent excessive trust in unknown devices, reflecting the principle of least privilege. In this embodiment, the basic trust level can be uniformly set by the security policy, typically a low value (e.g., 0.2–0.3). Setting the device trust level to the basic trust level can be achieved by directly assigning a preset basic trust level to uncertified devices with no violation records. Furthermore, this operation can be implemented by directly assigning a fixed value or by fine-tuning the basic value according to the device type, thereby providing a conservative default value and avoiding a trust vacuum.

[0078] For example, in a scenario where a third-party tester connects to the main station test platform, the relay protection tester security system based on the Power HarmonyOS system in this embodiment could be as follows: A new type of handheld relay protection tester is connected to a 220kV substation test platform for the first time. The system first determines that it is not in the Power HarmonyOS trusted device directory. Then, it queries historical security violation records and finds that the device has committed a medium-risk violation of unencrypted transmission of setpoint data once in the past 6 months. The system sets the initial trust level to 0.5. According to the strategy: 0.15 is deducted for each medium-risk event, so the final device trust level = 0.5 - 0.15 = 0.35. If the device has no violations, it is directly set to the basic trust level of 0.3. If it has passed Power HarmonyOS certification and the hardware trust root is at a high security level, a trust level of 0.9 is directly obtained through the mapping table without the need for behavior backtracking.

[0079] In one embodiment, the step of assessing and recording the sensitivity of the affected test data in power grid security testing as data sensitivity specifically includes: Determine whether the affected test data is classified test data; if it is classified test data, obtain the data classification level. The corresponding basic sensitivity coefficient is obtained by looking up the pre-set classification level-sensitivity coefficient comparison table; If the test data is not classified, then determine whether the data involves key power grid parameters, including relay protection settings, power grid topology, and equipment operating thresholds. If key parameters are involved, the weighted values ​​of the key parameters are added to the basic sensitivity coefficient; if no key parameters are involved, the basic sensitivity coefficient is used as the data sensitivity level.

[0080] The classified test data can be test data identified as containing sensitive or confidential information according to national or industry power data classification and grading standards. It can be used as the primary criterion for high sensitivity assessment, triggering the assignment of sensitivity coefficients based on the legally defined sensitivity level. In one exemplary embodiment, classified test data can be identified through data element tags, file attributes, or content keyword matching. Furthermore, classified test data can include, but is not limited to, one or more of the following: setting reports containing main grid topology, waveform data involving core substation configuration, and test logs containing dispatch communication keys. The data confidentiality level can be the confidentiality level of the classified test data defined by the power industry data security specifications, and can be used to determine the initial value of the basic sensitivity coefficient. In one specific embodiment, the data confidentiality level can be extracted from data metadata or a security management platform. For example, the data confidentiality level can include, but is not limited to, one or more of the following: sensitive level, high sensitivity level, and extremely high sensitivity level.

[0081] The classification level-sensitivity coefficient lookup table can be a pre-defined rule table that maps data classification levels to numerical basic sensitivity coefficients, and can be used to automatically convert compliance requirements into risk model parameters. In this embodiment, the classification level-sensitivity coefficient lookup table is configured and fixed by the security strategy center according to industry standards. Furthermore, the classification level-sensitivity coefficient lookup table can adopt a linear mapping table (Secret → 0.5, Confidential → 0.7, Top Secret → 0.9), a nonlinear enhancement table (exponential amplification for extremely high sensitivity levels), etc. The basic sensitivity coefficient can be an initial sensitivity benchmark value determined by the classification level or default rules, and can be used as the starting point for whether to superimpose the weighted values ​​of key parameters. In an exemplary embodiment, if the data is classified, it is obtained by looking up the table; if it is not classified, it is set to a default low value (e.g., 0.3). Power grid key parameters can be a set of core technical parameters that directly affect relay protection logic, system stability, or equipment safe operation, and can be used to identify non-classified but high-business-value data. For example, power grid key parameters can include, but are not limited to, one or more of relay protection settings, power grid topology, and equipment operating thresholds.

[0082] Relay protection settings can be the set values ​​for the action criteria of relay protection devices, such as current initiation values ​​and time delays. These directly determine whether the protection operates correctly and are considered key parameters. In one specific embodiment, relay protection settings can be extracted from the protection device configuration file or test task parameters. Power grid topology can be a network model describing electrical components such as substations, lines, and buses. It can influence fault location and protection coordination and is considered a key parameter. Further, the power grid topology can be obtained from SCADA or a power grid model database. Equipment operating thresholds can be boundary parameters for the safe operation of equipment, such as overcurrent limits and temperature rise limits. Exceeding these limits will lead to equipment damage or system instability and are considered key parameters. In one exemplary embodiment, equipment operating thresholds can be extracted from equipment nameplate parameters or operating procedures. Key parameter weighting values ​​can be additional sensitivity increments added due to the inclusion of key power grid parameters in the data. These can be used to increase the weight of key business data in risk assessment. In this embodiment, key parameter weighting values ​​are preset fixed values ​​by the security strategy or accumulated according to the number of key parameters. For example, the weighting value of key parameters can be a single key parameter weight of 0.2, multiple key parameters stacked up to a maximum of 0.4, or dynamic weighting (depending on the complexity of parameter combination).

[0083] Determining whether affected test data is classified can be done by checking if the data contains sensitive tags or matches a sensitive keyword database. Further, determining whether affected test data is classified can be achieved by parsing security markers in the data file header and calling a data classification and grading engine to perform content scanning, thereby distinguishing whether a legally applicable sensitivity level assessment path applies. Obtaining the data's classification level can be done by reading its confidentiality level from the metadata or security management interface of the classified test data. Further, obtaining the data's classification level can be achieved by reading XML / JSON metadata fields and querying grading information in the unified data asset catalog, thereby providing a compliance basis for assigning sensitivity coefficient values. The corresponding basic sensitivity coefficient can be found according to a preset classification level-sensitivity coefficient lookup table, which can be done by using the data's classification level as the key and retrieving the corresponding sensitivity coefficient value from the lookup table. In a specific embodiment, finding the corresponding basic sensitivity coefficient according to the preset classification level-sensitivity coefficient lookup table can be achieved through direct table lookup mapping and interpolation calculation (if the level is a continuous score), thereby transforming legal compliance requirements into calculable parameters for the risk model.

[0084] Determining whether data involves key power grid parameters can be achieved by analyzing whether the content or fields of the affected test data contain relay protection settings, power grid topology, or equipment operating thresholds. Furthermore, determining whether data involves key power grid parameters can be achieved by matching field names with key parameter keywords and semantically parsing data content to identify parameter types, thereby identifying high-value, non-confidential data. Adding a weighted value for key parameters to a basic sensitivity coefficient can be done by adding the basic sensitivity coefficient to a preset weighted value for key parameters. In an exemplary embodiment, adding a weighted value for key parameters to the basic sensitivity coefficient can be achieved through fixed weighting (+0.15 for each type of key parameter) or dynamic weighting (linearly increasing according to the number of parameter combinations), thereby increasing the risk weight of critical business data and reflecting its system-level impact. Using the basic sensitivity coefficient as the data sensitivity level can be done by directly using the basic sensitivity coefficient as the final sensitivity level for data that is neither confidential nor involves key parameters. Furthermore, using the basic sensitivity coefficient as the data sensitivity level can be achieved by directly assigning a default base value (e.g., 0.3) or fine-tuning the base value according to the data type, thereby providing a conservative default value and avoiding over-weighting.

[0085] Taking the regional protection setting verification test as an example, the safety system of the relay protection tester based on the power grid's HarmonyOS system in this embodiment can be as follows: In a 500kV line protection test, the affected test data is the distance II section impedance setting = 12.5Ω. The system first determines that the data is not marked as confidential, so it enters the key parameter judgment process. It is identified that it belongs to the relay protection setting, that is, the key parameter of the power grid. The system sets the basic sensitivity coefficient to 0.3 (the default value for non-confidential data), the weighting value of the key parameters is 0.25, and the final data sensitivity = 0.3 + 0.25 = 0.55. If the data contains both the topology of the local station and the opposite station, multiple key parameters may be superimposed, and the sensitivity may reach 0.7 or higher. If it is a station-wide setting table marked as confidential, the basic sensitivity coefficient of 0.7 is obtained by directly looking up the table. If it also contains the topology, it is further superimposed to 0.95.

[0086] In one embodiment, the step of combining data security interference level, device trust level, and data sensitivity to obtain the risk level of the affected test data and recording it as the basic risk level is as follows: Obtain the importance weight of the affected test data in the power grid testing process and record it as the data importance, where the importance of key test items is higher than that of regular test items; The attack threat level is determined based on the type of threat detected by the built-in security mechanism of the HarmonyOS power system; Set risk weight coefficients for data security interference level, device trust level, data sensitivity, data importance, and attack threat level; multiply each parameter by its corresponding weight coefficient and sum them to obtain the basic risk level of the affected test data.

[0087] The data importance can be a weighted value reflecting the structural importance of the affected test data in the power grid testing process, and can be used to reflect the difference in the impact of key test items and routine test items on system security. In an exemplary embodiment, the data importance can be obtained from a preset strategy library according to the test task type or test item classification. Further, the data importance can include, but is not limited to, one or more of the following: key test item importance (such as main protection action verification), routine test item importance (such as auxiliary signal calibration), and non-core monitoring item importance. Key test items can be core test content that directly affects the correct operation of relay protection or the power grid fault isolation capability, and can be used as the basis for determining high data importance. For example, key test items may include differential protection action logic verification, distance protection setting verification, circuit breaker tripping time testing, etc. Routine test items can be non-core test content used for auxiliary verification or performance evaluation, and can be assigned lower data importance. In a specific embodiment, routine test items may include analog quantity accuracy calibration, communication interface connectivity testing, human-machine interface response testing, etc.

[0088] Threat type can be the specific attack category of the current security event identified by the built-in security mechanism of the Power HarmonyOS system. It can be used to map the attack threat level and enhance the adversarial perception capability of risk assessment. In this embodiment, the threat type can be output by the intrusion detection, log auditing, or TEE anomaly monitoring module of the Power HarmonyOS system. Further, the threat type can include, but is not limited to, one or more of man-in-the-middle attacks, firmware rollback attacks, unauthorized access attempts, and replay attacks. Attack threat level can be the potential harm level of the current attack behavior to system security based on the threat type assessment. It can be used as a dynamic context factor for calculating the basic risk level. In an exemplary embodiment, the attack threat level can be generated by a mapping rule or scoring model from threat type to threat level. For example, the attack threat level can include high threat (potentially causing false triggering / denial of triggering), medium threat (potentially causing data leakage), and low threat (only detecting behavior). Risk weight coefficient can be a preset or adaptive parameter used to adjust the relative contribution of each risk factor in the basic risk level calculation. It can be used to achieve weighted fusion of multi-dimensional risk factors and support strategy optimization. In this embodiment, the risk weight coefficient can be configured by the security policy center and can be dynamically adjusted based on historical protection effect feedback. Furthermore, risk weight coefficients can include static weights (fixed configuration), scenario-adaptive weights (adjusted according to test type), and learning weights (optimized based on reinforcement learning).

[0089] Obtaining the importance weight of affected test data within the power grid testing process and recording it as data importance can be achieved by querying a preset importance weight based on the test item type (critical / routine) to which the affected test data belongs. Furthermore, this operation can be performed by extracting test item classifications from test task metadata and then assigning values ​​via table lookup, or by automatically deriving the criticality of test items based on protection logic diagrams. This allows the business process structure to be embedded in risk assessment, improving the engineering rationality of risk prioritization. Obtaining the attack threat level based on the threat types detected by the built-in security mechanisms of the Power HarmonyOS system can be achieved by parsing the threat alarm types output by the Power HarmonyOS security subsystem and mapping them to a quantified threat level. Further, this operation can be performed by directly converting using a predefined threat-level mapping table, or by calling a lightweight threat scoring model to output continuous values. This allows the introduction of a real-time adversarial context, enabling dynamic response capabilities in risk assessment.

[0090] Setting risk weight coefficients for data security interference level, device trust level, data sensitivity, data importance, and attack threat level can be achieved by assigning weight coefficients to each of the five risk factors, forming a weighted vector. Furthermore, this operation can be implemented by loading a static weight set from the policy configuration file or dynamically selecting a weight template based on the current test, thus supporting flexible adjustments to the risk focus in different scenarios. Multiplying each parameter by its corresponding weight coefficient and summing the results yields the basic risk level of the affected test data. This can be achieved by performing a linear weighted summation operation, i.e., multiplying each risk factor by its corresponding weight coefficient and then summing the results. Furthermore, this operation can be implemented using standard weighted summation or normalized weighted summation (ensuring the result is within the [0, 1] interval), thereby generating a unified and comparable local risk quantification value.

[0091] Taking a man-in-the-middle attack encountered during the differential protection test of a main transformer as an example, the security system of the relay protection tester based on the Power Harmony System in this embodiment can be as follows: In a test of a 500kV main transformer, the affected test data is the sampled value of the differential current on the high-voltage side, which is a critical test item with a data importance of 0.9. The Power Harmony System detects the man-in-the-middle attack threat type and maps the attack threat level to 0.85. The preceding steps have yielded: data security interference level = 0.7 (due to phase anomaly), device trust level = 0.6 (authenticated device but unencrypted transmission), and data sensitivity level = 0.8 (involving main protection and containing setpoints). The system is configured with risk weight coefficients as follows: interference level 0.3, trust level -0.2 (negative), sensitivity 0.25, importance 0.2, and threat level 0.25. The base risk level is calculated as follows: 0.7 × 0.3 + 0.6 × (-0.2) + 0.8 × 0.25 + 0.9 × 0.2 + 0.85 × 0.25 = 0.21 - 0.12 + 0.20 + 0.18 + 0.2125 = 0.6825, triggering a high-risk response strategy.

[0092] In one embodiment, key test items include relay protection action characteristic test data, and threat types include data tampering, man-in-the-middle attacks, and unauthorized access.

[0093] Among them, relay protection operating characteristic test data can be core test data reflecting the operating behavior of relay protection devices under simulated fault conditions. It can be used as a typical representative of key test items and is given high importance and sensitivity in risk assessment because it directly affects the correctness of protection. In an exemplary embodiment, relay protection operating characteristic test data may include, but is not limited to, one or more of the following: differential protection operating time data, distance protection impedance characteristic curve, and overcurrent protection return coefficient test results.

[0094] Data tampering can be an unauthorized modification of test data by an attacker during collection, transmission, or storage. It can be considered a threat type, triggering integrity verification failures and indicating a high level of attack threat. For example, data tampering can include, but is not limited to, one or more of the following: sample value forgery, parameter replacement, and waveform file injection. Man-in-the-middle attacks can be network layer attacks where an attacker intercepts and potentially tampers with communication data between the test instrument and the main station. It can be considered a threat type, compromising transmission confidentiality and integrity, and is identified by the Power HarmonyOS encrypted channel anomaly detection. Further, man-in-the-middle attacks can include, but are not limited to, one or more of the following: TLS session hijacking, GOOSE message replay, and unauthorized proxy forwarding. Unauthorized access can be the act of an unauthorized entity performing read, write, or control operations on test data or device interfaces. It can be considered a threat type, violating access controllability, and is detected by the Power HarmonyOS access control logs. In a specific embodiment, unauthorized access can include, but is not limited to, one or more of the following: illegal calls to debugging interfaces, non-maintenance accounts reading test caches, and third-party applications making unauthorized calls to security services.

[0095] For example, in a scenario where data tampering occurs during a longitudinal protection test of a line, the security system of the relay protection tester based on the Power Harmony System in this embodiment can be as follows: In a longitudinal differential protection test of a 220kV line, the affected test data is the action criterion of the current phase difference between the two sides, which belongs to the relay protection action characteristic test data and is identified by the system as a key test item. At the same time, the Power Harmony System detects that the hash value of this data does not match the standard characteristics and has no valid signature, and determines that the threat type is data tampering. Based on this, the system assigns a high data importance (0.9) and a high attack threat level (0.8), and calculates a basic risk level of 0.78 by combining other factors, triggering a high-priority protection strategy of immediately terminating the test, locking the equipment, and alarming the master station.

[0096] In one embodiment, the steps of extracting risk factors affecting the security of test data based on the security risk level, obtaining historical protection data for the risk factors, and generating a protection scheme based on the historical protection data are as follows: The dominant risk factors are selected from the risk factors based on the degree of safety risk; Historical protection cases matching the dominant risk factors are extracted from historical protection data, and the protection measures and their implementation effectiveness scores in the cases are obtained. The implementation effectiveness scores are weighted and ranked according to the level of security risk, and the combination of protection measures with the highest score is selected. By combining the built-in security mechanisms of the power HarmonyOS system and the hardware root of trust of the relay protection tester, a protection scheme adapted to the current test scenario is generated based on the combination of protection measures with the highest score.

[0097] The dominant risk factor can be a single or a few risk causes that contribute the most to the current security risk level and play a decisive role among multiple risk factors. It can be used as a key index for retrieving historical protection cases, focusing on core threats. In an exemplary embodiment, the dominant risk factor can be obtained based on the ranking or threshold filtering of the contribution of each risk factor to the basic risk level. Furthermore, the dominant risk factor can include, but is not limited to, one or more of the following: device identity forgery, unencrypted transmission, and tampering with key parameters. Historical protection cases can be complete protection event entries implemented and recorded by the system in the past for specific risk factors, including measures and effectiveness evaluations, which can be used to provide verified strategy references for current risks. For example, historical protection cases can be retrieved from structured historical protection data by tagging the dominant risk factor. In a specific embodiment, historical protection cases can include, but are not limited to, high-risk device impersonation handling cases, man-in-the-middle attack blocking cases, and sensitive data leakage emergency response cases.

[0098] Protective measures can be specific security operations or configuration instruction sets used in historical protection cases, and can be used to form reusable protective action units. In this embodiment, protective measures can be extracted from operation and maintenance logs or automated execution records. Furthermore, protective measures can include, but are not limited to, isolating test channels, resetting device binding relationships, enabling encryption processing within the TEE, and forcibly upgrading firmware versions. Implementation effectiveness scoring can be a quantitative evaluation of the comprehensive effectiveness of historical protective measures in practical applications, and can be used for strategy optimization and ranking. For example, implementation effectiveness scoring can be calculated based on a weighted average of multi-dimensional indicators (such as blocking success rate, performance impact, and operation and maintenance costs). In a specific embodiment, implementation effectiveness scoring can include, but is not limited to, high effectiveness and low overhead scoring, medium effectiveness and high reliability scoring, and emergency handling but high resource consumption scoring. Security risk level can be a classification result that divides continuous security risk values ​​into discrete levels (such as low, medium, high, and extremely high), and can be used to guide the weighting strategy for implementation effectiveness scoring. In this embodiment, security risk level can be mapped to risk value values ​​through a preset threshold range. Furthermore, the security risk level can include, but is not limited to, low risk (0.0–0.3), medium risk (0.3–0.6), high risk (0.6–0.85), and extremely high risk (0.85–1.0). The protective measure combination can be a collection of multiple collaborative protective measures included in a historical protection case, which can be used as a basic template for generating new protection schemes. For example, the protective measure combination can be extracted entirely from a historical protection case.

[0099] Selecting dominant risk factors from among risk factors based on security risk level can be achieved by analyzing the contribution weight of each risk factor to the security risk level and selecting the one with the highest contribution or exceeding a threshold. Furthermore, this operation can be implemented by sorting the factors by the size of their product terms in the basic risk level decomposition or by using interpretable AI methods such as SHAP to identify dominant features, thereby focusing on core threats and avoiding strategy generalization. Extracting historical protection cases matching the dominant risk factors from historical protection data can be achieved by retrieving relevant cases from the historical protection database using the dominant risk factor as the key. Furthermore, this operation can be implemented through precise tag matching or semantic similarity retrieval (supporting similar risk scenarios), thereby reusing effective strategies proven in practice.

[0100] Obtaining the protective measures and their effectiveness scores from case studies can be achieved by parsing the structured fields of matched historical protective cases. Furthermore, this operation can be implemented by directly reading JSON / YAML format case records or by calling a knowledge graph API to obtain the measure-effect relationships, thus acquiring executable actions and their historical performance. Weighting and sorting the effectiveness scores based on security risk levels can be done by adjusting the scoring weights according to the risk level (e.g., prioritizing effectiveness for high risk and considering efficiency for low risk). This operation can be further implemented by using a weighting of 1.5 for high risk and 0.8 for low risk, or by using a multi-objective optimization model for re-ranking, thus achieving dynamic risk-strategy adaptation. Selecting the combination of protective measures with the highest score can be done by selecting the top-ranked combination as a candidate after weighted ranking. This operation can be further implemented by a single best choice or Top-K candidates for manual confirmation, thus ensuring strategy optimality. By combining the built-in security mechanisms of the Power HarmonyOS system and the hardware root of trust of the relay protection tester, a protection scheme adapted to the current test scenario is generated based on the combination of protection measures with the highest score. This can be achieved by instantiating a combination of general measures into a specific instruction sequence that can call the Power HarmonyOS security service and the hardware root of trust interface. Furthermore, this operation can be implemented by calling the Power HarmonyOS security service API to generate an execution script or generate key binding or remote verification instructions that require the participation of the hardware root of trust, thereby ensuring that the scheme is executable, verifiable, and environmentally adaptable.

[0101] Taking the example of encountering high-risk equipment misuse during on-site testing, the relay protection tester security system based on the Power HarmonyOS system in this embodiment can be as follows: In a substation test, the security risk level reaches 0.82 (high risk level), and the dominant risk factor is equipment identity forgery. The system retrieves three matching cases from historical protection data, one of which has an original implementation effect score of 0.88 for the combination of isolation + rebinding + firmware verification. Due to the current high risk, the system weights the effectiveness dimension by 1.4, resulting in an adjusted score of 0.92, ranking first. Based on this, the solution generation module calls the device management interface of the Power HarmonyOS system to initiate test channel isolation, triggers the device identity rebinding process through the hardware trust root, and requires remote verification of firmware integrity. Finally, it generates a protection solution adapted to the current 500kV main transformer test scenario and pushes it to the operation and maintenance terminal.

[0102] In one embodiment, the dominant risk factors include device authentication failure, transmission encryption vulnerability, and abnormal access permissions. The built-in security mechanisms include secure boot, data encryption, and access control. The hardware root of trust includes device authentication and firmware integrity verification.

[0103] Among these factors, device authentication failure can occur when a relay protection tester fails to verify its identity through the hardware root of trust or the power system's authentication mechanism. This can be used as a primary risk factor to characterize threats of device identity forgery or impersonation. In an exemplary embodiment, device authentication failure may include, but is not limited to, one or more of the following: expired certificate, unregistered device ID, and failed remote authentication. Transmission encryption vulnerabilities can occur when test data is transmitted without or incorrectly encrypted, leading to the risk of data interception or tampering. This can be used as a primary risk factor to reflect a lack of data leakage prevention capabilities. Further, transmission encryption vulnerabilities may include, but are not limited to, one or more of the following: plaintext transmission, use of weak encryption algorithms, and failed key negotiation. Abnormal access permissions can occur when access to test data or system resources exceeds the authorized scope of the subject. This can be used as a primary risk factor to reflect threats of unauthorized access. For example, abnormal access permissions may include, but are not limited to, one or more of the following: unauthorized access to configuration files, unauthorized opening of debug interfaces, and unauthorized process access to sensitive memory.

[0104] Secure boot can be a boot process in the Power HarmonyOS system that verifies the integrity of firmware and critical components when the device is powered on. It can be used as a built-in security mechanism to prevent malicious firmware loading. In one specific embodiment, secure boot may include, but is not limited to, one or more of BootROM-level verification, kernel image signature verification, and driver module integrity measurement. Data encryption can be a security service provided by the Power HarmonyOS system to encrypt and decrypt static or dynamic test data. It can be used as a built-in security mechanism to ensure data confidentiality and integrity. In this embodiment, data encryption may include, but is not limited to, one or more of storage encryption (TDE), transport layer encryption (TLS / Chinese cryptographic protocol), and TEE in-memory encryption. Access control can be a mechanism in the Power HarmonyOS system that authorizes resource access requests based on subject identity and policies. It can be used as a built-in security mechanism to prevent unauthorized operations. Furthermore, access control may include, but is not limited to, one or more of role-based access control (RBAC), attribute-based access control (ABAC), and microkernel-level capability tokens.

[0105] Device authentication can be the device identity verification capability provided by the hardware root of trust based on a unique, unclonable identifier. It can be used as one of the core functions of the hardware root of trust to support device authenticity verification. For example, device authentication can include, but is not limited to, one or more of PUF-derived ID authentication, security chip binding certificates, and remote device verification. Firmware integrity verification can be the hardware root of trust's ability to verify firmware code hash values ​​during startup or runtime. It can be used as one of the core functions of the hardware root of trust to prevent firmware tampering. In a specific embodiment, firmware integrity verification can include, but is not limited to, one or more of boot chain step-by-step measurement, runtime firmware snapshot comparison, and integrity monitoring within the secure world.

[0106] Mapping dominant risk factors with built-in security mechanisms and hardware roots of trust to support the generation of protection schemes can be achieved by establishing a structured mapping relationship between dominant risk factors and corresponding security capabilities, which can then automatically invoke appropriate protection measures. Furthermore, this mapping can be implemented by constructing a risk-capability mapping table or by using knowledge graph reasoning to match the optimal combination of security capabilities. This allows for precise alignment of threat identification and protection capabilities, improving response targeting and execution efficiency.

[0107] The above are merely preferred embodiments of the present invention and do not limit the scope of the patent. Any equivalent structural or procedural transformations made based on the description and drawings of the present invention, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of the present invention.

Claims

1. A safety system for a relay protection tester based on the HarmonyOS power system, characterized in that, The system includes a data extraction module, a data verification module, a risk assessment module, a solution generation module, an information push module, and a secure storage module. The data extraction module is used to determine the power grid test scenario and record it as the test scenario to be tested. It extracts the basic power grid information data of the test scenario to be tested from the power HarmonyOS system and extracts the device identity authentication information from the hardware trust root of the relay protection tester. The data verification module is used to collect power grid test data of the test scenario under test, and combine the power grid basic information data and hardware root of trust verification results to determine whether the power grid test data is safe. The risk assessment module is used to extract security risk data from power grid basic information data and hardware trust root information if the test data is not secure, and to assess the security risk level of the test data based on the security risk data and record it as the security risk degree. The solution generation module is used to extract risk factors that affect the security of test data based on the security risk level, obtain historical protection data of the risk factors, and generate protection solutions based on the historical protection data. The information push module is used to send the security risk level and corresponding protection plan to the operation and maintenance terminal, reminding operation and maintenance personnel to protect the security of power grid test data; The secure storage module is used to encrypt and store the power grid test data if the test data is secure, and to continuously monitor and update the power grid test data.

2. The safety system for relay protection testing instruments based on the HarmonyOS power system as described in claim 1, characterized in that, The steps for collecting power grid test data from the test scenario under test, and combining this data with basic power grid information and hardware root of trust verification results to determine whether the power grid test data is secure, are as follows: Extract standard test data features of the test scenario to be tested from the basic information data of the power grid and record them as standard data features; calculate the hash similarity between the power grid test data and the standard data features to obtain the data integrity similarity; Set a data integrity standard threshold, determine whether the data integrity similarity reaches the data integrity standard threshold, and if it does, verify the device identity through the hardware root of trust of the relay protection tester to determine whether it is a trusted test device; If it is a trusted testing device, the access control log is extracted according to the built-in security mechanism of the Power HarmonyOS system to check for unauthorized access records; if no unauthorized access records are found, the encryption transmission protocol of the Power HarmonyOS system is checked during the test data transmission process. If an encrypted transmission protocol is used, the test data is deemed secure. If the data integrity similarity does not reach the data integrity standard threshold, or the device identity is untrustworthy, or there are unauthorized access records, or an encrypted transmission protocol is not used, then the test data is deemed insecure.

3. The safety system for relay protection testing instruments based on the HarmonyOS power system as described in claim 2, characterized in that, If the test data is insecure, the step of extracting security risk data from the power grid basic information data and hardware trust root information, assessing the security risk level of the test data based on the security risk data, and recording it as the security risk degree is as follows: Based on the safety risk data, the affected test data in the power grid test environment are extracted, and the standard safety status of the affected test data is obtained. The real-time safety status is extracted from the power grid test data. The degree of environmental interference on the affected test data is obtained based on the standard safety status and the real-time safety status and recorded as the data safety interference degree. The device trust level of the relay protection tester is extracted based on the hardware trust root information. Assess the sensitivity of the affected test data to power grid security testing and record it as data sensitivity. The risk level of the affected test data is determined by combining the data security interference level, the device trust level, and the data sensitivity, and recorded as the basic risk level. The basic risk level of all affected test data is superimposed to obtain the safety risk level of the power grid test data.

4. The safety system for relay protection testing instruments based on the HarmonyOS power system as described in claim 3, characterized in that, The step of obtaining the degree of environmental interference on the affected test data based on the standard security state and the real-time security state and recording it as the data security interference degree is as follows: Calculate the deviation values ​​of different security parameters in the standard security state and the real-time security state and record them as security deviation values, wherein the security parameters include data integrity, transmission confidentiality and access controllability; The sensitivity coefficients of the data to different security parameters are obtained based on the type of test data affected. The parameter interference degree is obtained by multiplying the safety deviation value by the corresponding sensitivity coefficient; the data safety interference degree of the affected test data is obtained by summing the parameter interference degrees of all safety parameters.

5. The safety system for relay protection testing instruments based on the HarmonyOS power system as described in claim 4, characterized in that, The step of extracting the device trust level of the relay protection tester based on the hardware trust root information is as follows: Determine whether the relay protection tester is a trusted device certified by the Power HarmonyOS system. If it is a certified trusted device, obtain the certification level of the hardware root of trust. The corresponding device trust level is obtained by looking up the preset authentication level-device trust level mapping table; If it is not a certified trusted device, then determine whether the device has a history of security violations; If there is a history of security violations, the initial trust level will be lowered based on the number and severity of the violations. If there are no historical security violations, the device trust level will be set to the basic trust level.

6. The safety system for relay protection testing instruments based on the HarmonyOS power system as described in claim 5, characterized in that, The step of assessing the sensitivity of the affected test data in power grid security testing and recording it as data sensitivity is as follows: Determine whether the affected test data is classified test data; if it is classified test data, obtain the data classification level. The corresponding basic sensitivity coefficient is obtained by looking up the pre-set classification level-sensitivity coefficient comparison table; If the test data is not classified, then determine whether the data involves key power grid parameters, including relay protection settings, power grid topology, and equipment operating thresholds. If key parameters are involved, the weighted values ​​of the key parameters are added to the basic sensitivity coefficient; if no key parameters are involved, the basic sensitivity coefficient is used as the data sensitivity level.

7. The safety system for relay protection testing instruments based on the HarmonyOS power system as described in claim 6, characterized in that, The step of combining data security interference level, device trust level, and data sensitivity to obtain the risk level of the affected test data and recording it as the basic risk level is as follows: Obtain the importance weight of the affected test data in the power grid testing process and record it as the data importance, where the importance of key test items is higher than that of regular test items; The attack threat level is determined based on the type of threat detected by the built-in security mechanism of the HarmonyOS power system; Set risk weight coefficients for data security interference level, device trust level, data sensitivity, data importance, and attack threat level; multiply each parameter by its corresponding weight coefficient and sum them to obtain the basic risk level of the affected test data.

8. The safety system for relay protection testing instruments based on the HarmonyOS power system as described in claim 7, characterized in that, The key test items include relay protection action characteristic test data, and the threat types include data tampering, man-in-the-middle attacks, and unauthorized access.

9. The safety system of the relay protection tester based on the HarmonyOS power system as described in claim 7, characterized in that, The steps of extracting risk factors affecting the security of test data based on the security risk level, obtaining historical protection data for the risk factors, and generating protection schemes based on the historical protection data are as follows: The dominant risk factors are selected from the risk factors based on the degree of safety risk; Extract historical protection cases that match the dominant risk factors from historical protection data, and obtain the protection measures and implementation effectiveness scores in the cases; The effectiveness scores of the implementation measures are weighted and ranked according to the level of safety risk, and the combination of protective measures with the highest score is selected. By combining the built-in security mechanisms of the power HarmonyOS system and the hardware root of trust of the relay protection tester, a protection scheme adapted to the current test scenario is generated based on the combination of the highest-scoring protection measures.

10. The safety system of the relay protection tester based on the HarmonyOS power system as described in claim 9, characterized in that, The primary risk factors include device authentication failure, transmission encryption vulnerabilities, and abnormal access permissions. The built-in security mechanisms include secure boot, data encryption, and access control. The hardware root of trust includes device authentication and firmware integrity verification.

Images