Multi-modal biological feature bound safety helmet block chain evidence storage management system

Abstract

The invention discloses a multi-modal biological feature bound safety helmet block chain evidence storage management system, and particularly relates to the technical field of safety helmet management, and the system comprises an ownership binding and activation module, a non-inductive passing and on-duty verification module, and a behavior evidence storage and tracing module. An identity fusion code is generated through normalization and dynamic weighted fusion, the identity fusion code is encrypted and written into a safety helmet RFID chip, and a binding relation is established; the non-inductive passing module captures a face image and RFID information through a gate, the comprehensive confidence coefficient is calculated in a local and cloud cooperative mode, and degradation verification is started according to root causes when Score is smaller than a threshold value; and the behavior evidence storage module generates an event log and evaluates the confidence coefficient, links the root hash after constructing a Merkle tree, and verifies the event through path proof during tracing. Unique binding of people and the helmet is realized, verification stability and anti-interference capability are improved, credibility and traceability of data are guaranteed, and the method is suitable for fine management of helmets in industrial, building and other scenes.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of safety helmet management, more particularly, the present application relates to a safety helmet blockchain storage management system based on multi-modal biological feature binding. BACKGROUND

[0002] In the current industrial production, construction and other scenarios, safety helmets as the key protective equipment to protect personnel safety, its management mode is still based on traditional manual registration, paper account or simple electronic record, there is a core problem of inaccurate binding of identity and safety helmet. The existing management mode is mainly through manual association of employee number, ordinary RFID tag identification and other ways to realize "person-cap corresponding", which cannot establish a unique strong binding relationship between employee identity and safety helmet, and also cannot avoid the situation of safety helmet misuse, misuse and misuse. At the same time, the manual registration operation is low in efficiency, and the record error is easy to be caused by human negligence. In the face of large-scale employee groups or high-frequency safety helmet distribution and recovery needs, the management is chaotic, which cannot meet the requirements of fine management in modern safety production scenarios.

[0003] The identity verification link of the existing safety helmet blockchain storage management system based on multi-modal biological feature binding has the defects of weak anti-interference ability, difficult to balance verification stability and efficiency. Some systems use single biological feature (such as fingerprint, single face recognition) for identity verification. This kind of way is easily affected by environmental factors - for example, strong light and dust will cause face recognition failure, and finger wear and dirt will cause fingerprint verification failure. Moreover, it lacks a dynamic adjustment mechanism for feature effectiveness, which cannot optimize feature priority according to different verification scenarios (such as workshop oil pollution environment, outdoor strong light environment) or historical verification data. Some systems only rely on local verification or single cloud verification. Local verification has insufficient feature extraction accuracy due to limited edge device computing power, and cloud verification has data transmission delay problem. The lack of collaborative mechanism of the two easily leads to traffic congestion or misjudgment, which is difficult to balance the efficiency demand of "non-contact access" and the accuracy demand of identity verification in industrial scenarios.

[0004] The current data storage and traceability capabilities of safety helmet management systems are far from meeting the actual needs of safety responsibility tracing. Most systems use centralized databases to store employee access records, safety helmet usage logs, and other data. This type of storage lacks data tamper-proof mechanisms, making the data susceptible to malicious deletion and alteration. Furthermore, no data credibility assessment system has been established—for example, the sensor status (such as camera signal strength, RFID reader calibration status) and data rationality (such as whether the employee's movement speed is reasonable) are considered when generating the data, leading to doubts about data credibility. In addition, when it is necessary to trace specific events (such as employee on-duty status at a certain time or safety helmet usage trajectory), it is necessary to retrieve the entire original data for retrieval, resulting in low query efficiency and an inability to quickly verify the authenticity of the event. Once a safety accident or management dispute occurs, it is difficult to determine responsibility through reliable data, failing to provide effective support for safety management and accident review. Summary of the Invention

[0005] To overcome the aforementioned deficiencies of the prior art, embodiments of the present invention provide a multimodal biometric-linked safety helmet blockchain evidence storage management system.

[0006] To achieve the above objectives, the present invention provides the following technical solution: A multimodal biometric-linked safety helmet blockchain-based evidence storage management system includes the following modules: The ownership binding and activation module is used to collect and integrate the multimodal biometric features of employees, such as fingerprints, facial features, and voiceprints, to generate a digital identity fusion code; the identity information is then encrypted and written into the safety helmet chip to complete the activation and binding of one person and one helmet. The seamless access and on-duty verification module is used to seamlessly capture facial information of personnel at the gate and compare it locally with the data in the chip inside the cap. At the same time, it combines cloud data to perform collaborative verification and permission verification, and makes decisions based on the comprehensive confidence level. When verification fails, a multi-modal degradation and fault tolerance process is automatically initiated. The behavior evidence storage and traceability module is used to attach a credibility score to all event data, batch construct Merkle trees, and store the root hash value on the blockchain to ensure that the data is tamper-proof; when auditing is required, the entire process of historical events is traced through zero-knowledge verification.

[0007] Specifically, the execution process of the ownership binding and activation module is as follows: Employee basic information registration creates employee digital profiles in the backend. , where i is the employee number, and the file contains fields such as name and department; Multimodal biometric data acquisition: Three biometric features of employees are collected at the hair cap terminal: fingerprint image. Facial images Voiceprint signal ; Feature extraction and normalization: Feature vectors of the three biological features are extracted and then normalized. Normalized fingerprint feature vector ; Normalized facial feature vector ; Normalized voiceprint feature vector ; Where: Normalize() is the normalization function. This is the fingerprint feature extraction function; Weighted feature fusion and digital identity generation employ a weighted fusion algorithm to generate the final identity fusion code. The fusion process is represented as:

[0008] in , , These are the weighting coefficients adjusted through a dynamic weighting adjustment mechanism; The fusion code has higher uniqueness and anti-counterfeiting properties; Safety Helmet Activation and Information Writing: A Lightweight Summary of Employee ID i and Facial Feature Vector , The hash function is used to encrypt the data, which is then written into the encrypted RFID chip on the safety helmet; the backend establishes and stores [employee ID, safety helmet ID, ... The binding relationship of ].

[0009] Specifically, the dynamic weight adjustment mechanism process is as follows: Verification result data collection and storage: After each seamless access or dynamic spot check verification attempt, a verification record is generated and stored in the database, containing the following data: Employee ID, timestamp, verification location, final verification result, similarity scores for each modality, and the old weights used; Modal performance evaluation and error contribution calculation: Periodically start the weight calculation task and analyze all verification records in the past period; For each record that failed verification, it is identified as a negative sample that needs to be learned; the error contribution of each modality in that failure is calculated. For a certain mode , It can represent f, face, and voice, and the degree of error contribution in this failed validation. The calculation formula is: ,in Let k be the similarity score of the k-th modality in this validation. These are the old weighting coefficients used for the k-th mode in this verification; Weighted penalty factor calculation: Count all failure records and calculate the penalty factor for each mode. Average error contribution ; Subsequently, a weight penalty factor is calculated for each mode. ; For factors greater than 0, their values ​​are related to the average error contribution. Inversely proportional; the calculation method is as follows: ; New weight calculation and normalization: Calculating the new round of weights using a penalty factor: ;in The initial new weights for the k-th mode after adjustment by the penalty factor; Weight normalization: The penalized weights are normalized to ensure that the sum of all weights is 1. ;in The final new weight coefficients for the k-th mode. These are the initial new weights for fingerprint, facial, and voiceprint modalities, respectively.

[0010] New weight deployment and application: Update the calculated new weight combination to the global configuration; starting from the next calculation cycle, all employees' verification processes will use the new weight coefficients; Weight stability check and threshold protection: Perform a stability check before deploying new weights. Calculate the magnitude of change of each coefficient between the new and old weights. : If all All are less than a preset stability threshold If the system performance has stabilized, the weight update is cancelled; at the same time, a minimum protection value is set for each weight.

[0011] Specifically, the execution process of the seamless access and on-duty verification module is as follows: Entrance data capture: When workers pass through, the turnstile camera captures real-time facial images. The edge calculator synchronously reads the RFID chip information inside the cap, decrypts it to obtain the employee number j and feature summary. ; Local fast comparison: Edge calculator extracts real-time facial feature vectors And calculate the similarity between it and the restored vector of the in-chip summary: ;in For string similarity algorithms; Cloud-based collaborative verification: The edge calculator combines employee ID j with real-time feature vectors. After encryption, the data is sent to the cloud; the cloud performs the following operations: a. Retrieve the complete fusion feature code associated with this employee ID. ; b. Calculate the similarity between real-time features and cloud-registered features. ; c. Check the employee's permission status. ; Comprehensive Confidence Assessment and Decision-Making: Multiple pieces of evidence from both edge nodes and the cloud are used to calculate a comprehensive confidence score for allowing passage. :

[0012] in , , These are the weighting coefficients. For indicator functions; Set a decision threshold ,like If the verification is successful, the passage is immediately granted; otherwise... If the verification fails, the degradation fault tolerance verification process will be initiated. Dynamic spot check verification: Monitoring equipment in the area periodically captures images of people and uses the same confidence assessment model to verify their identities.

[0013] Specifically, the degradation fault tolerance verification process is as follows: Analyze the reasons why the overall confidence score is lower than the decision threshold, and determine the root cause of failure based on diagnostic logic; the root cause of failure includes biometric mismatch, edge feature extraction failure, or permission abnormality. Based on the root cause of the failure, select the corresponding verification strategy from the predefined strategy library and issue an execution instruction to the user; Perform multimodal backup verification according to instructions: if the biometrics do not match, guide the user to remove their hat and retake the image and verify the voiceprint; if the edge feature extraction fails, recapture the image and perform local comparison. Ultimately, a decision is made based on the predefined arbitration rules regarding the backup verification results, determining whether to allow passage or trigger an alarm.

[0014] Specifically, the execution process of the behavior evidence storage and tracing module is as follows: Key event data generation: Continuously generate event logs. ; For timestamps, For employee ID, The location where the incident occurred. For event type, For sensor data; Event log The credibility and quality of the data are assessed; Constructing a Merkle tree for batch notarization: Construct a Merkle tree from all event logs generated within a time window; calculate the root hash value of the Merkle tree. ; On-chain blockchain: The timestamp T and the hash value of the previous block Packaged into a new block : ; Subsequently, the block was added to the blockchain network through a consensus mechanism, completing the notarization process. Verifiable query: When it is necessary to trace the behavior of an employee during a certain period of time, a Merkle path proof containing the employee's events is provided; The verification party uses Proof and publicly available [documents / data]. This verifies whether the Even event actually exists in the batch of records without needing to retrieve all the original data.

[0015] Specifically, the event log The process of assessing the credibility and quality of data is as follows: Evaluation dimensions: Sensor confidence score: Analyze the state of the sensor that generated the event and assign it a device health score. ; Data reasonableness: Based on historical data models, determine whether the current event data is within a reasonable range; and provide a reasonableness score. ; Data integrity: Checks whether the data packet is complete, whether there are missing fields or signs of tampering, and generates an integrity score. ; Generate a comprehensive confidence score: Calculate a comprehensive confidence score for this event log. ; Confidence score on-chain: put this confidence score on-chain. As an event log A new metadata field is added to participate in the subsequent Merkle tree construction and on-chain process.

[0016] The technical effects and advantages of this invention are as follows: This invention effectively solves the problem of inaccurate binding between employees and helmets in traditional safety helmet management. By collecting three biometric features of employees—fingerprints, facial features, and voiceprints—and generating a highly unique identity fusion code through normalization and dynamic weighted fusion, the employee ID and facial feature hash digest are encrypted and written into the safety helmet's RFID chip, establishing a unique binding relationship of "employee ID-safety helmet ID-fusion code." This completely avoids the misuse and misapplication of safety helmets, while eliminating the inefficiency and errors of manual registration and improving the level of management precision in large-scale scenarios. To achieve a balance between authentication efficiency and accuracy, a local + cloud collaborative verification system is used. The edge calculator quickly compares data locally to ensure efficient passage, while the cloud combines fusion codes and deep permission verification. When verification fails, the system accurately diagnoses the root cause and matches a downgrade strategy (such as activating voiceprint assistance for biometric mismatch or activating the HDR camera for edge faults). This solves the problem of single features being easily affected by environmental interference, avoids passage congestion, and the dynamic spot check mechanism can also ensure the consistency between on-duty personnel and safety helmets. To meet the needs of safety responsibility traceability, the confidence level of event logs is first assessed based on equipment health, data rationality, and integrity. Then, a Merkle tree is constructed according to the time window, and the root hash is uploaded to the blockchain to prevent tampering. During tracing, only the Merkle path proof and the public root hash are needed to verify the authenticity of the event, without the need for the full amount of original data, providing reliable data support for safety incident review and management dispute responsibility determination. Attached Figure Description

[0017] Figure 1 This is a system block diagram of the present invention. Detailed Implementation

[0018] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] like Figure 1 As shown, a multimodal biometric-linked safety helmet blockchain evidence storage management system module is as follows: The ownership binding and activation module uniquely binds the safety helmet to the employee's identity. By collecting and integrating the employee's multimodal biometric features such as fingerprints, facial features, and voiceprints, a digital identity fusion code is generated; this identity information is then encrypted and written into the safety helmet's chip, completing the "one person, one helmet" activation and binding, ensuring that the person and helmet are identical from the source; Employee basic information registration creates employee digital profiles in the system backend. Where i is the employee ID, and the file includes fields such as name and department; multimodal biometric collection collects three biometric features of employees at the cap terminal: fingerprint image. Facial images Voiceprint signal .

[0020] Feature extraction and normalization: Feature vectors of the three biological features are extracted and then normalized. Normalized fingerprint feature vector Normalize() is a normalization function. Fingerprint feature extraction function; normalized facial feature vector Normalized voiceprint feature vector Weighted feature fusion and digital identity generation employ a weighted fusion algorithm to generate the final identity fusion code. The fusion process is represented as:

[0021] in , , The weighting coefficients are adjusted through a dynamic weighting adjustment mechanism and satisfy the following conditions: + + =1; The dynamic weight adjustment mechanism is as follows: Verification Result Data Collection and Storage: After each seamless access or dynamic spot check verification attempt (regardless of success or failure), the system generates a detailed verification record and stores it in the database. This record contains the following key data: employee ID, timestamp, verification location, final verification result (success or failure), modal similarity scores (recording the original values ​​of fingerprint similarity, facial similarity, and voiceprint similarity in this verification) and the old weights used; Modal performance evaluation and error contribution calculation: A weight calculation task is initiated periodically (e.g., once every 24 hours at night). This task analyzes all validation records within a past period (e.g., 7 days); for each validation failure record, it is identified as a negative sample that needs to be learned; the error contribution of each modality in that failure is calculated; for a given modality... ( (can represent f, face, voice), and its contribution to the error in this failed validation. The calculation formula is: ,in Let k be the similarity score of the k-th modality in this validation. Let be the old weighting coefficient used for the k-th mode in this verification. This indicates that the higher the weight of this mode, the greater its decision-making responsibility. The higher the value, the stronger the mode. The greater the responsibility in this verification failure; Weighted penalty factor calculation: Count all failure records and calculate the penalty factor for each mode. Average error contribution Subsequently, a weight penalty factor is calculated for each mode. ; It is a factor greater than 0, and its value is related to the average error contribution. Inversely proportional. That is, the higher the average error contribution of a certain mode, the smaller its penalty factor, meaning its weight should be reduced in the next cycle. The calculation method is as follows: , To ensure the average error contribution, it is ensured that: if If it is very large (poor performance), then It will be significantly less than 1, if If it is very small (and performs well), then It will be close to 1.

[0022] New weight calculation and normalization: Calculating the new round of weights using a penalty factor: ;in The initial new weights for the k-th mode are adjusted by the penalty factor; weight normalization: the penalized weights are normalized to ensure that the sum of all weights is 1. ;in The final new weight coefficients for the k-th mode. These are the initial new weights for fingerprint, facial, and voiceprint modalities, respectively. New Weight Deployment and Application: The calculated new weight combination is updated to the global configuration. Starting from the next calculation cycle, all employee verification processes (generation in ownership binding and comparison in verification) will use this new set of weight coefficients; Weight Stability Check and Threshold Protection: Before deploying the new weights, a stability check is performed: the change range of each coefficient between the new and old weights is calculated. : If all All are less than a preset stability threshold If the weight is set to 0.05 (e.g., 0.05), the system performance is considered to have stabilized, and the weight adjustment range for this period is too small. To avoid unnecessary fluctuations, the weight update is cancelled this time, and the old weights will continue to be used. At the same time, a minimum protection value (e.g., 0.1) is set for each weight to prevent any modality's weight from being adjusted to 0 and becoming completely ineffective.

[0023] The fusion code offers higher uniqueness and anti-counterfeiting capabilities; Safety helmet activation and information writing: a lightweight summary of employee ID i and facial feature vector. ( The hash function is used to encrypt the data, which is then written into the encrypted RFID chip on the safety helmet. The backend establishes and stores [employee ID, safety helmet ID, ...]. The binding relationship is shown. The helmet status is marked as activated.

[0024] The seamless access and on-duty verification module captures facial information of personnel at the gate and compares it locally with the data in the chip inside the cap. At the same time, it combines cloud data to perform collaborative verification and permission verification, and makes decisions based on the comprehensive confidence level. When verification fails, a multi-modal degradation and fault tolerance process is automatically started to maximize passage efficiency while ensuring safety. Entrance data capture: When workers pass through, the turnstile camera captures real-time facial images. The edge calculator synchronously reads the RFID chip information inside the cap, decrypts it to obtain the employee number j and feature summary. .

[0025] Local fast comparison: Edge calculator extracts real-time facial feature vectors And calculate the similarity between it and the restored vector of the in-chip summary: ;in This is a string similarity algorithm used to calculate the similarity between two feature vectors (real-time and registered). Cloud-based collaborative verification: The edge calculator combines employee ID j with real-time feature vectors. After encryption, the data is sent to the cloud. The cloud then performs the following operations: a. Retrieve the complete fusion feature code associated with this employee ID. b. Calculate the similarity between real-time features and cloud-registered features. c. Check the employee's permission status. (Boolean value); By integrating multiple pieces of evidence from both edge nodes and the cloud, a comprehensive confidence score is calculated to determine whether to allow passage. :

[0026] in , , These are the weighting coefficients. This is an indicator function; its value is 1 when permissions are normal, and 0 otherwise. Set a decision threshold ,like If the verification is successful, the passage is immediately granted; otherwise... If the verification fails, the process is considered a failure, and a downgraded fault-tolerant verification process is initiated, as follows: Analysis of overall confidence level The reason, and the diagnostic logic: like and Below its individual threshold, and If the result falls within the normal range, it is classified as "biometric mismatch." Reasons include: drastic changes in lighting, large temporary facial obstruction (such as masks or oil stains), and abnormal facial expressions; if... Below its individual threshold If the result falls within the normal range, it is determined to be an "edge feature extraction failure"; reasons include: extremely poor local image quality, and instantaneous error in the edge feature extraction model; if If the information is outside the normal range, it is judged as "abnormal permissions"; reasons include: worker ID has expired, unauthorized access to the area, abnormal attendance, etc. Output: Obtain a primary root cause identifier for the failure; Based on the identified root cause of failure, the optimal degradation verification strategy is selected from the predefined strategy library, and clear and user-friendly instructions are given to the user through the gate display or voice module. Strategy library example: Strategy A (for biometric mismatch): Instruction: Verification failed. Please face the camera and briefly remove your hat.

[0027] Action: This command asks the user to perform a simple action to prepare to capture a clear image of a face without the hood obstructing the view.

[0028] Command diversity: The strategy library contains a variety of commands, such as "please raise your head slightly" and "please turn your head to the left", which the system uses randomly in rotation to prevent attackers from figuring out the pattern.

[0029] Strategy B (addressing edge feature extraction failures): Instruction: "Verification failed. Please wait or move to a better lighting location."

[0030] Action: Attempt to recapture the image, or activate a backup high dynamic range (HDR) camera for image acquisition.

[0031] Strategy C (for abnormal permissions): Command: Permission verification failed. Please contact the administrator.

[0032] Action: At this point, biometric retries will no longer be performed, the process will end directly and transfer to the manual processing channel, and the administrator will be notified at the same time.

[0033] Multimodal backup verification execution: After the user completes the corresponding action according to the instructions, the backup verification process is initiated; For strategy A (hat removal verification): Capture a new image; extract features using a powerful cloud-based model; in addition to facial features, the system can simultaneously initiate voiceprint verification as cross-validation. The display prompts "Please state your employee ID," and after collecting audio, it is compared with the cloud-based voiceprint model. Set a low pass threshold; if the voiceprint verification passes, it can also serve as strong supporting evidence. For strategy B (recapture): use the newly captured image to perform local fast alignment and subsequent processes again; After the downgrade verification is completed, the system makes a final decision based on a set of predefined arbitration rules, as follows: Rule 1: If the root cause of the verification failure is a mismatch in biometric features, and the biometric similarity obtained after downgrading and retrying reaches or exceeds the high threshold, then the verification is considered successful and the process is allowed. Rule 2: If the root cause of the verification failure is the mismatch of biometric features, and the biometric similarity after downgrading and retrying reaches or exceeds the low threshold, and the similarity of the backup voiceprint verification also reaches or exceeds its specific threshold, then the verification is determined to be successful through fusion decision and the release operation is executed. Rule 3: If the root cause of the verification failure is a mismatch in biometric features, and all downgrade verification attempts fail to meet the above success criteria (i.e., neither Rule 1 nor Rule 2 is satisfied), then the final verification is deemed to have failed, triggering a system alarm. Rule 4: If the root cause of the verification failure is an abnormal permission, the final verification failure status shall be maintained, the access shall not be granted, and the abnormal information shall be notified to the system administrator for manual handling.

[0034] Dynamic spot check verification: Monitoring equipment within the area periodically captures images of people and uses the same confidence assessment model for rapid identity verification.

[0035] The behavior evidence storage and tracing module attaches a credibility score to all key event data, constructs Merkle trees in batches, and stores the root hash value on the blockchain to ensure that the data is immutable. When auditing is required, the entire process of any historical event can be traced quickly and accurately through zero-knowledge verification and other methods, while effectively protecting privacy. Key event data generation: Continuously generate event logs. ; For timestamps, For employee ID, The location where the incident occurred. For event type, For sensor data; for event logs The credibility and quality of the data are assessed through the following process: Evaluation dimensions: Sensor confidence score: Analyze the state of the sensor (such as a camera or RFID reader) that generated the event (e.g., signal strength, battery level, last calibration time) and assign it a device health score. Data reasonableness: Based on historical data models, determine whether the current event data is within a reasonable range; for example, whether the employee's movement speed from point A to point B is within the reasonable limits of human walking / running. Provide a reasonableness score. Data integrity: Check whether the data packet is complete, whether there are any missing fields or signs of tampering (this can be verified through an attached digital signature), and generate an integrity score. ; Generate a comprehensive confidence score: Based on the scores above, calculate a comprehensive confidence score for this event log. ; Confidence score on-chain: put this confidence score on-chain As an event log A new metadata field is added, which participates in the subsequent Merkle tree construction and on-chain process.

[0036] Constructing a Merkle tree for batch notarization: To improve efficiency, all event logs generated within a time window (e.g., every 10 minutes) are constructed into a Merkle tree. The root hash value of this Merkle tree is then calculated. ; On-chain blockchain: The timestamp T and the hash value of the previous block Packaged into a new block : Subsequently, the block was added to the blockchain network through a consensus mechanism, completing the notarization process.

[0037] Verifiable query: When it is necessary to trace the behavior of an employee within a certain time period, a Merkle path proof containing the employee's events is provided; the verifier verifies the proof and the publicly available... This allows verification that a specific event, Even, actually exists in the batch of records without needing to obtain all the original data, achieving efficient and reliable traceability.

[0038] The above formulas are all dimensionless calculations. Dimensionless calculations can be performed using various methods such as standardization, which will not be elaborated here. The formulas are derived from software simulations based on a large amount of collected data, and the preset parameters in the formulas can be set by those skilled in the art according to the actual situation.

[0039] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, ATA hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. The semiconductor medium can be a solid-state ATA hard disk.

[0040] It should be understood that in the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0041] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0042] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0043] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0044] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0045] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable ATA hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0046] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A multimodal biometric-linked safety helmet blockchain-based evidence storage management system, characterized in that, Includes the following modules: The ownership binding and activation module is used to collect and integrate the multimodal biometric features of employees, such as fingerprints, facial features, and voiceprints, to generate a digital identity fusion code; the identity information is then encrypted and written into the safety helmet chip to complete the activation and binding of one person and one helmet. The seamless access and on-duty verification module is used to seamlessly capture facial information of personnel at the gate and compare it locally with the data in the chip inside the cap. At the same time, it combines cloud data to perform collaborative verification and permission verification, and makes decisions based on the comprehensive confidence level. When verification fails, a multi-modal degradation and fault tolerance process is automatically initiated. The behavior evidence storage and traceability module is used to attach a credibility score to all event data, batch construct Merkle trees, and store the root hash value on the blockchain to ensure that the data is tamper-proof; when auditing is required, the entire process of historical events is traced through zero-knowledge verification.

2. The multimodal biometric-linked safety helmet blockchain evidence management system according to claim 1, characterized in that, The execution process of the ownership binding and activation module is as follows: Employee basic information registration creates employee digital profiles in the backend. , where i is the employee number, and the file contains fields such as name and department; Multimodal biometric data acquisition: Three biometric features of employees are collected at the hair cap terminal: fingerprint image. Facial images Voiceprint signal ; Feature extraction and normalization: Feature vectors of the three biological features are extracted and then normalized. Normalized fingerprint feature vector ; Normalized facial feature vector ; Normalized voiceprint feature vector ; Where: Normalize() is the normalization function. This is the fingerprint feature extraction function; Weighted feature fusion and digital identity generation employ a weighted fusion algorithm to generate the final identity fusion code. The fusion process is represented as: ； in , , These are the weighting coefficients adjusted through a dynamic weighting adjustment mechanism; The fusion code has higher uniqueness and anti-counterfeiting properties; Safety Helmet Activation and Information Writing: A Lightweight Summary of Employee ID i and Facial Feature Vector , The hash function is used to encrypt the data, which is then written into the encrypted RFID chip on the safety helmet; the backend establishes and stores [employee ID, safety helmet ID, ... The binding relationship of ].

3. The multimodal biometric-linked safety helmet blockchain evidence management system according to claim 2, characterized in that, The dynamic weight adjustment mechanism process is as follows: Verification result data collection and storage: After each seamless access or dynamic spot check verification attempt, a verification record is generated and stored in the database, containing the following data: Employee ID, timestamp, verification location, final verification result, similarity scores for each modality, and the old weights used; Modal performance evaluation and error contribution calculation: Periodically start the weight calculation task and analyze all verification records in the past period; For each record that failed verification, it is identified as a negative sample that needs to be learned; the error contribution of each modality in that failure is calculated. For a certain mode , It can represent f, face, and voice, and the degree of error contribution in this failed validation. The calculation formula is: ,in Let k be the similarity score of the k-th modality in this validation. These are the old weighting coefficients used for the k-th mode in this verification; Weighted penalty factor calculation: Count all failure records and calculate the penalty factor for each mode. Average error contribution ; Subsequently Calculate a weight penalty factor for each mode. ; For factors greater than 0, their values ​​are related to the average error contribution. Inversely proportional; the calculation method is as follows: ; New weight calculation and normalization: Calculating the new round of weights using a penalty factor: ;in The initial new weights for the k-th mode after adjustment by the penalty factor; Weight normalization: The penalized weights are normalized to ensure that the sum of all weights is 1. ;in The final new weight coefficients for the k-th mode. These are the initial new weights for fingerprint, facial, and voiceprint modalities, respectively. New weight deployment and application: Update the calculated new weight combination to the global configuration; Starting from the next calculation cycle, the verification process for all employees will use the new weighting coefficients; Weight stability check and threshold protection: Perform a stability check before deploying new weights. Calculate the magnitude of change of each coefficient between the new and old weights. : If all All are less than a preset stability threshold If the system performance has stabilized, the weight update is cancelled; at the same time, a minimum protection value is set for each weight.

4. The multimodal biometric-linked safety helmet blockchain evidence management system according to claim 1, characterized in that, The execution process of the seamless access and on-duty verification module is as follows: Entrance data capture: When workers pass through, the turnstile camera captures real-time facial images. The edge calculator synchronously reads the RFID chip information inside the cap, decrypts it to obtain the employee number j and feature summary. ; Local fast comparison: Edge calculator extracts real-time facial feature vectors And calculate the similarity between it and the restored vector of the in-chip summary: ;in For string similarity algorithms; Cloud-based collaborative verification: The edge calculator combines employee ID j with real-time feature vectors. After encryption, the data is sent to the cloud; the cloud performs the following operations: a. Retrieve the complete fusion feature code associated with this employee ID. ; b. Calculate the similarity between real-time features and cloud-registered features. ; c. Check the employee's permission status. ; Comprehensive Confidence Assessment and Decision-Making: Multiple pieces of evidence from both edge nodes and the cloud are used to calculate a comprehensive confidence score for allowing passage. : ； in , , These are the weighting coefficients. For indicator functions; Set a decision threshold ,like If the verification is successful, the passage is immediately granted; otherwise... If the verification fails, the degradation fault tolerance verification process will be initiated. Dynamic spot check verification: Monitoring equipment in the area periodically captures images of people and uses the same confidence assessment model to verify their identities.

5. The multimodal biometric-linked safety helmet blockchain evidence management system according to claim 4, characterized in that, The degradation fault tolerance verification process is as follows: Analyze the reasons why the overall confidence score is lower than the decision threshold, and determine the root cause of failure based on diagnostic logic; the root cause of failure includes biometric mismatch, edge feature extraction failure, or permission abnormality. Based on the root cause of the failure, select the corresponding verification strategy from the predefined strategy library and issue an execution instruction to the user; Perform multimodal backup verification according to instructions: If the biometrics do not match, guide the user to complete the image retake and voiceprint verification after removing their hat; If the edge feature extraction fails, the image is recaptured and local comparison is performed. Ultimately, a decision is made based on the predefined arbitration rules regarding the backup verification results, determining whether to allow passage or trigger an alarm.

6. The multimodal biometric-linked safety helmet blockchain evidence management system according to claim 1, characterized in that, The execution process of the behavior evidence storage and tracing module is as follows: Key event data generation: Continuously generate event logs. ; For timestamps, For employee ID, The location where the incident occurred. For event type, For sensor data; Event log The credibility and quality of the data are assessed. Constructing a Merkle tree for batch notarization: All event logs generated within a time window are constructed into a Merkle tree; the root hash value of this Merkle tree is calculated. ; On-chain blockchain: The timestamp T and the hash value of the previous block Packaged into a new block : ; Subsequently, the block was added to the blockchain network through a consensus mechanism, completing the notarization process. Verifiable query: When it is necessary to trace the behavior of an employee during a certain period of time, a Merkle path proof containing the employee's events is provided; The verification party uses Proof and publicly available [documents / data]. This verifies whether the Even event actually exists in the batch of records without needing to retrieve all the original data.

7. The multimodal biometric-linked safety helmet blockchain evidence management system according to claim 6, characterized in that, The event log The process of assessing the credibility and quality of data is as follows: Evaluation dimensions: Sensor confidence score: Analyze the state of the sensor that generated the event and assign it a device health score. ; Data reasonableness: Based on historical data models, determine whether the current event data is within a reasonable range; and provide a reasonableness score. ; Data integrity: Checks whether the data packet is complete, whether there are missing fields or signs of tampering, and generates an integrity score. ; Generate a comprehensive confidence score: Calculate a comprehensive confidence score for this event log. ; Confidence score on-chain: This confidence score As an event log A new metadata field is added to participate in the subsequent Merkle tree construction and on-chain process.

Images