A method and system for licensing power system anti-misoperation software

Abstract

This application provides a method and system for authorizing power system anti-misoperation software. The method, applied to the authorization center, includes: receiving a function list, project configuration, debugging requirements, and system environment information of the target power system anti-misoperation system; generating an authorization list based on the function list, project configuration, and debugging requirements; encoding the system environment information, power engineering project information, and authorization list to generate original authorization data; performing encoding conversion on the original authorization data to form encoded data; and performing a digest operation on the machine code and the original authorization data to generate a checksum; the authorization center generates a segmented authorization code based on the checksum, machine code, and encoded data, and then encrypts it to generate the final authorization code. This method achieves automated authorization generation and security verification in an offline environment, meeting the multi-stage, multi-module refined authorization management needs of the power industry's closed network without requiring a network connection.

Description

Technical Field

[0001] This application relates to the field of product function licensing technology, and more specifically, to a method and system for licensing power anti-misoperation software. Background Technology

[0002] As the digital and intelligent transformation of the power industry deepens, the software functions of various power equipment management systems, monitoring systems, and field intelligent devices continue to expand. System deployment requires multiple stages, from on-site installation, commissioning and verification, to function activation and final operation. The requirements for software function permissions and authorization control differ at each stage. However, power systems typically operate in highly secure and isolated closed network environments. According to national power safety level protection requirements, field devices are strictly prohibited from directly accessing the internet or external authorized servers, making it difficult to implement traditional authorization models that rely on cloud verification, online activation, or periodic online verification.

[0003] To adapt to offline scenarios, existing technologies primarily employ manual methods such as combining activation codes and function debugging codes, or copying authorization files to USB drives to complete authorization. These methods are not only cumbersome and inefficient, impacting on-site commissioning progress, but also pose security risks of copying, leakage, or tampering due to the lack of automated verification mechanisms during the authorization file transfer process. They fail to meet the power industry's stringent requirements for traceability, uniqueness, and security in authorization management. Summary of the Invention

[0004] The purpose of this application is to provide a power grid anti-misoperation software licensing method and system to solve the above-mentioned problems.

[0005] In a first aspect, embodiments of this application provide a method for authorizing power system anti-misoperation software, applied to an offline-deployed power system anti-misoperation software authorization system. The authorization system includes an authorization center. The method includes: the authorization center receiving a function list, project configuration, debugging requirements, and system environment information of the target power system anti-misoperation system; wherein the system environment information includes machine code; the authorization center generating an authorization list based on the function list, project configuration, and debugging requirements; wherein the authorization list includes product version, functional modules, and authorization period; the authorization center encoding the system environment information, power engineering project information, and the authorization list to generate original authorization data; the authorization center performing encoding conversion on the original authorization data to form encoded data, and performing digest operation on the machine code and the original authorization data to generate a check code; the authorization center generating a segmented authorization code based on the check code, the machine code, and the encoded data, and then generating a final authorization code after encryption; wherein the segmented authorization code is used to provide a unified authorization model; the segmented authorization code includes a check code segment, a machine code segment, and an authorization information segment.

[0006] In the implementation of the above scheme, the authorization center receives the function list, project configuration, debugging requirements, and system environment information including machine code. It then sequentially generates an authorization list, performs digest and encryption operations, and encodes the code, ultimately forming a segmented authorization code containing a checksum segment, a machine code segment, and an authorization information segment. This segmented authorization code provides a unified authorization model through a standardized structure, compatible with the authorization management needs of different product versions and functional modules. It achieves automated authorization generation and security verification in offline environments, meeting the multi-stage, multi-module refined authorization management needs of the power industry's closed network without requiring a network connection. Furthermore, by embedding the machine code into the authorization code structure and binding it to the system environment information for verification, combined with the checksum verification mechanism generated by digest and encryption operations, it effectively prevents the authorization code from being copied, tampered with, or used across systems, thus improving the security and uniqueness of the authorization process.

[0007] In one implementation of the first aspect, the verification code segment includes a verification bit, an authorization code type field, and an authorization code version field; wherein, the authorization code type field is used to identify function authorization, debugging authorization, personal authorization, APP authorization, or restoration authorization; The machine code segment includes a server type field, a motherboard identifier field, and a hard disk serial number identifier field; The authorization information code segment includes the authorization creation time field, authorization start and end time field, product list length field, product code list field, product authorization file version field, product authorization module length field, and product authorization module field.

[0008] In the implementation of the above scheme, a binary field structure is used to construct the verification code segment, machine code segment, and authorization information code segment. The authorization code type field supports multiple types of identifiers, including function authorization, debugging authorization, personal authorization, APP authorization, and restoration authorization. The server type, motherboard identifier, and hard disk serial number identifier fields enable fine-grained device binding, forming a unified authorization model across products and versions, which improves the coding efficiency of authorization codes and system adaptability. On the other hand, through the structured definition of authorization creation time, authorization start and end time, product list length, product code list, and product functional module bit segments, precise control and dynamic adjustment of authorization period, product scope, and functional modules are achieved. This effectively supports the smooth transition from debugging to operation in the software lifecycle and incremental authorization scenarios, enhancing the flexibility and security of authorization management.

[0009] In one implementation of the first aspect, generating the authorization list based on the function list, the project configuration, and the debugging requirements includes: parsing the function list and the project configuration to obtain the association relationships between software versions, product codes, functional modules, menu codes, and API paths; determining the debugging mode of the authorization list based on the debugging requirements; arranging and encrypting the software version, the product code, the functional module, the menu code, the API path, and the debugging mode to generate the authorization list; writing the authorization list into the target power anti-misoperation system, and synchronizing the functional module information to the collaborative office system.

[0010] In the implementation of the above solution, the association between software version, product code, functional module, menu code, and API path is obtained by parsing the function list and project configuration. Based on debugging requirements, the debugging mode is determined. The above information is then arranged and encrypted to generate an authorization list, realizing the automated construction of the authorization list. This avoids information omissions and operational errors under the traditional manual configuration method, and improves the efficiency and accuracy of authorization. On the other hand, by writing the generated authorization list into the target power anti-misoperation system and synchronizing the functional module information to the collaborative office system, a two-way data channel is established between the authorization center and the collaborative office system. This ensures the real-time consistency and traceability of power engineering project information and authorization status across heterogeneous systems, and provides a unified management view for the parallel implementation of multiple projects in the power industry.

[0011] In one implementation of the first aspect, the method further includes: after activating the target power misoperation prevention system using the authorization code, the authorization center stores the authorization code, the system environment information, and the power engineering project information in the work order management system, and updates the work order status corresponding to the current engineering project to the completed status, so as to establish a one-to-one correspondence between the authorization code, the target power misoperation prevention system, and the engineering project; when an authorization request for the target power misoperation prevention system is initiated again, the authorization center verifies the system environment information based on the correspondence stored in the work order management system, and if the system environment information is already associated with other engineering projects, the authorization request is rejected.

[0012] In the implementation of the above scheme, after the target power misoperation prevention system is activated, the authorization code, system environment information, and power engineering project information are associated and stored in the work order management system, and the work order status is updated to the completed status. This establishes a one-to-one correspondence between the authorization code, the target power misoperation prevention system, and the engineering project, realizing full traceability and anti-reuse mechanism for authorization behavior. It ensures that the authorization code is strongly bound to a specific engineering project and the target power misoperation prevention system, effectively preventing the authorization code from being reused in unauthorized systems or projects. On the other hand, when an authorization request is initiated again, the system environment information is verified based on the correspondence stored in the work order management system. If the system environment information is detected to be associated with other engineering projects, the authorization request is rejected, forming a cross-system and cross-project authorization diffusion protection mechanism, which improves the security and controllability of offline authorization management.

[0013] In one implementation of the first aspect, the authorization system further includes a field deployment terminal, and the method further includes: After receiving the authorization code, the on-site deployment terminal performs the following multi-level verifications: Authenticity verification to confirm the integrity of the authorization code; system binding verification to compare the machine code with the current system environment information; power engineering information verification based on the binding relationship between the system environment information and the power engineering project information stored in the work order management system; if the system environment information is already associated with other engineering projects, the authorization code is rejected; authorization scope verification to confirm the validity of the product version, the functional module, and the authorization period; if all the above verifications pass, the corresponding debugging function or business module is dynamically enabled according to the authorization code type field; otherwise, the authorization code is rejected.

[0014] In implementing the above solution, a multi-level progressive verification process is performed on the authorization code through the field deployment terminal. This process includes verification of authenticity, system binding, power engineering information, and authorization scope. Without requiring a network connection, automated verification of authorization code integrity, device binding relationships, project relevance, and authorization compliance can be completed sequentially in an offline environment, improving the security and reliability of software authorization verification in the closed network of the power industry. Furthermore, by dynamically enabling the corresponding debugging function or business module based on the authorization code type field after all verifications pass, and rejecting the authorization code if verification fails, automated linkage and isolation control of authorization verification and function activation are achieved. This effectively prevents the risks of unauthorized use, cross-device copying, and authorization diffusion between projects, meeting the core needs of the power industry for strict control and on-demand activation of software authorization.

[0015] In one implementation of the first aspect, the dynamic activation of the corresponding debugging function or business module includes: the field deployment terminal determines the authorization strategy based on the authorization code type field; when the authorization code type is a function authorization, the product function module corresponding to the authorization information code segment is activated; when the authorization code type is a debugging authorization, the debugging function is activated based on the function authorization activation, and the effective time window of the debugging function is controlled according to the authorization creation time field and the authorization start and end time field; the field deployment terminal encrypts and stores the activated function module, and when a function call request is received, verifies the validity of the authorization code in real time and intercepts unauthorized function interfaces.

[0016] In the implementation of the above solution, the on-site deployment terminal distinguishes between the activation strategies of function authorization and debugging authorization based on the authorization code type field. In the debugging authorization scenario, the effective time window of the debugging function is controlled based on the authorization creation time field and the authorization start and end time field. This achieves differentiated management and fine-grained time control of permissions in the debugging and runtime phases throughout the software lifecycle. On the other hand, by encrypting and storing the enabled function modules and verifying the validity of the authorization code in real time when a function call request is received to block unauthorized function interfaces, a dynamic isolation and anti-unauthorization mechanism for runtime function use is constructed.

[0017] In one implementation of the first aspect, the encrypted storage of the enabled functional modules includes: encrypting the authorization file using an encryption algorithm and adding a digital signature, and periodically updating the authorization file and refreshing the effective time window for each authorization type; in cluster deployment mode, broadcasting authorization status changes through the Redis message mechanism and using a distributed lock to protect authorization file updates.

[0018] In the implementation of the above scheme, by encrypting the authorization file with an encryption algorithm and adding a digital signature, and by periodically updating the authorization file and refreshing the effective time window of each authorization type, the confidentiality protection and integrity verification of the authorization data are achieved, effectively preventing the risk of tampering, leakage and cracking of the authorization file in the offline storage environment. On the other hand, by broadcasting authorization status changes through the Redis message mechanism in the cluster deployment mode and using distributed locks to protect the authorization file updates, the consistency of authorization status and mutual exclusion of update operations among the nodes in the cluster are ensured, avoiding data inconsistency problems caused by concurrent conflicts.

[0019] In one implementation of the first aspect, the method further includes: receiving a new authorization code; wherein the new authorization code is generated based on the changed functional requirements; parsing the new authorization code to obtain the latest authorization information, the latest authorization information including a product functional module list, authorization code type, and authorization period; replacing the locally stored old authorization status with the latest authorization information, activating the corresponding module according to the product functional module list, and revoking modules not in the product functional module list; when the authorization code type in the latest authorization information is a functional authorization, the field deployment terminal enters the initial debugging state according to a preset configuration strategy; wherein the initial debugging state grants initial debugging permissions within a preset initial debugging time window; after the initial debugging time window expires, the field deployment terminal closes the initial debugging permissions.

[0020] In the implementation of the above scheme, the dynamic updating of the authorization status and the precise reconfiguration of functional modules are realized through incremental authorization codes. This enables the power anti-misoperation software to continuously run without redeployment, and to complete the online adjustment of the authorization scope and the automatic revocation of old permissions according to the changes in the needs of engineering projects, forming a closed-loop authorization lifecycle management. On the other hand, the initial debugging mechanism automatically opens the debugging permission for a preset time window after the function authorization is activated, and automatically closes it after the time window expires. This separates the initial function verification from the in-depth operation and maintenance debugging, which not only meets the necessary verification requirements before the new module is put into operation, but also builds a permission isolation barrier from deployment verification to long-term operation and maintenance through mandatory time constraints and subsequent independent debugging authorization codes.

[0021] In one implementation of the first aspect, the authorization system further includes a user terminal, and the method further includes: the user terminal receiving a work order; wherein the work order is used to uniquely identify the engineering project to be implemented and contains the power engineering project information; the user terminal calls the work order management system to scan the QR code generated by the target power anti-misoperation system to obtain the system environment information and the power engineering project information; wherein the QR code is generated by the target power anti-misoperation system after calling a local interface to collect machine information and product version information; the user terminal sends the system environment information and the power engineering project information to the authorization center; and the user terminal receives the authorization code returned by the authorization center.

[0022] In the implementation of the above solution, the user terminal receives a work order that uniquely identifies the engineering project and contains information about the power engineering project. The work order management system scans a QR code generated by the target power anti-misoperation system, which contains machine information and product version information. This establishes a strong association between the commissioning personnel's identity, the engineering project, and the target power anti-misoperation system environment, enabling secure collection of authorization information and task binding in an offline environment. On the other hand, the user terminal sends system environment information and power engineering project information to the authorization center and receives the returned authorization code, forming a closed-loop process of QR code scanning, information transmission, and authorization code distribution. This effectively avoids the risks of leakage and tampering caused by traditional USB flash drive copying and manual transmission methods, and improves the traceability and security of the authorization process in the closed network of the power industry.

[0023] Secondly, embodiments of this application provide a power grid anti-misoperation software licensing system, comprising: The authorization center receives a function list, project configuration, debugging requirements, and system environment information of the target power anti-misoperation system. The system environment information includes machine code. An authorization list is generated based on the function list, project configuration, and debugging requirements. This authorization list includes product version, functional modules, and authorization period. The system environment information, power engineering project information, and the authorization list are encoded to generate original authorization data. The original authorization data undergoes encoding conversion to form encoded data. A digest operation is performed on the machine code and the original authorization data to generate a checksum. Based on the checksum, the machine code, and the encoded data, a segmented authorization code is generated, which is then encrypted to generate the final authorization code. The segmented authorization code provides a unified authorization model and includes a checksum segment, a machine code segment, and an authorization information segment. The on-site deployment terminal, upon receiving the authorization code, performs the following multi-level verifications: Authenticity verification to confirm the integrity of the authorization code; system binding verification to compare the machine code with the current system environment information; power engineering information verification, based on the binding relationship between the system environment information and the power engineering project information stored in the work order management system; if the system environment information is already associated with other engineering projects, the authorization code is rejected; authorization scope verification to confirm the validity of the product version, the functional module, and the authorization period; if all the above verifications pass, the corresponding debugging function or business module is dynamically enabled according to the authorization code type field; otherwise, the authorization code is rejected. The user terminal is used to receive work orders; wherein the work order uniquely identifies the engineering project to be implemented and contains the power engineering project information; it calls the work order management system to scan the QR code generated by the target power anti-misoperation system to obtain the system environment information and the power engineering project information; wherein the QR code is generated by the target power anti-misoperation system after calling a local interface to collect machine information and product version information; it sends the system environment information and the power engineering project information to the authorization center terminal; and it receives the authorization code returned by the authorization center terminal.

[0024] Other features and advantages of this application will be set forth in the following description and will be apparent in part from the description or may be learned by practicing embodiments of this application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the written description, claims and drawings. Attached Figure Description

[0025] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0026] Figure 1 A flowchart illustrating the power grid anti-misoperation software licensing system provided in this application embodiment; Figure 2 A schematic diagram of the interaction process of each terminal in the power anti-misoperation software licensing system provided in the embodiments of this application; Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0027] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0028] Power industry application software deployments must adapt to core business scenarios such as power grid dispatch automation, substation monitoring, and distribution network management. Authorization management must span the entire lifecycle, from on-site installation and commissioning to trial operation and formal commissioning. Due to security regulations for power monitoring systems requiring physical isolation between the production control area and the information management area, the target power anti-misoperation system deployed on-site is typically in a closed network environment without internet access, preventing the authorization center from directly communicating with it online. Furthermore, the same software product requires different combinations of functional modules in different plants or projects, and the functional permission requirements differ between the commissioning and operation phases. Therefore, the authorization mechanism must possess functional module-level control capabilities in offline environments, multi-stage authorization switching capabilities, and cross-project authorization isolation capabilities.

[0029] Currently, offline authorization primarily relies on two technical solutions: The first is a combination of activation codes and function debugging codes. Manufacturers pre-generate activation codes containing basic function permissions, and on-site personnel obtain the debugging codes via phone or email, then manually enter both sets of codes into the target power system to enable functionality. The second method involves offline import of authorization files. Manufacturers copy the authorization files via USB drive or email, and on-site personnel import the files into the target power system, where the local authorization service parses and activates the functionality. In both solutions, authorization files are typically stored in plaintext JSON or simple Base64 encoding, and authorization codes are mostly fixed-length strings. These solutions lack the ability to bind to the hardware information of the target power system or power engineering project information, and there is a lack of automated information synchronization between the authorization center and the target power system, requiring manual verification of project order numbers and equipment serial numbers.

[0030] The existing offline authorization technology has the following defects: (1) The authorization file transfer process relies on manual transmission and import. Debugging personnel need to complete the authorization through multiple steps such as telephone confirmation, email sending and receiving, USB flash drive copying, and manual entry. The operation is cumbersome and time-consuming, which seriously affects the project progress in the emergency debugging scenario of power engineering site; (2) The authorization file is stored in plaintext or weak encryption format and is not cryptographically bound to the system hardware identifier (such as motherboard UUID, hard disk serial number) or power engineering project information. The authorization code is easy to be copied, forged or reused, which cannot meet the power industry's security requirements for authorization uniqueness and anti-proliferation; (3) Once the authorization file is generated, the functional scope is fixed and cannot be changed according to project needs to achieve incremental authorization. It also cannot automatically reclaim debugging permissions and smoothly transition to running authorization after debugging is completed, which leads to the risk of over-authorization of functions or untimely revocation of permissions.

[0031] In view of this, this application provides a power anti-misoperation software authorization method. This method receives a function list, project configuration, debugging requirements, and system environment information including machine code from an authorization center. It then sequentially generates an authorization list, performs execution digest and encryption operations, and encodes the result, ultimately forming a segmented authorization code containing a checksum segment, a machine code segment, and an authorization information segment. This segmented authorization code provides a unified authorization model through a standardized structure, compatible with the authorization management needs of different product versions and functional modules. It achieves automated authorization generation and security verification in an offline environment, meeting the multi-stage, multi-module refined authorization management needs of the power industry's closed network without requiring a network connection. Furthermore, by embedding the machine code into the authorization code structure and binding it to the system environment information for verification, combined with the checksum verification mechanism generated by digest and encryption operations, it effectively prevents the authorization code from being copied, tampered with, or used across systems, improving the security and uniqueness of the authorization process.

[0032] Before introducing the above-mentioned power grid anti-misoperation software licensing method, let's first introduce the power grid anti-misoperation software licensing system involved in this method: Please see Figure 1 This application provides a power grid anti-misoperation software licensing system, including: The authorization center (terminal 100) receives the function list, project configuration, debugging requirements, and system environment information of the target power anti-misoperation system. The system environment information includes machine code. An authorization list is generated based on the function list, project configuration, and debugging requirements. This authorization list includes the product version, functional modules, and authorization period. The system environment information, power engineering project information, and authorization list are encoded to generate original authorization data. The original authorization data undergoes encoding conversion to form encoded data, and a digest operation is performed on the machine code and original authorization data to generate a checksum. Based on the checksum, machine code, and encoded data, a segmented authorization code is generated, which is then encrypted to generate the final authorization code. The segmented authorization code provides a unified authorization model and includes a checksum segment, a machine code segment, and an authorization information segment. The on-site deployment terminal 200 performs the following multi-level verifications upon receiving the authorization code: Authenticity verification to confirm the integrity of the authorization code; system binding verification to compare the machine code with the current system environment information; power engineering information verification based on the binding relationship between the system environment information and power engineering project information stored in the work order management system; if the system environment information is already associated with other engineering projects, the authorization code is rejected; authorization scope verification to confirm the validity of the product version, functional modules, and authorization period; if all the above verifications pass, the corresponding debugging function or business module is dynamically enabled according to the authorization code type field; otherwise, the authorization code is rejected. User terminal 300 is used to receive work orders; the work order uniquely identifies the engineering project to be implemented and contains power engineering project information; it calls the work order management system to scan the QR code generated by the target power anti-misoperation system to obtain system environment information and power engineering project information; the QR code is generated by the target power anti-misoperation system after calling the local interface to collect machine information and product version information; it sends the system environment information and power engineering project information to the authorization center terminal 100; and receives the authorization code returned by the authorization center terminal 100.

[0033] The aforementioned authorization center terminal 100, as the core processing unit for authorization management, is responsible for receiving the function list, project configuration parameters, debugging requirement description, and system environment information collected from the target power anti-misoperation system provided by system maintenance personnel (wherein the system environment information includes at least a machine code used to uniquely identify the target hardware device). Based on this, the authorization center terminal 100 generates an authorization list containing product version, functional modules, and authorization period according to the association mapping relationship between the function list and the project configuration, combined with the authorization mode defined by the debugging requirements. Then, the authorization center terminal 100 uses a cryptographic encoding algorithm to structure and encode the system environment information, power engineering project information, and the aforementioned authorization list to generate original authorization data. It then performs a digest operation on the original authorization data to generate a check code, and performs encoding conversion processing on the original authorization data to form encoded data. Finally, based on the check code, machine code, and encoded data, a segmented authorization code is generated using binary bit segment encoding. This segmented authorization code provides a unified authorization model through a standardized structure to be compatible with the authorization management requirements of different product versions and functional modules. It consists of three parts: a check code segment, a machine code segment, and an authorization information segment, which respectively undertake the core functions of integrity verification, device binding, and permission description.

[0034] The aforementioned field deployment terminal 200 is deployed in the operating environment of the power industry application software. After receiving the authorization code, it performs a multi-level offline verification process. If all verifications pass, the field deployment terminal 200 dynamically enables the corresponding debugging function or business module according to the authorization code type field; otherwise, it rejects the authorization code.

[0035] The aforementioned user terminal 300 serves as the operating terminal for commissioning personnel, used to receive work orders dispatched by the OA system. These work orders uniquely identify the engineering project to be implemented and contain power engineering project information. User terminal 300 calls the work order management system to scan the QR code generated by the target power anti-misoperation system to obtain system environment information and power engineering project information. The QR code is generated by the target power anti-misoperation system after collecting machine information and product version information through a local interface. Subsequently, user terminal 300 sends the system environment information and power engineering project information to the authorization center terminal 100 and receives the authorization code returned by the authorization center terminal 100, thereby completing the triple binding of the engineering project, the target power anti-misoperation system, and the commissioning personnel's identity, ensuring full traceability of the authorization process.

[0036] Understandably, although Figure 1 (and what will be introduced later) Figure 2 The diagram illustrates the logical connection between the user terminal 300 and the field deployment terminal 200 from a system architecture perspective. This demonstrates the complete transmission path of the authorization code from the authorization center 100 through the user terminal 300 to the field deployment terminal 200. However, in real-world applications, the production control area where the field deployment terminal 200 is located may implement strict physical isolation policies, resulting in an offline environment with no internet access and complete disconnection from the management information area. In this scenario, after receiving the authorization code from the authorization center 100, the user terminal 300 cannot directly push the authorization code to the field deployment terminal 200 via network protocols. Instead, the debugging personnel holding the user terminal 300 retrieve the authorization code through a secure and reliable communication channel (such as a WeChat project order or encrypted message), and then manually input the authorization code string into the authorization code input interface provided by the field deployment terminal 200. Upon capturing this manually entered authorization code, the field deployment terminal 200 immediately triggers a multi-level verification process to complete authorization verification and functional module activation. This design ensures that the authorization process can be executed in a completely offline environment, while also strongly binding the commissioning personnel's identity, power engineering project information, and authorization operations through a manual data entry process, thereby further enhancing the traceability of authorization behavior and the ability to audit operations.

[0037] Please see Figure 2 The licensing methods for power anti-misoperation software applied to the user terminal 300 include: Step S310: Receive work order; wherein, the work order is used to uniquely identify the engineering project to be implemented and contains power engineering project information.

[0038] The aforementioned work order is an electronic task scheduling credential generated by the OA (Office Automation System). It uniquely identifies a specific substation or line project to be implemented during the power engineering project implementation process. Its data includes at least the project number, project name, list of authorized modules, authorization period, authorization mode (commissioning mode or operation mode), and information on the person responsible for commissioning. This work order serves as the starting point for the authorization process, strongly linking the commissioning personnel's identity, power engineering project information, and subsequent authorization actions, ensuring the traceability of the authorization request's origin and the uniqueness of the task.

[0039] User terminal 300 can receive the work order from the work order management system of the OA system through an HTTPS secure channel. The OA system automatically pushes the work order to the corresponding commissioning personnel's user terminal 300 according to the preset project allocation rules (such as project area, equipment type, and responsible person's permission level). User terminal 300 caches the work order locally and parses the power engineering project information in it, providing task context for subsequent scanning of the target power anti-misoperation system QR code and initiating authorization requests to the authorization center.

[0040] The aforementioned engineering projects to be implemented refer to software deployment and debugging task units that need to be implemented on-site at specific substations, lines, or equipment during the construction, upgrading, or operation and maintenance of power system infrastructure. These task units have clearly defined project scope, implementation period, and responsible parties. Examples include on-site installation and debugging of substation monitoring systems, software upgrades of distribution automation terminals, or the activation and configuration of dispatch master station functional modules. The project information for the engineering projects to be implemented is a structured metadata set describing the project, including a project number for unique identification, project name, a list of authorized modules (such as SCADA modules and protection information substation modules), authorization period (including the start and end times of the debugging and operation periods), authorization mode (debugging mode or formal operation mode), and information on the person responsible for debugging. Power engineering project information can be generated by the OA system when dispatching work orders and sent to the user terminal 300 along with the work order. This information is used to bind and verify with the system environment information and equipment hardware information of the target power anti-misoperation system, ensuring that the generation and distribution of authorization codes are strictly limited to the implementation boundaries of the specific engineering project.

[0041] Step S320: Call the work order management system to scan the QR code generated by the target power anti-misoperation system to obtain system environment information and power engineering project information; wherein, the QR code is generated by the target power anti-misoperation system after calling the local interface to collect machine information and product version information.

[0042] The aforementioned work order management system is a mobile application or web front-end interface deployed on the user terminal 300. It serves as the task interaction medium connecting the commissioning personnel and the authorization center terminal 100. Its core functions include receiving and parsing electronic work orders assigned by the OA system, calling the camera component of the user terminal 300 to scan QR codes, extracting system environment information and power engineering project information carried by the QR codes, encapsulating the above information into standardized authorization request messages, and sending them to the authorization center terminal 100. The work order management system can complete the commissioning personnel's identity authentication through relevant protocols of WeChat Work or the unified authentication interface of the OA system, ensuring that the information of the operating entity and the person responsible for the work order is consistent. It also supports seamless switching between the manual input interface for authorization codes and the QR code scanning interface, providing a convenient and reliable operation entry point for authorization information transmission in offline environments.

[0043] The Target Power Error Prevention System is a power industry application software deployed on-site at 200 deployment terminals, such as substation monitoring systems, distribution automation terminal management programs, and dispatch master station functional modules. It typically operates in a highly secure, isolated production control area, in an offline state without internet access. The system has a built-in local interface for collecting machine information such as server type, motherboard UUID, hard drive serial number, and product version information, and generates a QR code image containing Base64 encoded content based on this information. When a user terminal scans the QR code using the work order management system, the Target Power Error Prevention System displays the QR code on the screen, completing the transmission of system environment information and providing a unique identifier for subsequent authorization verification.

[0044] Step S330: Send the system environment information and power engineering project information to the authorized center terminal 100.

[0045] User terminal 300 can initiate a POST request to the standardized authorization application interface provided by the authorization center terminal 100 through an HTTPS encrypted channel. The request message is encapsulated in JSON format and includes the work order number, system environment information hash value, power engineering project information summary, timestamp, and user terminal digital signature. After receiving the request, the authorization center terminal 100 verifies the validity of the digital signature and completes two-way authentication with the user terminal 300 to ensure the confidentiality, integrity, and non-repudiation of information transmission. In scenarios where the power industry's production control area and management information area are physically isolated, if the user terminal 300 and the authorization center terminal 100 are located in different security partitions, information transmission can also be performed via a relay server equipped with a security isolation device for protocol conversion and data transfer. The user terminal 300 first sends the encrypted message to the relay server. After the relay server performs virus scanning and format verification on the message, it forwards it to the authorization center terminal 100 through a dedicated secure channel. The authorization center terminal 100 parses the message and extracts the system environment information and power engineering project information for subsequent authorization code generation.

[0046] Step S340: Receive the authorization code returned by the authorization center 100.

[0047] The above solution receives a work order from the user terminal 300, which uniquely identifies the project and contains information about the power engineering project. It then calls the work order management system to scan a QR code generated by the target power anti-misoperation system, which contains machine information and product version information. This establishes a strong association between the commissioning personnel's identity, the project, and the target power anti-misoperation system environment, enabling secure collection of authorization information and task binding in an offline environment. On the other hand, the user terminal 300 sends system environment information and power engineering project information to the authorization center terminal 100 and receives the returned authorization code, forming a closed-loop process of QR code scanning, information transmission, and authorization code distribution. This effectively avoids the risks of leakage and tampering caused by traditional USB flash drive copying and manual delivery methods, and improves the traceability and security of the authorization process in the closed network of the power industry.

[0048] Please see Figure 2 The following describes the authorization method for the power grid anti-misoperation software applied to the authorization center terminal 100. The authorization method for the power grid anti-misoperation software applied to the authorization center terminal 100 includes: Step S110: Receive the function list, project configuration, debugging requirements, and system environment information of the target power anti-misoperation system; wherein, the system environment information includes the machine code.

[0049] The aforementioned function list is a collection of functional module metadata compiled by the system project manager based on the business architecture of power industry application software. The function list defines authorizable software functional units in a structured JSON or XML format. Each function record includes at least the function module identifier, function name, menu code, API access path, module dependencies, and security level attributes. Its data source is the product function library maintained by the software development team, and it is batch-loaded into the data storage area of ​​the authorization center (end 100) via an import interface. The aforementioned project configuration is a set of authorization parameters set for a specific power engineering project during the implementation phase. It includes the project number, product code, authorization mode (debugging mode or running mode), authorization period, site quantity limit, and concurrent access threshold. Project configuration information is entered by the project management department when creating the engineering project in the OA system and synchronized to the authorization center (end 100) via a standardized interface to guide the generation scope and authorization constraints of the authorization list. The aforementioned debugging requirements are temporary authorization requests generated during the implementation of engineering projects due to on-site equipment commissioning, functional verification, or troubleshooting. These requests include the scope of debugging functions, debugging duration, responsible person for debugging, and work order number. The debugging personnel submit these requests through the WeChat project order or mobile work terminal. After approval by the project manager, the OA system parses and converts them into debugging mode parameters, which are then transmitted to the authorization center to trigger the generation process of the debugging authorization code.

[0050] The power anti-misoperation software authorization system provided in this application embodiment can achieve cross-product compatible authorization rule management by establishing a unified standardized function list system. This system requires each software product to provide a standardized function list file in JSON structured format, clearly defining the metadata model of authorizable functions. The core elements of the list include the product number, function module number, and their attribute descriptions. This structure not only clearly delineates the functional boundaries of different products but also ensures a high degree of uniformity and controllability in the parsing process between the authorization center's encoding and the authorization decoding module. In the authorization code generation and mapping stage, the authorization center 100 can automatically retrieve the corresponding function number from the function list based on the user-selected product and function module, and encode it into the function module encoding segment of the authorization code. During decoding, the field deployment 200 accurately compares the function number in the authorization code with the locally preset function list, mapping it to the function switch within the actual software, thereby establishing a complete traceability link from encoding to execution, ensuring the consistency and auditability of function activation.

[0051] The aforementioned system environment information is a set of hardware and software identification information automatically collected by the target power misoperation prevention system deployed at the field deployment terminal 200 through calling the local system interface. This information serves as a unique feature vector representing the target operating environment during the offline authorization process. The system environment information may include machine code and product version information. The machine code further includes the server type (used to distinguish physical servers, virtual machines, or cloud servers), motherboard UUID (a device fingerprint generated by hashing the motherboard's unique identifier), and hard drive serial number (a unique identifier for a fixed disk excluding removable storage devices). This hardware information is obtained through shell commands or system API calls and converted into a standardized string. The product version information includes the software product's version number, build number, and feature list version, which is read from the built-in configuration file by the target power misoperation prevention system upon startup. The collected system environment information is Base64 encoded and embedded with a QR code for scanning by the user terminal and transmitted to the authorization center. This QR code serves as the core input data for generating the machine code segment and is also used in the multi-level verification process to compare the machine information in the authorization code with the current system environment, achieving a cryptographic binding between the authorization code and the target power misoperation prevention system, preventing cross-device copying and unauthorized use.

[0052] Step S120: Generate an authorization list based on the function list, project configuration, and debugging requirements; wherein the authorization list includes product version, function modules, and authorization period.

[0053] The aforementioned authorization list is a structured authorization data file generated by the authorization center through automated orchestration and encryption based on the function list, project configuration, and debugging requirements. It defines the scope of software functions and permission constraints that can be activated by the target power anti-misoperation system in a specific engineering project. The authorization list can be stored in binary or JSON encrypted format. Its core data elements include the product version number, product code, list of function module identifiers, set of menu codes, set of API access paths, and debugging mode flag. This information is automatically generated by parsing the predefined module dependencies in the function list and the authorization parameters set in the project configuration (such as authorization period and site quantity limits).

[0054] Optionally, step S120 above may include: parsing the function list and project configuration to obtain the association between software version, product code, function module, menu code and API path; determining the debugging mode of the authorization list based on debugging requirements; arranging and encrypting the software version, product code, function module, menu code, API path and debugging mode to generate the authorization list; writing the authorization list into the target power anti-misoperation system and synchronizing the function module information to the collaborative office system.

[0055] The aforementioned relationships between software versions, product codes, functional modules, menu codes, and API paths form a hierarchical mapping structure predefined in the function list. This structure describes the complete technical implementation path of the product's functional system under a specific version of the power industry application software. For example, the software version number serves as the root node, with each software version corresponding to a unique product code, forming a baseline binding between version and product. Based on this, each product code is associated with a list of functional module identifiers. Each functional module acts as an independent functional unit carrying specific business logic. Furthermore, each functional module is mapped to a pair of menu codes and API paths for calling interfaces. The menu code defines the navigation location and operation entry point of the function in the graphical user interface, while the API path defines the unified resource identifier and access method for the backend service interface. These three elements constitute a closed loop for the front-end and back-end implementation of the functional module. These relationships can be stored in the database of the authorization center using a JSON structured file. When the authorization center parses the function list and project configuration, it automatically extracts the list of functional modules under the corresponding software version based on the product code matching algorithm and simultaneously reads the set of menu codes and API paths associated with each functional module, forming a complete authorization list entry.

[0056] The aforementioned commissioning modes can employ a tiered authorization mechanism, categorized into two interlocking types: A1 mode and B1 mode, based on the operational scope and safety level of power system on-site maintenance. A1 mode is the default standard commissioning mode, suitable for commissioning scenarios such as routine function verification, parameter viewing, and software defect repair that do not involve changes to the system topology. In this mode, software function permissions are strictly limited to authorized modules, prohibiting any operations that may alter the power grid operating topology or equipment relationships, ensuring the system remains in a safe interlocked state. B1 mode is an extended commissioning mode specifically designed to address special on-site maintenance needs in power engineering projects, including but not limited to high-risk operations involving system architecture adjustments such as equipment maintenance, adding new bays, and substation expansion. When commissioning personnel apply for and verify B1 mode authorization through the authorization center (100), some safety interlocking constraints are lifted, temporarily opening advanced function interfaces such as equipment configuration, topology editing, and data mapping, allowing necessary structural change operations to be completed within the authorized time window. Enabling B1 mode requires an already activated function authorization, and its validity period and scope of operation are subject to the dual constraints of the time field and function module field in the authorization information code. Once the debugging task is completed or the authorization expires, it will automatically revert to A1 mode and re-enable the full lockout mechanism to prevent the risk of misoperation due to permission retention.

[0057] The encryption process described above can employ symmetric encryption, asymmetric encryption, or a custom obfuscation encoding. For symmetric encryption, the AES-256 algorithm can be used. The authorization center 100 uses a pre-shared key to encrypt the plaintext JSON of the authorization list in CBC mode, generating an initialization vector before encryption. The encrypted ciphertext is appended with an HMAC-SHA256 message authentication code to ensure integrity. The key is pre-negotiated and periodically updated by the authorization center 100 and the field deployment terminal 200 through a secure channel. For asymmetric encryption and digital signature, the RSA-2048 or the Chinese national standard SM2 algorithm can be used. The authorization center 100 uses the public key of the target power anti-misoperation system to encrypt the authorization list, ensuring that only the field deployment terminal 200, holding the private key, can decrypt it. Simultaneously, the authorization center 100's private key is used to digitally sign the list digest, and the field deployment terminal 200 uses the authorization center 100's public key to verify the signature's authenticity. Custom obfuscation encoding schemes can combine bit-segment compression with Base32 encoding. The authorization center 100 performs binary compression on key fields such as time parameters, functional module bit segments, and version numbers in the authorization list according to a predetermined bit length, then converts them into printable strings through Base32 encoding, and performs cyclic shift obfuscation processing after encoding.

[0058] After generating the authorization list, the aforementioned authorization center terminal 100 can encapsulate the functional module metadata (including module identifier, module name, API path and menu code) extracted from the list into a JSON message and send it to the collaborative office system via a POST request.

[0059] The above solution obtains the association between software version, product code, functional module, menu code, and API path by parsing the function list and project configuration. Based on debugging requirements, it determines the debugging mode and generates an authorization list by arranging and encrypting the above information. This achieves automated construction of the authorization list, avoiding information omissions and operational errors in traditional manual configuration methods, and improving authorization efficiency and accuracy. On the other hand, by writing the generated authorization list into the target power anti-misoperation system and synchronizing the functional module information to the collaborative office system, a two-way data channel is established between the authorization center and the collaborative office system. This ensures the real-time consistency and traceability of power engineering project information and authorization status across heterogeneous systems, providing a unified management view for the parallel implementation of multiple projects in the power industry.

[0060] Step S130: Encode the system environment information, power engineering project information, and authorization list to generate original authorization data; The above step S130, which encodes the system environment information, power engineering project information, and authorization list, is implemented as follows: A structured data encapsulation protocol is used to integrate the system environment information, power engineering project information, and authorization list into a unified data model. The data model is defined in a binary serialization format, containing a fixed-length header identifier area and a variable-length data payload area. Specific encoding methods include: the system environment information is Base64 decoded to restore the original machine code (covering server type, motherboard UUID, and hard drive serial number), and the fields of the machine code are arranged sequentially in big-endian byte order; the power engineering project information extracts the project number, project name, and debugging supervisor identifier from the work order, converts it to a byte sequence using UTF-8 encoding, and adds a 4-byte field in the header to indicate the offset of each information item; the authorization list is decrypted using AES to restore the plaintext JSON structure, and after parsing, the product version number, functional module bit field, authorization start and end timestamp, and debugging mode flag are extracted. The timestamp is converted to UNIX time format (32-bit integer), the functional module bit field is compressed into a byte array according to bit order, and the product version number is encoded in ASCII with an added checksum. After being serialized, the above three types of information are concatenated according to a predefined field order (header identifier, machine code, project number, product version, functional module segment, time parameter, and debugging flag).

[0061] Step S140: Encode and convert the original authorized data to form encoded data, and perform digest operation on the machine code and the original authorized data to generate a check code.

[0062] Step S140 above performs encoding conversion on the authorized raw data, aiming to convert the binary data structure into a standardized text format suitable for transmission and storage. Encoding conversion can employ various schemes such as Base32, Base64, or custom obfuscation encoding.

[0063] Step S140 above can employ an integrity verification mechanism based on a cryptographic digest algorithm. This involves performing multi-level digest operations on the authorized original data and machine code to generate a verification code. Specifically: a Cyclic Redundancy Check (CRC-16) operation is performed on the authorized original data to generate a 16-bit binary checksum, used to detect possible bit-level errors during transmission or storage; subsequently, the SHA-256 hash algorithm is used to calculate the digest of the authorized original data, generating a 256-bit message digest, and the first 128 bits of this digest are used as the base value for the digital signature. Based on this, an HMAC-SHA256 operation is performed on the concatenation result of the machine code and the authorized original data using a pre-shared key to generate a keyed hash message authentication code. This verification code serves both data integrity verification and source authentication functions.

[0064] Step S150: Based on the check code, machine code, and encoded data, generate a segmented authorization code, and then generate the final authorization code after encryption; wherein, the segmented authorization code is used to provide a unified authorization model; the segmented authorization code includes a check code segment, a machine code segment, and an authorization information code segment.

[0065] The above encryption process involves cryptographically obfuscating the segmented authorization code, rearranging and substituting binary bits using a predefined bit shifting algorithm, and attaching a key-based message authentication code to generate a final authorization code with resistance to reverse engineering and integrity protection. This segmented authorization code uses binary bit-segment encoding and provides a unified authorization model through a three-segment structure: a check segment, a machine segment, and an authorization information segment. The check segment includes a built-in check bit and authorization code type identifier to verify the integrity of the authorization code and distinguish between functional authorization, debugging authorization, personal authorization, APP authorization, and restoration authorization types. The machine segment uses server type, motherboard identifier, and hard drive serial number fields to implement a unified device binding strategy for physical servers, virtual machines, and cloud server environments. The authorization information segment uses a bit-segment compression structure to encapsulate the authorization creation time, authorization start and end time, product list length, product code list, and the authorization file version, authorization module length, and authorization module bitmap for each product, ensuring that the authorization period, functional module scope, and power engineering project information have fixed field meanings and a unified parsing process at the binary level. When generating the segmented authorization code, the authorization center constructs a binary data structure according to the field order and performs shift and obfuscation processing, which enables the authorization model to be compatible across product versions and adapt to the authorization management needs of multiple products and multi-functional modules in different power engineering projects, thereby achieving standardization and scalability of the authorization rule system.

[0066] Optionally, the above verification code segment includes a verification bit, an authorization code type field, and an authorization code version field; wherein, the authorization code type field is used to identify function authorization, debugging authorization, personal authorization, APP authorization, or restoration authorization; The machine code segment includes the server type field, motherboard identifier field, and hard disk serial number identifier field; The authorization information code segment includes the authorization creation time field, authorization start and end time field, product list length field, product code list field, as well as the product authorization file version field, product authorization module length field, and product authorization module field.

[0067] The structure of the above segmented authorization code is shown in Table 1: Table 1. Structure of Segmented Authorization Code

[0068] The following sections will describe the check code, machine code, and authorization information code in the segmented authorization code described above: 1. Verification code; (1) Check Bit: The check bit mentioned above is an integrity verification field in the check code segment used to detect whether the authorization code has been tampered with or has bit errors during transmission, storage, or parsing. The CRC-16 Cyclic Redundancy Check algorithm is used to perform digest operations on all fields in the authorization code except the check bit itself (including the machine code segment and the authorization information code segment) to generate a 16-bit binary check value. The CRC algorithm can treat the byte sequence to be checked as polynomial coefficients, divide it by a predefined generator polynomial using modulo 2 division, and the remainder is used as the check bit and appended to the authorization code terminal. When the field deployment terminal 200 performs authenticity verification, it uses the same generator polynomial to recalculate the CRC-16 value of the received authorization code and compares it with the check bit. If the two are inconsistent, it is determined that the integrity of the authorization code has been compromised and activation is rejected. The introduction of the check bit enables the authorization code to actively defend against man-in-the-middle attacks and storage media failures, and is a basic cryptographic barrier to ensure the trustworthiness of authorization data in offline environments.

[0069] (2) Authorization Code Type: The above authorization code type field is a classification identifier segment in the verification code segment used to identify the application scenario and permission policy of the authorization code. Different authorization types can be represented by 3-bit binary encoding. For example: Functional authorization (ACTIVATE_CODE, binary encoding 001) is used to formally activate the basic business functions of the software and set the validity period; Debugging authorization (DEBUGGING_CODE, binary encoding 010) provides time-limited debugging permissions on the basis of functional authorization, supporting on-site fault diagnosis and function verification; Personal authorization (PERSONAL_CODE, binary encoding 011) is bound to specific debugging personnel and equipment, and is suitable for dedicated debugging scenarios for R&D personnel; APP authorization (APP_CODE, binary encoding 100) is used to activate the access permissions of the mobile client; Restore authorization (RESTORE_CODE, binary encoding 101) is used for temporary authorization for data recovery operations. As the decision input of the local authorization policy, the authorization code type field determines the set of functions and permission boundaries that the target power anti-misoperation system should enable. It supports the authorization center 100 to flexibly distribute different types of authorization codes according to the needs of the project stage, so as to realize the phased and refined control of the entire software life cycle.

[0070] (3) Authorization Code Version: The authorization code version field mentioned above is a metadata field in the verification code segment used to identify the authorization code structure version number. It can be represented by 4-bit binary encoding to represent 16 version numbers. The initial version is defined as 0001, and the version number is incremented every time there is a structural change (such as adding a verification algorithm, adjusting the field length, or expanding the authorization type). The authorization code version field is automatically written by the authorization center terminal 100 according to the currently implemented encoding specification when generating the authorization code. The field deployment terminal 200 reads the version field when parsing the authorization code and matches it with the local supported decoding version library. If the versions are incompatible (e.g., the field deployment terminal 200 only supports versions 0001 to 0010, but receives an authorization code of version 1111), it will refuse to parse it. The introduction of the version field enables the authorization code to have backward compatibility. When the authorization center terminal 100 upgrades the encoding rules, the old version of the field deployment terminal 200 can actively reject incompatible authorization codes through version identification to avoid functional abnormalities caused by parsing errors.

[0071] II. Machine code; (1) Server type field: The above server type field is a classification code segment in the machine code segment used to identify the underlying hardware platform type of the target power anti-misoperation system. It can use 2-bit binary encoding to distinguish four types of servers: 00 encoding represents physical servers, referring to physical industrial control computers or rack servers deployed in substations or dispatch centers; 01 encoding represents virtual machine instances in virtualization platforms, suitable for systems running in VMware or KVM virtualization environments; 10 encoding represents cloud server instances in public or private cloud environments; 11 encoding is a reserved value for future expansion of other server types. The server type field can be automatically determined by the target power anti-misoperation system when generating the QR code by calling the system API to read the virtualization identifier or cloud platform metadata, and written into the system environment information. The authorization center 100 extracts this field and embeds it into the machine code segment. When the field deployment 200 performs system binding verification, it compares the server type field in the authorization code with the current actual operating environment. If the type does not match (e.g., the authorization code is limited to a physical server while the target power anti-misoperation system is actually running in a virtual machine), it is determined to be an illegal porting and activation is refused, thereby preventing the authorization code from being reused across platforms and ensuring the strict binding of the authorization policy and the hardware environment.

[0072] (2) Motherboard Identification Field: The aforementioned motherboard identification field is a machine fingerprint segment in the machine code segment used to uniquely identify the hardware identity of the target power misoperation prevention system motherboard. It is generated by hashing the motherboard UUID (Universally Unique Identifier) ​​and extracting the first 6 bytes. When generating the QR code, the target power misoperation prevention system reads the original UUID value burned in the motherboard BIOS by executing a shell command. This UUID is generated by the motherboard manufacturer in accordance with the RFC 4122 standard and has global uniqueness. After obtaining the UUID, the target power misoperation prevention system can perform a digest operation on the UUID string to generate a 32-byte hash value, and extract the first 6 bytes (48 bits) of the hash value as the value of the motherboard identification field, which is then arranged in big-endian order and embedded with system environment information. When the field deployment terminal 200 performs system binding verification, it recalculates the UUID hash of the current motherboard and extracts the first 6 bytes, which are then precisely compared with the motherboard identification field in the authorization code. If they do not match, it is determined that the device has been illegally replaced, and authorization activation is refused. This strictly limits the scope of the authorization code to a specific motherboard, achieving high-security hardware-level binding.

[0073] (3) Hard disk serial number identifier field: The above-mentioned hard disk serial number identifier field is a unique verification bit field of the storage device used as an auxiliary machine identifier in the machine code segment. It is used to enhance the reliability of system binding verification. It can be generated by hashing the serial number of a fixed disk and then extracting the first 6 bytes. When the target power anti-misoperation system generates the QR code, it obtains the original string of the serial number of the main hard disk (usually the system disk). This serial number is written into the firmware by the hard disk manufacturer and has device-level uniqueness. After obtaining the serial number, it also uses the SHA-256 hash algorithm to perform digest operation and extracts the first 6 bytes as the hard disk serial number identifier field. It is arranged in big-endian order and concatenated with the motherboard identifier field to form the core content of the machine code segment. The hard drive serial number identifier field provides a backup verification basis when the motherboard's UUID changes due to BIOS upgrades or hardware failures. The field deployment terminal 200 can prioritize comparing the motherboard identifier field during system binding verification. If the motherboard is replaced, causing the verification to fail but the hard drive is not replaced, the hard drive serial number identifier field can be enabled for auxiliary verification. In specific scenarios (such as motherboard repair and replacement but needing to retain the original authorization), the authorization code is allowed to migrate to a limited extent, thereby ensuring strong binding security while taking into account the flexibility and fault tolerance of the engineering site.

[0074] III. Authorization Information Code; (1) Authorization Creation Time Field: The above-mentioned authorization creation time field is a timestamp field in the authorization information code segment used to record the time when the authorization code was generated. It can be represented by 16-bit binary encoding, which is the date information obtained from the system clock at the authorization center, accurate to the day. The authorization creation time field is obtained by the authorization center 100 when it calls the system time API to obtain the current date (format YYYY-MM-DD) when generating the authorization code, and then encoded and embedded in the authorization information code segment. The field deployment terminal 200 reads this field and decodes it when parsing the authorization code, thereby obtaining the authorization code generation timestamp, which is used to determine whether the authorization code is within the valid activation window period. If the current time exceeds the window period, the authorization code is determined to be invalid and activation is refused, thereby preventing the pre-generated authorization codes from being hoarded or delayed for a long time, and ensuring the timeliness of authorization and system security.

[0075] (2) Authorization Start and End Time Field: The authorization start and end time field is a continuous time segment in the authorization information code segment used to define the authorization validity period. It consists of two sub-fields: the authorization start date field and the authorization end date field, and can be encoded using 16-bit binary encoding. The authorization start date field is obtained by the authorization center terminal 100 through encoding based on the authorization effective time set in the project configuration; the authorization end date field is calculated based on the authorization period (e.g., one year after project acceptance) and the same encoding is performed. The field deployment terminal 200 decodes this field during the authorization scope verification phase to obtain the start and end dates of the authorization validity period and compares them with the current system date. If the current date is earlier than the start date, it indicates that the authorization has not taken effect; if it is later than the end date, it determines that the authorization has expired and rejects the function call, thereby achieving precise control over the duration of software function usage.

[0076] (3) Product List Length Field: The above-mentioned Product List Length Field is a metadata field in the authorization information code segment used to indicate the number of products covered by this authorization. In multi-product joint deployment scenarios (such as a central control station monitoring system that simultaneously includes three independent products: SCADA, protection information substation, and power energy acquisition), the authorization center terminal 100 can count the total number of products to be authorized based on the product list in the project configuration, encode it as an unsigned integer, and embed it in the Product List Length Field. When parsing the authorization code, the field deployment terminal 200 reads the Product List Length Field to determine the parsing length of the subsequent product code list field.

[0077] (4) Product Code List Field: The above-mentioned product code list field is a variable-length data area immediately following the product list length field in the authorization information code segment. It is used to store the unique code of each product to be authorized. The code value is converted by the authorization center terminal 100 according to the product number predefined in the product configuration library. In the parsing process, the field deployment terminal 200 can continuously read N preset bit binary segments from the authorization information code segment according to the N value determined by the product list length field. Each segment is decoded into an integer product code and matched with the locally registered product list. If there is an unrecognized product code, it is determined to be an illegal authorization.

[0078] (5) Product Authorization File Version Field: The above-mentioned Product Authorization File Version Field is a sub-field defined for each authorized product in the authorization information code segment, used to identify the version number of the authorization file format applicable to the current authorization. When the authorization file structure changes, forward compatibility control is achieved by incrementing the product authorization file version number. When parsing the authorization code, the on-site deployment terminal 200 reads this field and matches it with the locally supported authorization file version parsing library. If the version number exceeds the supported range, activation is rejected and a system upgrade is prompted.

[0079] (6) Product Authorization Module Length Field: The above-mentioned Product Authorization Module Length Field is a sub-field defined for each authorized product in the authorization information code segment, used to indicate the number of functional modules authorized for the current product. The authorization center encodes this field according to the statistical results of the number of functional modules selected in the project configuration. When the field deployment terminal parses the 200, it determines the number of bits to read in the subsequent product authorization module field based on this length value, realizing flexible parsing of the variable-length functional module list.

[0080] (7) Product Authorization Module Field: The Product Authorization Module Field is a dynamic bit field defined for each authorized product in the authorization information code segment. Each bit corresponds to a functional module in the function list. A bit value of 1 indicates that the module is authorized and activated, and a bit value of 0 indicates that the module is not authorized or needs to be revoked. The Product Authorization Module Field can realize fine-grained permission control at the functional module level through a bitmap mechanism, supporting the simultaneous activation or deactivation of dozens of functional modules in a single authorization code. The field deployment terminal 200 performs a bitwise AND operation between the parsed bitmap and the local function list, mapping it to the actual function switch register, thereby realizing the automatic revoke of authorized and unauthorized modules as needed.

[0081] The above solution constructs verification code segments, machine code segments, and authorization information code segments using a binary field structure. The authorization code type field supports multiple types of identifiers, including function authorization, debugging authorization, personal authorization, APP authorization, and restoration authorization. The server type, motherboard identifier, and hard drive serial number identifier fields enable fine-grained device binding, forming a unified authorization model across products and versions, improving the coding efficiency and system adaptability of authorization codes. On the other hand, through the structured definition of authorization creation time, authorization start and end time, product list length, product code list, and product functional module bit segments, precise control and dynamic adjustment of authorization period, product scope, and functional modules are achieved. This effectively supports a smooth transition from debugging to operation in the software lifecycle and incremental authorization scenarios, enhancing the flexibility and security of authorization management.

[0082] Optionally, the above-mentioned power misoperation prevention software authorization method may further include: after activating the target power misoperation prevention system using an authorization code, the authorization center 100 stores the authorization code, system environment information, and power engineering project information in the work order management system, and updates the work order status corresponding to the current engineering project to the completed status, so as to establish a one-to-one correspondence between the authorization code, the target power misoperation prevention system, and the engineering project; when the authorization request for the target power misoperation prevention system is initiated again, the authorization center 100 verifies the system environment information based on the correspondence stored in the work order management system. If the system environment information is already associated with other engineering projects, the authorization request is rejected.

[0083] Understandably, in the above scheme, after the authorization code passes multi-level verification and successfully activates the target power anti-misoperation system, the authorization center 100 can write the authorization code, the system environment information of the target power anti-misoperation system (including machine code and product version), and the power engineering project information (including project number and project name) into the authorization log database of the work order management system as an associated record. This record adopts a composite primary key design (project number and machine code) to ensure the uniqueness of each record, and synchronously updates the work order status field to "completed," locking the authorization distribution channel of the project and preventing duplicate work orders. This operation establishes a one-way one-to-one correspondence between the authorization code, the target power anti-misoperation system, and the project at the database level, forming an immutable binding snapshot. When the same target power anti-misoperation system or other systems initiate an authorization request again, the authorization center will forcibly trigger the anti-reuse verification sub-process before generating a new authorization code: it will call the query interface of the work order management system, using the machine code in the system environment information carried in the current request as an index, to search the historical binding records to see if there is an active binding relationship between the machine code and any other project (not the project to which the current request belongs). If the query result is not empty, it is determined that the system environment information has been used by other engineering projects. This request constitutes cross-project authorization reuse, and the authorization center directly rejects the request and returns an error code and the reason for rejection. If the query result is empty, the subsequent authorization code generation process is allowed. This mechanism can fundamentally prevent the illegal copying, transplantation, and reuse of authorization codes between different engineering projects by transforming a one-time authorization activation event into a persistent and auditable binding relationship record and embedding the verification logic into the pre-judgment stage of all authorization requests. This meets the strict requirements of the power industry for the uniqueness, exclusivity, and traceability of authorizations. At the same time, it allows auditors to trace the first activation time of any authorization code, the associated engineering project, and the hardware fingerprint of the target power anti-misoperation system through the work order management system, forming a complete authorization chain audit track.

[0084] The above solution establishes a one-to-one correspondence between the authorization code, the target power anti-misoperation system, and the power engineering project information after the target power anti-misoperation system is activated. This enables full traceability of the authorization process and prevents reuse, ensuring that the authorization code is strongly bound to a specific engineering project and the target power anti-misoperation system, effectively preventing the authorization code from being reused in unauthorized systems or projects. On the other hand, when a new authorization request is initiated, the system environment information is verified based on the correspondence stored in the work order management system. If the system environment information is found to be associated with other engineering projects, the authorization request is rejected, forming a cross-system and cross-project authorization diffusion protection mechanism, which improves the security and controllability of offline authorization management.

[0085] Please see Figure 2 The following describes the licensing method for the power anti-misoperation software applied to the field deployment terminal 200. Optionally, the licensing method for the power anti-misoperation software applied to the field deployment terminal 200 includes: Step S210: After receiving the authorization code, perform the following multi-level verifications: verify the authenticity of the authorization code to confirm its integrity; perform system binding verification to compare the consistency between the machine code and the current system environment information; perform power engineering information verification based on the binding relationship between the system environment information and power engineering project information stored in the work order management system. If the system environment information is already associated with other engineering projects, the authorization code will be rejected; and perform authorization scope verification to confirm the validity of the product version, functional modules, and authorization period. Step S220: If all the above verifications pass, dynamically enable the corresponding debugging function or business module according to the authorization code type field; otherwise, reject the authorization code.

[0086] After receiving the authorization code, the on-site deployment terminal 200 starts a multi-level verification mechanism. The multi-level verification mechanism can execute four layers of verification in the order of cryptographic strength and business logic progression. If any verification step fails, a rejection policy will be triggered. Specifically: (1) First, the authenticity verification is performed. The CRC-16 digest value of all fields in the authorization code except the check bit is recalculated and compared with the check bit in the authorization code to detect whether the authorization code has been tampered with at the bit level or corrupted during transmission or storage; (2) The system binding verification is performed. The on-site deployment terminal 200 extracts the machine code segment in the authorization code and compares it with the server type, motherboard UUID and hard disk serial number collected in real time by the current system through the local interface. If the three do not match completely, it is determined to be an illegal copy across devices. Activation is refused, and hardware-level identity anchoring is achieved; (3) Power engineering information verification is performed. The field deployment terminal 200 calls the query interface of the work order management system and uses the machine code in the current system environment information as the index to retrieve historical binding records. If it is detected that the machine code has been associated with other engineering projects and the work order status is completed, it is determined to be cross-project authorization reuse and is immediately rejected to prevent the same hardware device from repeatedly applying for authorization in different engineering projects; (4) Authorization scope verification is performed. The product version field, functional module bit field and authorization start and end time field in the authorization information code segment are parsed and compared with the product version number, available function list and current system date registered locally in the target power anti-misoperation system to ensure that the authorization code has not expired and the applied functional module is within the product license range. If all four layers of verification pass, the dynamic activation logic is executed according to the authorization code type field. Otherwise, the authorization code is rejected and the system records the rejection reason to the local audit log.

[0087] The aforementioned solution employs a multi-level, progressive verification process at the field deployment end, performing verification on the authorization code's authenticity, system binding, power engineering information, and authorization scope. This automated verification of authorization code integrity, device binding relationships, project relevance, and authorization compliance can be completed sequentially in an offline environment without a network connection, enhancing the security and reliability of software authorization verification within the power industry's closed network. Furthermore, by dynamically enabling corresponding debugging functions or business modules based on the authorization code type field after all verifications pass, and rejecting the authorization code upon verification failure, the solution achieves automated linkage and isolation control between authorization verification and function activation. This effectively prevents the risks of unauthorized use, cross-device copying, and authorization diffusion between projects, meeting the power industry's core needs for strict control and on-demand activation of software authorizations.

[0088] Optionally, the above-mentioned dynamic activation of corresponding debugging functions or business modules includes: determining the authorization strategy based on the authorization code type field; when the authorization code type is function authorization, activating the product function module corresponding to the authorization information code segment; when the authorization code type is debugging authorization, enabling the debugging function based on the function authorization activation, and controlling the effective time window of the debugging function based on the authorization creation time field and the authorization start and end time field; encrypting and storing the activated function modules, and verifying the validity of the authorization code in real time when a function call request is received, and intercepting unauthorized function interfaces. An example of this implementation is: When the authorization code type field is identified as functional authorization, the field deployment terminal 200 executes the following process: (1) Verify the legality of the authorization code format and the validity of the authorization period to ensure that it is within the activatable time window; (2) Execute the machine code verification step, extract the corresponding hardware identifier according to the actual deployment mode (single machine, main standby or cluster) of the target power anti-misoperation system, and compare it with the machine code segment in the authorization code. If the deployment mode is cluster, the machine information of all online nodes needs to be collected and verified one by one to ensure that the overall binding relationship between the authorization code and the target cluster is established; (3) After the verification is passed, the authorization center parses the product information and authorization period in the authorization code, verifies the validity of the product version and the legality of the functional module, constructs the initial authorization file object and sets the authorization start and end timestamp. If the configuration allows, the first debugging time window (default 3 days) is initialized and it is ensured that it does not exceed the total authorization period; (4) The authorization file is encrypted using the AES-256 algorithm, and an HMAC-SHA256 digital signature is added to ensure the integrity of the file. The encrypted authorization file is persistently stored in the secure storage area of ​​the target power anti-misoperation system to complete the activation and solidification of the functional authorization.

[0089] When the authorization code type field is identified as debug authorization, the field deployment terminal 200 executes the following process: (1) The execution logic of debug authorization must be triggered on the basis that the function authorization has been successfully activated. Therefore, the precondition check is first performed to confirm that the system is in an activated state and to verify that the current activation code type is a standard function authorization code rather than other special types; (2) Check the unique identifier of the debug code to prevent the same debug code from being used repeatedly; the authorization center calculates the debugging end time according to the debugging duration parameter specified in the debugging requirements (such as 1 day, 3 days or 7 days) and forces the verification that the time window does not exceed the original authorization period; (3) Initialize the debug counter to count the actual number of times or duration of debugging function use, and write the start and end time of the debugging time window and the information of the person responsible for debugging into the authorization file, and update the authorization file using the same encryption and signature strategy as the function authorization. After the debugging authorization is activated, the on-site deployment terminal 200 monitors the usage status of the debugging function in real time based on the authorization creation time field and the authorization start and end time field. When the current time exceeds the debugging end time or the debugging usage time reaches the upper limit, the debugging function failure mechanism is automatically triggered, the debugging-related cache is cleared and the running function control policy is switched to ensure the strict timeliness of debugging permissions.

[0090] When the authorization code type field is identified as personal authorization, the execution logic of the field deployment terminal 200 is similar to that of function authorization, but with the addition of special constraints on personal use attributes. Its activation process also goes through parameter verification, machine code verification, authorization file creation and encrypted storage. The difference is that when the authorization center generates a personal authorization code, it forces the binding of the machine code segment with the identity identifier of a specific debugging personnel (such as employee number or digital certificate) and embeds a personal use flag in the authorization information code segment. When the field deployment terminal parses the personal authorization code, in addition to performing standard function activation verification, it also needs to compare whether the identity of the currently logged-in user is consistent with the personal identity bound to the authorization code, and prohibits the use of the authorization code in other systems other than the bound device, so as to achieve fine-grained personal-level isolation of authorization permissions and prevent the spread of authorization capabilities.

[0091] When the authorization code type field is identified as APP authorization, in addition to the authorization activation of the execution logic function of the field deployment terminal 200, additional control over the access permissions of specific APP clients is added. When generating the APP authorization code, the authorization center terminal 100 will add an APP client identification field (such as iOS, Android or HarmonyOS platform identification) and a device fingerprint field to the authorization information code segment. After parsing the APP authorization code, the field deployment terminal 200 will not only activate the standard business functions, but also unlock the corresponding mobile terminal API interface access permissions according to the APP identifier, and attach device fingerprint verification to the requests from the APP client to ensure that only authorized mobile devices can access the system.

[0092] When the authorization code type field is identified as "restore authorization," since restore authorization is a temporary authorization mechanism, which can be used in data recovery or disaster recovery scenarios, it is necessary to strictly confirm that the system is already in an activated state before activation and check whether the restore code has been reused to prevent abuse. The authorization center 100 sets a recovery time window (usually shorter than the debugging time window) based on the recovery duration parameter and initializes a counter for the use of the recovery function to limit the cumulative number of recovery operations. During the authorization file update process, the recovery authorization information (including the recovery time window, the range of data allowed to be recovered, and operator information) is written to the authorization file and stored encrypted. The field deployment 200 monitors the usage status of the recovery function in real time during the recovery authorization period. Once the number of recovery operations or the duration reaches the limit, or the recovery time window expires, the recovery function is immediately and automatically disabled and related caches are cleared to ensure strict restriction and timely revocation of this high-risk permission.

[0093] The above solution differentiates the enabling strategies for function authorization and debugging authorization based on the authorization code type field at the field deployment end. In the debugging authorization scenario, it controls the effective time window of the debugging function based on the authorization creation time field and the authorization start and end time field, thereby realizing differentiated management and fine-grained time control of permissions in the debugging and runtime phases throughout the software lifecycle. On the other hand, by encrypting and storing the enabled function modules and verifying the validity of the authorization code in real time when a function call request is received to block unauthorized function interfaces, a dynamic isolation and anti-unauthorization mechanism for runtime function use is constructed.

[0094] Optionally, the above-mentioned encrypted storage of enabled functional modules includes: encrypting the authorization file using an encryption algorithm and adding a digital signature, and periodically updating the authorization file to refresh the effective time window of each authorization type; in cluster deployment mode, broadcasting authorization status changes through the Redis message mechanism and using distributed locks to protect authorization file updates.

[0095] The aforementioned valve stem periodically updates the authorization file and refreshes the effective time windows for each authorization type, based on the dual technical requirements of dynamic security strategies and consistency assurance in a distributed environment. During the long-term operation of the power anti-misoperation software, the authorization file, as the sole persistent carrier of the permission policy, faces the security threat of accumulated key leakage risks if its internal encryption keys remain static for an extended period. A preset key rotation mechanism can automatically invalidate potentially leaked keys without interrupting business operations, thereby maintaining the confidentiality of authorized data. Simultaneously, the calculation of the effective time windows for each authorization type (including function authorization, debugging authorization, and restoration authorization) relies on real-time comparison between the system clock and the authorization start and end time fields. In cluster deployments or master-slave switching scenarios, clock drift between nodes, restart recovery, or network partitioning can all lead to asynchronous time window states. The periodic update mechanism recalibrates the time parameters in the authorization file with the unified clock benchmark of the distributed lock protection, ensuring that each node reconstructs the time window state in memory based on the refreshed authorization file, eliminating misjudgments or premature expiration of authorizations caused by clock deviations.

[0096] It is understandable that the above-mentioned encrypted storage scheme constructs a multi-layered security mechanism from single-machine protection to cluster collaboration. At the single-machine level, the field deployment terminal 200 can use a symmetric encryption algorithm to encrypt the entire authorization file. The encryption key is pre-distributed by the authorization center and stored in the secure key area of ​​the target power anti-misoperation system. The encryption mode uses CBC mode and introduces a random initialization vector to resist replay attacks. After the ciphertext is generated, a message authentication code is attached as a digital signature. The signature key and encryption key are managed separately to ensure dual protection of the confidentiality and integrity of the authorization file. In addition, to further enhance the anti-cracking capability, a key update timer task can be pre-set to automatically trigger the key rotation process according to a preset cycle. The new key is pushed to the target power anti-misoperation system by the authorization center terminal 100 through an encrypted channel. The old key is securely destroyed after confirming that all authorization files to be updated have been re-encrypted, preventing the risk of leakage due to long-term key use.

[0097] In cluster deployment mode, since all nodes need to share the same authorization state to maintain functional consistency, the on-site deployment terminal 200 uses the Redis message mechanism to achieve cross-node state synchronization: when a node (master node) completes authorization code verification and updates the local authorization file, it can publish an authorization state change message to a specific channel in Redis. The message body is encapsulated in JSON format and includes the latest authorization code hash, authorization timestamp, functional module bitmap, and digital signature. Other nodes in the cluster (slave nodes) subscribe to the channel, receive the message, verify the signature validity, and if the verification is successful, trigger the local authorization file update process, write the new authorization information to local storage, and refresh the authorization policy cache in memory. To avoid contention and data inconsistency caused by multiple nodes updating the authorization file simultaneously, a Redis-based distributed lock mechanism can be introduced: Before updating the authorization file, a node attempts to acquire a mutex lock named after the project number (such as Redisson RLock). Only after successfully acquiring the lock can it perform file write and cache refresh operations, and release the lock immediately after the operation is completed. Nodes that fail to acquire the lock enter a waiting queue and listen for lock release events through Redis's publish-subscribe mechanism, ensuring that only one node performs critical update operations at any given time, thereby achieving effective authorization state consistency and operation mutual exclusion guarantees in a cluster environment.

[0098] The above scheme achieves confidentiality protection and integrity verification of authorization data by encrypting the authorization file with an encryption algorithm and adding a digital signature, and periodically updating the authorization file and refreshing the effective time window of each authorization type. This effectively prevents the risk of tampering, leakage and cracking of authorization files in offline storage environments. On the other hand, by broadcasting authorization status changes through the Redis message mechanism in cluster deployment mode and using distributed locks to protect authorization file updates, the consistency of authorization status and mutual exclusion of update operations among nodes in the cluster are ensured, avoiding data inconsistency problems caused by concurrent conflicts.

[0099] Optionally, the above-mentioned power anti-misoperation software authorization method may further include: receiving a new authorization code; wherein the new authorization code is generated based on the changed functional requirements; parsing the new authorization code to obtain the latest authorization information, the latest authorization information including a list of product functional modules, authorization code type, and authorization period; replacing the old authorization status stored locally with the latest authorization information, activating the corresponding module according to the product functional module list, and revoking modules not in the product functional module list; when the authorization code type in the latest authorization information is a function authorization, the field deployment terminal enters the initial debugging state according to a preset configuration strategy; wherein the initial debugging state opens the initial debugging permission within a preset initial debugging time window; after the initial debugging time window expires, the field deployment terminal closes the initial debugging permission.

[0100] The aforementioned incremental update mechanism, through version iteration of the authorization code and automatic overwriting of the local authorization status, achieves a flexible upgrade capability that allows for dynamic adjustment of the authorization scope without redeploying the target power misoperation prevention system. When an engineering project needs to add, deactivate, or modify functional modules due to changes in requirements or functional expansion, the authorization center 100 can regenerate a new authorization code based on the changed functional requirements. This authorization code contains the latest product functional module list, authorization code type, and authorization period. After the user scans the target power misoperation prevention system's QR code using the user terminal 300 and submits an incremental authorization application, the authorization center 100 sends the new authorization code to the field deployment terminal 200. Upon receiving the new authorization code, the field deployment terminal 200 immediately triggers the parsing process, using a decoding algorithm symmetrical to the authorization code generation stage to extract the latest authorization information. It then replaces the old authorization status (including functional module bitmaps, authorization period, and debugging flags) stored locally with the latest authorization information. During the replacement process, no historical authorization data is retained, ensuring that the system always uses the latest authorization and avoiding permission conflicts or unauthorized access risks caused by residual old authorizations.

[0101] During the module activation and recycling process, the on-site deployment terminal 200 can compare the current status of local functional modules bit by bit according to the bit information in the latest product functional module list. For modules with a corresponding bit of 1 in the list, the activation operation is performed, loading their business logic and opening the corresponding menu code and API path access permissions. For modules with a corresponding bit of 0 in the list and that were previously active in the old authorization state, the recycling mechanism is triggered, unloading their business components, clearing related caches and closing interface access, thereby achieving precise shrinkage and dynamic adaptation of authorization.

[0102] The aforementioned initial debugging permission is a temporary debugging capability granting mechanism tied to the function authorization activation process. Essentially, it's a one-time debugging authorization state automatically triggered by the authorization strategy engine at the field deployment end according to a preset configuration policy after the function authorization code successfully verifies and activates the basic business modules of the target power anti-misoperation system. The initial debugging permission is not obtained through a separate debugging authorization code application process, but rather as a byproduct of the function authorization activation event, automatically taking effect within a preset initial debugging time window (e.g., set to 72 hours). During this period, the debugging interface corresponding to the authorized function module is opened, allowing debugging personnel to debug the newly activated function.

[0103] The above solution achieves dynamic updates of authorization status and precise reconfiguration of functional modules through incremental authorization codes. This enables the power anti-misoperation software to continuously run without redeployment, adjust the authorization scope online according to changes in project requirements, and automatically reclaim old permissions, forming a closed-loop authorization lifecycle management. On the other hand, the initial debugging mechanism automatically opens debugging permissions for a preset time window after the function authorization is activated and automatically closes them after the time window expires. This separates the initial function verification from in-depth operation and maintenance debugging, which not only meets the necessary verification requirements before the new module is put into operation, but also builds a permission isolation barrier from deployment verification to long-term operation and maintenance through mandatory time constraints and subsequent independent debugging authorization codes.

[0104] The following section introduces the authorization method for the aforementioned power grid anti-misoperation software and other mechanisms of the system: I. Automatic Expiration Mechanism for Debugging Functions: The automatic expiration mechanism for debugging functions achieves strict time-limited management of permissions through refined time window control and multi-level status monitoring. Each debugging authorization can define an independent start and end time, forming a debugging time window. Debugging authorizations are divided into two types: initial debugging authorization and static debugging authorization. Initial debugging authorization is automatically allocated after the target power anti-misoperation system completes function authorization activation, with a default duration of 3 days. Its time window start and end times are stored in the variables FIRST_TIME_START_DEBUGGER and FIRST_TIME_END_DEBUGGER. Ordinary debugging authorization is actively triggered by the user through requesting a debugging code. The duration can be configured to 1 day, 3 days, 7 days, or 30 days, etc., and its time window parameters are stored in the variables START_DEBUGGER and END_DEBUGGER. The debugging time window is strictly constrained to not exceed the overall authorization period. If the calculated debugging end time is later than the authorization deadline, the debugging end time will be automatically trimmed to the authorization end time to prevent unauthorized extension of debugging permissions. Real-time status monitoring is achieved by continuously tracking the runtime status of debug authorizations through scheduled tasks and counters. A 1-second scheduled task can be maintained to continuously obtain the current timestamp and compare it with the start and end times of the debug time window to determine in real time whether the debug authorization is valid. In addition to time-based monitoring, a usage duration statistics mechanism can be introduced. The DEBUGGER_USED and FIRST_TIME_DEBUGGER_USED counters accurately record the actual cumulative usage time of the debug function. This counter value increments in seconds, supporting constraints on debug permissions from both time duration and usage volume dimensions. The checkStatus() method is periodically called to detect authorization status change events. Once a transition from debug to non-debug state is detected (such as time window expiration or debug code revocation), a cache cleanup operation is immediately triggered, forcibly clearing debug-related temporary data and memory flags to ensure that permission changes take effect immediately. Automatic debugging function failure can be automatically determined through a triple-check logic based on time limit exceedance, usage limit exceedance, and system restart recovery. The time limit exceedance check is implemented by the `isDebugActive()` method. This method retrieves the current time during each permission check call and compares it with the debugging end time. If the current time is later than the end time, the debugging status is immediately set to failed, and subsequent debugging function calls are prevented. The usage limit exceedance check is independent of the time check. It continuously monitors the `DEBUGGER_USED` counter value. When this counter value reaches the total duration of the debugging time window (in seconds), even if the time window has not yet ended, the debugging function is also determined to be failed. This mechanism is used to prevent the debugging function from being occupied or abused for extended periods.To address potential planned restarts or abnormal downtimes of the target power system, a persistence mechanism can ensure the continuity of the debugging state: the field deployment terminal 200 calls the updateUsedTime() method periodically (e.g., every minute) to write the debugging usage time and debugging state information in memory to the encrypted area of ​​the authorization file. After the target power system restarts, it reads the historical state from this file and restores the remaining duration of the debugging time window, ensuring that the debugging authorization is not unexpectedly interrupted due to a restart. In a distributed environment, the consistency of the debugging state among cluster nodes can be ensured through the collaboration of the Redis message bus and distributed locks. Specifically: in cluster deployment mode, when the debugging state of a node changes (e.g., the time window expires or the debugging function is manually disabled), the node can use the syncLicenseChangeAfterCommit() method to publish a state change message to the Redis LICENSE_EVENT_CHANNEL channel after the authorization change transaction is committed. The message body includes the latest authorization signature, change timestamp, and node identifier. Other nodes receive the broadcast message in real time by subscribing to this channel and update their local authorization cache and debugging state flags based on the signature verification result. To prevent data inconsistency caused by multiple nodes concurrently updating the authorization file of the same project, the system uses a Redis distributed lock (RLock) to implement mutual exclusion access when performing critical operations such as updating usage duration or debugging flags: Before writing to the authorization file, a node needs to successfully acquire a distributed lock with the project number as the key. After the operation is completed, the lock is released immediately. Waiting nodes can detect the lock release event through Redis's lock listening mechanism and try to acquire it, thereby ensuring that only one node performs the critical write operation at any given time.

[0105] II. Strict Activation Control Mechanism for Operational Functions; To achieve the strict activation control mechanism for the aforementioned operational functions, the following measures are mainly adopted: 1. Machine Code Binding Verification: Machine code binding verification strategies can be adopted under three deployment modes to ensure strict activation control of operational functions. In single-machine mode, the motherboard serial number and hard drive serial number are bound simultaneously. The authorization code is uniquely anchored to the target device through dual hardware identification, preventing the authorization code from being copied to other physical machines. In master-slave mode, machine code verification is supported in master-slave node switching scenarios, allowing the authorization code to be shared between the master and slave devices. When the master node fails and triggers a switchover, the slave node can perform joint verification based on the pre-stored master machine code and its own machine code and pass the activation, ensuring the continuity of authorization under the high-availability architecture. In cluster mode, a list containing the machine codes of all online nodes is maintained, and each node is verified one by one to see if its machine code matches the binding information in the authorization code, ensuring that any node in the cluster obtains legal authorization and achieving consistent authorization management across nodes. This multi-mode adaptable binding mechanism enables the authorization system to flexibly cover various scenarios in the power industry, from single-device to cluster deployment, while maintaining hardware-level binding strength. 2. Encrypted Storage Protection: Authorized files can be stored using a symmetric encryption algorithm. The encryption key is periodically pushed from the authorization center to the security key area of ​​the target power anti-misoperation system. CBC mode and random initialization vector are used to enhance anti-cracking capabilities. At the same time, the system adds an HMAC-SHA256 digital signature to each authorized file. The signature key and encryption key are managed separately. When loading an authorized file, the field deployment terminal 200 first verifies the validity of the signature to ensure that the file has not been tampered with or forged. To further enhance security, a key update schedule can be preset to automatically trigger the encryption key rotation at a preset cycle (e.g., every 30 days). After the new key is distributed through a secure channel, the old key is securely destroyed after confirming that all files to be updated have been re-encrypted, preventing the risk of leakage due to long-term key use and forming a dynamically evolving closed loop for key lifecycle management. 3. Fine-grained permission control: Fine-grained permission control achieves precise authorization scope definition through three dimensions: module level, site level, and concurrency level. Authorization scope is divided according to product modules. The product authorization module field in the authorization code uses a bitmap mechanism to mark the activation status of each functional module. After parsing by the on-site deployment terminal 200, only modules with a bit value of 1 are activated, and interface access to unauthorized modules is closed, achieving on-demand authorization at the functional level. It supports site number limits; the maximum number of allowed sites can be configured in the authorization information code segment. When the on-site deployment terminal 200 receives a new node registration request, it counts the number of online sites in real time. If the limit is reached, the new node access is rejected to prevent the authorization scope from expanding outwards. It controls the number of concurrent accesses by limiting the number of concurrent sessions under the same authorization through a token bucket or counter algorithm. When concurrent requests exceed the threshold, subsequent requests are blocked, ensuring that resources are reasonably allocated within the authorized scope.This hierarchical control system enables authorization strategies to precisely match the actual needs of power engineering projects, avoiding over-authorization and resource abuse. 4. Dynamic Permission Verification: Authorization checks are integrated into the entire request processing lifecycle, ensuring continuous control over runtime functions. Upon receiving a business function call request, the validity of the authorization code is verified in real time, checking the authorization period, functional module bitmap, and machine code binding status. Authorization changes can be detected instantly without restarting. Restricted interfaces are intercepted and access denied. Through Aspect-Oriented Programming (AOP) or API gateway mechanisms, unauthorized functional interface calls are intercepted before the request enters the business logic, directly returning a rejection response code and recording it in the audit log. A permission query interface can also be provided for business modules to call. Before processing sensitive operations, business modules can proactively call this interface to query the authorization status of the current session and dynamically adjust the business logic based on the returned results, achieving loose coupling between the authorization strategy and the business logic.

[0106] III. Security Mechanism for Binding Authorization Codes to System Environment Information and Power Engineering Project Information; The aforementioned security mechanism for binding authorization codes to system environment information and power engineering project information aims to establish a unique correspondence between authorization codes and target power anti-misoperation systems and engineering projects in an offline environment, achieving anti-copying, anti-reuse, and traceability of authorization capabilities. This mechanism uses the work order management system as a link, binding the commissioning personnel's identity, engineering project tasks, and the target power anti-misoperation system hardware identifier in a three-element binding, ensuring that authorization behavior is strictly limited to the implementation boundaries of a specific engineering project. During the project initiation phase, the authorization center (100) receives work orders dispatched by the OA system through the work order management system. These work orders uniquely identify the engineering project to be implemented and contain power engineering project information, with data content covering at least core parameters such as the authorization module, authorization time, and authorization mode. As the starting credential for the authorization process, the work order strongly associates the commissioning personnel's identity with the power engineering project information, providing task context for subsequent authorization requests and ensuring the traceability of the authorization request source. The target power system for preventing errors is deployed at the field deployment terminal 200. Its system environment information is automatically collected and generated by calling the local system interface, including feature vectors that uniquely represent the operating environment, such as server type, motherboard UUID, hard drive serial number, product version, and deployment identifier. After collection, the target power system for preventing errors encodes the system environment information into a QR code image. The user terminal 300 calls the work order management system to scan the QR code to obtain the system environment information and power engineering project information, and sends it to the authorization center terminal 100 through a secure channel. This QR code transmission mechanism avoids the risks of information leakage and input errors caused by traditional USB flash drive copying or manual transcription, and achieves secure one-way output of system environment information in a physically isolated offline environment. After receiving the system environment information and power engineering project information, the authorization center terminal 100 uses a cryptographic encoding protocol to structurally integrate the two with the authorization list to generate original authorization data. The original authorization data is then encoded and converted to form encoded data, and a digest operation is performed on the machine code and the original authorization data to generate a check code. Based on the checksum, machine code, and encoded data, the final authorization code is generated after encryption. The authorization center generates a segmented authorization code, where the machine code segment directly embeds the hardware identifier from the system environment information, and the authorization information segment contains a digest of the power engineering project information. This cryptographically binds the authorization code to the target power system's error prevention system and the project, ensuring the authorization code cannot function independently of the bound hardware environment or project. After generation, the user can manually enter the authorization code into the target power system's error prevention system to complete activation. During activation, the target power system verifies the consistency between the currently collected system environment information and the machine information contained in the authorization code. If the verification passes, the authorization is deemed valid, and system activation is completed.After system activation, the work order management system associates and stores the authorization code, system environment information, and power engineering project information, and updates the work order status corresponding to the current project to "completed." This establishes a one-to-one correspondence between the authorization code, the target power anti-misoperation system, and the engineering project within the work order management system. When a new authorization request for the target power anti-misoperation system is initiated, the authorization center 100 verifies the system environment information based on the stored correspondence in the work order management system. If the system environment information is detected to be associated with other engineering projects, the authorization request is rejected, forming a cross-project, cross-system authorization diffusion protection mechanism. This ensures a strong binding between authorization capabilities and specific engineering projects and the hardware of the target power anti-misoperation system, preventing the authorization code from being illegally copied or reused.

[0107] Figure 3 This is a schematic diagram of an electronic device provided in an embodiment of this application. (Refer to...) Figure 3Electronic device 400 includes a processor 410, a memory 420, and a communication interface 430. These components are interconnected and communicate with each other via a communication bus 440 and / or other forms of connection mechanisms (not shown). The memory 420 includes one or more (only one is shown in the figure), which may be, but is not limited to, Random Access Memory (RAM), Read-Only Memory (ROM), Programmable Read-Only Memory (PROM), Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), etc. The processor 410 and other possible components can access, read, and / or write data to the memory 420. The processor 410 includes one or more (only one is shown in the figure), which may be an integrated circuit chip with signal processing capabilities. The processor 410 mentioned above can be a general-purpose processor, including a Central Processing Unit (CPU), a Microcontroller Unit (MCU), a Network Processor (NP), or other conventional processors; it can also be a special-purpose processor, including a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The communication interface 430 includes one or more (only one is shown in the figure), which can be used to communicate directly or indirectly with other devices to exchange data. For example, the communication interface 430 can be an Ethernet interface; it can be a mobile communication network interface, such as an interface for 3G, 4G, or 5G networks; or it can be other types of interfaces with data transmission and reception functions.One or more computer program instructions can be stored in the memory 420. The processor 410 can read and execute these computer program instructions to implement the power anti-misoperation software licensing method applied to the authorization center 100, the power anti-misoperation software licensing method applied to the field deployment terminal 200, or the power anti-misoperation software licensing method applied to the user terminal 300, and other desired functions provided in this application embodiment. It is understood that... Figure 3 The structure shown is for illustrative purposes only; the electronic device 400 may also include more than [other components]. Figure 3 The more or fewer components shown, or having the same Figure 3 The different configurations shown. Figure 3 The components shown can be implemented using hardware, software, or a combination thereof. For example, electronic device 400 can be a single server (or other device with computing power), a combination of multiple servers, a cluster of a large number of servers, etc., and can be either a physical device or a virtual device. This application embodiment also provides a computer-readable storage medium storing computer program instructions. These computer program instructions are read and executed by a processor to perform the power anti-misoperation software authorization method provided in this application embodiment, applicable to the authorization center 100, the power anti-misoperation software authorization method applied to the field deployment 200, or the power anti-misoperation software authorization method applied to the user terminal 300. For example, the computer-readable storage medium can be implemented as... Figure 3 The memory 420 in the electronic device 400, or a separate storage product (such as a USB flash drive, portable hard drive, etc.). This application embodiment also provides a computer program product, which includes computer program instructions. These computer program instructions are read and executed by a processor to perform the power anti-misoperation software authorization method provided in this application embodiment, applicable to the authorization center 100, the power anti-misoperation software authorization method applied to the field deployment 200, or the power anti-misoperation software authorization method applied to the user terminal 300. For example, these computer program instructions can be stored in... Figure 3 The memory 420 in the electronic device 400 is located inside the memory, or it is stored in a separate storage product (such as a USB flash drive, portable hard drive, etc.).

[0108] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for licensing power system anti-misoperation software, characterized in that, A power system error prevention software licensing system for offline deployment, the licensing system including an authorization center, the method comprising: The authorization center receives a function list, project configuration, debugging requirements, and system environment information of the target power anti-misoperation system; wherein, the system environment information includes machine code; The authorization center generates an authorization list based on the function list, the project configuration, and the debugging requirements; wherein, the authorization list includes the product version, functional modules, and authorization period; The authorization center encodes the system environment information, power engineering project information, and authorization list to generate original authorization data. The authorization center performs encoding conversion on the original authorization data to form encoded data, and performs digest operation on the machine code and the original authorization data to generate a check code; The authorization center generates a segmented authorization code based on the checksum, the machine code, and the encoded data, and then generates the final authorization code after encryption. The segmented authorization code is used to provide a unified authorization model. The segmented authorization code includes a checksum segment, a machine code segment, and an authorization information segment.

2. The power system anti-misoperation software licensing method according to claim 1, characterized in that, The verification code segment includes a verification bit, an authorization code type field, and an authorization code version field; wherein, the authorization code type field is used to identify function authorization, debugging authorization, personal authorization, APP authorization, or restoration authorization; The machine code segment includes a server type field, a motherboard identifier field, and a hard disk serial number identifier field; The authorization information code segment includes the authorization creation time field, authorization start and end time field, product list length field, product code list field, product authorization file version field, product authorization module length field, and product authorization module field.

3. The power system anti-misoperation software licensing method according to claim 1, characterized in that, The generation of the authorization list based on the function list, the project configuration, and the debugging requirements includes: Parse the function list and the project configuration to obtain the association between software version, product code, function module, menu code and API path; The debugging mode of the authorized list is determined based on the aforementioned debugging requirements; The software version, product code, functional module, menu code, API path, and debugging mode are arranged and encrypted to generate the authorization list; The authorization list is written into the target power misoperation prevention system, and the functional module information is synchronized to the collaborative office system.

4. The power grid anti-misoperation software licensing method according to claim 1, characterized in that, The method further includes: After activating the target power error prevention system using the authorization code, the authorization center stores the authorization code, the system environment information, and the power engineering project information in the work order management system, and updates the work order status corresponding to the current engineering project to the completed status, so as to establish a one-to-one correspondence between the authorization code, the target power error prevention system, and the engineering project. When the authorization request for the target power anti-misoperation system is initiated again, the authorization center verifies the system environment information based on the corresponding relationship stored in the work order management system. If the system environment information is associated with other engineering projects, the authorization request is rejected.

5. The power system anti-misoperation software licensing method according to claim 1, characterized in that, The authorization system also includes a field deployment terminal, and the method further includes: After receiving the authorization code, the on-site deployment terminal performs the following multi-level verification: Perform authenticity verification to confirm the integrity of the authorization code; Perform system binding verification to compare the consistency between the machine code and the current system environment information; The power engineering information is verified based on the binding relationship between the system environment information and the power engineering project information stored in the work order management system. If the system environment information is already associated with other engineering projects, the authorization code is rejected. Perform authorization scope verification to confirm the validity of the product version, the functional modules, and the authorization period; If all the above checks pass, the corresponding debugging function or business module will be dynamically enabled based on the authorization code type field; otherwise, the authorization code will be rejected.

6. The power grid anti-misoperation software licensing method according to claim 5, characterized in that, The dynamic activation of corresponding debugging functions or business modules includes: The on-site deployment terminal determines the authorization strategy based on the authorization code type field. When the authorization code type is a function authorization, the product function module corresponding to the authorization information code segment is activated. When the authorization code type is a debug authorization, the debug function is enabled on the basis of the function authorization activation, and the effective time window of the debug function is controlled according to the authorization creation time field and the authorization start and end time field. The on-site deployment terminal encrypts and stores the enabled functional modules, and verifies the validity of the authorization code in real time when it receives a function call request, and intercepts unauthorized functional interfaces.

7. The power system anti-misoperation software licensing method according to claim 6, characterized in that, The encrypted storage of enabled functional modules includes: The license files are encrypted using encryption algorithms and digitally signed, and the license files are updated regularly to refresh the valid time window for each license type; In cluster deployment mode, authorization status changes are broadcast via Redis messaging and authorization file updates are protected using distributed locks.

8. The power grid anti-misoperation software licensing method according to claim 5, characterized in that, The method further includes: Receive a new authorization code; wherein the new authorization code is generated based on the changed functional requirements; Parse the new authorization code to obtain the latest authorization information, which includes a list of product function modules, authorization code type, and authorization period. Replace the old authorization status stored locally with the latest authorization information, activate the corresponding module according to the product function module list, and reclaim the module that is not in the product function module list; When the authorization code type in the latest authorization information is a function authorization, the field deployment terminal enters the initial debugging state according to the preset configuration strategy; wherein, the initial debugging state grants initial debugging permissions within a preset initial debugging time window; After the initial debugging time window expires, the field deployment terminal closes the initial debugging privileges.

9. The power system anti-misoperation software licensing method according to claim 1 or 5, characterized in that, The authorization system also includes a user terminal, and the method further includes: The user terminal receives a work order; wherein the work order is used to uniquely identify the engineering project to be implemented and contains information about the power engineering project; The user terminal calls the work order management system to scan the QR code generated by the target power error prevention system to obtain the system environment information and the power engineering project information; wherein, the QR code is generated by the target power error prevention system after calling the local interface to collect machine information and product version information; The user terminal sends the system environment information and the power engineering project information to the authorization center terminal; The user terminal receives the authorization code returned by the authorization center.

10. A power grid anti-misoperation software licensing system, characterized in that, include: The authorization center receives a function list, project configuration, debugging requirements, and system environment information of the target power anti-misoperation system. The system environment information includes machine code. An authorization list is generated based on the function list, project configuration, and debugging requirements. This authorization list includes product version, functional modules, and authorization period. The system environment information, power engineering project information, and the authorization list are encoded to generate original authorization data. The original authorization data undergoes encoding conversion to form encoded data. A digest operation is performed on the machine code and the original authorization data to generate a checksum. Based on the checksum, the machine code, and the encoded data, a segmented authorization code is generated, which is then encrypted to generate the final authorization code. The segmented authorization code provides a unified authorization model and includes a checksum segment, a machine code segment, and an authorization information segment. The on-site deployment terminal, upon receiving the authorization code, performs the following multi-level verifications: Authenticity verification to confirm the integrity of the authorization code; system binding verification to compare the machine code with the current system environment information; power engineering information verification based on the binding relationship between the system environment information and the power engineering project information stored in the work order management system; if the system environment information is already associated with other engineering projects, the authorization code is rejected; authorization scope verification to confirm the validity of the product version, the functional module, and the authorization period; if all the above verifications pass, the corresponding debugging function or business module is dynamically enabled according to the authorization code type field; otherwise, the authorization code is rejected. The user terminal is used to receive work orders; wherein the work order uniquely identifies the engineering project to be implemented and contains the power engineering project information; it calls the work order management system to scan the QR code generated by the target power anti-misoperation system to obtain the system environment information and the power engineering project information; wherein the QR code is generated by the target power anti-misoperation system after calling a local interface to collect machine information and product version information; it sends the system environment information and the power engineering project information to the authorization center terminal; and it receives the authorization code returned by the authorization center terminal.

Images