A permission management method based on binary bit mapping and an operation authorization device for electrostatic protection equipment.

Abstract

This invention provides a permission management method and an operation authorization device for electrostatic discharge (ESD) protection equipment based on binary bit mapping, belonging to the field of system permission management technology. It includes: predefining a binary permission value corresponding to each of multiple permission items; generating a decimal permission value corresponding to the permission item and establishing a unique mapping relationship between the permission item, the binary permission value, and the decimal permission value; generating a decimal permission code for the role to be authorized based on the unique mapping relationship; receiving the target user identifier and the permission item to be verified in the permission verification request, determining the associated target role and obtaining its decimal permission code; converting the decimal permission code to binary to obtain a binary permission code; performing a binary operation between the binary permission value corresponding to the permission item to be verified and the binary permission code of the target role, and determining whether the target user has the permission for the permission item to be verified based on the operation result. This invention achieves lightweight permission storage and high-speed verification.

Description

Technical Field

[0001] This invention relates to the technical field of system access control, and in particular to an access control method based on binary bit mapping and an operation authorization device for electrostatic protection equipment. Background Technology

[0002] In the field of system access control technology, Role-Based Access Control (RBAC) is widely used due to its clear "user-role-permission" logic. A typical RBAC scheme employs a multi-table join storage model: "user table - role table - permission table - user-role association table - role-permission association table". During permission verification, multiple table join queries are required. First, the user's associated roles are obtained; then, the set of associated permission items is retrieved through the role; finally, it is determined whether the target permission exists in that set.

[0003] As the number of users and permissions increases, the amount of data in the related tables expands exponentially (for example, 1,000 users and 100 permissions may generate hundreds of thousands of related records), resulting in huge storage overhead. At the same time, frequent multi-table join queries can cause significant database performance bottlenecks in high-concurrency scenarios (such as e-commerce promotions), increasing the latency of permission verification response and affecting the overall availability of the system.

[0004] In addition, when it is necessary to expand the permission module or grant batch authorization, it is necessary to insert or delete a large number of related records, which is cumbersome, time-consuming and error-prone, and historical data migration is complicated.

[0005] To improve permission verification efficiency, a scheme using binary arithmetic for decimal permission encoding has emerged for front-end component permission control and instant verification. However, pure binary encoding schemes face many challenges in industrial applications: 1. Binary encoding has extremely poor readability, making it difficult for administrators to intuitively understand and manage the specific permissions of roles, thus losing the visual operation advantage of the RBAC model; 2. There is a lack of effective mechanisms for handling concurrent update conflicts, which can easily lead to data inconsistency when multiple requests modify the permissions of the same role simultaneously; 3. Large-scale industrial application problems such as cache consistency, permission bit overflow, and cross-system permission synchronization have not yet been systematically solved.

[0006] Therefore, existing technical solutions struggle to achieve a balance between management flexibility, computational efficiency, and system stability, and cannot simultaneously meet the needs of modern system access control that is large-scale, highly concurrent, and easy to maintain.

[0007] In view of this, a novel permission management method based on binary bit mapping and an operation authorization device for electrostatic protection equipment are proposed to solve the above problems in whole or in part. Summary of the Invention

[0008] To address at least one of the aforementioned problems and deficiencies in the existing technology, embodiments of the present invention provide a permission management method and an operation authorization device for electrostatic protection equipment based on binary bit mapping. By establishing a unique mapping relationship between permission items and binary permission values, the decimal permissions of roles are encoded as one or more decimal integers. This combines the management flexibility of RBAC with the efficiency of binary operations, allowing administrators to configure permissions through a visual interface. The system automatically completes the generation, updating, and millisecond-level verification of the codes at the underlying level, thereby achieving lightweight permission storage (reducing storage volume by up to 95%) and millisecond-level high-speed verification (improving performance several times over). The technical solution is as follows:

[0009] According to one aspect of the present invention, a permission management method based on binary bit mapping is provided, comprising:

[0010] Predefine the binary permission value corresponding to each of the multiple permission items;

[0011] Generate the corresponding decimal permission value based on the binary permission value, and establish a unique mapping relationship between the permission item, the binary permission value, and the decimal permission value;

[0012] Based on a unique mapping relationship, generate a decimal permission code for the role to be authorized;

[0013] The system receives the target user identifier and the permission item to be verified in the permission verification request, determines the associated target role based on the target user identifier, and obtains the decimal permission code of the target role.

[0014] Convert the decimal permission code to binary to obtain the binary permission code;

[0015] By performing a binary operation between the binary permission value corresponding to the permission item to be verified and the binary permission code of the target role, the system determines whether the target user has the permission for the permission item to be verified based on the operation result.

[0016] According to another aspect of the present invention, an operation authorization device for electrostatic discharge (ESD) protection equipment is provided, comprising an ESD protection hardware unit and an access control unit.

[0017] Specifically, the electrostatic discharge (ESD) protection hardware unit includes an electrically connected metal connector plug, an ESD discharge circuit, an ESD sampling circuit, and a first microcontroller; the access control unit includes a second microcontroller and a memory, the memory storing a computer program, which, when executed by the second microcontroller, implements the access control method described above; the ESD protection hardware unit is configured to authorize the target operator to operate the corresponding device when the access control unit determines that the target operator has the permission to operate the device to be verified, and the first microcontroller detects that the target operator's ESD voltage is less than or equal to a preset safety voltage.

[0018] The permission management method and electrostatic discharge protection equipment operation authorization device based on binary bit mapping provided in the embodiments of the present invention have at least one or a part of the following advantages:

[0019] (1) By encoding all the decimal permissions of a role into a single (or multiple) integer field for storage, the massive role-permission association records in traditional RBAC are replaced. In scenarios such as 5 million users and 20 permission items, the amount of stored data can be reduced from 100 million association records to 5 million user records. The database disk usage is reduced from about 100GB to less than 5GB, and the storage cost is reduced by more than 95%. This greatly alleviates the pressure on database storage and sharding, and storage efficiency is significantly improved.

[0020] (2) By replacing complex multi-table join queries with one or more in-memory AND operations, the performance of permission verification has achieved a qualitative leap. The response time of permission verification has been reduced from tens of milliseconds in the traditional RBAC scheme to sub-millisecond level. In high-concurrency scenarios (QPS=100,000), the average response time can be controlled within 0.8ms, and the database CPU utilization rate has been reduced from 90% to within 15%, enabling the system to support a much higher concurrent access volume than the traditional RBAC scheme, which is particularly suitable for high-concurrency scenarios.

[0021] (3) By adopting a three-layer architecture of “RBAC management layer + binary encoding operation layer + mapping adaptation layer”, the administrator can operate through the familiar RBAC visual interface and the system can automatically complete the generation, update and synchronization of binary encoding at the bottom layer. For example, when updating the permissions of 100,000 users in batches, only one encoding field of their associated role needs to be updated, which takes less than 1 millisecond, and all users take effect in real time. The operation efficiency is hundreds of times higher than that of traditional solutions, taking into account both management flexibility and operation and maintenance efficiency.

[0022] (4) By dividing binary bit ranges according to business modules and supporting the dynamic creation of multiple encoding segments, permission items can be extended non-intrusively. Adding new permissions does not require modifying the core table structure or batch updating historical data. The system can provide complete historical RBAC data migration scripts, support smooth transition, decouple the core operation logic from the specific database and development language, and has strong adaptability.

[0023] (5) By configuring the "Cache-Aside + Delayed Double Deletion" caching strategy, the concurrent update control based on optimistic locking and retry mechanism, the hot role degradation, and the Bloom filter to prevent cache penetration, the system ensures that in high-concurrency read and write scenarios, the system has a high cache hit rate (≥99%), a low update conflict rate (≤0.1%), strong data consistency, and stable and reliable system operation.

[0024] (6) In a multi-terminal system, permission synchronization only requires transmitting the user identifier and the decimal permission code of its role (one or several integers). The amount of data transmitted is reduced by more than 96% compared to transmitting a list of permission IDs. Each terminal can parse the complete permission list locally based on the pre-stored unique mapping relationship, which greatly reduces network bandwidth usage and interface latency, and improves the synchronization success rate and user experience. Attached Figure Description

[0025] These and / or other aspects and advantages of the present invention will become apparent and readily understood from the following description of preferred embodiments taken in conjunction with the accompanying drawings, in which:

[0026] Figure 1 This is a flowchart illustrating the steps of a permission management method according to an embodiment of the present invention.

[0027] Figure 2 This is an architecture topology diagram of a permission management method according to an embodiment of the present invention;

[0028] Figure 3 This is a schematic diagram of the binary operation logic for permission verification according to an embodiment of the present invention;

[0029] Figure 4 This is a schematic diagram of the binary operation logic for permission update according to an embodiment of the present invention;

[0030] Figure 5 This is a schematic diagram illustrating the principle structure of an electrostatic discharge protection equipment operation authorization device according to an embodiment of the present invention. Detailed Implementation

[0031] The technical solution of the present invention will be further described in detail below through embodiments and in conjunction with the accompanying drawings. In this specification, the same or similar reference numerals indicate the same or similar components. The following description of the embodiments of the present invention with reference to the accompanying drawings is intended to explain the overall inventive concept of the present invention and should not be construed as a limitation thereof.

[0032] The permission management method of this invention proposes a three-layer collaborative architecture: a RBAC visual management layer, a binary encoding operation layer, and a mapping adaptation layer. By establishing a unique mapping relationship between permission items and binary permission values, the decimal permissions of roles are encoded into one or more decimal integers. This architecture combines the management flexibility of RBAC with the efficiency of binary operations, allowing administrators to configure permissions through a visual interface, while the system automatically completes the generation, updating, and millisecond-level verification of codes at the underlying level.

[0033] See Figure 1 The flowchart illustrates the steps of the access control method of the present invention. The access control method includes:

[0034] Step S110: Predefine the binary permission value corresponding to each of the multiple permission items;

[0035] Step S120: Generate the decimal permission value corresponding to the permission item based on the binary permission value, and establish a unique mapping relationship between the permission item, the binary permission value, and the decimal permission value;

[0036] Step S130: Generate a decimal permission code for the role to be authorized based on the unique mapping relationship;

[0037] Step S140: Receive the target user identifier and the permission item to be verified in the permission verification request, determine the target role associated with the target user identifier, and obtain the decimal permission code of the target role.

[0038] Step S150: Convert the decimal permission code to binary to obtain the binary permission code;

[0039] Step S160: Perform binary operation between the binary permission value corresponding to the permission item to be verified and the binary permission code of the target role, and determine whether the target user has the permission for the permission item to be verified based on the operation result.

[0040] First, the system predefines all permission items and assigns a unique, non-overlapping binary permission value to each item. Preferably, only one bit in the binary permission value is set to 1, and the binary permission values ​​for each permission item are distinct. More preferably, the number of bits in the binary permission value is determined based on the total number of permission items, and is 2 bits. n The digit is n ∈ N, where N is a natural number. For example, 2 3=8 bits, 2 4 =16 bits, 2 5 =32 bits, 2 6 =64 bits, etc., to establish a stable and unique mapping relationship between permission items and binary permission values ​​and decimal permission values.

[0041] Furthermore, since only one bit in the binary permission value is set to 1, and the binary permission values ​​of each permission item are different from each other—that is, the position of the 1 in the binary permission value corresponding to each permission item is different—in other words, the 1 corresponding to each permission item exists in a different bit position in the binary permission value. This gives the 1 in each permission item a meaning that can be used to uniquely identify the person holding the permission for that permission item.

[0042] Meanwhile, in the subsequent process of forming the decimal permission code, since the position of 1 used for each permission item is different and unique, there is no carry when performing binary AND or OR operations. Therefore, the meaning of whether or not one of the 1s in the binary code has the corresponding permission item is not changed.

[0043] Furthermore, since the position of 1 used for each permission item is different and unique, the decimal permission value corresponding to each permission item and the subsequent decimal permission code also have unique identification.

[0044] Therefore, during authentication, the decimal permission code is converted to binary, and the 1s in different bits of the resulting binary permission code correspond to the permissions of the corresponding permission items that the role possesses, while the 0s in different bits correspond to the permissions of the corresponding permission items that the role does not possess.

[0045] When authorization is required for a role (i.e., the "role to be authorized"), the system finds the corresponding binary permission value based on the permission items selected for that role, and then performs a bitwise OR operation on all the bit values ​​to obtain a decimal permission value. This value is the "decimal permission code" for that role.

[0046] When permission verification is required, the system receives a request containing the target user's identifier and the permission item to be verified. Based on the user's identifier, the system locates the associated role (i.e., the "target role") and obtains its decimal permission code. Next, the system extracts the binary permission value corresponding to the permission item to be verified and performs a bitwise AND operation with the target role's decimal permission code. Whether the result is 0 indicates whether the user possesses the permission for the requested permission item.

[0047] In one example, decimal permission encoding is obtained by performing bitwise operations or binary addition on the binary permission values ​​corresponding to each permission item possessed by the role to be authorized, and then converting the result to decimal. Alternatively, decimal permission encoding is obtained by summing the decimal permission values ​​corresponding to each permission item possessed by the role to be authorized.

[0048] Preferably, the bitwise operations performed on the binary permission values ​​corresponding to each permission are OR or AND operations. Since only one bit in the binary permission value is set to 1, and the rest are set to 0, and the positions of the corresponding 1s in the binary permission values ​​of each permission item are different, no carry occurs when summing the binary permission values ​​of all permissions possessed by the role. Furthermore, when performing an OR operation (i.e., a bitwise OR operation) on the binary permission values ​​of all permissions possessed by the role, if the binary bits at the same position are both 0, the output for that bit is 0; if the binary bits at the same position are both 0 and 1, the output is 1. Therefore, after summing or performing an AND operation on the binary bits, the meaning of the 1 in the final binary permission code remains unchanged.

[0049] In one example, the binary permission value corresponding to the permission item to be verified is performed with the binary permission code of the target role through a binary operation. The result is used to determine whether the target user has the permission for the permission item to be verified, including:

[0050] Perform a binary AND operation between the binary permission value corresponding to the permission item to be verified and the binary permission code of the target role. If the result of the binary AND operation is not all zeros, it is determined that the target user has the permission for the permission item to be verified; if the result of the binary AND operation is all zeros, it is determined that the target user does not have the permission for the permission item to be verified.

[0051] This is because the positions of the 1s in each binary permission value are different. Therefore, when performing a bitwise AND operation between the binary code and the binary permission value to be verified, the output of that bit is 1 only if both bits in the binary code and the binary permission value to be verified are 1. When the corresponding bits are different or both are 0, the output of that bit is 0. Therefore, performing a bitwise AND operation between the binary code and the binary permission value to be verified achieves a weighted sum and ensures the accuracy of the result.

[0052] See Figure 2 The diagram illustrates the architecture topology of the permission management method of the present invention, which includes a three-layer collaborative architecture of "RBAC visualization management layer + binary encoding operation layer + mapping adaptation layer".

[0053] The RBAC visual management layer provides a visual interface that supports functions such as role creation, permission configuration, user-role binding, and batch permission updates. It retains the intuitiveness and flexibility of the RBAC solution, and the operational logic for administrators and operations personnel remains consistent with traditional RBAC, requiring no additional learning curve and lowering the technical barrier to access control.

[0054] In the binary encoding operation layer, core operations such as decimal permission encoding generation, permission verification, encoding update, and encoding parsing are mainly performed. Lightweight storage and efficient verification of permissions are achieved through binary operations (AND, OR, NOT operations).

[0055] In the mapping and adaptation layer, the mapping relationship between permission items and binary bits is maintained. As a key bridge connecting the management layer and the operation layer, it realizes the automatic conversion between RBAC operations and binary encoding without manual intervention.

[0056] Administrators perform permission operations (such as role authorization) through the management layer, the adaptation layer reads the mapping rules, and the computation layer executes the encoding to generate calculations. The calculation results are stored in the cache and / or database. During verification, the computation layer performs bitwise operations through encoding, and the adaptation layer parses the results and feeds them back to the management layer.

[0057] In one example, using the mapping example of a business module shown in Table 1, to organize permissions more rationally when establishing the mapping relationship, the binary bits are divided according to the "business module". For example, bits 0-3 are assigned to the "product module", and bits 4-7 are assigned to the "order module". Each module occupies a continuous binary bit range. Then, for different permission items under the same business module (such as "view", "list", "edit", "delete", etc. under the product module), different mutually exclusive binary permission values ​​are assigned within the bit range corresponding to that module.

[0058] Furthermore, to optimize the verification speed of high-frequency permissions, the "high-frequency, low-bit" principle is followed when assigning bit values ​​to permission items within the same module. That is, permission items whose usage frequency exceeds a preset threshold (e.g., the top 50% of high-frequency permissions as determined by system logs) are assigned to the lower bits (such as bit 0, bit 1, and bit 2) of the module's binary bit range. Since low-bit operations are more efficient on some hardware architectures, this design further improves the verification performance of frequently used high-frequency permissions.

[0059] Table 1. Example of business module mapping

[0060]

[0061] In one example, the process involves performing a binary operation between the binary permission value corresponding to the permission item to be verified and the binary permission code of the target role, and then determining whether the target user has the permission for the permission item to be verified based on the result. This also includes:

[0062] Before performing binary operations, compare the binary permission value corresponding to the permission item to be verified with the binary permission code of the target role to see if the number of bits is the same:

[0063] When the binary permission value corresponding to the permission item to be verified has the same number of bits as the binary permission code of the target role, a binary AND operation is performed.

[0064] When the number of bits in the binary permission value corresponding to the permission item to be verified is different from the number of bits in the binary permission code of the target role, the binary with fewer bits is padded with zeros starting from the highest bit until the number of bits in the binary permission value corresponding to the permission item to be verified is the same as the number of bits in the binary permission code of the target role. Then, a binary AND operation is performed between the binary permission value corresponding to the permission item to be verified and the binary permission code of the target role.

[0065] In one example, when adding a new permission causes the total number of accumulated permission items to exceed the number of bits in the existing binary permission value, the number of bits in the binary permission value is updated to 2 from the date of the new permission. m The number of bits is m > n, m ∈ N, and N is a natural number. For example, when the number of accumulated permission items is 17 due to the addition of a new permission, and the number of bits in the existing binary permission value is 16, then a dynamic adjustment is made, that is, from the time the new permission is added, the binary permission value is updated to 32 bits, or 64 bits, etc.

[0066] Preferably, when updating the number of bits in the binary permission value, the number of bits in the predefined binary permission value is also updated simultaneously.

[0067] For example, considering that the number of permissions typically grows continuously as system functionality expands, a dynamic expansion mechanism was designed. When a permission item needs to be assigned a bit value, but the binary bit range (e.g., bits 0-63) of the current coding segment (e.g., the "main coding segment") is already fully occupied, the system will not report an error. Instead, it will automatically or manually "dynamically create a new coding segment" (e.g., "extended coding segment 1"). The new coding segment has its own independent bit range (e.g., bits 64-127). Subsequently, a binary permission value is assigned to the new permission item within the new coding segment. In this way, the number of permissions can theoretically be expanded indefinitely.

[0068] In one example, to implement core operational functions such as decimal permission code generation, permission verification, code update, and code parsing, see Table 2, which shows the addition of code-related fields to the traditional RBAC table structure to ensure compatibility with historical data and smooth migration.

[0069] Table 2. Newly Added Core Encoding Fields and Explanations in the RBAC Table Structure

[0070]

[0071] In one example, referring to the business module mapping example in Table 1, the core operation logic and process of the permission management method are explained in detail as follows:

[0072] (1) Decimal permission code generation process

[0073] In one example, an administrator selects permission items for a role to be authorized in a visual interface and submits an "authorization command." The system receives the command and parses out a list of selected permission item identifiers. Next, based on a preset unique mapping relationship, it retrieves the binary permission value corresponding to each selected permission item. Then, it initializes a variable to 0, iterates through all retrieved binary permission values, and performs a bitwise OR operation with the initialized variable, or performs a decimal conversion on the binary permission values. The final decimal result is the decimal permission code for that role. Finally, the system associates this decimal permission code with the role's unique identifier (role ID) and stores it in the role table of the database.

[0074] When an administrator assigns permissions to a role through the RBAC interface, the system automatically generates the following code:

[0075] ① Input received: Role ID + list of selected permission item names (e.g., ["Product Listing", "Order Viewing", "Data Viewing"]);

[0076] ② Permission bit value query: Query the permission table based on the permission item name to obtain the corresponding perm_bit (2, 16, 256);

[0077] ③ OR operation combination: Initialize the encoding to 0, and then perform the "encoding|=perm_bit" operation in sequence (0 | 2 = 2 → 2 | 16 = 18 → 18 | 256 = 274);

[0078] ④ Encoding and storage: Store the generated decimal code (274) into the role_perm_cod field of the role table.

[0079] In one example, to balance the efficiency of binary encoding with the readability and auditability of traditional RBAC, the system employs a dual-track storage strategy. While storing the calculated decimal permission codes in the role table, the system also inserts a record in the traditional "Role and Permission Item Association Table" linking the role ID with the permission ID of each selected permission item. This table can be used for displaying the permission list and tracing historical operations in the backend management interface without affecting the core verification logic.

[0080] (2) Permission verification process

[0081] See Figure 3 This shows an example of the binary operation logic for permission verification.

[0082] In one example, the permission verification logic is very concise and efficient. After performing a bitwise AND operation between the decimal permission code and the permission bit value, the result is checked. If the result is not equal to 0, it means the corresponding bit in the decimal permission code for the permission to be verified is 1, thus confirming that the user has the permission; if the result is equal to 0, it means the corresponding bit in the decimal permission code for the permission to be verified is 0, thus confirming that the user does not have the permission.

[0083] When a user accesses system functions (e.g., clicking the "Order Refund" button), the system performs a permission check:

[0084] ① Request reception: The front end transmits the user ID + target permission name (e.g., "order refund");

[0085] ② Code query: Query the user table by user ID to get role_id, and then query the role table by role_id to get role_perm_code (e.g., 274).

[0086] ③ Target permission bit query: Query the permission table based on the target permission name and get perm_bit (32);

[0087] ④ Bitwise AND operation check: Perform the operation "role_perm_code & perm_bit". If the result is not equal to 0, then the user has permission (274 & 32 = 0 → no permission; 306 & 32 = 32 → permission).

[0088] ⑤ Result feedback: Return the verification result (true / false) to the front end. The entire process takes less than 1ms.

[0089] (3) Permission update process

[0090] See Figure 4 This shows an example of the bitwise operation logic for updating permissions in binary bits.

[0091] In one example, the permission update step supports add and delete operations. It receives a permission update instruction for the target role, which may contain identifiers of permission items to be added and / or revoked. Based on a unique mapping, it determines the bit values ​​of the permissions to be added (first binary permission value) and / or the bit values ​​of the permissions to be revoked (second binary permission value). It obtains the current decimal permission code for the target role.

[0092] For new entries, execute the new code = current code | first binary permission value (or operation);

[0093] For recycling, perform the following operation: New code = Current code & (~Second binary permission value) (AND operation).

[0094] The calculated new code is updated and stored as the decimal permission code for that role.

[0095] ① Single permission addition: Receive role ID + new permission name → query perm_bit and encoding segment → execute "original encoding|perm_bit" → update role_perm_code field → synchronously update role_permission related table;

[0096] ② Single permission revocation: Receive role ID + revocation permission name → query perm_bit and code segment → execute "original code & ~perm_bit" → update role_perm_code field;

[0097] ③ Batch Update: Receive role ID + list of new permissions + list of revoked permissions → execute batch add operation and batch revoke operation in sequence → generate final code and update → synchronize related table data.

[0098] In one example, to prevent data overwriting caused by multiple administrators simultaneously updating the same role's permissions, an optimistic locking mechanism is used to control concurrent updates. A "version" field is added to the role table. When performing a decimal permission code update operation, the current role's decimal permission code and version number are first read. After calculating the new code, the update SQL statement is executed, and the condition must match both the role ID and the read version number. If the update succeeds (affected rows > 0), it indicates no conflict, and the version number is incremented by 1; if it fails, it means the data has been modified by someone else, and the system can automatically retry or indicate a conflict.

[0099] (4) Decimal permission code parsing process

[0100] In one example, to facilitate administrators in viewing the specific permissions of a role, the system provides a decimal permission code parsing function. When a permission query request for a specific role is received, the system first obtains the decimal permission code of that role. Then, it iterates through all predefined permission items in the system. For each permission item, its binary permission value is ANDed with the decimal permission code of the role. All permission items whose result is not 0 are collected; these are the permission items that the role actually possesses, and finally, the data is returned in list form, enabling a visual interpretation of the code.

[0101] ① Input received: Role ID or role_perm_code (decimal permission code for the encoding segment);

[0102] ② Code Acquisition: If the input is a role ID, first query the role table to obtain role_perm_code;

[0103] ③ Traverse and match: Traverse all enabled permission items in the permission table and perform the "encode &perm_bit" operation in sequence;

[0104] ④ Result collection: For permission items whose operation result is not equal to 0, collect their perm_name;

[0105] ⑤ Output: Returns a list of permission item names (e.g., main segment code 274 is parsed as ["Product Listing", "Order View", "Data View"]), which is used for display in the backend management interface.

[0106] (5) Cross-device synchronization process

[0107] In one example, when the system serves multiple clients such as Web, App, and Mini Program, cross-platform permission synchronization is required. Clients (such as Apps) send permission synchronization requests to the server upon startup or periodically, carrying a user identifier. The server locates the associated role based on the user identifier and obtains the role's decimal permission code (which may include multiple code segments). The server does not parse the code; instead, it directly returns the user identifier and the decimal permission code (integer) to the client. The client pre-stores a "permission item - binary permission value" mapping relationship consistent with the server's. Upon receiving the code, it executes parsing logic similar to claim 8 locally to obtain the user's available permissions list for the current client and caches it.

[0108] When synchronizing permissions across multiple devices (e.g., apps / mini-programs / third-party systems), a lightweight transmission solution should be adopted:

[0109] ① Permission synchronization request: Multiple devices send user permission synchronization requests to the core system;

[0110] ② Encoding return: The core system queries the role_perm_code of the user's bound role (decimal permission code of each encoding segment), and only returns "user ID + role_perm_code" (e.g., user ID=1001, code=274, ext1=0).

[0111] ③ End-side parsing: Multiple devices pre-store a mapping dictionary of "permission item - binary bit - encoded segment" and restore the permission list through the encoding parsing logic;

[0112] ④ Local caching: The parsed permission list is cached across multiple platforms and updated periodically (e.g., every hour) to reduce duplicate requests.

[0113] In one example, to alleviate database pressure and further accelerate permission verification, a cache (e.g., Redis) is introduced when retrieving the decimal permission code for the role. The permission verification module first attempts to read the decimal permission code corresponding to the target role identifier from the cache. If the code exists in the cache (hits), it is used directly; if it does not exist (misses), the database is queried again. After obtaining the code, it is not only used for this verification but also written to the cache with a reasonable expiration time for subsequent requests to read quickly.

[0114] In one example, to ensure data consistency between the cache and the database after role permissions are updated, a "delayed double-delete" strategy is used to update the cache. When the decimal permission code for the target role is updated in the database, the corresponding old code is immediately deleted from the cache (first deletion). Then, after a short delay (e.g., 200 milliseconds), the deletion is attempted again (second deletion). This eliminates the risk of old data being reloaded back into the cache during database master-slave synchronization delays.

[0115] In one example, in larger-scale applications, the database can employ a read-write separation architecture. Read-only operations, such as permission verification requests, are routed to the database slave to alleviate the load on the master. Write operations, such as decimal permission-encoded updates, must be performed on the database master. The master-slave replication mechanism of the database cluster ensures that the slave data eventually matches the master. For example, a MySQL cluster using a 1-master, 2-slave architecture, with master-slave synchronization latency controlled within 100ms, and configured with innodb_buffer_pool_size=8G (buffer pool size) and sync_binlog=1, ensures master-slave synchronization consistency.

[0116] In one example, indexes can be created on the `role_id` field of the `user` table, the `role_id` field of the `role` table, and the `perm_name`, `perm_bit`, and `code_segment` fields of the `permission` table. Partitioning strategies can also be configured, such as partitioning the `role_permission` table by `role_id`. This reduces the data scan scope during queries and improves the efficiency of permission-based queries.

[0117] In one example, invalid permission handling can also be implemented. When a user's permission item is disabled, its perm_bit value is retained, and the permission item is only marked with status=0 in the permission table, filtering it during encoding parsing. If the decimal permission code is null or an invalid value, it is automatically reset to 0 (i.e., no permission), and logged in the system log. Invalid requests can also be directly intercepted through interface parameter validation and Bloom filters, returning standardized error messages.

[0118] In one example, concurrent conflict handling can also be implemented. Combining optimistic locking, a `version` field is added to the `role` table. When updating the code, the `version` value is checked; if inconsistent, a conflict warning is returned. A conflict retry strategy can also be configured, such as setting an automatic retry mechanism of 3 times with a retry interval of 100ms. If a conflict still exists after 3 retryes, the administrator is prompted to operate later. For frequently updated "hot" roles, a pessimistic lock (SELECT ... FOR UPDATE) can be used to avoid frequent retries. When updating role permissions in batches, the update of each role is split into an independent transaction, reducing the conflict window and improving permission management efficiency.

[0119] This invention also provides performance testing of the permission management method. Referring to Tables 3 and 4, the core performance indicators of the permission management method of this invention are compared with existing / traditional solutions under different user scales and high-concurrency scenarios.

[0120] Table 3. Permission Management Response Efficiency under Different User Scales and Test Scenarios

[0121]

[0122] Table 4 Validation results of different functional indicators

[0123]

[0124] See Figure 5 The schematic structure of an embodiment of an electrostatic discharge protection device operation authorization device is shown.

[0125] Corresponding to the permission management method in the above embodiments, the present invention also provides an electrostatic protection equipment operation authorization device 200, which is composed of an electrostatic protection hardware unit 210 and a permission management unit 220.

[0126] For example, the electrostatic discharge protection hardware unit 210 includes an electrically connected metal plate connector, an electrostatic discharge circuit, an electrostatic sampling circuit, and a first microcontroller;

[0127] For example, the permission management unit 220 includes a second microcontroller and a memory. The memory stores a computer program, and when the computer program is executed by the second microcontroller, it implements the permission management method described in the above embodiments.

[0128] The electrostatic discharge protection hardware unit 210 is configured to grant the target operator the corresponding device operation authorization when the permission management unit 220 determines that the target operator has the permission to operate the device to be verified, and the first microcontroller detects that the electrostatic voltage of the target operator is less than or equal to the preset safety voltage.

[0129] The access control unit 220 specifically includes:

[0130] The mapping management module 221 is used to predefine the binary permission value corresponding to each permission item among multiple permission items and establish a unique mapping relationship between permission items and binary permission values;

[0131] The encoding generation module 222 is used to generate decimal permission codes for the role to be authorized based on a unique mapping relationship. The decimal permission code is represented by the decimal permission value obtained by performing an OR operation on the binary permission values ​​corresponding to each permission item possessed by the role to be authorized.

[0132] The permission verification module 223 is used to receive the target user identifier and the permission item to be verified in the permission verification request, determine the target role associated with the target user based on the target user identifier, and obtain the decimal permission code of the target role; and determine whether the target user has the permission of the permission item to be verified by performing binary operation between the binary permission value corresponding to the permission item to be verified and the decimal permission code of the target role.

[0133] In one example, the permission management unit 220 may also include: an encoding parsing module 224, a caching module 225, and a cache synchronization module 226.

[0134] The encoding parsing module 224 is used to reverse-parse the decimal permission code of a role into a list of permission items. Specifically, in the above embodiment, it involves: receiving a permission query request for a specified role; obtaining the decimal permission code of the specified role; iterating through the binary permission values ​​of all permission items, and for each permission item, performing a bitwise AND operation between its binary permission value and the decimal permission code; and identifying permission items whose result is not equal to 0 as the permission items possessed by the specified role.

[0135] The caching module 225 (e.g., Redis) is used to cache the decimal permission codes of roles. Specifically, in the above embodiment, it reads the decimal permission code corresponding to the target role identifier from the cache first; if the cache is not found, it queries the database for the decimal permission code of the target role and writes the queried decimal permission code into the cache.

[0136] The cache synchronization module 226 is used to perform delayed double-deletion strategies to maintain cache consistency when the decimal permission code is updated. Specifically, in the above embodiment, when the decimal permission code of the target role is updated in the database, the corresponding old code is immediately deleted from the cache (first deletion); then, after a short delay (e.g., 200 milliseconds), the deletion is attempted again (second deletion).

[0137] In one example, the caching module 225 and the cache synchronization module 226 are further optimized. For instance, for hot data caching, the role_perm_code of frequently accessed roles is cached in Redis (using a caching strategy such as LRU), and permission checks prioritize reading from the cache to reduce database access. For instance, for cache preheating, the decimal permission codes of the top 100 most frequently accessed roles are automatically loaded into the cache at system startup to avoid cache penetration during cold starts. For cache synchronization, when a role's decimal permission code is updated, the Redis cache is synchronously updated (using a "update database + delete cache" strategy) to ensure data consistency between the cache and the database.

[0138] Before operating precision electronic equipment (such as semiconductor manufacturing equipment and precision testing instruments), operators must undergo electrostatic discharge and pass identity and authorization verification to prevent damage to the equipment from static electricity and ensure that only authorized personnel can operate the equipment. Authorization verification is based not only on the operator's role (their decimal authorization code) but may also incorporate biometric information (such as fingerprints) for identity verification and checks whether the target equipment is currently under preset safe voltage conditions. Only when authorization verification is successful, identity is confirmed, and environmental safety conditions are met can the electrostatic discharge protection equipment operation authorization device 200 authorize the operation, thus achieving a balance between safety and management efficiency.

[0139] In this application scenario, the permission management method (permission management unit 220) of the present invention serves as the core permission engine in the background and is deeply integrated and works collaboratively with the electrostatic protection hardware unit 210 (including electrostatic detection metal sheet, electrostatic sampling circuit, discharge circuit, biometric module, microcontroller, etc.) through electrical interconnection.

[0140] In the permission management unit 220, various operations of the target device (i.e., the precision instrument to be operated) (such as "device start", "parameter adjustment", "maintenance mode entry", "data export" etc.) are defined as specific permission items.

[0141] Assign binary permission values ​​to these permission items. For example, the high-frequency basic operation "Device Startup" can be assigned to the low bit (e.g., 2). 0 =1、2 1 =2); High-risk operations such as "maintenance mode" are allocated to high positions (e.g., 2). 10 =1024、2 12 =4096).

[0142] Create roles for operators in different positions (such as "junior technician" and "senior engineer equipment administrator"), generate corresponding decimal permission codes for each role based on their responsibilities, and store them in the role table.

[0143] The microcontroller in the electrostatic discharge protection hardware unit 210, or the host computer communicating with it, is integrated with the permission verification module 223 in the permission management unit 220 via, for example, an API interface. The microcontroller or host computer pre-stores a unique mapping relationship between device operation permission items and binary permission values.

[0144] When an operator needs to operate a target device that is protected against electrostatic discharge, the following steps should be performed:

[0145] Step A: Biometric Identification and Identity Association. The operator touches the electrostatic detection metal plate with the integrated fingerprint recognition module. The host computer of the electrostatic protection hardware unit 210 of the electrostatic protection equipment operation authorization device 200 obtains the operator's fingerprint information (biometric information) and sends it as the target user identifier to the access control unit 220.

[0146] Step B: Decimal Permission Code Acquisition and Verification. The permission management unit 220 receives the user identifier and the permission item to be verified (e.g., "Target Device A - Start"). The system queries the user table based on the user identifier to determine the associated target role (e.g., "Senior Engineer"). It first retrieves the decimal permission code for this role from the cache (cache module 225, cache synchronization module 226); if the cache misses, it then retrieves it from the database. The system obtains the binary permission value corresponding to the "Target Device A - Start" permission item by querying a pre-stored unique mapping relationship. A binary operation is performed: decimal permission code & permission bit value. The result determines whether the user has device start permission. If no permission is granted, the process terminates, and an authorization failure is returned to the host computer.

[0147] Step C: Electrostatic Safety Status Detection. Simultaneously with Step B, the electrostatic protection hardware unit 210 performs parallel detection: when an operator touches the metal sheet, the electrostatic sampling circuit measures the electrostatic voltage of the operator's body in real time. The microcontroller compares the analog-to-digital converted electrostatic voltage value with the preset safety voltage threshold of the target device.

[0148] Step D: Comprehensive Authorization Decision. The host computer or microcontroller combines the two results from Step B and Step C: the "Operation Authorization Verification Result" (Boolean value) from the authorization management unit 220 and the "Electrostatic Safety Status Result" (electrostatic voltage ≤ safety threshold) from the electrostatic protection hardware unit 210.

[0149] Step E: Final Operation Authorization. Operation authorization for the device is granted to the operator only if both conditions are met: "Operation Permission Verification Result == TRUE" and "Electrostatic Safety Status Result == TRUE". The microcontroller or host computer can output an "Authorized" message (e.g., illuminate a green light) and unlock the device's operating interface.

[0150] In workshop environments with high-frequency entry, exit, and shift changes, the millisecond-level response speed of the permission management method of this invention matches the real-time performance of electrostatic discharge (ESD) detection. Administrators can quickly configure different combinations of operating permissions for different devices and levels, and efficiently distribute them through binary encoding. Simultaneously, optimistic locking and cache consistency mechanisms ensure accurate system data during multi-user permission configuration updates or high-concurrency attendance authorization. Furthermore, through cross-device permission synchronization, the decimal permission code of operators can be synchronized to mobile inspection terminals or ESD protection equipment at different workstations, achieving "one-time authorization, multiple uses."

[0151] The permission management method and electrostatic discharge protection equipment operation authorization device based on binary bit mapping provided in the embodiments of the present invention have at least one or a part of the following advantages:

[0152] (1) By encoding all the decimal permissions of a role into a single (or multiple) integer field for storage, the massive role-permission association records in traditional RBAC are replaced. In scenarios such as 5 million users and 20 permission items, the amount of stored data can be reduced from 100 million association records to 5 million user records. The database disk usage is reduced from about 100GB to less than 5GB, and the storage cost is reduced by more than 95%. This greatly alleviates the pressure on database storage and sharding, and storage efficiency is significantly improved.

[0153] (2) By replacing complex multi-table join queries with one or more in-memory AND operations, the performance of permission verification has achieved a qualitative leap. The response time of permission verification has been reduced from tens of milliseconds in the traditional RBAC scheme to sub-millisecond level. In high-concurrency scenarios (QPS=100,000), the average response time can be controlled within 0.8ms, and the database CPU utilization rate has been reduced from 90% to within 15%, enabling the system to support a much higher concurrent access volume than the traditional RBAC scheme, which is particularly suitable for high-concurrency scenarios.

[0154] (3) By adopting a three-layer architecture of “RBAC management layer + binary encoding operation layer + mapping adaptation layer”, the administrator can operate through the familiar RBAC visual interface and the system can automatically complete the generation, update and synchronization of binary encoding at the bottom layer. For example, when updating the permissions of 100,000 users in batches, only one encoding field of their associated role needs to be updated, which takes less than 1 millisecond, and all users take effect in real time. The operation efficiency is hundreds of times higher than that of traditional solutions, taking into account both management flexibility and operation and maintenance efficiency.

[0155] (4) By dividing binary bit ranges according to business modules and supporting the dynamic creation of multiple encoding segments, permission items can be extended non-intrusively. Adding new permissions does not require modifying the core table structure or batch updating historical data. The system can provide complete historical RBAC data migration scripts, support smooth transition, decouple the core operation logic from the specific database and development language, and has strong adaptability.

[0156] (5) By configuring the "Cache-Aside + Delayed Double Deletion" caching strategy, the concurrent update control based on optimistic locking and retry mechanism, the hot role degradation, and the Bloom filter to prevent cache penetration, the system ensures that in high-concurrency read and write scenarios, the system has a high cache hit rate (≥99%), a low update conflict rate (≤0.1%), strong data consistency, and stable and reliable system operation.

[0157] (6) In a multi-terminal system, permission synchronization only requires transmitting the user identifier and the decimal permission code of its role (one or several integers). The amount of data transmitted is reduced by more than 96% compared to transmitting a list of permission IDs. Each terminal can parse the complete permission list locally based on the pre-stored unique mapping relationship, which greatly reduces network bandwidth usage and interface latency, and improves the synchronization success rate and user experience.

[0158] While some embodiments of the present general inventive concept have been shown and described, those skilled in the art will understand that changes may be made to these embodiments without departing from the principles and spirit of the present general inventive concept, the scope of which is defined by the claims and their equivalents.

Claims

1. A permission management method based on binary bit mapping, characterized in that, The permission management method includes: Predefine the binary permission value corresponding to each of the multiple permission items; Based on the binary permission value, generate the decimal permission value corresponding to the permission item, and establish a unique mapping relationship between the permission item, the binary permission value, and the decimal permission value; Based on the unique mapping relationship, a decimal permission code is generated for the role to be authorized; The system receives the target user identifier and the permission item to be verified in the permission verification request, determines the associated target role based on the target user identifier, and obtains the decimal permission code of the target role. The decimal permission code is converted to binary to obtain the binary permission code; By performing a binary operation between the binary permission value corresponding to the permission item to be verified and the binary permission code of the target role, it is determined whether the target user has the permission for the permission item to be verified based on the operation result. The permission management method also includes a permission update step: Receive a permission update instruction for a target role, the permission update instruction including the identifier of the permission item to be added and / or the identifier of the permission item to be revoked; Based on the unique mapping relationship, determine the first binary permission value corresponding to the permission item to be added and / or the second binary permission value corresponding to the permission item to be revoked; Obtain the decimal permission code of the target role; Based on the first binary permission value, the decimal permission code is updated by an OR operation to obtain the first updated decimal permission code; and / or Based on the second binary permission value, the decimal permission code is updated by AND-NOT operation to obtain the second updated decimal permission code; Store the first updated decimal permission code and / or the second updated decimal permission code as the new decimal permission code for the target role.

2. The access control method according to claim 1, characterized in that, In the binary permission value, only one bit is set to 1, and the rest are all set to 0, and the positions of the corresponding 1 in the binary permission value of each permission item are different from each other.

3. The access control method according to claim 2, characterized in that, The number of bits in the binary permission value is determined based on the total number of permission items, and the number of bits is 2. n The digit is n∈N, where N is a natural number.

4. The access control method according to claim 2, characterized in that, The decimal permission encoding is obtained by performing bitwise operations or binary addition on the binary permission values ​​corresponding to each permission item possessed by the role to be authorized, and then converting the result into a decimal value. The decimal value is obtained by summing the decimal permission values ​​corresponding to each permission item.

5. The access control method according to claim 4, characterized in that, The bitwise operation performed on the binary permission values ​​corresponding to each permission item is an OR operation.

6. The access control method according to any one of claims 2-5, characterized in that, By performing a binary operation between the binary permission value corresponding to the permission item to be verified and the binary permission code of the target role, and determining whether the target user has the permission for the permission item to be verified based on the operation result, the following steps are taken: Perform a binary AND operation between the binary permission value corresponding to the permission item to be verified and the binary permission code of the target role. If the result of the binary AND operation is not all zeros, then it is determined that the target user has the permissions for the permission item to be verified. If the result of the binary AND operation is all 0, then it is determined that the target user does not have the permissions for the permission item to be verified.

7. The access control method according to claim 6, characterized in that, The method further includes performing a binary operation between the binary permission value corresponding to the permission item to be verified and the binary permission code of the target role, and determining whether the target user has the permission for the permission item to be verified based on the operation result. Before performing binary operations, compare the binary permission value corresponding to the permission item to be verified with the number of bits in the binary permission code of the target role. When the number of bits in the binary permission value corresponding to the permission item to be verified is the same as the number of bits in the binary permission code of the target role, a binary AND operation is performed. When the number of bits in the binary permission value corresponding to the permission item to be verified is different from the number of bits in the binary permission code of the target role, the binary with fewer bits is padded with zeros starting from the highest bit until the number of bits in the binary permission value corresponding to the permission item to be verified is the same as the number of bits in the binary permission code of the target role. Then, a binary AND operation is performed between the binary permission value corresponding to the permission item to be verified and the binary permission code of the target role.

8. The access control method according to claim 6, characterized in that, When a new permission causes the total number of accumulated permission items to exceed the number of bits in the existing binary permission value, the number of bits in the binary permission value will be updated to 2 from the date of the new permission. m The number of digits is m, where m > n, m ∈ N, and N is a natural number.

9. The access control method according to claim 8, characterized in that, When updating the number of bits in the binary permission value, the number of bits in the predefined binary permission value is also updated.

10. The access control method according to claim 2, characterized in that, The binary permission value corresponding to each of the predefined multiple permission items includes: Divide the data into multiple consecutive binary bit ranges according to business modules; Different binary permission values ​​within the binary bit range are assigned to different permission items within the same business module.

11. The access control method according to claim 10, characterized in that, When assigning binary permission values ​​to different permission items within the same business module, permission items with a usage frequency higher than a preset threshold are assigned to the lower bits within the binary bit range.

12. The access control method according to claim 1, characterized in that, The process of generating decimal permission codes for the role to be authorized includes: Receive an authorization instruction for the role to be authorized, the authorization instruction containing an identifier of at least one selected permission item; Based on the unique mapping relationship, determine the binary permission value corresponding to each selected permission item; Perform an OR or AND operation on all the determined binary permission values ​​to obtain the decimal permission code of the role to be authorized; The decimal permission code is stored in correspondence with the role identifier of the role to be authorized.

13. The access control method according to claim 12, characterized in that, While storing the decimal permission code corresponding to the role identifier of the role to be authorized, the association relationship between the role identifier of the role to be authorized and the permission identifier of each selected permission item is stored in the role and permission item association table.

14. The access control method according to claim 2, characterized in that, The permission management method also includes a decimal permission code parsing step: Receive permission query requests for a specified role; Obtain the decimal permission code for the specified role; Iterate through the binary permission values ​​of all permission items, and for each permission item, perform a bitwise AND operation between its binary permission value and the decimal permission code; Each non-zero bit in the calculation result is identified as a corresponding permission item possessed by the specified role.

15. The access control method according to claim 1, characterized in that, When updating the decimal permission code of the target role, an optimistic locking mechanism is used to control concurrent update conflicts.

16. The access control method according to claim 2, characterized in that, The step of obtaining the decimal permission code of the target role includes: First, read the decimal permission code corresponding to the target role identifier from the cache; If the cache misses, the decimal permission code of the target role is retrieved from the database and written into the cache.

17. The access control method according to claim 16, characterized in that, When the decimal permission code of the target role is updated, a delayed double-delete strategy is used to update the corresponding decimal permission code of the target role in the cache.

18. The access control method according to claim 16, characterized in that, The decimal permission code is stored in the role table of the database, and the role table includes a version number field. In response to the decimal permission code update operation, when updating the decimal permission code of the target role in the database, the version number field is checked and updated simultaneously.

19. The access control method according to claim 18, characterized in that, The database adopts a read-write separation architecture. The query operation corresponding to the permission verification request is executed on the slave database of the database, and the decimal permission code update operation is executed on the master database of the database.

20. The access control method according to any one of claims 10-19, characterized in that, When the permission management method is used in a multi-terminal system, it also includes a cross-terminal permission synchronization step: Receive a permission synchronization request from a client, the permission synchronization request including a user identifier; The user's associated role is determined based on the user identifier, and the decimal permission code of that role is obtained. Send the user identifier and the decimal permission code to the client; The client parses the received decimal permission code based on the unique mapping relationship between pre-stored permission items and binary permission values ​​to obtain a list of permission items owned by the user.

21. An operation authorization device for electrostatic discharge (ESD) protection equipment, comprising an ESD protection hardware unit and an access control unit, characterized in that, The electrostatic protection hardware unit includes an electrically connected metal plate connector, an electrostatic discharge circuit, an electrostatic sampling circuit, and a first microcontroller. The access control unit includes a second microcontroller and a memory. The memory stores a computer program. When the computer program is executed by the second microcontroller, it implements the access control method according to any one of claims 1-20. The electrostatic discharge protection hardware unit is configured to grant the target operator the corresponding device operation authorization when the permission management unit determines that the target operator has the permission to operate the device to be verified, and the first microcontroller detects that the target operator's electrostatic voltage is less than or equal to a preset safety voltage.

22. The electrostatic discharge protection equipment operation authorization device according to claim 21, characterized in that, The metal connector is connected to the metal plate, the electrostatic discharge circuit, and the electrostatic sampling circuit, respectively. The electrostatic sampling circuit includes a voltage divider circuit and a conditioning circuit, wherein the voltage divider circuit is connected to the metal plate connector and the conditioning circuit, respectively. The first microcontroller is communicatively connected to the electrostatic sampling circuit and the electrostatic discharge circuit, respectively, and is used to perform analog-to-digital conversion on the output voltage of the conditioning circuit to obtain the electrostatic voltage of the target operator, and control the electrostatic discharge circuit to be turned on or off.

23. The electrostatic discharge protection equipment operation authorization device according to claim 21 or 22, characterized in that, The access control unit includes: The mapping management module is configured to predefine the binary permission value corresponding to each permission item among multiple device operation permission items, generate the decimal permission value corresponding to the permission item based on the binary permission value, and establish a unique mapping relationship between the permission item, the binary permission value, and the decimal permission value. The encoding generation module is configured to generate decimal permission codes for device operation roles based on the unique mapping relationship. The decimal permission codes are represented by decimal permission values ​​obtained by performing an OR operation on the binary permission values ​​corresponding to each permission item possessed by the device operation role. The permission verification module is configured to receive a permission verification request containing the biometric information of the target operator and the operation permission item of the device to be verified; determine the associated target operation role based on the biometric information and obtain the decimal permission code of the target operation role; and perform binary operation between the binary permission value corresponding to the operation permission item of the device to be verified and the decimal permission code of the target operation role, and determine whether the target operator has the permission for the operation permission item of the device to be verified based on the operation result.

24. The electrostatic discharge protection equipment operation authorization device according to claim 23, characterized in that, The access control unit also includes: The cache module is configured with the decimal permission code for the cache device operation role; When obtaining the decimal permission code of the target operation role, the permission management unit first reads from the cache module; if no match is found, it queries the database.

25. The electrostatic discharge protection equipment operation authorization device according to claim 24, characterized in that, The permission management unit also includes a cache synchronization module, which is configured to update the corresponding decimal permission code in the cache module using a delayed double-deletion strategy when the decimal permission code of the device operation role is updated.

26. The electrostatic discharge protection equipment operation authorization device according to claim 25, characterized in that, The permission management unit also includes an encoding parsing module, configured to, Receive permission query requests for the specified device operation role; Obtain the decimal permission code of the specified device operation role; Traverse all binary permission values ​​of device operation permission items, and determine the permission items whose result of AND operation between the binary permission value and the decimal permission code is not equal to zero as the permission items owned by the specified device operation role.

Images