A blockchain-based evidence management system for safety helmets with multimodal biometric binding

Abstract

This invention discloses a multimodal biometric-based safety helmet blockchain-based evidence management system, specifically relating to the field of safety helmet management technology. It includes modules for ownership binding and activation, contactless access and on-duty verification, and behavior evidence storage and traceability. The ownership binding module creates employee files, collects fingerprint, facial, and voiceprint features, and generates an identity fusion code through normalization and dynamic weighted fusion. This code is then encrypted and written into the safety helmet's RFID chip, establishing a binding relationship. The contactless access module captures facial images and RFID information through a gate, calculates the overall confidence score locally and in the cloud, and initiates downgraded verification based on the root cause when the score is less than a threshold. The behavior evidence storage module generates event logs and evaluates the confidence score. After constructing a Merkle tree, the root hash is uploaded to the blockchain, and events are verified through path proof during tracing. This invention achieves unique binding between the person and the helmet, improves verification stability and anti-interference capabilities, ensures data reliability and traceability, and is suitable for refined safety helmet management in industrial and construction scenarios.

Description

Technical Field

[0001] This invention relates to the field of safety helmet management technology, and more specifically, to a multimodal biometric-linked safety helmet blockchain evidence storage management system. Background Technology

[0002] In current industrial production and construction scenarios, safety helmets, as critical protective equipment for ensuring personnel safety, are still primarily managed through traditional manual registration, paper ledgers, or simple electronic records. This presents a core problem: inaccurate linking of employee identity with safety helmets. Existing management models often achieve "person-helmet correspondence" through manual association with employee ID numbers or ordinary RFID tags. This fails to establish a unique and strong binding relationship between employee identity and safety helmets, and also makes it difficult to prevent situations such as misuse, incorrect use, or mixing of safety helmets. Furthermore, manual registration is inefficient and prone to errors due to human negligence. When dealing with large groups of employees or frequent safety helmet distribution and collection needs, management chaos becomes particularly prominent, failing to meet the requirements of refined management in modern safety production scenarios.

[0003] Existing multimodal biometric-based safety helmet blockchain-based evidence management systems generally suffer from weak anti-interference capabilities and difficulties in balancing verification stability and efficiency in their identity verification processes. Some systems use a single biometric feature (such as fingerprint or facial recognition) for identity verification. This method is susceptible to environmental factors—for example, strong light and dust can cause facial recognition failure, while worn or dirty fingers can cause fingerprint verification failure. Furthermore, they lack a dynamic adjustment mechanism for feature validity and cannot optimize feature priority based on different verification scenarios (such as oily workshop environments or strong outdoor light environments) or historical verification data. Other systems rely solely on local verification or a single cloud verification. Local verification suffers from insufficient feature extraction accuracy due to limited computing power of edge devices, while cloud verification suffers from data transmission delays. The lack of a collaborative mechanism between the two can easily lead to congestion or misjudgments, making it difficult to balance the efficiency requirements of "seamless passage" in industrial scenarios with the accuracy requirements of identity verification.

[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:

[0007] A multimodal biometric-linked safety helmet blockchain-based evidence storage management system includes the following modules:

[0008] 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.

[0009] 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.

[0010] 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.

[0011] Specifically, the execution process of the seamless access and on-duty verification module is as follows:

[0012] 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. ;

[0013] 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 cosine similarity algorithm;

[0014] 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:

[0015] a. Retrieve the complete fusion feature code associated with this employee ID. ;

[0016] b. Calculate the similarity between real-time features and cloud-registered features. ;

[0017] c. Check the employee's permission status. ;

[0018] 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. :

[0019] ;

[0020] in , , These are the weighting coefficients. For indicator functions;

[0021] 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.

[0022] 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.

[0023] Specifically, the degradation fault tolerance verification process is as follows:

[0024] 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.

[0025] 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;

[0026] 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.

[0027] 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.

[0028] Specifically, the execution process of the behavior evidence storage and tracing module is as follows:

[0029] 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;

[0030] Event log The credibility and quality of the data are assessed.

[0031] 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. ;

[0032] On-chain blockchain: The timestamp T and the hash value of the previous block Packaged into a new block : ;

[0033] Subsequently, the block was added to the blockchain network through a consensus mechanism, completing the notarization process.

[0034] 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;

[0035] 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.

[0036] Specifically, the event log The process of assessing the credibility and quality of data is as follows:

[0037] Evaluation dimensions:

[0038] Sensor confidence score: Analyze the state of the sensor that generated the event and assign it a device health score. ;

[0039] Data reasonableness: Based on historical data models, determine whether the current event data is within a reasonable range; and provide a reasonableness score. ;

[0040] Data integrity: Checks whether the data packet is complete, whether there are missing fields or signs of tampering, and generates an integrity score. ;

[0041] Generate a comprehensive confidence score: Calculate a comprehensive confidence score for this event log. ;

[0042] 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.

[0043] The technical effects and advantages of this invention are as follows:

[0044] 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.

[0045] 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.

[0046] 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

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

[0048] 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.

[0049] like Figure 1 As shown, a multimodal biometric-linked safety helmet blockchain evidence storage management system module is as follows:

[0050] 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;

[0051] 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.

[0052] 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. .

[0053] 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 cosine similarity algorithm used to calculate the similarity between two feature vectors (real-time and registered).

[0054] 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:

[0055] 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);

[0056] 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. :

[0057] ;

[0058] in , , These are the weighting coefficients. This is an indicator function; its value is 1 when permissions are normal, and 0 otherwise.

[0059] 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:

[0060] Analysis of overall confidence level The reason, and the diagnostic logic:

[0061] 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.

[0062] Output: Obtain a primary root cause identifier for the failure;

[0063] 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.

[0064] Strategy library example:

[0065] Strategy A (for biometric mismatch):

[0066] Instruction: Verification failed. Please face the camera and briefly remove your hat.

[0067] 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.

[0068] 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.

[0069] Strategy B (for edge feature extraction failures):

[0070] Instruction: "Verification failed. Please wait or move to a better lighting location."

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

[0072] Strategy C (for permission-related issues):

[0073] Command: Permission verification failed. Please contact the administrator.

[0074] 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.

[0075] Multimodal backup verification execution: After the user completes the corresponding action according to the instructions, the backup verification process is initiated;

[0076] For strategy A (hat removal verification):

[0077] 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.

[0078] For strategy B (recapture): use the newly captured image to perform local fast alignment and subsequent processes again;

[0079] After the downgrade verification is completed, the system makes a final decision based on a set of predefined arbitration rules, as follows:

[0080] 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.

[0081] 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.

[0082] 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.

[0083] 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.

[0084] 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.

[0085] 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.

[0086] 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:

[0087] Evaluation dimensions:

[0088] 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. ;

[0089] 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.

[0090] 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. ;

[0091] 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.

[0092] 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.

[0093] 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.

[0094] 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.

[0095] 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.

[0096] 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.

[0097] 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.

[0098] 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.

[0099] 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.

[0100] 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.

[0101] 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 scope of the technology 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 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 This is a cosine similarity algorithm; 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. The degradation fault tolerance verification process is as follows: The reasons for the overall confidence score falling below the decision threshold are analyzed, and the root cause of failure is determined based on diagnostic logic. The root cause of failure includes biometric mismatch, edge feature extraction failure, or permission abnormality. Specifically: like and Below the corresponding individual threshold, and If it falls within the normal range, it is determined to be a biometric mismatch; if Below the corresponding individual threshold If it falls within the normal range, it is determined to be an edge feature extraction failure; like If the value is outside the normal range, it is considered an abnormal permission issue. Based on the root cause of the failure, a corresponding verification strategy is selected from the predefined strategy library, and an execution command is issued to the user.

2. The multimodal biometric-linked safety helmet blockchain evidence management system according to claim 1, characterized in that, Also includes: The behavior evidence storage and tracing 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 immutable; when auditing is required, the entire process of historical events can be traced through zero-knowledge verification. 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.

3. The multimodal biometric-linked safety helmet blockchain evidence management system according to claim 2, 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