Method and system for multi-level authority classification management of parameters of production line test equipment, storage medium and electronic device

Abstract

The application relates to the field of computer and automation control technology, and discloses a production line test equipment parameter multistage permission hierarchical management method, a system, a storage medium and electronic equipment.The method comprises the following steps: obtaining the role level and the corresponding access permission matrix of a current user through user identity authentication, and dynamically rendering a parameter configuration interface according to the access permission matrix; in response to a parameter modification request, performing permission verification based on the access permission matrix and intercepting an unauthorized operation; after each parameter modification operation is completed, generating a structured operation log containing the numerical values before and after parameter modification, the identity of an operator, a timestamp and workstation information, and storing the structured operation log in a log record chain; and synchronizing the operation log and parameter configuration change information to a cloud server; the role-based differentiated permission control and whole-process operation trace of production line test parameters are realized, the risk of unauthorized modification of key test parameters is effectively prevented, and the safety and traceability of production and measurement parameter management are improved.

Description

Technical Field

[0001] This invention relates to the field of computer and automation control technology, and in particular to a method, system, storage medium and electronic device for multi-level permission hierarchical management of parameters of production line testing equipment. Background Technology

[0002] In the mass production of audio electronic products, the various test parameters configured in the production testing tools (including but not limited to audio performance pass thresholds, sensor response thresholds, interface connectivity criteria, sampling frame count, timeout time, and retry count) directly determine the standards for judging the quality of the products leaving the factory and are core elements of the product quality control system. The accuracy and consistency of the production testing parameters are related to the quality qualification assessment of the entire batch of products and have a significant impact on the company's quality reputation and compliance.

[0003] However, current production testing tools generally suffer from a systemic problem of inadequate parameter management permissions. Firstly, most production testing tools grant the same modification permissions to all logged-in users through their parameter configuration interfaces, failing to tier permissions based on operator job responsibilities and professional capabilities. This allows frontline operators, unfamiliar with parameter meanings, to mistakenly modify critical thresholds that shouldn't be adjusted, posing a significant quality risk of defective products being released due to unintended adjustments. Secondly, parameter modifications often take effect immediately without any approval or confirmation process. In the absence of interception mechanisms, accidental or malicious alterations can directly impact the quality judgment standards of subsequent production batches, and there is also the possibility of maliciously tampering with test parameters to cover up product defects. Thirdly, existing systems generally lack comprehensive parameter modification logging capabilities, leaving no trace of parameter modifications and making it impossible to trace the responsible party afterward. This fails to meet the management needs for quality traceability and accountability, posing a significant hidden danger to product quality control. Fourth, in multi-workstation and multi-production-line scenarios, existing solutions lack centralized management and consistency verification of parameter versions, which can easily lead to inconsistent parameter configurations at different workstations, resulting in inconsistent test results for the same product at different workstations. This seriously affects the uniformity and reliability of quality judgment.

[0004] Therefore, there is an urgent need to establish a production line test parameter management method with role-based hierarchical access control, approval processes, and complete operation traceability capabilities, so as to fundamentally improve the security, traceability, and consistency management level of production test parameters. Summary of the Invention

[0005] This invention provides a method, system, storage medium, and electronic device for multi-level permission hierarchical management of production line testing equipment parameters. Its purpose is to achieve controllable and auditable management of the entire lifecycle of test parameters through role hierarchical classification, permission matrix mapping, approval process, and tamper-proof log chain, thereby improving the security and traceability of the production testing process.

[0006] On the one hand, the present invention provides a method for multi-level access control of parameters of production line testing equipment, including the following steps: In response to user authentication, obtain the current user's role level and access permission matrix. The access permission matrix defines the operation permissions of different role levels for various test parameters. The operation permissions include at least invisible, read-only, and modifiable. Based on the access permission matrix, the parameter configuration interface of the production testing tool is dynamically rendered, so that users can only perform modification operations on parameters that they have the permission to modify. In response to a user's parameter modification request, an access permission check is performed on the parameter modification request based on the access permission matrix. If the check passes, the parameter modification operation is allowed; if the check fails, the operation is blocked and an unauthorized attempt log is recorded. After each parameter modification operation is completed, a structured operation log is generated. The operation log includes at least the parameter name, the value before modification, the value after modification, the operator's identity, the operation timestamp, and the workstation information from which the operation originated. The hash value of this operation log is associated with the hash value of the previous operation log record in the log record chain to calculate the hash value of this operation log record, forming a tamper-proof log record chain linked in chronological order. The operation log is then stored in the log record chain. The operation logs and parameter configuration change information will be synchronized to the cloud server for auditing and traceability by the quality management department.

[0007] Furthermore, the role levels include at least operator, engineer, and administrator roles. The operator role only has the permission to view test parameters, the engineer role has the permission to modify non-critical debugging parameters, and the administrator role has the permission to modify all test parameters. Each role corresponds to a unique account system and login credentials.

[0008] Furthermore, the method for establishing the access permission matrix includes: Each configurable test parameter is labeled with a sensitivity level, which includes at least low sensitivity, medium sensitivity and high sensitivity, and an access permission mapping matrix between parameters and roles is established; The access permissions for each role to each type of test parameter are clearly defined. The access permission matrix is ​​centrally managed in the form of an encrypted configuration file. The encrypted configuration file is stored using a symmetric encryption algorithm. The decryption key is dynamically obtained from the cloud authentication server through a secure handshake protocol when the production testing tool's main program starts.

[0009] Furthermore, the user authentication supports password login and / or contactless identity card login. After successful login, the system interface displays the identity information and role level of the currently logged-in user. The user authentication also includes an automatic logout mechanism for session timeout: The system has a preset idle timeout period. If the user does not perform any operation within the preset idle timeout period, the current session will be automatically logged out and the parameter modification entry will be locked.

[0010] Furthermore, the permission verification includes front-end interface layer verification and back-end application interface layer verification, wherein: The front-end interface layer verification achieves access control for the operation entry by disabling input boxes with parameters that do not have permission and making read-only parameters viewable but not editable. The backend application interface layer verification is achieved by verifying whether the role permissions corresponding to the user identity token carried in the parameter modification request match the sensitivity level of the target parameter. If the match fails, execution is refused and an insufficient permission error is returned, forming a defense-in-depth mechanism between the frontend and the backend.

[0011] Furthermore, the unauthorized access attempt log includes at least the identity of the person attempting the operation, the timestamp of the operation, the name of the parameter to be modified, and the target value. The unauthorized access attempt log is uploaded to the cloud security monitoring platform in real time and triggers an alarm notification.

[0012] Preferably, the permission verification also includes a secondary authentication mechanism for highly sensitive operations: When the parameter modification request targets a highly sensitive parameter, a secondary authentication process is triggered after the permission verification is passed, requiring the current user to resubmit identity verification credentials. The parameter modification operation is only allowed after the secondary authentication is passed. The identity verification credentials include, but are not limited to, login password, dynamic verification code and biometric information.

[0013] Furthermore, the generation of structured operation logs also includes a parameter modification approval process: When the target parameter of the parameter modification request is a highly sensitive parameter, the parameter modification request is submitted to the approval process. An administrator with approval authority will make an approval decision on the modification request. Only after the approval is approved can the parameter modification request enter the execution stage. The approval result is fed back to the applicant in real time. After the approved parameter change takes effect, a unique version number is assigned.

[0014] Furthermore, the tamper-proof log record chain formed by linking records in chronological order also includes: When a discontinuous hash check is detected between any two adjacent operation log records in any node of the log record chain, it is determined that the log record segment has been tampered with and a security alarm is triggered.

[0015] Furthermore, the method also includes parameter version management: For each type of test parameter set, maintain a complete historical version storage by product type. After each parameter change takes effect, the old version parameter set is fully archived and retained instead of being directly overwritten and deleted. Administrators with the appropriate permissions can view complete parameter snapshots of any historical version and perform a one-click rollback to a specified historical version. The rollback operation is recorded in the log record chain as a new parameter change.

[0016] Furthermore, the method also includes multi-station parameter version consistency verification: The system performs centralized verification of the current effective parameter version number of all online workstations according to a preset cycle. It compares the current parameter version number of each workstation with the latest version number stored on the cloud server. If the parameter version number of a workstation is found to be inconsistent with the latest version number, a forced synchronization operation is automatically triggered to push the parameter configuration of the latest version number to the workstation and generate an alarm message.

[0017] Furthermore, the cloud server provides the function of retrieving and auditing parameter change history. The quality management department can query the parameter change history by work position, by time period, or by parameter name on the cloud platform. The cloud server is configured with abnormal change detection rules. When the number of times the same parameter is modified within a preset time window exceeds a preset threshold, an abnormal alarm notification is automatically triggered.

[0018] On the other hand, the present invention provides a multi-level access control system for production line testing equipment parameters, comprising: The user authentication and permission matrix loading module is used to obtain the role level and access permission matrix corresponding to the current user in response to user authentication. The access permission matrix defines the operation permissions of different role levels for various test parameters. The operation permissions include at least invisible, read-only, and modifiable. The parameter configuration interface dynamic rendering module is used to dynamically render the parameter configuration interface of the production testing tool according to the access permission matrix, so that users can only perform modification operations on parameters that they have the right to modify. The permission verification and operation interception module is used to respond to the parameter modification request submitted by the user, perform permission verification on the parameter modification request based on the access permission matrix, and allow the parameter modification operation to be performed if the verification passes, and intercept the operation and record the unauthorized attempt log if the verification fails. The operation log generation and recording module is used to generate a structured operation log after each parameter modification operation is completed. The operation log includes at least the parameter name, the value before modification, the value after modification, the operator's identity, the operation timestamp, and the workstation information from which the operation originated. The module associates the hash value of this operation log with the hash value of the previous operation log record in the log record chain to calculate the hash value of this operation log record, forming a tamper-proof log record chain linked in chronological order. The operation log is then stored in the log record chain. The cloud synchronization and audit traceability module is used to synchronize the operation logs and parameter configuration change information to the cloud server for the quality management department to conduct audit traceability.

[0019] In addition, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the multi-level permission hierarchical management method for production line testing equipment parameters as described above.

[0020] Meanwhile, an electronic device is provided, comprising: one or more processors; and a storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the multi-level permission hierarchical management method for production line testing equipment parameters as described above.

[0021] Compared with the prior art, the beneficial effects of the present invention are: (1) This invention enables users to operate only the parameters within their authorized scope by using role classification and permission matrix mapping, thereby eliminating the possibility of unauthorized modification of key test parameters from the entry point and effectively preventing the risk of defective products being released due to misoperation or malicious tampering. (2) This invention performs permission verification before parameter modification and intercepts unauthorized operations. At the same time, it combines the permission re-verification mechanism of the backend API layer to form a defense in depth, fundamentally preventing unauthorized tampering behavior that bypasses the front-end interface. (3) After each parameter modification, the present invention automatically generates a structured operation log containing the parameter values ​​before and after, the operator's identity, timestamp and workstation information, and links each log in a hash chain to form a tamper-proof chain structure, so as to realize full traceability of parameter changes, tamper-proof and verifiable, and solve the problems of no modification record, difficulty in tracing responsibility and the possibility of the log itself being tampered with afterward. (4) This invention synchronizes operation logs and parameter configuration change information to cloud storage, enabling the quality management department to retrieve and audit the parameter change history of any workstation and any time period at any time, providing reliable data support for quality anomaly identification and system certification audit. Attached Figure Description

[0022] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings: Figure 1 This is a flowchart of a multi-level permission hierarchical management method for parameters of production line testing equipment according to the present invention; Figure 2 This is a structural block diagram of a multi-level permission hierarchical management system for production line testing equipment parameters according to the present invention; Figure 3 This is a schematic diagram of an embodiment of an electronic device according to the present invention. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0024] The specific embodiments of the present invention will be described below with reference to the accompanying drawings and examples.

[0025] Example 1

[0026] This embodiment uses the method described in this invention to manage multi-level access permissions for audio testing equipment on a production line in an audio electronics manufacturing plant, as an example to further illustrate the invention. The production line involved in this embodiment has 12 testing stations distributed across 3 production lines. Each production line is equipped with 4 All-In-One production line testing tools. Each testing tool runs on an independent industrial control computer, and each industrial control computer communicates with the company's domain account server and cloud-based parameter management platform through the factory's internal network. The production line operates in two shifts daily, with several operators per shift, and additional on-duty engineers and quality management personnel providing online support.

[0027] The specific implementation steps are as follows, please refer to [link / reference]. Figure 1 The technical solution provided in this embodiment includes the following steps: S1: In response to user authentication, obtain the role level and access permission matrix corresponding to the current user. The access permission matrix defines the operation permissions of different role levels for various test parameters. The operation permissions include at least invisible, read-only and modifiable. S2: Based on the access permission matrix, dynamically render the parameter configuration interface of the production testing tool so that users can only perform modification operations on parameters that they have the permission to modify. S3: In response to the parameter modification request submitted by the user, perform permission verification on the parameter modification request based on the access permission matrix. If the verification passes, the parameter modification operation is allowed. If the verification fails, the operation is intercepted and an unauthorized attempt log is recorded. S4: After each parameter modification operation is completed, a structured operation log is generated. The operation log includes at least the parameter name, the value before modification, the value after modification, the operator's identity, the operation timestamp, and the workstation information from which the operation originated. The hash value of this operation log is associated with the hash value of the previous operation log record in the log record chain to calculate the hash value of this operation log record, forming a tamper-proof log record chain linked in chronological order. The operation log is then stored in the log record chain. S5: Synchronize the operation logs and parameter configuration change information to the cloud server for auditing and traceability by the quality management department.

[0028] First, user login and permission matrix loading are performed in step S1. The role levels include at least operator, engineer and administrator roles. The operator role only has the permission to view test parameters, the engineer role has the permission to modify non-critical debugging parameters, and the administrator role has the permission to modify all test parameters. Each role corresponds to a unique account system and login credentials.

[0029] Secondly, the method for establishing the access permission matrix includes: S11: Label each configurable test parameter with a sensitivity level, the sensitivity level including at least low sensitivity level, medium sensitivity level and high sensitivity level, and establish an access permission mapping matrix between parameters and roles; S12: Clearly define the access permissions of each role to each type of test parameter. The access permission matrix is ​​centrally managed in the form of an encrypted configuration file. The encrypted configuration file is stored using a symmetric encryption algorithm. The decryption key is dynamically obtained from the cloud authentication server through a secure handshake protocol when the production testing tool's main program starts.

[0030] The user authentication supports password login and / or contactless identity card login. After successful login, the system interface displays the identity information and role level of the currently logged-in user. In addition, the user authentication also includes an automatic logout mechanism for session timeout: The system has a preset idle timeout period. If the user does not perform any operation within the preset idle timeout period, the current session will be automatically logged out and the parameter modification entry will be locked.

[0031] Specifically, in this embodiment, when deploying this method, the factory pre-creates unique accounts and assigns role levels to all production line personnel in the domain account server. In this embodiment, a total of 128 operator accounts, 15 engineer accounts, and 3 administrator accounts (2 of which are quality managers and 1 is a production line supervisor) are created. The role level information of each account is connected to the permission system of the production testing tool through a single sign-on protocol based on Security Assertion Markup Language (SAML).

[0032] After account creation, the system administrator uses the permission configuration interface of the production testing tool to label the sensitivity level of each type of test parameter and establish an access permission matrix between parameters and roles. The main test parameters and their sensitivity level labels involved in this embodiment are as follows: Audio total harmonic distortion plus noise (THD+N) pass threshold (high sensitivity), directly affects the final PASS / FAIL determination of the product; signal-to-noise ratio (SNR) lower limit threshold (high sensitivity); left and right channel balance tolerance (high sensitivity); ambient light sensor (ALS) brightness difference threshold (high sensitivity); log output level (low sensitivity), only affects the level of detail of debugging information; interface display refresh interval (low sensitivity).

[0033] The configuration principle for the access permission matrix is ​​as follows: for highly sensitive parameters, the operator role is set to "invisible," the engineer role to "read-only," and the administrator role to "modifiable"; for less sensitive parameters, the operator role is set to "read-only," the engineer role to "modifiable," and the administrator role to "modifiable." The access permission matrix configuration file is written in JavaScript Object Notation (JSON) format and encrypted using the Advanced Encryption Standard (AES-256) algorithm, stored on the local industrial control computer's solid-state drive. The decryption key is not stored on disk but is dynamically obtained by the production testing tool's main program each time it starts, after completing two-way certificate authentication with the cloud authentication server via Transport Layer Security (TLS).

[0034] For example, operator Zhang arrives at workstation 2 on Line 1 and starts the production testing tool. After the tool starts, the login interface loads first. Zhang places his RFID work card near the reader. After the system reads the work card information, it automatically sends an authentication request to the domain account server. After successful authentication, Zhang logs into the system as an "operator". After successful login, the status bar at the top of the production testing tool interface displays "Current User: Zhang** / Role: Operator". At the same time, the system loads the decrypted access permission matrix from the local machine according to Zhang's role level.

[0035] Based on the authentication results described above, the parameter configuration interface in step S2 is dynamically rendered. Specifically, the interface rendering engine of the production testing tool dynamically generates the parameter configuration page according to the loaded access permission matrix. In this embodiment, when operator Zhang logs in and opens the parameter configuration interface, all parameter input boxes on the interface are grayed out and displayed with the currently effective values. However, no input box can receive focus or accept keyboard input. Zhang can only browse the current settings of various test parameters and does not have the ability to modify any parameters. For highly sensitive parameters (such as the THD+N pass threshold), not only are the input boxes disabled, but a read-only label is also displayed next to the parameter name to indicate to the user that the parameter is protected by permissions.

[0036] When engineer Li logged in using his card on the same device, the interface dynamically switched. Li, a process engineer responsible for the audio testing process on Line 1, opened the parameter configuration interface after logging in. The input boxes for low-sensitivity parameters (such as log output level) were editable (white background), while high-sensitivity parameters (such as THD+N pass threshold and SNR lower limit threshold) remained grayed out and disabled. Li could only view their values ​​but could not modify them. When the administrator (quality manager Wang) logged in, all parameter input boxes were editable, but the high-sensitivity parameters still had an additional security label, indicating that secondary authentication was required to modify them.

[0037] Next, step S3 involves intercepting the parameter modification request and verifying permissions. The permission verification includes front-end UI layer verification and back-end application interface layer verification, wherein: S31: The front-end interface layer verification achieves access control for the operation entry by disabling input boxes with parameters without permissions and making read-only parameters viewable but not editable. S32: The backend application interface layer verification is achieved by verifying whether the role permissions corresponding to the user identity token carried in the parameter modification request match the sensitivity level of the target parameter. If the match fails, execution is refused and an insufficient permission error is returned, forming a defense-in-depth mechanism between the frontend and the backend.

[0038] The unauthorized access attempt log includes at least the identity of the person attempting the operation, the timestamp of the operation, the name of the parameter to be modified, and the target value. The unauthorized access attempt log is uploaded to the cloud security monitoring platform in real time and triggers an alarm notification.

[0039] In addition, the permission verification also includes a secondary authentication mechanism for highly sensitive operations: S33: When the target parameter of the parameter modification request is a highly sensitive parameter, a secondary authentication process is further triggered after the permission verification is passed, requiring the current user to resubmit the identity verification credentials. The parameter modification operation is only allowed after the secondary authentication is passed. The identity verification credentials include, but are not limited to, login password, dynamic verification code and biometric information.

[0040] In this embodiment, one day, due to customer feedback that the audio performance margin of a certain batch of products was insufficient, Quality Manager Wang logged into the production testing tool and attempted to adjust the THD+N pass threshold from the original setting of 1.0% to 0.8% to tighten the quality control standards. Wang changed the value in the THD+N threshold input box from "1.0" to "0.8" in the parameter configuration interface and clicked the "Save" button. The system front-end interface layer first performed permission verification, confirming that the current user (administrator role) had "modifiable" permission for the parameter. After the front-end verification passed, the parameter modification request was encapsulated into a data packet containing the user's identity token, parameter identifier, modified value, and current timestamp, and sent to the back-end application interface of the production testing tool via Hypertext Transfer Security Protocol (HTTPS).

[0041] Upon receiving the request, the backend application interface first parses and verifies the validity of the user's identity token (including whether the token has expired or been forged). After confirming the token's validity, it extracts the current user's role level information and compares it with the records in the access permission matrix—confirming that the "Administrator" role has "modifiable" permission for the parameter "THD+N Qualified Threshold". Because this parameter is marked as highly sensitive, the backend further triggers a two-factor authentication process after the permission verification passes, returning a two-factor authentication challenge to the client, requiring the current user to re-enter their login password before continuing.

[0042] The production testing tool interface immediately displayed a password verification dialog box, prompting "The current operation involves highly sensitive parameters. Please re-enter your password to confirm your identity." Wang entered his password and clicked confirm. The client then hashed the password input and bound it to the request, sending it back to the backend. The backend verified the password's correctness through the domain account server, and the secondary authentication was successful. At this point, the entire permission verification chain was complete. The backend wrote the new parameter value "0.8" to the local parameter configuration file and simultaneously submitted the parameter change record to the operation log module.

[0043] If an attempt is made to bypass the front-end interface and directly call the API for unauthorized modifications, for example, if a technician uses an application programming interface debugging tool (Postman) for testing purposes to send a parameter modification request to the back-end API along with an operator role identity token, the back-end API will re-verify the role permissions corresponding to the token before performing any actual operation. If it finds that the "operator" role does not have "modify" permission for the highly sensitive parameter, it will immediately refuse to execute the request and return an HTTP 403 status code (insufficient permissions error), and record this unauthorized attempt in a detailed unauthorized attempt log.

[0044] As a preferred embodiment of the present invention, the triggering conditions for the aforementioned secondary authentication and approval processes are not limited to the static determination of parameter sensitivity levels. The present invention also provides a dynamic operational risk scoring algorithm to comprehensively assess the risk level of each parameter modification operation and dynamically determine whether secondary authentication needs to be triggered or whether the modification needs to be upgraded to an approval process. This algorithm comprehensively considers four dimensions of risk factors: parameter sensitivity normalized score... Risk factors during operation period Operator's historical anomaly score and the magnitude of modification risk factor Comprehensive risk score The calculation formula is: , Among them, the comprehensive risk score The value ranges from [0, 1], with a larger value indicating a higher risk of parameter modification. The parameter sensitivity normalization score is obtained by mapping the pre-labeled sensitivity levels (low / medium / high) of the parameters to 1 / 2 / 3 respectively, and then dividing by 3. That is, low sensitivity is 0.33, medium sensitivity is 0.67, and high sensitivity is 1.0; risk factor during operation period. A score of 0 is assigned to regular working hours (e.g., 08:00-20:00), and a score of 1 is assigned to irregular hours (e.g., night shifts, holidays); operator's historical anomaly score. Record the number of times the operator attempted to exceed authorization and made abnormal modifications within the past 30 days. and in accordance with Normalization was performed; the magnitude risk factor was modified. Take the absolute value of the difference between the values ​​before and after this modification, and then proceed accordingly. Normalization processing; , , , and are the weight coefficients of the four factors, respectively, satisfying It can be preset by the quality department based on historical data or expert experience, and can be configured separately according to parameter type or production line scenario.

[0045] The system pre-sets risk thresholds (For example, 0.6), when the calculated comprehensive risk score When the system determines that the operation is high-risk, in addition to triggering secondary authentication, it will automatically escalate to requiring an approval process before execution; At this time, the system will process the request according to the standard access control process (e.g., only triggering secondary authentication, without mandatory approval).

[0046] The following explanation uses the operation of Quality Manager Wang in this embodiment as an example. The historical statistical standard deviation of the THD+N pass threshold parameter is set. Weighting , , , Risk threshold .

[0047] In this embodiment, Wang logged into the system at 22:15 during the night shift and attempted to change the THD+N qualification threshold from 1.0% to 1.5%. The system found that Wang had one unauthorized access attempt record within the past 30 days. , , , .but The system judged this as a high-risk operation and, in addition to secondary authentication, automatically upgraded the modification to a mandatory approval process (rather than the simplified path of direct modification by the administrator in the original embodiment). If Wang made a 0.1% adjustment to this parameter at 10:00 AM during the day... , , , ,but The risk was determined to be a routine risk, requiring only secondary authentication and no mandatory upgrade approval, consistent with the original implementation's "direct administrator operation" processing path. The comparison of the two scenarios demonstrates the algorithm's ability to differentiate risks.

[0048] Through the aforementioned dynamic scoring algorithm, this invention enables differentiated control of the same parameter under different operational scenarios. This avoids excessive approval of low-risk operations that could impact production efficiency, while simultaneously enhancing the interception of high-risk operations, further improving the security and flexibility of production testing parameter management. All input data for this algorithm (parameter sensitivity labeling, operation timestamps, operator history logs, and values ​​before and after modification) have already been recorded and retained in the original embodiments of the specification, requiring no additional data collection and resulting in low implementation costs.

[0049] After verification, the key parameter modification approval process in step S4 is performed. The generation of the structured operation log also includes a parameter modification approval process: When the target parameter of the parameter modification request is a highly sensitive parameter, the parameter modification request is submitted to the approval process. An administrator with approval authority will make an approval decision on the modification request. Only after the approval is approved can the parameter modification request enter the execution stage. The approval result is fed back to the applicant in real time. After the approved parameter change takes effect, a unique version number is assigned.

[0050] Specifically, the tamper-proof log record chain formed by linking records in chronological order also includes: When a discontinuous hash check is detected between any two adjacent operation log records in any node of the log record chain, it is determined that the log record segment has been tampered with and a security alarm is triggered.

[0051] In this embodiment, after each successful parameter modification operation, the operation log module generates a complete structured operation log. Taking this THD+N threshold modification as an example, the generated log record contains the following fields: Parameter Name: THD+N Pass Threshold; Original Value: 1.0%; Modified Value: 0.8%; Operator Account: Wang Moumou (EMP0512); Operator Role: Administrator; Operation Timestamp: 2025-03-15 10:23:45 (Beijing Time, accurate to the second); Operation Source Workstation: LINE1-ST02; Reason for Modification: Customer feedback indicates insufficient audio margin in the product, requiring stricter control; Approver: No approval required (administrator operates directly).

[0052] After a log is generated, the system concatenates the hash value of the current log record with the hash value of the previous historical log record to calculate the hash value of the current log record. Then, the system stores the current log record and its hash value together in the log record chain. The log record chain is stored as an independent file in the protected system partition of the local industrial control computer and is simultaneously uploaded asynchronously to the cloud parameter management platform via HTTPS.

[0053] In addition, the method also includes parameter version management: For each type of test parameter set, maintain a complete historical version storage by product type. After each parameter change takes effect, the old version parameter set is fully archived and retained instead of being directly overwritten and deleted. Administrators with the appropriate permissions can view complete parameter snapshots of any historical version and perform a one-click rollback to a specified historical version. The rollback operation is recorded in the log record chain as a new parameter change.

[0054] In this embodiment, during a subsequent log integrity check, the system discovered a discontinuous hash checksum for a certain historical log segment. The system immediately determined that this log segment might have been tampered with, triggered a security alarm, and froze the corresponding workstation's access to the production testing tools, awaiting intervention from the IT security team. The investigation confirmed that the data bit flipping was caused by hard drive damage, not malicious tampering. After repair, the workstation's operating permissions were restored.

[0055] After recording in the evening, step S5 is performed for cloud synchronization and audit traceability. When storing data in the cloud, the method also includes multi-station parameter version consistency verification: The system performs centralized verification of the current effective parameter version number of all online workstations according to a preset cycle. It compares the current parameter version number of each workstation with the latest version number stored on the cloud server. If the parameter version number of a workstation is found to be inconsistent with the latest version number, a forced synchronization operation is automatically triggered to push the parameter configuration of the latest version number to the workstation and generate an alarm message.

[0056] The cloud server provides the function of retrieving and auditing parameter change history. The quality management department can query the parameter change history by work position, time period or parameter name on the cloud platform. The cloud server is configured with abnormal change detection rules. When the number of times the same parameter is modified within a preset time window exceeds a preset threshold, an abnormal alarm notification is automatically triggered.

[0057] In this embodiment, all operation logs and parameter configuration change information are uploaded asynchronously to the centralized log platform in the cloud via HTTPS in real time. In this embodiment, if a log fails to upload on the first attempt due to network jitter, the system automatically initiates an exponential backoff retry mechanism, retrying after 5 seconds, 10 seconds, and 20 seconds respectively, and finally succeeds in uploading on the third retry.

[0058] Quality engineers in the quality management department can log in to the audit system via a browser on the cloud platform to search and query parameter change history by workstation, time period, parameter name, or operator. For example, when a batch of products has a quality anomaly, the quality engineer logs into the audit system and sets the query conditions, namely the time range "2025-03-15 00:00:00 to 2025-03-15 23:59:59", workstation "LINE1-ST02", and parameter "THD+N qualified threshold". The system returns all four parameter change history records for that workstation within one second, including the values ​​before and after each modification, the operator, the timestamp, and the reason for the modification, providing complete data support for quality traceability.

[0059] Meanwhile, the cloud server is configured with abnormal change detection rules: an alarm is triggered if the same parameter is modified more than 3 times within 10 minutes. One day, the system detected that the signal-to-noise ratio parameter of workstation LINE2-ST05 was modified 4 times consecutively within 10 minutes. The system automatically triggered an abnormal alarm notification to the workstation supervisor's enterprise instant messaging tool. The supervisor checked on-site and confirmed that it was due to engineers frequently and temporarily adjusting parameters to optimize the test algorithm during debugging, and was not malicious behavior. The alarm was automatically archived for future reference, and did not affect the production line operation.

[0060] In addition, the system uses a one-way message queue telemetry transport protocol (MQTT) to continuously broadcast the latest parameter version number from the cloud to all online production testing tool clients. Each client subscribes to this broadcast topic and monitors the consistency between the local parameter version and the latest version on the cloud in real time. Early that morning, due to maintenance of the factory's core switch, the network was interrupted for approximately 12 minutes. During this period, the LINE3-ST04 workstation failed to receive the parameter update broadcast in a timely manner. After the network was restored, the client at this workstation automatically compared its local version number with the latest version number on the cloud in the next round of heartbeat reporting. Finding that the version was outdated, it immediately triggered forced synchronization and generated an alarm log, prompting the production line supervisor that "the LINE3-ST04 workstation may have been running with an older version of parameters between 08:12 and 08:24; it is recommended to conduct a quality review of products produced during this period."

[0061] In summary, the implementation results of this embodiment demonstrate that the method of this invention fundamentally improves the security and traceability of parameter management in production line testing tools. By combining role-based access control with dynamic interface rendering, the possibility of unauthorized personnel misoperating or maliciously tampering with key test parameters is eliminated at the entry point. Through dual access control verification and secondary authentication mechanisms at the front-end UI layer and back-end API layer, an effective defense-in-depth system is formed. By storing data in a hash chain and synchronizing it with the cloud, tamper-proof traceability and full lifecycle auditable management of parameter changes are achieved.

[0062] Based on the above method, this embodiment also provides a multi-level access control system for production line testing equipment parameters, including: User authentication and permission matrix loading module 10 is used to obtain the role level and access permission matrix corresponding to the current user in response to user identity authentication. The access permission matrix defines the operation permissions of different role levels for various test parameters. The operation permissions include at least invisible, read-only and modifiable. The parameter configuration interface dynamic rendering module 20 is used to dynamically render the parameter configuration interface of the production testing tool according to the access permission matrix, so that users can only perform modification operations on parameters that have modification permissions. The permission verification and operation interception module 30 is used to respond to the parameter modification request submitted by the user, perform permission verification on the parameter modification request based on the access permission matrix, and allow the parameter modification operation to be performed if the verification passes, and intercept the operation and record the unauthorized attempt log if the verification fails. The operation log generation and recording module 40 is used to generate a structured operation log after each parameter modification operation is completed. The operation log includes at least the parameter name, the value before modification, the value after modification, the operator's identity, the operation timestamp, and the workstation information from which the operation originated. The module associates the hash value of this operation log with the hash value of the previous operation log record in the log record chain to calculate the hash value of this operation log record, forming a tamper-proof log record chain linked in chronological order. The module then stores the operation log in the log record chain. The cloud synchronization and audit traceability module 50 is used to synchronize the operation logs and parameter configuration change information to the cloud server for the quality management department to conduct audit traceability.

[0063] It should be noted that the steps in the multi-level permission hierarchical management method for production line testing equipment parameters provided in this embodiment can be implemented based on the corresponding modules in the multi-level permission hierarchical management system for production line testing equipment parameters. Those skilled in the art can refer to the technical solution of the system to implement the steps of the method. That is, the embodiments in the system can be understood as preferred examples of implementing the method, and will not be elaborated here.

[0064] This embodiment also provides an electronic device, such as... Figure 3 As shown, the electronic device includes a processor 14 and a memory 13. The memory 13 stores machine-executable instructions that can be executed by the processor 14. The processor 14 executes the machine-executable instructions to implement the above-mentioned multi-level permission hierarchical management method for production line testing equipment parameters.

[0065] Furthermore, Figure 3 The electronic device shown also includes a bus 12 and a communication interface 11, with the processor 14, the communication interface 11 and the memory 13 connected via the bus 12.

[0066] The memory 13 may include high-speed random access memory (RAM) and may also include non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one communication interface 11 (which can be wired or wireless), such as the Internet, wide area network, local area network, metropolitan area network, etc. The bus 12 may be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 3 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0067] Processor 14 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of processor 14 or by instructions in software form. Processor 14 can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in this embodiment. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this embodiment can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory 13. The processor 14 reads the information in memory 13 and, in conjunction with its hardware, completes the steps of the multi-level permission hierarchical management method for production line test equipment parameters.

[0068] This disclosure also provides a computer-readable storage medium, which can be a non-volatile computer-readable storage medium or a volatile computer-readable storage medium, storing a computer program that, when run on a computer, causes the computer to execute the steps of a multi-level permission hierarchical management method for production line testing equipment parameters.

[0069] Finally, it should be noted that the above description is only a preferred embodiment of the present invention, and the scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be pointed out that for those skilled in the art, any improvements and modifications made without departing from the principle of the present invention should also be considered within the scope of protection of the present invention.

[0070] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

Claims

1. A method for multi-level access control of parameters for production line testing equipment, characterized in that, Includes the following steps: In response to user authentication, obtain the current user's role level and access permission matrix. The access permission matrix defines the operation permissions of different role levels for various test parameters. The operation permissions include at least invisible, read-only, and modifiable. Based on the access permission matrix, the parameter configuration interface of the production testing tool is dynamically rendered, so that users can only perform modification operations on parameters that they have the permission to modify. In response to a user's parameter modification request, an access permission check is performed on the parameter modification request based on the access permission matrix. If the check passes, the parameter modification operation is allowed; if the check fails, the operation is blocked and an unauthorized attempt log is recorded. After each parameter modification operation is completed, a structured operation log is generated. The operation log includes at least the parameter name, the value before modification, the value after modification, the operator's identity, the operation timestamp, and the workstation information from which the operation originated. The hash value of this operation log is associated with the hash value of the previous operation log record in the log record chain to calculate the hash value of this operation log record, forming a tamper-proof log record chain linked in chronological order. The operation log is then stored in the log record chain. The operation logs and parameter configuration change information will be synchronized to the cloud server for auditing and traceability by the quality management department.

2. The method for multi-level access control of production line testing equipment parameters according to claim 1, characterized in that, The role levels include at least operator, engineer, and administrator roles. The operator role only has the permission to view test parameters, the engineer role has the permission to modify non-critical debugging parameters, and the administrator role has the permission to modify all test parameters. Each role corresponds to a unique account system and login credentials.

3. The method for multi-level access control of production line testing equipment parameters according to claim 1, characterized in that, The method for establishing the access permission matrix includes: Each configurable test parameter is labeled with a sensitivity level, which includes at least low sensitivity, medium sensitivity and high sensitivity, and an access permission mapping matrix between parameters and roles is established; The access permissions for each role to each type of test parameter are clearly defined. The access permission matrix is ​​centrally managed in the form of an encrypted configuration file. The encrypted configuration file is stored using a symmetric encryption algorithm. The decryption key is dynamically obtained from the cloud authentication server through a secure handshake protocol when the production testing tool's main program starts.

4. The method for multi-level access control of production line testing equipment parameters according to claim 1, characterized in that, The user authentication supports password login and / or contactless identity card login. After successful login, the system interface displays the identity information and role level of the currently logged-in user. The user authentication also includes an automatic logout mechanism for session timeout: The system has a preset idle timeout period. If the user does not perform any operation within the preset idle timeout period, the current session will be automatically logged out and the parameter modification entry will be locked.

5. The method for multi-level access control of production line testing equipment parameters according to claim 1, characterized in that, The permission verification includes front-end interface layer verification and back-end application interface layer verification, wherein: The front-end interface layer verification achieves access control for the operation entry by disabling input boxes with parameters that do not have permission and making read-only parameters viewable but not editable. The backend application interface layer verification is achieved by verifying whether the role permissions corresponding to the user identity token carried in the parameter modification request match the sensitivity level of the target parameter. If the match fails, execution is refused and an insufficient permission error is returned, forming a defense-in-depth mechanism between the frontend and the backend.

6. The method for multi-level access control of production line testing equipment parameters according to claim 1, characterized in that, The unauthorized access attempt log includes at least the identity of the person attempting the operation, the timestamp of the operation, the name of the parameter to be modified, and the target value. The unauthorized access attempt log is uploaded to the cloud security monitoring platform in real time and triggers an alarm notification.

7. The method for multi-level access control of production line testing equipment parameters according to claim 5, characterized in that, The permission verification also includes a secondary authentication mechanism for highly sensitive operations: When the parameter modification request targets a highly sensitive parameter, a secondary authentication process is triggered after the permission verification is passed, requiring the current user to resubmit identity verification credentials. The parameter modification operation is only allowed after the secondary authentication is passed. The identity verification credentials include, but are not limited to, login password, dynamic verification code and biometric information.

8. The method for multi-level access control of production line testing equipment parameters according to claim 1, characterized in that, The generation of structured operation logs also includes a parameter modification approval process: When the target parameter of the parameter modification request is a highly sensitive parameter, the parameter modification request is submitted to the approval process. An administrator with approval authority will make an approval decision on the modification request. Only after the approval is approved can the parameter modification request enter the execution stage. The approval result is fed back to the applicant in real time. After the approved parameter change takes effect, a unique version number is assigned.

9. The method for multi-level access control of production line testing equipment parameters according to claim 1, characterized in that, The tamper-proof log record chain formed by linking records in chronological order also includes: When a discontinuous hash check is detected between any two adjacent operation log records in any node of the log record chain, it is determined that the log record segment has been tampered with and a security alarm is triggered.

10. The method for multi-level access control of production line testing equipment parameters according to claim 1, characterized in that, The method also includes parameter version management: For each type of test parameter set, maintain a complete historical version storage by product type. After each parameter change takes effect, the old version parameter set is fully archived and retained instead of being directly overwritten and deleted. Administrators with the appropriate permissions can view complete parameter snapshots of any historical version and perform a one-click rollback to a specified historical version. The rollback operation is recorded in the log record chain as a new parameter change.

11. The method for multi-level access control of production line testing equipment parameters according to claim 1, characterized in that, The method also includes multi-station parameter version consistency verification: The system performs centralized verification of the current effective parameter version number of all online workstations according to a preset cycle. It compares the current parameter version number of each workstation with the latest version number stored on the cloud server. If the parameter version number of a workstation is found to be inconsistent with the latest version number, a forced synchronization operation is automatically triggered to push the parameter configuration of the latest version number to the workstation and generate an alarm message.

12. The method for multi-level access control of production line testing equipment parameters according to claim 1, characterized in that, The cloud server provides the function of retrieving and auditing parameter change history. The quality management department can query the parameter change history by work position, time period or parameter name on the cloud platform. The cloud server is configured with abnormal change detection rules. When the number of times the same parameter is modified within a preset time window exceeds a preset threshold, an abnormal alarm notification is automatically triggered.

13. A multi-level access control system for parameters of production line testing equipment, characterized in that, include: The user authentication and permission matrix loading module is used to obtain the role level and access permission matrix corresponding to the current user in response to user authentication. The access permission matrix defines the operation permissions of different role levels for various test parameters. The operation permissions include at least invisible, read-only, and modifiable. The parameter configuration interface dynamic rendering module is used to dynamically render the parameter configuration interface of the production testing tool according to the access permission matrix, so that users can only perform modification operations on parameters that they have the right to modify. The permission verification and operation interception module is used to respond to the parameter modification request submitted by the user, perform permission verification on the parameter modification request based on the access permission matrix, and allow the parameter modification operation to be performed if the verification passes, and intercept the operation and record the unauthorized attempt log if the verification fails. The operation log generation and recording module is used to generate a structured operation log after each parameter modification operation is completed. The operation log includes at least the parameter name, the value before modification, the value after modification, the operator's identity, the operation timestamp, and the workstation information from which the operation originated. The module associates the hash value of this operation log with the hash value of the previous operation log record in the log record chain to calculate the hash value of this operation log record, forming a tamper-proof log record chain linked in chronological order. The operation log is then stored in the log record chain. The cloud synchronization and audit traceability module is used to synchronize the operation logs and parameter configuration change information to the cloud server for the quality management department to conduct audit traceability.

14. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the multi-level permission hierarchical management method for production line testing equipment parameters as described in any one of claims 1-12.

15. An electronic device, characterized in that, include: One or more processors; A storage device for storing one or more programs, which, when executed by one or more processors, cause the one or more processors to implement the multi-level permission hierarchical management method for production line testing equipment parameters as described in any one of claims 1-12.

Images