Machine authority management method and system based on customer independent decision-making mechanism

Abstract

The present invention provides a machine authority management method based on a customer autonomous decision-making mechanism. First, the current account authority configuration set of the target machine is obtained. The current account authority configuration set contains multiple authority level nodes and corresponding operation range identifiers, associated account identifiers and verification features. Then, the authority features are extracted to obtain the hierarchical constraint features and operation behavior features of each authority level node. The hierarchical constraint features include the correlation strength parameters of the upper and lower authority nodes. Based on a preset autonomous decision-making model, a dynamic decision node set representing the authority change trigger conditions and verification paths is generated. The authority verification model is called to perform multi-dimensional matching processing on the relevant features and node sets to generate the authority change verification results. The current account authority configuration set is updated accordingly. Finally, the updated configuration set is synchronized to the target machine operation control module to make the authority take effect, thereby realizing flexible and intelligent machine authority management.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a machine authority management method and system based on a customer autonomous decision-making mechanism. Background Art

[0002] In the current development of industrial automation and intelligentization, machine device permission management has become a critical component in ensuring secure and stable system operation. Traditional machine permission management methods often rely on pre-set, fixed permission configurations. Once these configurations are set, they are difficult to flexibly adjust to meet actual needs. As production environments become increasingly complex and dynamic, this static permission management model has gradually exposed many drawbacks.

[0003] On the one hand, traditional methods lack the ability to deeply analyze and dynamically adjust the hierarchical relationships between nodes at different permission levels. In practice, accounts with different permission levels often need to perform operations within different scopes. Traditional methods only provide simple permission divisions and are unable to accurately describe and quantify the strength of the relationships between permission nodes. This results in less refined permission configuration and makes it difficult to meet complex and changing business needs.

[0004] On the other hand, traditional methods lack intelligent decision-making support when changing permissions. Permission changes typically involve comprehensive consideration of multiple factors, such as the rationality of the operation and the urgency of the permission change. Traditional methods often rely on manual experience and subjective judgment, lacking scientific and objective decision-making basis, which can easily lead to errors or delays in permission changes. Summary of the Invention

[0005] In view of the above-mentioned problems, in combination with the first aspect of the present invention, an embodiment of the present invention provides a machine authority management method based on a customer autonomous decision-making mechanism, the method comprising:

[0006] Obtaining a current account permission configuration set for the target machine, wherein the current account permission configuration set includes multiple permission level nodes and their corresponding operation range identifiers, each permission level node being associated with at least one account identifier and its verification feature;

[0007] Performing permission feature extraction processing on the current account permission configuration set to obtain hierarchical constraint features and operation behavior features of each permission level node, wherein the hierarchical constraint features include association strength parameters of upper and lower level permission nodes;

[0008] Generate a dynamic decision node set of the permission level node based on a preset autonomous decision model, wherein the dynamic decision node set is used to represent the triggering conditions and associated verification paths of the permission change operation;

[0009] Calling the permission verification model to perform multi-dimensional matching processing on the hierarchical constraint characteristics, operation behavior characteristics, and dynamic decision node set, generating a permission change verification result, and updating the current account permission configuration set according to the permission change verification result;

[0010] Synchronize the updated account permission configuration set to the operation control module of the target machine to trigger the permission validation operation.

[0011] On the other hand, an embodiment of the present invention also provides a rights management system, including a processor and a machine-readable storage medium, wherein the machine-readable storage medium is connected to the processor, the machine-readable storage medium is used to store programs, instructions or codes, and the processor is used to execute the programs, instructions or codes in the machine-readable storage medium to implement the above method.

[0012] Based on the above aspects, the embodiments of the present invention achieve intelligent and dynamic machine permission management, significantly improving the flexibility and security of permission management. Specifically, by obtaining the current account permission configuration set of the target machine and performing permission feature extraction processing on it, the hierarchical constraint characteristics and operational behavior characteristics of each permission level node can be accurately identified, providing a solid data foundation for subsequent permission change decisions. Furthermore, based on a preset autonomous decision-making model, a dynamic decision node set is generated. This set not only represents the triggering conditions for the permission change operation but also clarifies the associated verification path, ensuring that the permission change decision-making process both complies with preset rules and flexibly adapts to actual business needs. During the permission change verification phase, by invoking the permission verification model to perform multi-dimensional matching processing on the hierarchical constraint characteristics, operational behavior characteristics, and the dynamic decision node set, the rationality and security of the permission change can be comprehensively and accurately assessed, thereby generating a reliable permission change verification result. The current account permission configuration set is updated based on this verification result, ensuring the real-time and accuracy of the permission configuration. Finally, the updated account permission configuration set is synchronized with the target machine's operation control module, which can quickly trigger the permission validation operation, ensuring that the permission change is immediately reflected in the actual operation of the machine. As a result, not only the automation level of permission management is improved and the risk of human intervention is reduced, but also the flexibility and adaptability of permission management are enhanced through the dynamic decision-making mechanism. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Figure 1 It is a schematic diagram of the execution flow of the machine authority management method based on the customer autonomous decision-making mechanism provided by an embodiment of the present invention.

[0014] Figure 2 FIG. 4 is a schematic diagram of exemplary hardware and software components of a rights management system provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0015] The present invention will be described in detail below with reference to the accompanying drawings. Figure 1 This is a flow chart of a method for managing machine rights based on a customer autonomous decision-making mechanism provided by an embodiment of the present invention. The method for managing machine rights based on a customer autonomous decision-making mechanism is introduced in detail below.

[0016] Step S110 , obtaining the current account permission configuration set of the target machine, wherein the current account permission configuration set includes a plurality of permission level nodes and their corresponding operation range identifiers, and each permission level node is associated with at least one account identifier and its verification feature.

[0017] For example, in an automated production factory, there are multiple production equipment as target machines, and the target machines are responsible for the production of different products. In order to ensure safe and efficient production, a strict permission management system needs to be set up for the accounts that operate the above machines.

[0018] Specifically, permission levels can be categorized as basic operation permission nodes, intermediate management permission nodes, and advanced decision-making permission nodes. Basic operation permission nodes, such as A1, have a corresponding scope of operation that limits them to basic operations such as daily equipment startup and shutdown and simple parameter settings. Account identifiers associated with A1 include Z1 and Z2. Z1 accounts are authenticated through a combination of fingerprint and password, while Z2 accounts are authenticated through facial recognition and dynamic passwords. Intermediate management permission nodes, such as A2, have a scope of operation that covers management operations such as adjusting production plans and scheduling equipment maintenance tasks. Associated account identifiers include Y1 and Y2. Y1 accounts are authenticated through digital certificates and SMS verification codes, while Y2 accounts are authenticated through hardware tokens and passwords. Advanced decision-making permission nodes, such as A3, have a scope of operation that covers advanced operations such as formulating production strategies and making decisions about major equipment upgrades. Associated account identifiers include X1 and X2. X1 accounts are authenticated through multi-factor biometrics (including iris recognition, fingerprint recognition, and facial recognition) and one-time passwords, while X2 accounts are authenticated through complex encryption keys and dynamic passwords.

[0019] Step S120 , performing permission feature extraction processing on the current account permission configuration set to obtain hierarchical constraint features and operation behavior features of each permission level node, wherein the hierarchical constraint features include association strength parameters of upper and lower level permission nodes.

[0020] In this embodiment, the configuration parameters of the permission level nodes can first be parsed. Specifically, taking the basic operation permission node A1 as an example, its node depth is extracted as level 1, with three peer nodes (A1, A11, and A12). The reference path of the parent node points to the intermediate management permission node A2. This constructs an initial hierarchical topology, which exhibits a tree-like relationship. From the high-level decision-making permission node A3 as the root node, branches extend downward, including the intermediate management permission node A2. The intermediate management permission nodes then branch out to the basic operation permission nodes.

[0021] Next, a bidirectional traversal is performed on the initial hierarchical topology. For example, starting from node A1 and traversing forward to the parent node A2, the calculated predecessor dependency weight is 0.6, indicating that A1's dependence on A2 is 60%, because some operations of A1 require A2's authorization. Traversing backward to the subordinate nodes that it may affect (assuming A1 has an indirect subordinate node A13), the calculated successor influence weight is 0.3, indicating that A1's influence on A13 is 30%. Based on the ratio of the predecessor dependency weight to the successor influence weight (0.6 ÷ 0.3 = 2), the hierarchical constraint strength value is generated.

[0022] Next, the historical operation record set corresponding to the operation scope identifier is traversed. Taking node A1 as an example, within the past week (preset time window), the basic operations covered by its operation scope identifier had a trigger frequency of 50 for device startup, 45 for device shutdown, and 30 for simple parameter setting. Associated account identifier Z1 triggered the device startup operation 20 times, Z2 30 times, and so on. After counting this data, an operation frequency distribution matrix is ​​generated. This matrix uses operation type as rows and account identifier as columns, recording the trigger frequency of each account for different operations.

[0023] Next, the operation frequency distribution matrix is ​​aligned to its time series. Taking each hour as a time window, the gradient of operation pattern changes between adjacent time windows is observed. For example, between 9:00 AM and 10:00 AM, the frequency of device startup operations increases from 3 to 5, while the frequency of simple parameter setting operations decreases from 2 to 1. Combined with the previously generated hierarchical constraint strength value of 2, a composite operation behavior signature is generated. This composite operation behavior signature comprehensively reflects the temporal variation patterns of operations and their characteristics within the hierarchical structure.

[0024] Finally, the hierarchical constraint strength value 2 is standardized and concatenated with the composite operational behavior characteristics. The hierarchical constraint strength value is scaled to the same numerical range as the composite operational behavior characteristics and then concatenated together to obtain a permission level feature vector that includes both the time and topological dimensions. This vector serves as a joint representation of the hierarchical constraint characteristics and operational behavior characteristics. This permission level feature vector can describe the constraint relationships and operational behavior characteristics of the A1 permission level node in the hierarchical structure.

[0025] Step S130 : generating a dynamic decision node set of the permission level node based on a preset autonomous decision model, wherein the dynamic decision node set is used to represent the triggering conditions and associated verification paths of the permission change operation.

[0026] In this embodiment, the permission level feature vector can be input into the first feature encoding layer of the autonomous decision-making model. For example, taking the permission level feature vector generated by node A1 as an example, this permission level feature vector contains information such as the hierarchical constraint strength value and operation frequency distribution. The first feature encoding layer processes this information to generate an implicit state sequence containing the permission hierarchy relationship. This implicit state sequence is an encrypted information package that contains key information such as node A1's position in the entire permission system and its operational characteristics.

[0027] Then, the implicit state sequence is segmented using a sliding window. Assuming the sliding window size is 5 time steps, and moving 1 time step at a time, multiple local state segments are obtained. For example, the first local state segment contains information from the 1st time step to the 5th time step. The semantic coherence between adjacent local state segments is calculated. For example, by comparing the similarity of the first and second local state segments regarding information such as permission levels and operational behaviors, the semantic coherence is calculated to be 0.7.

[0028] Next, a state transition probability graph is constructed based on semantic coherence. In this state transition probability graph, each local state segment serves as a node, and the edges between nodes represent state transitions. The weight of the edges is the semantic coherence. For example, the weight of the edge from the first local state segment to the second local state segment is 0.7. In the state transition probability graph, critical transition paths that meet preset conditions are identified. The preset conditions can be that the semantic coherence is greater than 0.6 and involves specific changes in permission operations. For example, a critical transition path is identified, from a local state segment representing a stable state of basic operation permissions to a local state segment representing a possible need for permission upgrades. The decision dependencies between the path nodes in the critical transition path are extracted. In this critical transition path, it is found that the decision of the subsequent node depends on the sudden increase in the frequency of operations in the previous node and the change in the hierarchical constraint relationship.

[0029] Then, based on the decision dependencies, a dynamic decision template is generated, including a conditional trigger threshold and a verification path length. For example, the conditional trigger threshold is set to trigger a permission change when the device startup operation frequency exceeds 20 times within three consecutive hours (based on previous operation data and analysis) and the hierarchical constraint strength value changes by more than 0.2. The verification path length is set to require three different verification steps (such as account and password verification, superior permission confirmation, and security audit check).

[0030] Next, the matching degree between the dynamic decision template and the operation scope identifier of the permission level node is calculated. The condition trigger threshold in the dynamic decision template is parsed and converted into a feature vector of the same dimension as the operation scope identifier. For example, information such as the device startup operation frequency threshold of 20 times and the level constraint strength value change threshold of 0.2 are converted into a feature vector. From this, the cosine similarity between this feature vector and the operation frequency distribution matrix corresponding to the operation scope identifier can be calculated. For example, the cosine similarity calculated is 0.6. Dynamic calibration of the cosine similarity is performed based on the update frequency of the current account permission configuration set. The current account permission configuration set has been updated five times in the past month. Based on this update frequency and relevant rules, the time stamp interval sequence of adjacent versions and the number of change operation types between corresponding versions are extracted from the historical version records. A dynamic calibration weight is generated by analyzing the fluctuation of the time stamp interval sequence and the distribution density of the number of change operation types. Assume that the generated dynamic calibration weight is 0.8. The dynamic calibration weight is weighted and superimposed with the cosine similarity, 0.8 × 0.6 = 0.48, to generate the transition similarity value after superposition. The transition similarity value is normalized and truncated. Assuming the preset value range is 0 to 1, 0.48 is retained within the preset value range to obtain a valid similarity segment. The mean (here is 0.48) and variance (assuming it is 0.05) of the valid similarity segment are mapped to the dimensional space of the dynamic decision template to generate a calibrated similarity value. If the calibrated similarity value exceeds the preset matching threshold (assuming it is 0.4), it is determined to be a valid match, and the valid matching template and its corresponding permission change operation type are recorded to form a mapping relationship table between dynamic decision nodes and operation ranges. For example, when the above conditions are met to trigger the threshold, it is recorded that the corresponding permission change operation type is upgraded from basic operation permissions to intermediate management permissions.

[0031] Step S140 , calling the permission verification model to perform multi-dimensional matching processing on the hierarchical constraint features, operation behavior features and dynamic decision node set, generating a permission change verification result, and updating the current account permission configuration set according to the permission change verification result.

[0032] In this embodiment, the hierarchical constraint feature can be compared with the conditional trigger threshold in the dynamic decision node set. Still taking node A1 as an example, the hierarchical constraint strength value in the hierarchical constraint feature is 2, and the conditional trigger threshold in the dynamic decision node set involves a change in the hierarchical constraint strength value exceeding 0.2. If the change in the current hierarchical constraint strength value is within the allowable range, a hierarchical compliance score is generated. Assuming that the scoring criteria is 1 to 10 according to the rules, and since the conditions are met, a hierarchical compliance score of 8 is given.

[0033] Next, we can extract the operating mode change gradient from the operational behavior signature and perform time alignment with the verification path length in the dynamic decision node set. In the operational behavior signature, the device startup operating mode has a recent gradient of 0.5 startup operations per hour. The verification path length in the dynamic decision node set is set to three verification steps. By analyzing the relationship between the operating mode change gradient and the verification path length, we can calculate the operating mode offset. Assume that, based on a specific calculation method, the operating mode offset is 0.2.

[0034] Next, a two-dimensional verification space can be constructed based on a hierarchical compliance score of 8 and an operating mode offset of 0.2. In this two-dimensional verification space, the horizontal axis represents the hierarchical compliance score, and the vertical axis represents the operating mode offset. The boundaries of the feasible region for the permission change operation are determined. For example, according to security policy rules, the feasible region can be set when the hierarchical compliance score is greater than 6 and the operating mode offset is less than 0.5. For example, if the current data meets this condition, it falls within the feasible region.

[0035] Next, an overlap analysis is performed based on the boundaries of the feasible region and the preset security policy rules. The preset security policy rules specify a series of conditions and restrictions for permission changes. Because the current permission change operation falls within the feasible region, the overlap area with the security policy rules exceeds the preset threshold (assuming the preset threshold is 0.6 and the actual overlap area is calculated to be 0.8), a positive verification result is generated.

[0036] Finally, the forward verification results can be bound to the corresponding dynamic decision nodes to generate a permission change verification result set with time stamps. For example, if the permission change operation (from basic operation permissions to intermediate management permissions) of node A1 passes verification at the current time, a permission change verification result set with time stamps can be generated.

[0037] In step S150 , the updated account permission configuration set is synchronized to the operation control module of the target machine to trigger the permission validation operation.

[0038] In this embodiment, the positive verification results in the permission change verification result set can be parsed to extract the permission change operation type and target permission level node corresponding to the dynamic decision node bound to the positive verification result. For example, from the permission change verification result set with time series marks, it can be known that the permission change operation type is an upgrade from basic operation permissions to intermediate management permissions, and the target permission level node is A1.

[0039] Perform a topological impact analysis on the target permission level node A1 and calculate the cascading impact parameters of the change operation on upstream and downstream nodes. For example, obtain the reference path set of node A1's immediate superior node A2 and immediate subordinate node A13. Traverse each node in the reference path set and use the hierarchical constraint strength value in the hierarchical constraint feature to calculate the dependency decay coefficient between the nodes. For example, if the hierarchical constraint strength between A1 and A2 is 2, assume that the dependency decay coefficient is 0.5 by setting calculation rules. A propagation impact model is constructed based on the dependency decay coefficient to simulate the propagation path and intensity decay curve of the permission change operation in the topology. Assume that the simulated intensity decay curve shows that the impact of the permission change operation on node A2 gradually decreases during the propagation process. Integrate the intensity decay curve to obtain the cumulative impact value of the change operation on each upstream and downstream node. For example, the cumulative impact value on node A2 is 0.3, and the cumulative impact value on node A13 is 0.1. The cumulative impact value is weighted and summed with the node's current operational behavior characteristics to generate a cascading impact parameter that reflects topological stability. Assuming that the current operation behavior feature weight of node A2 is 0.6 and the current operation behavior feature weight of node A13 is 0.4, the calculated cascade impact parameter is 0.3×0.6+0.1×0.4=0.22.

[0040] Since the cascading impact parameter of 0.22 is less than the preset fault tolerance threshold (assuming the preset fault tolerance threshold is 0.3), the configuration parameters of the target permission level node A1 are directly updated. The permission level of node A1 is updated from basic operation permission to intermediate management permission, and the associated operation scope identifier, account identifier, and verification characteristics are also updated.

[0041] Write the updated permission level node and its associated hierarchical constraint features to the current account permission configuration set, and generate a version iteration log for rollback operations. For example, in the current account permission configuration set, modify the relevant information of the A1 node, and record the updated version number, update time, update content, etc. in the version iteration log.

[0042] Finally, the updated account permission configuration set is synchronized to the target machine's operation control module to trigger the permission validation operation. The updated account permission configuration set is sent to the target machine's operation control module via network transmission or other means. After receiving the updated configuration set, the operation control module allows the associated accounts (such as Z1, Z2, etc.) to perform operations within the scope of intermediate management permissions according to the new permission settings, thereby triggering the permission validation operation and completing the entire permission change and validation process.

[0043] Based on the above steps, the present invention implements intelligent and dynamic machine permission management, significantly enhancing its flexibility and security. Specifically, by obtaining the target machine's current account permission configuration set and performing permission feature extraction processing on it, the hierarchical constraint features and operational behavior characteristics of each permission level node can be accurately identified. Furthermore, a dynamic decision node set is generated based on a preset autonomous decision model. This set not only represents the triggering conditions for permission change operations but also clarifies the associated verification path, ensuring that the permission change decision-making process both complies with preset rules and flexibly adapts to actual business needs. During the permission change verification phase, the permission verification model is invoked to perform multi-dimensional matching processing on the hierarchical constraint features, operational behavior characteristics, and the dynamic decision node set. This allows for a comprehensive and accurate assessment of the rationality and security of the permission change, thereby generating a reliable permission change verification result. Based on this verification result, the current account permission configuration set is updated, ensuring the real-time and accuracy of the permission configuration. Finally, the updated account permission configuration set is synchronized with the target machine's operation control module, rapidly triggering the permission validation operation and ensuring that the permission change is immediately reflected in the machine's actual operation. As a result, not only the automation level of permission management is improved and the risk of human intervention is reduced, but also the flexibility and adaptability of permission management are enhanced through the dynamic decision-making mechanism.

[0044] In a possible implementation, step S120 includes:

[0045] Step S121 , parsing the configuration parameters of the permission level nodes, extracting the node depth identifier, the number of peer nodes and the reference path of the upper node, and constructing an initial hierarchical topology structure.

[0046] For example, in the authority system of the above-mentioned factory, taking a permission level node named "Equipment Parameter Adjustment" as an example, it can be clearly extracted from its configuration parameters that the node depth is identified as the second level, which indicates that it is in the middle position in the entire authority hierarchy. For example, after statistics, there are 4 nodes at the same level. These 4 nodes are at the same level and have similar but different authority responsibilities. At the same time, it is clear that the reference path of the upper node points to the "Production Management General Control" permission level node, thereby establishing an association between this node and higher-level permissions. Based on the above information, an initial hierarchical topology is constructed to show the position and interconnected relationship of each permission level node in the entire system.

[0047] Step S122 , performing a bidirectional traversal process on the initial hierarchical topology structure, obtaining the predecessor dependency weight and successor influence weight of each authority level node, and generating a hierarchical constraint strength value based on the ratio of the predecessor dependency weight to the successor influence weight.

[0048] For example, starting from the "Equipment Parameter Adjustment" node, we explore its dependency on the parent "Production Management Control" node. Analyzing past operation data and permission association logic reveals that 70% of key operations on the "Equipment Parameter Adjustment" node require authorization confirmation from the "Production Management Control" node. This results in a predecessor dependency weight of 0.7. We then examine the node's impact on its subordinate nodes. Assuming a subordinate node is the "Specific Equipment Parameter Fine-tuning" node, statistical analysis shows that operations on the "Equipment Parameter Adjustment" node have a 30% chance of directly impacting the operation of the "Specific Equipment Parameter Fine-tuning" node, resulting in a subsequent impact weight of 0.3. Based on the ratio of the predecessor dependency weight to the subsequent impact weight, we calculate 0.7 divided by 0.3 (approximately 2.33), which is the approximate value for the hierarchical constraint strength. This value reflects the relative degree of constraint for the permission-level node within the hierarchy. A larger value indicates a greater influence from the parent node and a relatively smaller influence on the parent node.

[0049] Step S123 , traverse the historical operation record set corresponding to the operation range identifier, count the triggering frequency of each operation type and the number of associated account identifiers within a preset time window, and generate an operation frequency distribution matrix.

[0050] For example, the operation range identification of the "device parameter adjustment" node covers multiple operation types such as "temperature parameter adjustment" and "speed parameter adjustment". Taking the past two weeks as the preset time window, the triggering frequency of each operation type and the number of associated account identifications are counted in detail. For example, the "temperature parameter adjustment" operation was triggered 80 times, and the associated account identifications involved were 5 accounts such as M1, M2, and M3; the "speed parameter adjustment" operation was triggered 60 times, and the associated account identifications involved were 4 accounts such as M2 and M4. Therefore, the above data is organized into an operation frequency distribution matrix, with operation type as row and account identification as column, recording the triggering of different operations by each account, thereby presenting the distribution pattern of the operation.

[0051] Step S124 , performing time series alignment processing on the operation frequency distribution matrix, extracting the operation mode change gradient between adjacent time windows, and generating a composite operation behavior feature in combination with the hierarchical constraint strength value.

[0052] For example, from Monday to Tuesday, the frequency of "temperature parameter adjustment" operations decreased from 30 times per day to 25 times per day, while the frequency of "speed parameter adjustment" operations increased from 20 times per day to 22 times per day. By calculating the magnitude of these changes, the gradient of the operation mode change is obtained. For example, combined with the previously generated hierarchical constraint strength value of 2.33, a composite operation behavior feature is generated. This composite operation behavior feature comprehensively considers the changes in the operation in the time dimension and the constraint relationship in the hierarchical structure, and comprehensively reflects the operation behavior characteristics of the node at this permission level.

[0053] Step S125 , performing standardized splicing on the hierarchical constraint strength value and the composite operation behavior feature to obtain an authority level feature vector including a time dimension and a topology dimension as a joint representation of the hierarchical constraint feature and the operation behavior feature.

[0054] For example, the hierarchical constraint strength value can be scaled to the same numerical range as the composite operational behavior feature according to a set ratio. Assuming the composite operational behavior feature ranges from 0 to 100, the hierarchical constraint strength value of 2.33 can be mapped to this range through calculation. For example, using the formula (2.33 / maximum hierarchical constraint strength value) × 100 (assuming the maximum hierarchical constraint strength value is 5), the result is approximately 46.6. This value is then concatenated with the composite operational behavior feature to obtain a permission level feature vector that includes both the temporal and topological dimensions, serving as a joint representation of the hierarchical constraint feature and the operational behavior feature.

[0055] In a possible implementation, step S130 includes:

[0056] Step S131: input the permission level feature vector into the first feature coding layer of the autonomous decision-making model to generate an implicit state sequence containing the permission hierarchy relationship.

[0057] For example, the generated permission level feature vector can be input into the first feature encoding layer of the autonomous decision-making model. Taking the permission level feature vector of the "Device Parameter Adjustment" node as an example, this vector carries a wealth of information about hierarchical constraints and operational behaviors. The first feature encoding layer deeply processes this information, acting like an intelligent information processing plant, converting the input vector into an implicit state sequence containing the permission hierarchy. This implicit state sequence conceals the various potential relationships and characteristics of this node within the entire permission system.

[0058] Step S132 : performing sliding window segmentation processing on the implicit state sequence to obtain a plurality of local state segments, and calculating the semantic coherence between adjacent local state segments.

[0059] For example, set the window size to 4 time steps and move 1 time step each time. In this way, multiple local state fragments are segmented from the implicit state sequence. For example, the first local state fragment contains information from the 1st time step to the 4th time step, and the second local state fragment contains information from the 2nd time step to the 5th time step. Calculate the semantic coherence between adjacent local state fragments. By comparing the similarity of key information such as permission hierarchy and operation behavior in the two local state fragments, a specific algorithm is used for calculation. For example, by comparing the first and second local state fragments, it is found that they have 80% similarity in permission hierarchy information and 70% similarity in operation behavior information. After comprehensive consideration, the semantic coherence is calculated to be 0.75.

[0060] Step S133 , constructing a state transition probability graph based on the semantic coherence, identifying a key transition path that meets preset conditions in the state transition probability graph, and extracting decision dependency relationships between path nodes in the key transition path.

[0061] For example, in this state transition probability graph, each local state segment is a node, and edges between nodes represent state transitions. The edge weights represent semantic coherence. For example, there is an edge from the first local state segment to the second local state segment with a weight of 0.75. Critical transition paths that meet pre-defined conditions are identified in the state transition probability graph. The pre-defined conditions are set as semantic coherence greater than 0.7 and involving specific permission changes. After careful analysis, a critical transition path was discovered, from a local state segment representing routine device parameter adjustment to a local state segment representing a state that may require elevated permissions for more advanced parameter adjustments. Decision dependencies between nodes in this critical transition path were extracted. Within this critical transition path, it was found that the decisions of subsequent nodes depend on changes in the frequency of operations in the previous node and subtle adjustments to the permission hierarchy. For example, when the frequency of operations exceeds a certain threshold and the hierarchical constraints indicate the need for higher permissions, a transition to a new state is triggered.

[0062] Step S134: generating a dynamic decision template including a condition trigger threshold and a verification path length according to the decision dependency relationship.

[0063] For example, the conditional trigger threshold is set to trigger the permission change operation when the frequency of the "temperature parameter adjustment" operation exceeds 60 times within three consecutive days, and the hierarchical constraint relationship shows that the correlation strength with the parent node changes by more than 0.2. The verification path length is set to require four different verification steps, including account password verification, operation record review, parent permission confirmation, and security risk assessment.

[0064] Step S135 , calculating the matching degree between the dynamic decision template and the operation range identifier of the permission level node, selecting dynamic decision templates with matching degrees higher than a set matching degree threshold as dynamic decision nodes, and associating them with corresponding permission change operation types.

[0065] For example, information such as the "temperature parameter adjustment" operation frequency threshold of 60 times and the hierarchical constraint change threshold of 0.2 is organized into a feature vector. From this, the cosine similarity between this feature vector and the operation frequency distribution matrix corresponding to the operation range identifier can be calculated. Using a specific calculation method, the correlation between the feature vector and each element in the matrix is ​​compared. After a series of complex calculations (such as vector dot products and vector moduli), the cosine similarity is calculated to be 0.65. Dynamic calibration of the cosine similarity is performed based on the update frequency of the current account permission configuration set. The current account permission configuration set has been updated three times in the past month. The historical version records are extracted from the timestamp intervals between adjacent versions and the number of change operation types between corresponding versions. For example, the timestamp intervals between adjacent versions are 10 days and 12 days, respectively, and the number of change operation types between corresponding versions is 5 and 3, respectively. Dynamic calibration weights are generated by analyzing the fluctuation of the timestamp interval sequence and the distribution density of the number of change operation types. Assume that after calculation and analysis, the generated dynamic calibration weight is 0.7. The dynamic calibration weight and cosine similarity are weighted and superimposed, resulting in a transitional similarity value of 0.7 × 0.65 = 0.455. The transitional similarity value is normalized and truncated, assuming a preset range of 0 to 1, to keep 0.455 within this range, resulting in a valid similarity segment. The mean (here, 0.455) and variance (assuming 0.03) of the valid similarity segment are mapped to the dimensional space of the dynamic decision template to generate the calibrated similarity value. If the calibrated similarity value exceeds the preset matching threshold (assuming 0.4), it is considered a valid match. The matching template and its corresponding permission change operation type are recorded, forming a mapping table between dynamic decision nodes and operation ranges. For example, when the trigger threshold is met, the corresponding permission change operation type is recorded as upgrading from "Device Parameter Adjustment" to "Advanced Device Parameter Control."

[0066] In one possible implementation, the call permission verification model performs multi-dimensional matching processing on the hierarchical constraint features, operation behavior features, and dynamic decision node set to generate a permission change verification result, including:

[0067] Step S141 : Compare the hierarchical constraint feature with the condition trigger threshold in the dynamic decision node set to generate a hierarchical compliance score.

[0068] For example, still taking the aforementioned "Device Parameter Adjustment" permission level node as an example, its hierarchical constraint characteristics are compared with the conditional trigger threshold in the dynamic decision node set to generate a hierarchical compliance score. The hierarchical constraint characteristics of the "Device Parameter Adjustment" node include information such as the hierarchical constraint strength value. Assume that the hierarchical constraint strength value of this node is 2.5. The conditional trigger threshold set for this node in the dynamic decision node set involves the range of variation of the hierarchical constraint strength, for example, requiring the hierarchical constraint strength value to be between 2 and 3 to trigger the permission change operation. By comparison, the hierarchical constraint strength value of 2.5 of the "Device Parameter Adjustment" node is within the prescribed range of 2 to 3. According to the pre-set scoring rules, if it is within this range, it will be given a hierarchical compliance score of 8 points. This scoring process is a rule formulated by comprehensively considering multiple factors such as the position of the permission level node in the hierarchical structure and the strength of the association with the upper and lower nodes. It aims to evaluate whether the current hierarchical status meets the basic hierarchical requirements for permission changes.

[0069] Step S142 : extracting the operation mode change gradient in the operation behavior feature, performing time alignment with the verification path length in the dynamic decision node set, and calculating the operation mode offset.

[0070] For example, the operational behavior characteristics of the "Device Parameter Adjustment" node include information related to the gradient of operational mode changes. Analyzing the operational records over the past period, assuming that in weekly statistics, it is found that the mode change gradient of the "Temperature Parameter Adjustment" operation is to increase the frequency of operation by 5 times per week, and the mode change gradient of the "Speed ​​Parameter Adjustment" operation is to reduce the frequency of operation by 3 times per week, a comprehensive operational mode change gradient value is calculated by comprehensively considering the changes in the above operational types. The verification path length set in the dynamic decision node set is 4 links. To align the operational mode change gradient with the verification path length in time is to compare the relationship between the two in the time dimension. For example, in chronological order, check whether the trend of the operational mode change gradient matches the operational change rhythm expected by the verification path length. The operational mode offset is calculated using a specific calculation method. Assume we first calculate the offset ratio for each operation type. Comparing the expected increase in the frequency of the "Temperature Parameter Adjustment" operation with the actual frequency, we see an increase of 3 times per week, but an actual increase of 5 times. The offset ratio is (5-3) ÷ 3 ≈ 0.67. Comparing the expected decrease in the frequency of the "Speed ​​Parameter Adjustment" operation with the actual frequency, we see a decrease of 2 times per week, but an actual decrease of 3 times. The offset ratio is (3-2) ÷ 2 = 0.5. Taking into account the weights of each operation type, assuming a weight of 0.6 for "Temperature Parameter Adjustment" and 0.4 for "Speed ​​Parameter Adjustment," the total operation mode offset is 0.67 × 0.6 + 0.5 × 0.4 = 0.602. This operation mode offset reflects the degree of difference between the actual operation mode and the dynamic decision node's expectations.

[0071] Step S143: construct a two-dimensional verification space based on the hierarchical compliance score and the operation mode offset, and determine the feasible area boundary of the permission change operation in the two-dimensional verification space.

[0072] For example, a two-dimensional space is drawn with the hierarchical compliance score as the horizontal axis and the operation mode offset as the vertical axis. The boundaries of the feasible area are determined based on the factory's preset security policies and permission management requirements. For example, it is stipulated that when the hierarchical compliance score is greater than 6 points and the operation mode offset is less than 0.8, it is the feasible area for permission change operations. The determination of the boundaries of this feasible area comprehensively considers multiple factors such as factory production safety and operational stability to ensure that permission change operations are carried out within a reasonable range. This not only ensures that permission changes can meet production needs, but also avoids security risks caused by excessive permission changes.

[0073] Step S144 , performing an overlap analysis based on the feasible area boundary and the preset security policy rules, and generating a forward verification result if the overlapping area exceeds a preset threshold, otherwise generating a reverse verification result including a conflict point.

[0074] For example, pre-set security policy rules specify in detail the permitted scope and conditions for permission changes under different circumstances. Within this two-dimensional verification space, the determined feasible area is compared with the permitted area specified by the security policy rules. Assume that the area of ​​the overlapping area is calculated using a pre-set calculation method (e.g., calculating the intersection of two areas). The pre-set threshold is set at 0.5, and the calculated overlapping area is 0.6, exceeding the pre-set threshold. At this point, a forward verification result is generated, indicating that the current permission change operation complies with the security policy rules and that subsequent operations can proceed. If the overlapping area does not exceed the pre-set threshold, for example, the calculated overlapping area is 0.4, a reverse verification result is generated, including conflict points, to clearly identify the areas of non-compliance with the security policy rules. For example, while the hierarchical compliance score meets the requirements, the operation mode deviates significantly, exceeding the permitted range of the security policy, necessitating adjustment or reassessment of the permission change operation.

[0075] Step S145 : Bind the forward verification result or the reverse verification result with the corresponding dynamic decision node to generate a permission change verification result set with a time sequence mark.

[0076] When a forward verification result is generated, bind this result to the dynamic decision node corresponding to the "Device Parameter Adjustment" permission level node. Record the time when the verification passed, for example, "At 10:30 on October 15, 2024, the permission change operation of the 'Device Parameter Adjustment' permission level node passed verification," to form a permission change verification result set with a time stamp. If a reverse verification result is generated, the same binding is performed, recording "At 10:30 on October 15, 2024, the permission change operation of the 'Device Parameter Adjustment' permission level node failed verification. The conflict point is that the operation mode offset is out of range" for subsequent analysis and processing.

[0077] In a possible implementation, updating the current account permission configuration set according to the permission change verification result includes:

[0078] Step S146: parse the forward verification result in the permission change verification result set, and extract the permission change operation type and target permission level node corresponding to the dynamic decision node bound to the forward verification result.

[0079] For example, if the permission change operation for the "Device Parameter Adjustment" permission level node passes verification, relevant information is extracted from the time-stamped permission change verification result set. The permission change operation type corresponding to the dynamic decision node is an upgrade from the "Device Parameter Adjustment" permission to the "Advanced Device Parameter Control" permission, and the target permission level node is the "Device Parameter Adjustment" node.

[0080] Step S147: performing a topological structure impact analysis on the target authority level node, and calculating the cascading impact parameters of the target authority level node change operation on upstream and downstream nodes.

[0081] For example, the "Device Parameter Adjustment" node has the "Production Management Control" node as its immediate superior, and the "Specific Equipment Parameter Fine-tuning" node as its immediate subordinate. Therefore, after obtaining the reference path set for these nodes, each node in the reference path set can be traversed. Taking the "Device Parameter Adjustment" and "Production Management Control" nodes as examples, the hierarchical constraint strength value in the hierarchical constraint feature is used to calculate the dependency decay coefficient between the nodes. Assuming the hierarchical constraint strength value between the "Device Parameter Adjustment" and "Production Management Control" nodes is 2.5, the dependency decay coefficient is calculated according to specific calculation rules. For example, if the dependency decay coefficient = 1 ÷ (1 + hierarchical constraint strength value), then the dependency decay coefficient is 1 ÷ (1 + 2.5) ≈ 0.29. For the "Device Parameter Adjustment" and "Specific Equipment Parameter Fine-tuning" nodes, assuming the hierarchical constraint strength value is 1.5, the dependency decay coefficient is calculated using the same rule as 1 ÷ (1 + 1.5) = 0.4. Based on these dependency decay coefficients, a propagation impact model is constructed to simulate the propagation path and strength decay curve of permission change operations in the topology. In this propagation impact model, assume that a permission change operation begins propagating from the "Device Parameter Adjustment" node. As it propagates to the "Production Management Control" node, its intensity gradually decreases according to a dependency attenuation coefficient of 0.29. As it propagates to the "Specific Device Parameter Fine-Tuning" node, its intensity gradually decreases according to a dependency attenuation coefficient of 0.4. The intensity attenuation curve is integrated to calculate the cumulative impact of the change operation on each upstream and downstream node. For example, for the "Production Management Control" node, by integrating the propagation intensity over time or the number of operations (assuming the integration process divides the time period into multiple intervals, approximating the change in propagation intensity within each interval and accumulating the value), the cumulative impact value is 0.2. For the "Specific Device Parameter Fine-Tuning" node, a similar integration operation yields a cumulative impact value of 0.3. The cumulative impact value is weighted and summed with the node's current operational behavior to generate a cascading impact parameter that reflects topological stability. Assuming that the current operation behavior feature weight of the "Production Management Master Control" node is 0.6 and the current operation behavior feature weight of the "Specific Equipment Parameter Fine-tuning" node is 0.4, the cascade impact parameter is 0.2×0.6+0.3×0.4=0.24.

[0082] Step S148: If the cascade impact parameter is less than a preset fault tolerance threshold, the configuration parameters of the target authority level node are directly updated.

[0083] For example, if the preset fault tolerance threshold is set to 0.3, and the calculated cascade impact parameter of 0.24 is less than the preset fault tolerance threshold, the parameters of the "Device Parameter Adjustment" node are directly updated. For example, the permission range parameters of this node are updated from only being able to perform routine device parameter adjustments to being able to perform more advanced device parameter control-related operations. At the same time, the associated account permission settings, operation record requirements, and other parameters are updated to ensure that the operations after the permission change can be effectively managed and monitored.

[0084] Step S149: If the cascade impact parameter exceeds a preset fault tolerance threshold, a hierarchical buffer node is generated and inserted into the original topology structure, and the predecessor dependency weight and successor impact weight of the affected node are recalculated.

[0085] For example, suppose the calculated cascade impact parameter is 0.4, exceeding the preset fault tolerance threshold of 0.3. In this case, a hierarchical buffer node, for example, named "Parameter Adjustment Transition," is generated. This node is inserted into the topology between the "Device Parameter Adjustment" node, the "Production Management Control" node, and the "Specific Equipment Parameter Fine-tuning" node. After insertion, the predecessor dependency weights and successor impact weights of the affected nodes are recalculated. For the "Device Parameter Adjustment" node, its predecessor dependency weight on the "Parameter Adjustment Transition" node needs to be reevaluated. By analyzing the new topology and operational relationships, it is assumed that the calculated predecessor dependency weight is 0.5; the successor impact weight of the "Parameter Adjustment Transition" node on the "Production Management Control" node is calculated to be 0.3. For the "Specific Equipment Parameter Fine-tuning" node, the relationship with the "Parameter Adjustment Transition" node is also recalculated. Assuming the predecessor dependency weight is 0.6, the successor impact weight of the "Parameter Adjustment Transition" node on the "Specific Equipment Parameter Fine-tuning" node is 0.4. The recalculated weights will be used for subsequent permission management and operation analysis to ensure that the topology remains stable and orderly after the permission change.

[0086] Step S1410: Write the updated permission level node and its associated hierarchical constraint features into the current account permission configuration set, and generate a version iteration log for rollback operation.

[0087] For example, the updated "Device Parameter Adjustment" node (upgraded to "Advanced Device Parameter Control" permission) and its new hierarchical constraint features (such as the relationship with the newly inserted "Parameter Adjustment Transition" node, etc.) can be written in detail to the current account permission configuration set. At the same time, a version iteration log is generated to record the detailed information of this update, including the update time (10:45 on October 15, 2024), the update content (the "Device Parameter Adjustment" node permission is upgraded to the "Advanced Device Parameter Control" permission, the "Parameter Adjustment Transition" hierarchical buffer node is inserted, etc.), the types of permission change operations involved, and related verification results. This version iteration log provides a detailed basis for subsequent possible rollback operations. Once a problem occurs, the permission configuration can be restored to its previous state based on the information in the log to ensure the continuity and stability of production operations.

[0088] In a possible implementation, step S147 includes:

[0089] Step S1471: Obtain a reference path set of the direct superior node and the direct subordinate node of the target authority level node.

[0090] Taking the change operation of upgrading the "Equipment Parameter Adjustment" permission level node to the "Advanced Equipment Parameter Control" permission as an example, first obtain the reference path set of the direct superior node and direct subordinate node of the target permission level node "Equipment Parameter Adjustment". The direct superior node of the "Equipment Parameter Adjustment" node is the "Production Management General Control" node. Its reference path clearly records the permission hierarchy branch from the root directory of the factory permission management system, through a series of permission classification and sub-classification paths, and finally points to the "Production Management General Control" node. The direct subordinate nodes include the "Specific Equipment Parameter Fine-tuning" node, etc. The reference path of the "Specific Equipment Parameter Fine-tuning" node also records its position information in detail in the permission system, extending from the sub-path of the "Equipment Parameter Adjustment" node, clarifying its affiliation with the superior "Equipment Parameter Adjustment" node.

[0091] Step S1472: traverse each node in the reference path set, and call the hierarchical constraint strength value in the hierarchical constraint feature to calculate the dependency attenuation coefficient between nodes.

[0092] For example, for the "Equipment Parameter Adjustment" node and the "Production Management General Control" node, the hierarchical constraint strength value in the hierarchical constraint feature is 2.5. According to the established calculation rules, the dependency attenuation coefficient is calculated by dividing 1 by 1 plus the sum of the hierarchical constraint strength values. Therefore, the dependency attenuation coefficient between the "Equipment Parameter Adjustment" node and the "Production Management General Control" node is 1 divided by (1+2.5). First calculate the value in the brackets, 1+2.5 equals 3.5, and then divide 1 by 3.5 to get approximately 0.29. For the "Equipment Parameter Adjustment" node and the "Specific Equipment Parameter Fine-tuning" node, the hierarchical constraint strength value is 1.5. Following the same calculation rules, first calculate 1+1.5 equals 2.5, and then divide 1 by 2.5 to get a dependency attenuation coefficient of 0.4.

[0093] Step S1473: constructing a propagation impact model based on the dependency attenuation coefficient to simulate the propagation path and intensity attenuation curve of the permission change operation in the topology structure.

[0094] For example, in this propagation impact model, the permission change operation is assumed to begin propagating from the "Device Parameter Adjustment" node. As it propagates to the "Production Management Control" node, the previously calculated dependency decay coefficient of 0.29 indicates that the strength of the permission change operation gradually decreases during the propagation process. With each propagation stage, the strength decays by a factor of 0.29. For example, assuming the permission change operation has a starting strength of 100, after propagating to the first stage, the strength becomes 100 times (1 - 0.29), or 100 times 0.71, which equals 71. When propagating to the "Specific Equipment Parameter Fine-tuning" node, the strength decays by a dependency decay coefficient of 0.4. Similarly, assuming the starting strength is 100, after propagating to the first stage, the strength becomes 100 times (1 - 0.4), or 100 times 0.6, which equals 60. Similarly, as the propagation stages increase, the strength decays according to the corresponding dependency decay coefficient, forming a strength decay curve.

[0095] Step S1474: performing an integration operation on the intensity attenuation curve to obtain a cumulative impact value of the change operation on each upstream and downstream node.

[0096] For example, for the "Production Management Control" node, the integration process involves dividing the propagation time period of the permission change operation into multiple intervals. Within each interval, the change in propagation intensity is approximately calculated and accumulated. For example, in the first interval, the intensity changes from 100 to 71. The average intensity change within this interval is approximately (100 + 71) divided by 2, which equals 85.5. In the second interval, assuming the intensity changes from 71 to 50 (calculated according to the attenuation law), the average intensity change is (71 + 50) divided by 2, which equals 60.5. Similarly, the average intensity changes across all intervals are accumulated. After a series of calculations, the cumulative impact of the change operation on the "Production Management Control" node is 0.2. For the "Specific Equipment Parameter Fine-tuning" node, the same approach is used: the propagation process is divided into multiple intervals, and the average intensity change in each interval is calculated and accumulated. Assume that after detailed calculations, the cumulative impact of the change operation on the "Specific Equipment Parameter Fine-tuning" node is 0.3.

[0097] Step S1475 : performing a weighted summation on the cumulative impact value and the current operation behavior characteristics of the node to generate a cascade impact parameter reflecting topology stability.

[0098] For example, the current operational behavior characteristic weight of the "Production Management Master Control" node is set to 0.6, and the current operational behavior characteristic weight of the "Specific Equipment Parameter Fine-tuning" node is set to 0.4. The calculation of the cascading impact parameter is to multiply the cumulative impact value of the "Production Management Master Control" node by its weight, and then add the cumulative impact value of the "Specific Equipment Parameter Fine-tuning" node multiplied by its weight. That is, 0.2 multiplied by 0.6 plus 0.3 multiplied by 0.4. First calculate the multiplication part, 0.2 multiplied by 0.6 equals 0.12, and 0.3 multiplied by 0.4 equals 0.12. Then add the two results together, 0.12+0.12 equals 0.24. This 0.24 is the final cascade impact parameter that reflects the stability of the topology. This cascade impact parameter comprehensively considers the impact of the permission change operation on the upstream and downstream nodes and the operational behavior characteristics of the node itself.

[0099] In a possible implementation, step S135 includes:

[0100] Step S1351 , parsing the condition trigger threshold in the dynamic decision template, and converting the condition trigger threshold into a feature vector of the same dimension as the operation range identifier.

[0101] For example, for the "device parameter adjustment" permission level node, the conditional trigger threshold in its dynamic decision template contains multiple key information. For example, in terms of the frequency of equipment operation, it is stipulated that the "temperature parameter adjustment" operation must be triggered more than 40 times within a week, and the "speed parameter adjustment" operation must be triggered more than 30 times within a week. At the same time, the change in the hierarchical constraint strength value must be above 0.5 to trigger the permission change operation. The above conditional trigger threshold information is organized into a feature vector. First, the "temperature parameter adjustment" operation trigger count threshold of 40 times, the "speed parameter adjustment" operation trigger count threshold of 30 times, and the hierarchical constraint strength value change threshold of 0.5 are constructed into a multi-dimensional feature vector in a manner corresponding to the operation types and related features covered by the operation range identifier. The dimension of the feature vector is consistent with the dimension of the operation frequency distribution matrix corresponding to the operation range identifier, so as to facilitate subsequent similarity calculations.

[0102] Step S1352 : Calculate the cosine similarity between the feature vector and the operation frequency distribution matrix corresponding to the operation range identifier.

[0103] For example, the operation frequency distribution matrix corresponding to the operation scope identifier records the actual triggering frequency of different operation types within the "Device Parameter Adjustment" permission level node within a certain period of time. For example, in the past week, the "Temperature Parameter Adjustment" operation was actually triggered 45 times, and the "Speed ​​Parameter Adjustment" operation was actually triggered 32 times. This information is recorded in detail in the operation frequency distribution matrix. When calculating cosine similarity, it is first necessary to clarify that the calculation principle is based on the relationship between the dot product of vectors and their modulus. For the eigenvector and the vector in the operation frequency distribution matrix, their dot product can be calculated. For example, suppose the eigenvector is [40, 30, 0.5], and the corresponding vector in the operation frequency distribution matrix is ​​[45, 32, 0.6] (here, it is assumed that the hierarchical constraint strength value also has a corresponding value of 0.6 in reality). The dot product is calculated by multiplying the corresponding elements of the two vectors and then adding them together, that is, 40×45+30×32+0.5×0.6. First, calculate the multiplication: 40 × 45 = 1800, 30 × 32 = 960, and 0.5 × 0.6 = 0.3. Then add the results: 1800 + 960 + 0.3 = 2760.3. Next, calculate the modulus of the two vectors. The modulus of the eigenvector is calculated by squaring each element: 40 squared is 1600, 30 squared is 900, and 0.5 squared is 0.25. Then, add the sum of the squares: 1600 + 900 + 0.25 = 2500.25, and take the square root of this sum to get approximately 50.0025. The modulus of the corresponding vector in the operation frequency distribution matrix is ​​calculated: 45 squared is 2025, 32 squared is 1024, and 0.6 squared is 0.36. Adding the sum of the squares: 2025 + 1024 + 0.36 = 3049.36, and taking the square root of this sum yields approximately 55.22. Finally, cosine similarity is equal to the dot product divided by the product of the two vector moduli, which is 2760.3 ÷ (50.0025 × 55.22). First calculate the value in the brackets 50.0025 × 55.22 ≈ 2760.13, and then use 2760.3 ÷ 2760.13 ≈ 0.9999.

[0104] Step S1353 : dynamically calibrating the cosine similarity according to the update frequency of the current account permission configuration set to obtain a calibrated similarity value.

[0105] In a possible implementation, step S1353 includes:

[0106] Step S1353-1: extract the time stamp interval sequence of adjacent versions and the number sequence of change operation types between corresponding versions from the historical version records of the current account permission configuration set.

[0107] Assume that the historical version records of the current account permission configuration set show that the timestamp intervals of the latest five versions are 10 days, 12 days, 8 days, 15 days, and 11 days, respectively. The number of change operation types between the corresponding versions are 3, 4, 2, 5, and 3, respectively.

[0108] Step S1353 - 2 : generating a dynamic calibration weight according to the degree of fluctuation of the timestamp interval sequence and the distribution density of the change operation type quantity sequence.

[0109] First, analyze the volatility of the timestamp interval series and calculate its average. Add 10 + 12 + 8 + 15 + 11 to get 56, and divide by 5 to get the average value of 11.2. Then calculate the difference between each timestamp interval and the average value: 10 - 11.2 = -1.2, 12 - 11.2 = 0.8, 8 - 11.2 = -3.2, 15 - 11.2 = 3.8, and 11 - 11.2 = -0.2. Squaring these differences yields (-1.2) squared to 1.44, 0.8 squared to 0.64, (-3.2) squared to 10.24, 3.8 squared to 14.44, and (-0.2) squared to 0.04. Add the above square values ​​1.44+0.64+10.24+14.44+0.04=26.8, and divide it by the number of data 5, and the variance is about 5.36. The larger the variance, the greater the degree of fluctuation.

[0110] For example, adding 3+4+2+5+3 equals 17, and dividing by 5 gives an average of 3.4. Distribution density can be comprehensively assessed by analyzing the concentration of the data, for example. Assuming that certain rules and experience are used, combining volatility and distribution density, and through complex calculations and analysis (for example, considering the weighting of volatility and distribution density), a dynamic calibration weight of 0.8 is ultimately generated.

[0111] Step S1353 - 3 , performing weighted superposition processing on the dynamic calibration weight and the cosine similarity to generate a superposed transition similarity value.

[0112] For example, 0.8×0.9999=0.79992, which is the transition similarity value after superposition.

[0113] Step S1353 - 4 , performing normalization and truncation processing on the transition similarity value, and retaining valid similarity segments within a preset value range.

[0114] For example, the preset numerical range is assumed to be 0 to 1. Since 0.79992 is within the range, it is directly retained as a valid similarity segment.

[0115] Step S1353-5: Map the mean and variance of the valid similarity segments to the dimensional space of the dynamic decision template to generate a calibrated similarity value.

[0116] For example, here, the valid similarity segment has only one value, 0.79992, whose mean is itself 0.79992 and variance is 0 (because there is only one data point). Mapping the mean 0.79992 to the dimensional space of the dynamic decision template according to certain rules, assuming a simple linear mapping relationship (for example, adjusted according to the range and characteristics of the dynamic decision template dimensional space), ultimately generates a calibrated similarity value of 0.8.

[0117] In step S1354, the calibrated similarity value is compared with the preset matching threshold. If the calibrated similarity value exceeds the matching threshold, it is determined to be a valid match, and the valid matching template and its corresponding permission change operation type are recorded to form a mapping relationship table between dynamic decision nodes and operation ranges.

[0118] For example, the preset matching threshold is 0.7. Since the calibrated similarity value of 0.8 exceeds the preset matching threshold, it is determined to be a valid match. This valid matching dynamic decision template is recorded, and its corresponding permission change operation type is an upgrade from the "Device Parameter Adjustment" permission to the "Advanced Device Parameter Control" permission. This information is organized into a mapping table of dynamic decision nodes and operation scopes, clearly recording the correspondence between the dynamic decision templates for each permission level node and the possible permission change operation types.

[0119] In one possible implementation, the method further includes:

[0120] Step S210: receiving a permission level adding request, wherein the permission level adding request includes a target permission level identifier and associated operation range parameters.

[0121] For example, a new target permission level is identified as "Complex Equipment Function Debugging." The associated operating scope parameters clearly specify that this permission level allows operations such as in-depth parameter debugging and advanced fault diagnosis for specific complex equipment. These operations involve some core and sophisticated equipment in the factory production process, requiring extremely high levels of operational expertise and permission management.

[0122] Step S220 , verifying whether the authority level of the current operating account meets the hierarchical constraint strength threshold of the dynamic decision node set in the authority topology structure.

[0123] For example, the operating account requesting the "Complex Device Function Debugging" permission level, whose current permission level is "Intermediate Device Maintenance," meets the hierarchical constraint strength threshold for permission level addition operations. This threshold specifies that the addition condition is met only when the operating account's permission level reaches "Advanced Device Management" or above, and the difference in hierarchical constraint strength between the operating account's "Intermediate Device Maintenance" permission level and the target permission level ("Complex Device Function Debugging") is within a certain range (e.g., less than 0.5). A detailed comparison of the position, hierarchical relationship, and corresponding constraint strength values ​​of the current operating account's "Intermediate Device Maintenance" permission level and the target "Complex Device Function Debugging" permission level in the permission topology reveals that the difference in hierarchical constraint strength between "Intermediate Device Maintenance" and "Complex Device Function Debugging" is calculated to be 0.8 (calculation process: first, the hierarchical constraint strength value for "Intermediate Device Maintenance" is determined to be 2.0, and the preset hierarchical constraint strength value for "Complex Device Function Debugging" is 2.8; the difference is 2.8-2.0 = 0.8). This exceeds the specified threshold of 0.5, and the initial verification fails. However, after further evaluation, considering that the operating account had performed well in the recent key equipment maintenance tasks and had training records and experience certification for the commissioning of relevant complex equipment, it was finally determined to have passed the verification after a special approval process.

[0124] Step S230: If the verification is successful, the target permission level identifier is added to the end of the permission level node sequence of the current account permission configuration set, and a corresponding hierarchical constraint feature initial value is generated.

[0125] For example, in the current account permission configuration set, the permission level node sequence originally included nodes such as "Basic Operation Permissions", "Intermediate Equipment Maintenance", and "Advanced Equipment Management". The permission level identifier of "Complex Equipment Function Debugging" is appended to the end of the sequence. When generating the initial value of the hierarchical constraint feature, refer to the situation of adjacent permission level nodes. The direct superior node of "Complex Equipment Function Debugging" is "Advanced Equipment Management", and its hierarchical constraint strength value is 3.0. According to certain rules (for example, the difference in the hierarchical constraint strength value between the new node and the superior node is usually set between 0.5-1.0), the initial value of the hierarchical constraint feature generated for "Complex Equipment Function Debugging" is set to 3.5. This value comprehensively considers factors such as the operational complexity of the new permission level, the degree of dependence on the superior permission, and the position in the entire permission topology structure.

[0126] Step S240 , triggering a hierarchical topology reconstruction operation, recalculating the predecessor dependency weight and the successor influence weight of the newly added permission level node, and updating the associated verification path of the dynamic decision node set.

[0127] For example, in one possible implementation, step S240 includes:

[0128] Step S241: extract the reference path and hierarchical constraint strength value of the direct superior node of the newly added permission level node.

[0129] Step S242: generating an initial value of the predecessor dependency weight of the newly added node based on the successor influence weight historical data of the direct superior node.

[0130] First, extract the reference path and hierarchical constraint strength value of the newly added permission level node "Complex Equipment Function Debugging," the direct superior node "Advanced Equipment Management." The reference path for "Advanced Equipment Management" clearly records the path from the core control layer of the factory permission management system, through the equipment management classification path, and ultimately to this node. Its hierarchical constraint strength value is 3.0. Based on the historical data of the subsequent impact weight of "Advanced Equipment Management," generate the initial value of the predecessor dependency weight of the newly added node. Assume that the historical data of the subsequent impact weight of "Advanced Equipment Management" on its subordinate nodes shows that the average subsequent impact weight is 0.4. Considering the special nature of "Complex Equipment Function Debugging" and its close dependence on "Advanced Equipment Management," the initial value of the predecessor dependency weight of "Complex Equipment Function Debugging" is 0.6 (this value is higher than the average subsequent impact weight, reflecting its stronger dependency relationship).

[0131] Step S243, traverse all lower-level nodes in the permission level node sequence, and obtain the difference between their current predecessor dependency weight and the hierarchical constraint strength value of the newly added node.

[0132] Step S244: adjusting the predecessor dependency weight of the lower-level node according to the difference, and updating the successor influence weight of the upper-level node by reverse iteration.

[0133] For example, a lower-level node in the permission-level node sequence, such as "Specific Device Parameter Fine-tuning," has a current predecessor dependency weight of 0.3. The difference between this and the hierarchical constraint strength value of 3.5 for "Complex Device Function Debugging" is 3.5 - 0.3 = 3.2. The current predecessor dependency weight for the "Equipment Basic Maintenance" node is 0.2, and the difference between this and the hierarchical constraint strength value for "Complex Device Function Debugging" is 3.5 - 0.2 = 3.3. The predecessor dependency weights of the lower-level nodes are adjusted based on these differences. For "Specific Device Parameter Fine-tuning," due to the large difference, its predecessor dependency weight is appropriately increased to 0.4 (the increase is determined based on the difference and certain rules). The predecessor dependency weight of the "Equipment Basic Maintenance" node is adjusted to 0.3. Simultaneously, the successor influence weights of the upper-level nodes are updated in a reverse iterative manner. Due to the adjustment in the predecessor dependency weights of the lower-level nodes, the successor influence weight of "Advanced Device Management" is also updated accordingly. After a series of complex calculations and analyses (taking into account the relationships and influences of all relevant nodes), the successor influence weight of "Advanced Device Management" is updated to 0.5.

[0134] Step S245 , cross-validating the updated predecessor dependency weight and successor influence weight with the operating range parameters of the newly added nodes to generate a reconstructed hierarchical topology structure feature matrix.

[0135] For example, the operating scope parameters for "Complex Device Function Debugging," such as the list of specific complex device debugging operations that can be performed and the frequency limit for these operations, are combined with the updated predecessor dependency weights and successor impact weights. The parameters can then be checked for logical conflicts or irrationalities. For example, the new predecessor dependency weights and successor impact weights can be verified to be consistent with the required permission levels for the operating scope. After comprehensive and meticulous cross-validation, a reconstructed hierarchical topology feature matrix is ​​generated, which accurately reflects the changes and characteristics of the entire permission topology structure after the new permission levels are added.

[0136] Step S250 , writing the reconstructed hierarchical topology structure and dynamic decision node set into the cache queue of the permission verification model, waiting for the trigger condition of the next permission change operation to be matched.

[0137] In a possible implementation, step S250 includes:

[0138] Step S251 , parsing the reconstructed hierarchical topology structure feature matrix, extracting the latest hierarchical constraint strength value and operation behavior feature timestamp of each permission level node.

[0139] For example, the latest hierarchical constraint strength value of "Complex Device Function Debugging" is 3.5, and the operation behavior feature timestamp records the time of creation of the permission level and related operations. The latest hierarchical constraint strength value of "Advanced Device Management" is updated to 3.2 (changed due to hierarchical structure reconstruction), and its operation behavior feature timestamp is also updated accordingly. Align the time window of the above latest hierarchical constraint strength value with the unprocessed permission change verification result set in the cache queue. There are some previously unprocessed permission change verification results in the cache queue, such as the verification results for the permission upgrade of "Intermediate Device Maintenance". Compare and match the hierarchical constraint strength values ​​of nodes such as "Complex Device Function Debugging" with the time windows in the above unprocessed results.

[0140] Step S252: aligning the time window of the latest level constraint strength value with the unprocessed permission change verification result set in the cache queue.

[0141] Step S253 , filtering out the permission change verification results with overlapping time windows, and recalculating their hierarchical compliance scores and operation mode offsets.

[0142] Assume that the verification result time window for the "Intermediate Device Maintenance" permission upgrade overlaps with the time window after the "Complex Device Function Debugging" permission is added. When recalculating the hierarchical compliance score for the "Intermediate Device Maintenance" permission upgrade, the new hierarchical topology is taken into account. Due to the addition of "Complex Device Function Debugging", the hierarchical relationship between "Intermediate Device Maintenance" and the parent node has changed, and its hierarchical compliance score is re-evaluated. For example, the original hierarchical compliance score between "Intermediate Device Maintenance" and the parent node was 7 points. Under the new topology, after detailed calculation (taking into account the new hierarchical constraint strength value, the relationship between nodes, and other factors), the recalculated hierarchical compliance score is 6 points. At the same time, the operating mode offset is recalculated. If the previous "Intermediate Device Maintenance" operating mode offset was 0.3, under the new topology and operating environment, based on the new operating behavior characteristics and verification path requirements, the operating mode offset is recalculated to 0.4.

[0143] Step S254 : updating the condition trigger threshold and verification path length of the dynamic decision node set according to the recalculated score and offset.

[0144] For example, based on the new hierarchical compliance score and operational mode offset, the condition trigger threshold and verification path length associated with the "Intermediate Device Maintenance" privilege escalation in the dynamic decision node set have been updated. For example, the condition trigger threshold has been adjusted from the original hierarchical compliance score of 6.5 to 7 points, and the verification path length has been increased from 3 links to 4 links. These adjustments ensure that the dynamic decision node set matches the new permission topology and operational behavior.

[0145] Step S255 : transactionally committing the updated dynamic decision node set and the reconstructed hierarchical topology structure to ensure atomic update of the operation control module.

[0146] For example, the updated set of dynamic decision nodes and the reconstructed hierarchical topology are submitted as a single transaction to the cache queue of the permission verification model. During this submission process, the consistency and integrity of all relevant data are ensured to prevent situations where some data updates succeed while others fail. This allows the operation control module to accurately perform permission management and verification operations based on the updated information, ensuring the efficiency and accuracy of permission management during factory production. This allows the newly added "Complex Equipment Function Debugging" permission level and changes to the entire permission topology to take effect smoothly and operate stably.

[0147] In a possible implementation, step S253 includes:

[0148] Step S2531, obtaining the permission level node identifier and operation scope change record corresponding to each result in the permission change verification result set.

[0149] Step S2532 : Match the latest hierarchical constraint strength value and the operation frequency distribution matrix of the same node identifier in the reconstructed hierarchical topology structure.

[0150] For example, for the verification result of the "Intermediate Equipment Maintenance" permission upgrade, its permission level node is identified as "Intermediate Equipment Maintenance", and the operation scope change record shows that it has expanded from routine equipment maintenance operations to some advanced equipment maintenance operations. Match the latest hierarchical constraint strength value and operation frequency distribution matrix of the same node identifier in the reconstructed hierarchical topology structure. In the reconstructed hierarchical topology structure, the latest hierarchical constraint strength value of the "Intermediate Equipment Maintenance" node is 2.2, and the operation frequency distribution matrix records the triggering frequency of various operations of the node in different time periods. For example, the daily equipment inspection operation was triggered 20 times in the past week, and the simple equipment fault repair operation was triggered 15 times.

[0151] Step S2533 : re-perform the threshold comparison operation of the hierarchical compliance score based on the latest hierarchical constraint strength value to generate an updated score set.

[0152] Assume that the threshold for the hierarchical compliance score is set so that the difference from the hierarchical constraint strength value of the parent node is within a certain range. The latest hierarchical constraint strength value of "Advanced Device Management," the parent node of "Intermediate Device Maintenance," is 3.2, and the difference is 3.2 - 2.2 = 1.0. According to the scoring rules, if the difference is between 0.8 and 1.2, the hierarchical compliance score is 7; if the difference is outside this range, the score is adjusted accordingly. In this example, the resulting updated hierarchical compliance score is 7.

[0153] Step S2534 : recalculate the operation mode change gradient based on the latest operation frequency distribution matrix, and perform time difference processing with the original verification path length.

[0154] Step S2535: Use the differential result as a new operation mode offset to overwrite the historical data in the original permission change verification result set.

[0155] For example, the original verification path length is set to three steps. Analysis of the operation frequency distribution matrix shows that the frequency of daily equipment inspections increases from 15 to 20 times per week, while the frequency of simple equipment fault repairs increases from 10 to 15 times per week. The operation mode change gradient is calculated. For example, the change gradient for daily equipment inspections is (20 - 15) ÷ 15 ≈ 0.33, and the change gradient for simple equipment fault repairs is (15 - 10) ÷ 10 = 0.5. Taking into account the weights of these operations, assuming a weight of 0.4 for daily equipment inspections and 0.6 for simple equipment fault repairs, the overall operation mode change gradient is 0.33 × 0.4 + 0.5 × 0.6 = 0.432. A time-series difference (TD) is performed with the original verification path length of three steps. Assuming the original estimated operation mode change gradient is 0.3, the TD difference result is 0.432 - 0.3 = 0.132. The differential result is used as the new operation mode offset to overwrite the historical data in the original permission change verification result set, so that the permission change verification result can more accurately reflect the new permission topology structure and operation behavior.

[0156] In a possible implementation, after step S250, the method further includes:

[0157] Step S310 : monitoring the permission validity status feedback signal of the operation control module of the target machine.

[0158] Step S320: If an abnormal signal of permission effectiveness is detected, the permission level node identifier and the operation range conflict parameter corresponding to the abnormal signal are extracted.

[0159] For example, after the "Complex Equipment Function Debugging" permission level is added, the system continuously monitors signals from the target machine's operation control module. If a permission validation anomaly is detected, the permission level node identifier and the operation scope conflict parameter corresponding to the anomaly are extracted. For example, if the "Complex Equipment Function Debugging" permission is detected to be anomaly on a target machine, the permission level node identifier corresponding to the anomaly is "Complex Equipment Function Debugging," and the operation scope conflict parameter indicates that the advanced fault diagnosis operation attempted by this permission exceeds the preset device range.

[0160] Step S330 , backtracking the update path of the predecessor dependency weight and the successor influence weight of the node involved in the hierarchical topology reconstruction operation.

[0161] For example, the initial value of the predecessor dependency weight of the "Complex Device Function Debugging" node is 0.6, which is generated based on the historical data of the subsequent impact weight of its direct superior node "Advanced Device Management". During the reconstruction of the hierarchical topology, the predecessor dependency weights of subordinate nodes such as "Specific Device Parameter Fine-tuning" and "Basic Equipment Maintenance" are adjusted due to the addition of "Complex Device Function Debugging". The predecessor dependency weight of "Specific Device Parameter Fine-tuning" is adjusted from 0.3 to 0.4, and the predecessor dependency weight of "Basic Equipment Maintenance" is adjusted from 0.2 to 0.3. At the same time, the subsequent impact weight of "Advanced Device Management" is updated to 0.5. By retracing the above update path, the weight calculation deviation node that may cause abnormal permission effectiveness is located.

[0162] Step S340 , locating the weighted deviation node according to the backtracking path, and triggering a local topology rebalancing operation.

[0163] Step S350: Re-inject the rebalanced hierarchical constraint characteristics and operation behavior characteristics into the authority verification model to generate a compensatory authority change verification result.

[0164] For example, suppose it is found that the adjustment range of the predecessor dependency weight of the "Specific device parameter fine-tuning" node is too large, resulting in an abnormality in the operation associated with the "Complex device function debugging" permission in the node. Trigger the local topology rebalancing operation, first freeze the configuration parameter modification permission of the permission level node associated with the abnormal signal of the "Complex device function debugging" permission to prevent further erroneous operations. With the "Complex device function debugging" node as the center of the circle, expand two layers of nodes outward along the upper and lower paths of the hierarchical topology structure to form a local balance area. This local balance area includes "Advanced device management", "Specific device parameter fine-tuning", "Basic equipment maintenance" and the lower nodes of "Specific device parameter fine-tuning".

[0165] In a possible implementation, triggering a local topology rebalancing operation includes:

[0166] Freeze the configuration parameter modification permission of the permission level node associated with the permission effectiveness abnormal signal.

[0167] With this node as the center, two layers of nodes are expanded outward along the upper and lower paths of the hierarchical topology structure to form a local balance area.

[0168] Recollect the historical operation frequency distribution matrix and hierarchical constraint strength values ​​of all nodes in the local balance area.

[0169] An incremental update algorithm is used to adjust the distribution ratio of predecessor dependency weight and successor influence weight in the local balance area.

[0170] Verify whether the adjusted weight ratio meets the consistency condition of the associated verification path in the dynamic decision node set.

[0171] If the conditions are met, the node freeze state is released; otherwise, the global topology structure is rolled back to the last valid version.

[0172] For example, for the "Specific Device Parameter Fine-tuning" node, we recollected its historical operation frequency distribution matrix and found that small adjustments to device parameters were triggered 50 times in the past month, while medium adjustments were triggered 30 times. We also collected the node's hierarchical constraint strength value, which is currently 2.0. For the "Advanced Device Management" node, we collected its operation frequency distribution matrix, including the triggering frequency of overall device planning operations, and found that the hierarchical constraint strength value was 3.2.

[0173] Furthermore, for the "fine-tuning of specific device parameters" node, the predecessor dependency weight is adjusted from 0.4 to 0.35 based on its operation frequency and its relationship with other nodes. Through a series of complex calculations and analyses, the weights of other nodes in the local balance area are also adjusted accordingly. Verify whether the adjusted weight ratio meets the consistency conditions of the associated verification path in the dynamic decision node set. Check whether the adjusted weight makes the permission change operation meet the requirements of the dynamic decision node set on the verification path. For example, check whether the verification path of the "complex device function debugging" permission can still accurately verify the relevant operations.

[0174] If the adjusted weight ratio meets the consistency conditions, the "Complex Device Function Debugging" node is unfrozen and its configuration parameter modification permissions are restored. If the conditions are not met, for example, if the verification path for certain permission change operations is disrupted after the adjustment, the global topology structure is rolled back to the last valid version to ensure the stability and accuracy of the permission management system.

[0175] In a possible implementation, after step S250, the method further includes:

[0176] Step S410: receiving a permission name change request, wherein the request specifies a new naming identifier of a target permission level node.

[0177] For example, factory management decides to change the name of the "Intermediate Equipment Maintenance" permission level to "Intermediate Equipment Comprehensive Support." This request is received, requesting the new name identifier "Intermediate Equipment Comprehensive Support" for the target permission level node "Intermediate Equipment Maintenance." The new name identifier is verified for uniqueness and character compliance within the hierarchical topology. The system checks whether the name "Intermediate Equipment Comprehensive Support" already exists in the entire hierarchical topology and whether it complies with the system's naming rules, such as whether it contains illegal characters.

[0178] Step S420 : Verify the uniqueness and character compliance of the new naming identifier in the hierarchical topology structure.

[0179] Step S430: If the verification is successful, the operation scope identification metadata of the target permission level node is updated, and the display attribute of the associated account identification is modified synchronously.

[0180] For example, the metadata for the "Intermediate Equipment Maintenance" operation scope records the scope of operations that this permission can perform. The name in the corresponding metadata is updated to "Intermediate Equipment Comprehensive Support." Simultaneously, for the associated account identifier, such as account Z3, the permission name in its display properties is also changed to "Intermediate Equipment Comprehensive Support."

[0181] Step S440 , triggering the hot update instruction of the permission name of the operation control module to ensure the real-time display consistency of all associated machines.

[0182] Step S450 , recording the history of the name change operation and binding it to the verification path log of the corresponding dynamic decision node.

[0183] For example, intercept the display cache data block associated with the target authority level node "Intermediate Equipment Maintenance" (now "Intermediate Equipment Comprehensive Security") in the current operation control module. Locate the permission name storage address in the data block, and assume that the address location of the storage permission name is found through a specific search algorithm. Then write the binary code of the new naming identifier "Intermediate Equipment Comprehensive Security". Calculate the checksum of the data blocks before and after writing to verify the integrity of the code conversion process. For example, calculate the checksum of the data block before writing, and obtain a checksum value by performing a specific calculation (such as a hash algorithm) on all the data in the data block. After writing the new code, calculate the checksum again. If the two checksums match, it means that the code conversion process is complete and correct.

[0184] In a possible implementation, the permission name hot update instruction that triggers the operation control module includes:

[0185] Intercept the display cache data block associated with the target permission level node in the current operation control module.

[0186] The permission name storage address is located in the data block, and the binary code of the new naming identifier is written.

[0187] Calculate the checksum of the data block before and after writing to verify the integrity of the encoding conversion process.

[0188] If the checksum matches, an asynchronous refresh command is sent to all online machines to force an update of the permission name display in the graphical interface.

[0189] If an offline machine is detected, the new name identifier is added to the synchronization queue, and the name update transaction is executed first when the standby machine reconnects.

[0190] In this embodiment, upon receiving the command, all online machines immediately update their graphical user interfaces from "Intermediate Equipment Maintenance" to "Intermediate Equipment Comprehensive Support." If an offline machine is detected, the newly named identifier is added to the pending synchronization queue, and the name update is prioritized when the machine reconnects. For example, if machine M5 is currently offline, "Intermediate Equipment Comprehensive Support" is added to the pending synchronization queue. When machine M5 reconnects to the system, the permission name update is performed first to ensure its display is consistent with other machines.

[0191] Next, record the details of the name change operation, including the change time (2:00 PM, November 20, 2024), the account initiating the change (Account A1), the original name, the new name, and other information. This information is then bound to the verification path log of the dynamic decision node associated with the "Intermediate Device Maintenance" permission for future query and auditing.

[0192] In a possible implementation, after step S250, the method further includes:

[0193] An account addition request is received, the request including an identifier of the account to be added and a target permission level thereof.

[0194] Verify whether the permission level of the current account initiating the request is higher than the target permission level and meets the path verification conditions of the dynamic decision node.

[0195] If the verification is successful, a new account entry is created under the target permission level node and an initial verification feature template is generated.

[0196] Automatically associate and map the new account entry with the operation scope identifier in the hierarchical topology structure.

[0197] Trigger the account permission initialization verification process and inject the new account's verification feature template into the real-time detection channel of the permission verification model.

[0198] For example, the factory has hired a new employee and needs to assign him the "Intermediate Equipment Maintenance" permission. Receive an account addition request, which includes the account ID "Z5" to be added and its target permission level "Intermediate Equipment Maintenance". Verify whether the permission level of the current account initiating the request is higher than the target permission level and meets the path verification conditions of the dynamic decision node. Assume that the current account initiating the request is account A2 with the "Advanced Equipment Management" permission level, and the "Advanced Equipment Management" permission level is higher than "Intermediate Equipment Maintenance". Check the path verification conditions of the dynamic decision node, for example, requiring the current account to have successfully performed a certain number of advanced equipment management operations (assuming 5 times) in the past week, and the operation records comply with relevant security policies. After inspection, account A2 meets the above conditions.

[0199] If verification passes, a new account entry is created under the target permission level node, "Intermediate Device Maintenance," and an initial verification feature template is generated. In the permission management system, a new account entry is created for the "Z5" account under the "Intermediate Device Maintenance" node, recording basic account information. The initial verification feature template is generated, for example, setting the initial verification method to password plus SMS verification code, with password strength requirements including uppercase and lowercase letters, numbers, and special characters, and an SMS verification code validity period of one minute.

[0200] Automatically associate new account entries with the scope of operations in the hierarchical topology. The scope of operations for "Intermediate Equipment Maintenance" covers operations such as routine equipment inspections and simple troubleshooting. Associate the "Z5" account with this scope to ensure that the account can only perform operations within the specified scope.

[0201] Trigger the account permission initialization verification process and inject the new account's verification feature template into the permission verification model's real-time detection channel. Simulate a typical operational behavior sequence for the new account ID "Z5" at the target permission level of "Intermediate Equipment Maintenance." For example, simulate the process of daily equipment inspections for the "Z5" account, including logging into the system, selecting equipment, and performing inspections. Input the simulated operational behavior sequence into the permission verification model to obtain an estimate of its operational mode offset. Assume that the permission verification model calculates an estimated operational mode offset of 0.2 by analyzing the simulated operational behavior sequence.

[0202] In one possible implementation, the triggering of the account authority initialization verification process includes:

[0203] Simulate a typical sequence of operations performed by a new account ID at the target permission level node.

[0204] The simulated operation behavior sequence is input into the permission verification model to obtain an estimated value of its operation mode offset.

[0205] If the estimated value exceeds the tolerance threshold in the dynamic decision node set, the initial verification feature template of the new account is automatically adjusted.

[0206] Perform similarity cluster analysis on the adjusted verification feature template and historical account data to ensure consistency of feature distribution.

[0207] The operation frequency distribution matrix of the target permission level node is reversely optimized through cluster analysis results to complete the closed-loop verification of account initialization.

[0208] Assume the tolerance threshold set in the dynamic decision node set is 0.15. Since the estimated value of 0.2 exceeds the threshold, the initial verification feature template for new accounts is automatically adjusted. For example, in addition to passwords and SMS verification codes, fingerprint recognition verification is also required.

[0209] The adjusted "Z5" account verification signature template was then compared and analyzed with historical verification signature data for other accounts at the "Intermediate Device Maintenance" permission level. By calculating similarity metrics, such as fingerprint recognition and password strength, the new account's verification signature distribution was ensured to be consistent with historical account signatures, preventing overly unique or unreasonable verification signatures.

[0210] Therefore, based on the cluster analysis results, if the verification characteristics of the "Z5" account are found to be significantly different from those of historical accounts, it may affect the operation frequency distribution of the "Intermediate Equipment Maintenance" permission level. For example, if the new verification method causes the account login time to increase, it may affect the frequency of daily equipment inspection operations. Based on this, the operation frequency distribution matrix of the target permission level node "Intermediate Equipment Maintenance" is reversely optimized, and information such as the expected frequency of daily equipment inspection operations is adjusted to complete the entire account initialization closed-loop verification, ensuring that the new account can be normally integrated into the permission management system and perform related operations safely and accurately.

[0211] Figure 2 The diagram shows exemplary hardware and software components of the rights management system 100 that can implement the concept of the present invention according to some embodiments of the present invention. For example, the processor 120 can be used in the rights management system 100 to perform the functions of the present invention.

[0212] The rights management system 100 can be a general-purpose server or a special-purpose server, both of which can be used to implement the machine rights management method based on the customer autonomous decision-making mechanism of the present invention. Although only one server is shown in the present invention, for convenience, the functions described in the present invention can be implemented in a distributed manner on multiple similar platforms to balance the processing load.

[0213] For example, the rights management system 100 may include a network port 110 connected to a network, one or more processors 120 for executing program instructions, a communication bus 130, and various forms of storage media 140, such as a disk, ROM, or RAM, or any combination thereof. Exemplarily, the rights management system 100 may also include program instructions stored in ROM, RAM, or other types of non-transitory storage media, or any combination thereof. The method of the present invention may be implemented based on these program instructions. The rights management system 100 also includes an input / output (I / O) interface 150 between the computer and other input / output devices.

[0214] For ease of explanation, only one processor is described in the rights management system 100. However, it should be noted that the rights management system 100 in the present invention may also include multiple processors, so the steps performed by one processor described in the present invention may also be performed jointly or individually by multiple processors. For example, if the processor of the rights management system 100 performs step A and step B, it should be understood that step A and step B may also be performed jointly by two different processors or individually in one processor. For example, the first processor performs step A and the second processor performs step B, or the first processor and the second processor perform steps A and B together.

[0215] In addition, an embodiment of the present invention further provides a readable storage medium, in which computer-executable instructions are preset. When a processor executes the computer-executable instructions, the above-mentioned machine authority management method based on the customer autonomous decision-making mechanism is implemented.

[0216] It should be noted that in order to simplify the description of the present invention and thus help understand one or more embodiments of the invention, in the foregoing description of the embodiments of the present invention, multiple features are sometimes combined into one embodiment, figure or description thereof.

Claims

1. A machine authority management method based on a customer autonomous decision-making mechanism, characterized in that: The method comprises: Obtaining a current account permission configuration set for the target machine, wherein the current account permission configuration set includes multiple permission level nodes and their corresponding operation range identifiers, each permission level node being associated with at least one account identifier and its verification feature; Performing permission feature extraction processing on the current account permission configuration set to obtain hierarchical constraint features and operation behavior features of each permission level node, wherein the hierarchical constraint features include association strength parameters of upper and lower level permission nodes; Generate a dynamic decision node set of the permission level node based on a preset autonomous decision model, wherein the dynamic decision node set is used to represent the triggering conditions and associated verification paths of the permission change operation; Calling the permission verification model to perform multi-dimensional matching processing on the hierarchical constraint characteristics, operation behavior characteristics, and dynamic decision node set, generating a permission change verification result, and updating the current account permission configuration set according to the permission change verification result; Synchronize the updated account permission configuration set to the target machine's operation control module to trigger the permission validation operation; The call permission verification model performs multi-dimensional matching processing on the hierarchical constraint features, operation behavior features, and dynamic decision node set to generate a permission change verification result, including: Comparing the hierarchical constraint characteristics with the condition trigger thresholds in the dynamic decision node set to generate a hierarchical compliance score; Extracting the operation mode change gradient in the operation behavior feature, performing time alignment with the verification path length in the dynamic decision node set, and calculating the operation mode offset; constructing a two-dimensional verification space based on the hierarchical compliance score and the operation mode offset, and determining a feasible region boundary of the permission change operation in the two-dimensional verification space; Perform overlap analysis based on the boundaries of the feasible area and the preset security policy rules. If the area of ​​the overlapping area exceeds a preset threshold, a forward verification result is generated; otherwise, a reverse verification result containing a conflict point is generated; The forward verification result or the reverse verification result is bound to the corresponding dynamic decision node to generate a permission change verification result set with a time sequence mark.

2. The machine authority management method based on the customer autonomous decision-making mechanism according to claim 1 is characterized in that: The permission feature extraction process is performed on the current account permission configuration set to obtain the hierarchical constraint features and operation behavior features of each permission level node, including: Parsing the configuration parameters of the permission level nodes, extracting the node depth identifier, the number of peer nodes and the reference path of the parent node, and constructing the initial hierarchical topology structure; Performing a bidirectional traversal process on the initial hierarchical topology structure to obtain a predecessor dependency weight and a successor influence weight of each permission level node, and generating a hierarchical constraint strength value based on a ratio of the predecessor dependency weight to the successor influence weight; Traversing the historical operation record set corresponding to the operation range identifier, counting the triggering frequency of each operation type and the number of associated account identifiers within a preset time window, and generating an operation frequency distribution matrix; Performing time series alignment processing on the operation frequency distribution matrix, extracting the operation mode change gradient between adjacent time windows, and generating a composite operation behavior feature in combination with the hierarchical constraint strength value; The hierarchical constraint strength value and the composite operation behavior feature are standardized and spliced ​​to obtain an authority level feature vector including a time dimension and a topology dimension as a joint representation of the hierarchical constraint feature and the operation behavior feature.

3. The machine authority management method based on the customer autonomous decision-making mechanism according to claim 2 is characterized in that: The dynamic decision node set of generating the authority level node based on the preset autonomous decision model includes: Inputting the permission level feature vector into the first feature encoding layer of the autonomous decision-making model to generate an implicit state sequence containing the permission hierarchy relationship; Performing a sliding window segmentation process on the implicit state sequence to obtain a plurality of local state segments, and calculating the semantic coherence between adjacent local state segments; Constructing a state transition probability graph based on the semantic coherence, identifying a key transition path that meets preset conditions in the state transition probability graph, and extracting decision dependency relationships between path nodes in the key transition path; Generating a dynamic decision template including a condition trigger threshold and a verification path length according to the decision dependency; The matching degree of the dynamic decision template and the operation range identifier of the permission level node is calculated, and the dynamic decision template with a matching degree higher than the set matching degree threshold is selected as the dynamic decision node, and the corresponding permission change operation type is associated.

4. The machine authority management method based on the customer autonomous decision-making mechanism according to claim 1 is characterized in that: The updating of the current account permission configuration set according to the permission change verification result includes: Parsing the positive verification result in the permission change verification result set, and extracting the permission change operation type and target permission level node corresponding to the dynamic decision node bound to the positive verification result; Performing a topological structure impact analysis on the target authority level node, and calculating the cascading impact parameters of the target authority level node change operation on upstream and downstream nodes; If the cascade impact parameter is less than a preset fault tolerance threshold, directly updating the configuration parameters of the target authority level node; If the cascade impact parameter exceeds a preset fault tolerance threshold, a hierarchical buffer node is generated and inserted into the original topology structure, and the predecessor dependency weight and successor impact weight of the affected node are recalculated; The updated permission level node and its associated hierarchical constraint features are written into the current account permission configuration set, and a version iteration log is generated for rollback operations.

5. The machine authority management method based on the customer autonomous decision-making mechanism according to claim 4 is characterized in that: The performing of topological structure impact analysis on the target authority level node and calculating cascading impact parameters of the target authority level node change operation on upstream and downstream nodes includes: Obtain a reference path set of the direct superior node and the direct subordinate node of the target permission level node; Traversing each node in the reference path set, calling the hierarchical constraint strength value in the hierarchical constraint feature to calculate the dependency attenuation coefficient between the nodes; Constructing a propagation impact model based on the dependency attenuation coefficient to simulate the propagation path and intensity attenuation curve of the permission change operation in the topology structure; Performing an integration operation on the intensity attenuation curve to obtain a cumulative impact value of the change operation on each upstream and downstream node; The cumulative impact value is weightedly summed with the current operational behavior characteristics of the node to generate a cascade impact parameter reflecting the topology stability.

6. The machine authority management method based on customer autonomous decision-making mechanism according to claim 3 is characterized in that: The calculating the matching degree between the dynamic decision template and the operation range identifier of the authority level node includes: Parsing the condition trigger threshold in the dynamic decision template, and converting the condition trigger threshold into a feature vector of the same dimension as the operation range identifier; Calculating the cosine similarity between the feature vector and the operation frequency distribution matrix corresponding to the operation range identifier; Dynamically calibrating the cosine similarity according to the update frequency of the current account permission configuration set to obtain a calibrated similarity value; The calibrated similarity value is compared with the preset matching threshold. If the calibrated similarity value exceeds the matching threshold, it is determined to be a valid match, and the valid matching template and its corresponding permission change operation type are recorded to form a mapping relationship table between dynamic decision nodes and operation ranges.

7. The machine authority management method based on customer autonomous decision-making mechanism according to claim 6 is characterized in that: The dynamically calibrating the cosine similarity according to the update frequency of the current account permission configuration set to obtain a calibrated similarity value includes: Extracting a sequence of adjacent version timestamp intervals and a sequence of change operation type quantities between corresponding versions from the historical version records of the current account permission configuration set; generating a dynamic calibration weight according to the fluctuation degree of the timestamp interval sequence and the distribution density of the change operation type quantity sequence; Performing weighted superposition processing on the dynamic calibration weight and the cosine similarity to generate a superimposed transition similarity value; Performing normalization and truncation processing on the transition similarity value to retain valid similarity segments within a preset value range; The mean and variance of the effective similarity segments are mapped to the dimensional space of the dynamic decision template to generate a calibrated similarity value.

8. The machine authority management method based on customer autonomous decision-making mechanism according to claim 1 is characterized in that: After synchronizing the updated account permission configuration set to the operation control module of the target machine to trigger the permission validation operation, the method further includes: receiving a permission level adding request, the permission level adding request including a target permission level identifier and associated operation range parameters; Verify whether the permission level of the current operating account meets the hierarchical constraint strength threshold of the dynamic decision node set in the permission topology structure; If the verification is successful, the target permission level identifier is added to the end of the permission level node sequence of the current account permission configuration set, and the corresponding hierarchical constraint feature initial value is generated; Triggering a hierarchical topology reconstruction operation, recalculating the predecessor dependency weight and successor influence weight of the newly added permission level node, and updating the associated verification path of the dynamic decision node set; The reconstructed hierarchical topology structure and dynamic decision node set are written into the cache queue of the permission verification model, waiting for the trigger condition of the next permission change operation to be matched.

9. A rights management system, comprising a processor and a machine-readable storage medium, wherein the machine-readable storage medium is connected to the processor, the machine-readable storage medium is used to store programs, instructions or codes, and the processor is used to execute the programs, instructions or codes in the machine-readable storage medium to implement the machine rights management method based on the customer autonomous decision-making mechanism as described in any one of claims 1-8.

Images