Generation and credible storage method of verification report for metrological supervision platform

Abstract

The application discloses a kind of verification report generation and trusted evidence method for metrological supervision platform, to solve the technical problems of existing verification report generation complex and low efficiency, data is easy to tamper with.The light-weighted large language model compressed after knowledge distillation and mixed precision quantization is deployed in the edge computing device of hydrogenation station site, and the edge deployment mode is free from dependence on internet connection;And the hash calculation is placed in the verification device end, the hash value is calculated at the same time when the original sampling data is generated, and the hash value is digitally signed and solidified in the trusted execution environment of the device.Subsequently, the hash value of report file is calculated again after report generation, and the original sampling data hash and report hash are bound and written into blockchain simultaneously.Thus, by the double-hash binding structure, the problem of source tampering is effectively solved.

Description

Technical Field

[0001] This invention relates to the field of metrological verification technology, specifically to a method for generating and reliably storing verification reports for a metrological supervision platform. Background Technology

[0002] Mandatory verification of measuring instruments such as hydrogen dispensers is typically undertaken by provincial or municipal statutory metrological verification institutions. Verifiers carry standard instruments to the site and conduct multiple filling tests according to the verification procedures, recording key indicators such as indication error and repeatability. After completing the on-site tests, the verifiers must manually fill out a verification report based on the raw data. The report has a complex format, involving extensive numerical calculations and textual descriptions.

[0003] Currently, the generation of verification reports relies on manual or semi-automatic methods, which are inefficient and prone to errors. Furthermore, the format requirements of regulations vary across provinces. When verification agencies undertake verification obligations for multiple provinces simultaneously, they need to maintain multiple templates for each province, and the workload increases linearly with the number of provinces. In addition, most verification agencies save reports in PDF or Word format on local servers or USB drives, providing only paper or electronic versions to the inspected entities. If market regulators need to understand the verification status of hydrogen refueling machines within their jurisdiction, they must require companies to periodically submit scanned copies of reports or visit the site to review the original reports. The submission and review processes involve additional steps such as file transfer and format conversion, resulting in low regulatory efficiency. Moreover, in practice, even if the electronic verification report is digitally signed, it cannot guarantee that the data in the report is consistent with the original sampling data of the verification device, because the signature only applies to the final document and does not anchor the original data. In real-world dispute scenarios, it is impossible to effectively prove that the entire process from original sampling to report generation has not been tampered with.

[0004] The information disclosed in this background section is intended only to enhance the understanding of the background technology of this disclosure and should not be construed as an admission or in any way implying that the information constitutes prior art known to those skilled in the art. Summary of the Invention

[0005] In view of at least one of the above technical problems, this disclosure provides a method for generating and credibly storing verification reports for a metrological supervision platform, aiming to solve the technical problems of existing verification report generation being complex, inefficient, and prone to data tampering.

[0006] According to one aspect of this disclosure, a method for generating and reliably storing verification reports for a metrological supervision platform is provided, comprising the following steps: (1) Export structured verification metadata from the edge verification device, including the identification of the device being verified, verification result data, hash value of the original sampling data and province code; (2) Input the verification metadata into the lightweight large language model deployed on the edge verification device or local server. The lightweight large language model calls the corresponding template fragment from the local procedure knowledge base according to the province code, and constructs the template fragment and the verification result together into prompt words, driving the lightweight large language model to generate the corresponding verification report text and render it into a distributable file. (3) Calculate the report hash value of the distributable file of the inspection report, generate a data packet containing the report hash value and the original sampling data hash value, and write the data packet into the consortium blockchain through a smart contract; (4) Push the data package containing the verification report and the access address to the metrology supervision platform; (5) Receive the report file to be verified, calculate the hash value of the report file to be verified and compare it with the hash value of the report stored on the chain for the first time. At the same time, compare the hash value of the original sampled data stored on the chain with the hash value of the original output of the verification device for the second time, and output the verification status according to the comparison result.

[0007] In some embodiments of this disclosure, in step (2), compliance history verification reports from multiple provinces are collected, and each verification report is decomposed into a structured input including the province code and verification result data, and a text output of the corresponding verification conclusion, forming an instruction fine-tuning dataset.

[0008] In some embodiments of this disclosure, in step (2), a pre-trained Transformer decoder model with no more than 1.8 billion parameters is selected as the base model, the parameters of the base model are fine-tuned based on the instruction fine-tuning dataset, and after the fine-tuning is completed, a teacher model with more parameters than the base model is used to perform knowledge distillation on the base model.

[0009] In some embodiments of this disclosure, in step (2), the local procedure knowledge base is a vector database or structured rule base independent of the lightweight large language model, and is indexed by the province code. Each index entry includes the name and number of the verification procedure, the tolerance threshold, the compliance judgment logic, the conclusion sentence and the formatting requirements.

[0010] In some embodiments of this disclosure, in step (2), an output format constraint instruction is embedded in the prompt word to force the lightweight large language model to output the generated result according to a predefined JSON data structure; the JSON data structure includes a conclusion field, an error value field, and a reference procedure number field; and after the lightweight large language model outputs, a rule layer verification is performed on the corresponding JSON data structure.

[0011] In some embodiments of this disclosure, in step (3), the evidence storage data packet further includes the operator's decentralized identity identifier, the unique identifier of the device being tested, the evidence storage timestamp, and the province code; the smart contract maintains a global evidence storage record mapping table with the report hash as the primary key.

[0012] In some embodiments of this disclosure, in step (3), before the evidence storage data packet is written into the consortium blockchain, the absolute value between the evidence storage timestamp and the current block time of the blockchain is less than a preset threshold, the original sampling data hash value is not bound to other report hashes, the operator's decentralized identity belongs to the whitelist of the verification device, and the report hash is not stored, the evidence storage data packet is then written into the consortium blockchain.

[0013] In some embodiments of this disclosure, in step (3), the consortium blockchain includes several consensus nodes jointly operated by multiple regulatory agencies, and the consensus nodes maintain the consistency of connected data by adopting the Byzantine fault-tolerant consensus algorithm.

[0014] In some embodiments of this disclosure, in step (4), the metrology supervision platform generates a globally unique traceability code after receiving the data packet and access address of the verification report.

[0015] In some embodiments of this disclosure, in step (5), when both the first comparison and the second comparison match, the output verification status is that the data has not been tampered with and the original data is traceable; when the first comparison matches but the second comparison does not match, the output verification status is that the report version is correct but the original data is questionable; when the first comparison does not match, the output verification status is that the report does not match the evidence record.

[0016] One or more technical solutions provided in the embodiments of this application have at least one of the following technical effects or advantages: 1. The lightweight large language model, after knowledge distillation and hybrid precision quantization compression, is deployed in the edge computing equipment at the hydrogen refueling station. This ensures that the original verification data containing trade settlement sensitive information does not leave the station's local area network and does not need to be uploaded to the public cloud or third-party API services. At the same time, the edge deployment method eliminates the dependence on the Internet connection. Even if the network signal at the hydrogen refueling station is weak or completely disconnected, the verification report can still be generated normally.

[0017] 2. By constructing a local procedure knowledge base containing multiple provincial procedure texts, tolerance thresholds, and conclusion statement formats, and dynamically retrieving corresponding procedure fragments from the knowledge base based on the provincial code at runtime to construct prompt words, the large language model, fine-tuned from real compliance reports, generates verification conclusion paragraphs. This ensures that the generated reports are not only numerically accurate, but also that the language fully conforms to the specific writing habits of the verification procedures in that province.

[0018] 3. The hash calculation is pre-processed at the verification device. The SHA-256 hash value is calculated simultaneously with the generation of the original sampled data, and this hash value is digitally signed and solidified within the device's trusted execution environment. Subsequently, after the report is generated, the hash value of the report file is calculated again. The hash of the original sampled data and the hash of the report are then bound together and written to the blockchain. This dual-hash binding structure ensures that any attempt to tamper with the original data and regenerate the report will result in a hash mismatch, effectively solving the problem of source tampering. Attached Figure Description

[0019] Figure 1 This is a schematic diagram illustrating the process division of the verification report generation and credible evidence storage method in one embodiment of this application. Detailed Implementation

[0020] To better understand the technical solution of this application, the above technical solution will be described in detail below with reference to the accompanying drawings and specific embodiments.

[0021] To address the technical problems of complex and inefficient generation of existing verification reports, as well as the ease with which data can be tampered with, see [link to relevant documentation]. Figure 1 This example discloses a method for generating and reliably storing verification reports for a metrology supervision platform.

[0022] (1) Export structured verification metadata from the edge verification device, including the identification of the device being verified, verification result data, hash value of the original sampling data and province code.

[0023] After completing on-site calibration, the hydrogen dispenser calibration device generates raw sampling data, including indication error, repeatability, standard quality, and display quality. This data is typically stored internally in binary, proprietary formats, or as unstructured text, and cannot be directly used for report generation. Therefore, the calibrator must read the data from the device screen and manually record it on a paper calibration record sheet, or export a CSV file via USB drive, open the CSV file on a computer terminal, and copy and paste it into the report template.

[0024] Through long-term practice, the inventors found that there is an error rate of about 5% in the manual copying process. Although CSV files are machine readable, they lack standardized descriptions of metadata such as equipment number, inspector's identity, and province code, which still require manual supplementation. Furthermore, CSV files can be edited arbitrarily and cannot be used as a reliable source of evidence.

[0025] Therefore, in this embodiment, the firmware of the edge detection device is first modified to encapsulate the results into structured text-formatted metadata after detection. Specifically, in this example, the text-formatted metadata fields include the unique identifier of the detected device, the name of the hydrogen refueling station, the province code, the detection result object (containing the percentage of indication error, repeatability, display quality, standard quality, and timestamp), and the hash value of the original sampled data. This structured output allows downstream modules to directly parse and use the data without manual intervention. In this embodiment, the hash value of the original sampled data is obtained by the trusted execution environment built into the detection device through a SHA-256 operation on the millisecond-level original sample sequence, and once generated, it is locked and cannot be forged outside the device.

[0026] (2) Input the corresponding verification metadata into the lightweight large language model deployed on the edge verification device or local server. After the lightweight large language model calls the corresponding template fragment from the local procedure knowledge base according to the province code, it constructs the template fragment and verification result together into prompt words, drives the lightweight large language model to generate the corresponding verification report text and render it into a distributable file.

[0027] Considering that the verification report not only needs to be filled in with numerical values, but also needs to generate paragraphs containing correct procedure citations, compliance judgments, and natural language conclusions in accordance with the language style of the metrological verification procedures of each province, this embodiment deploys a lightweight large language model at the edge side, so that it can output natural language conclusions that conform to the specific procedure context based on the input structured error data.

[0028] Specifically, in this embodiment, a pre-trained Transformer decoder architecture with 1.8 billion (1.8B) parameters is selected as the base model Qwen-1.8B-Chat. In this example, the 1.8 billion parameters effectively balance semantic understanding capabilities with edge inference resource consumption. Its original weight file at FP16 precision is approximately 3.6GB, which can be reduced to less than 1GB after subsequent quantization and compression. Furthermore, the inference latency on an ARM architecture CPU can be controlled within 2 seconds. Simultaneously, its number of attention heads (approximately 24 heads) and hidden layer dimensions (approximately 2048 dimensions) are sufficient to accommodate the complex semantic features of the metrology. In terms of model architecture, this example retains the standard causal language model structure, including a multi-layered stacked Transformer decoder.

[0029] To accommodate subsequent edge deployments, in this embodiment, a pluggable linear adapter, activated only during the inference phase, is added after the embedding layer of the base model. This adapter maps the logits scores output by the model to a metrology-specific vocabulary space (e.g., increasing the generation probability of technical terms such as "indication error" and "repeatability"). This is equivalent to injecting prior knowledge of the metrology domain into the model, making it more likely to output technical terms even when subsequent fine-tuning data is limited, thus reducing the misuse of common terms.

[0030] However, considering that general pre-trained models are trained on massive amounts of internet corpora, while possessing a language foundation, they are completely unfamiliar with the specific procedures for hydrogen refueling machine verification and the verification measurement scenario. If directly used to generate verification conclusions, they might output statements with no professional value, such as "the equipment performs well." Therefore, this example first constructs an instruction fine-tuning dataset.

[0031] Specifically, in the actual project corresponding to this embodiment, after obtaining authorization from multiple provincial metrology research institutes and desensitizing sensitive information, over 3,200 compliance verification reports generated during actual verification work from 2019 to 2025, signed and confirmed by auditors, were collected, covering various equipment types such as hydrogen dispensers, gasoline dispensers, and compressed natural gas dispensers. Each report was then broken down, using raw verification data including equipment model, indication error, repeatability, ambient temperature, and standard instrument number as input, and the verification conclusion paragraph, cited procedure number, and final judgment result as output. Simultaneously, reports with non-standard formats and obvious hand-written alterations were cleaned and removed, ultimately retaining 2,150 valid samples. Furthermore, considering the limited number of actual reports from some provinces, this example employs back-translation and synonym substitution based on a metrology terminology dictionary to transform data from provinces with abundant samples into the expression style of provinces with scarce samples, achieving data augmentation. This resulted in the construction of a fine-tuning dataset of instructions covering 5 provinces and a total of 5,100 training samples. In this instruction fine-tuning dataset, the input to each training sample is a structured text description (including province code, indication error, repeatability, and procedure tolerance), and the output is the target conclusion paragraph.

[0032] Furthermore, this example applies structured constraints to the model's output format during the fine-tuning training phase. Specifically, each output target in the training samples is a set of key-value pairs containing predetermined fields. During training, the key names are provided to the model as prefixes for generating prompts, while the key values ​​are used as the training targets the model needs to generate. Thus, through repeated training guided by key names and generated key values, the model can accurately learn the ability to map test values ​​to fixed field positions, thereby avoiding formatting chaos and data misalignment that could result from free generation.

[0033] However, fully fine-tuning the entire model with 1.8 billion parameters based on the constructed instruction fine-tuning dataset requires at least a high-performance GPU with 24GB of VRAM, and the training time is several weeks. Edge devices cannot afford this training cost, and the weight file of the fine-tuned model is as large as the base model, which is not conducive to subsequent lightweight distribution. Therefore, in this embodiment, a trainable low-rank decomposition matrix pair with a rank of 16 is injected next to the attention calculation module of each Transformer layer of the base model. During training, all original weight parameters of the base model are frozen, and only about 2 million parameters in this low-rank matrix (accounting for about 1.1% of the total parameters) are updated. The training hardware uses a single NVIDIA RTX 3060 (12GB VRAM) consumer-grade graphics card, the training epochs are set to 5, and the learning rate adopts a cosine annealing strategy from 2×10 -4 Attenuation to 1×10 -5 The batch size was set to 4. The loss function used was standard autoregressive language modeling cross-entropy loss, with a focus on assigning a 1.2x loss weight to the last sentence of the conclusion paragraph (i.e., the final pass / fail judgment sentence) to enhance the model's accuracy in generating the most crucial conclusion. After training, the low-rank adaptation matrix was merged and saved with the original weights of the base model. The merged full weights were then subjected to temperature smoothing (temperature parameter T=2.0) in knowledge distillation to further soften the probability distribution, thereby improving the model's sensitivity to numerical errors. The final fine-tuned model file obtained in this example is approximately 3.6GB (FP16).

[0034] As can be seen, even after fine-tuning, the merged full model (FP16 precision) is still as large as 3.6GB, exceeding the 2GB memory limit of edge devices, and the inference speed is not fast enough. Therefore, in this embodiment, a larger model with 7 billion (7B) parameters is used as the teacher model, while the fine-tuned 1.8 billion model is used as the student model. The teacher model generates soft labels (i.e., outputs with probability distributions) under the same test input, and the student model fits the soft labels of the teacher model while fitting the original true labels. In addition, the distillation loss function is set as a weighted sum of KL divergence and cross-entropy loss, with a weight ratio of 0.7:0.3, and the number of distillation iterations is 100,000 steps, so that the student model can compress parameters while preserving the semantic understanding ability of the teacher model as much as possible. After distillation, layer-by-layer mixed precision quantization is performed on the weights of the 1.8 billion student model. Specifically, in this embodiment, the weights of the multi-head attention layer and output layer of the model are retained to INT8 precision, and the weights of the feedforward network layer are compressed to INT4 precision. The quantization calibration dataset uses 200 calibration samples that were not used in training, and the GPTQ algorithm is employed to find the optimal quantization scaling factor. Through distillation and mixed-precision quantization, the final model file size is 820MB, significantly smaller than 1GB. When loaded onto an edge device, the runtime memory usage is approximately 1.2GB, and the CPU inference time (optimized using OpenVINO or ONNX Runtime) is approximately 1.8 seconds per report.

[0035] Through practical implementation, the inventors found that this lightweight large language model may generate meaningless or incorrectly formatted text during reasoning, such as omitting information in the conclusion or outputting colloquial expressions like "passable" for the "%" symbol. Research revealed that conventional models employ standard autoregressive sampling strategies, resulting in highly randomized results, making them unsuitable for testing scenarios and leading to unpredictable outcomes.

[0036] Therefore, in this embodiment, structured constraint decoding is performed when the model is deployed at the edge, rather than free sampling. Specifically, in this example, when generating the next token at each time step, the system dynamically filters out invalid tokens according to a predefined JSON Schema. Simultaneously, the inference temperature is set to 0.1, and a combination of greedy search and beam search is used. First, a baseline sequence is generated by greedy search, then three candidate sequences are generated by beam search with a beam width of 3. Finally, the sequence with the highest numerical match to the input indication error value is selected as the final output. Furthermore, in this embodiment, the constraint decoding logic runs in a separate post-processing process. This process reads each token output by the model in real time and compares it with the regular expression of the current field. If a mismatch is found, the generation probability of the corresponding token is immediately set to negative infinity, forcing the model to reselect a compliant token. This effectively eliminates formatting errors caused by the illusion of a lightweight large language model, ensuring the seriousness of the final verification report.

[0037] Then, the compressed model is deployed on the edge server or local industrial control computer at the hydrogen refueling station, so that the verification data does not leave the station network throughout the process and does not need to be uploaded to the Internet, which can meet regulatory compliance requirements; and it can still work normally when the network is interrupted, without API call fees.

[0038] Furthermore, since the verification procedures of different provinces differ in terms of tolerance thresholds, reference numbers, and judgment rules, mixing all provincial rules into the model training would lead to model parameter conflicts, and fine-tuning would be required for each new province. Therefore, in this embodiment, a local procedure knowledge base independent of the lightweight large language model is constructed. Specifically, this local procedure knowledge base can be implemented using a vector database or a structured configuration file, with the province code as the primary key. Each record contains the procedure name and number corresponding to the province, the tolerance threshold, typical examples of qualified / unqualified statements, format requirements, and optional additional judgment rules. Before data enters the model, the corresponding procedure fragment is retrieved from the knowledge base in real time using the province code as an index. This fragment, along with the verification value and output format constraints, is then concatenated into a structured prompt word before being fed into the large language model. The prompt word instructs the model to output according to a specified JSON structure. This allows the model to focus on language generation, while the knowledge base focuses on rules and expressions, decoupling the two. Moreover, when a new province is added, only a record needs to be inserted into the knowledge base; there is no need to retrain or redeploy the model.

[0039] To avoid potential illusions during model generation, such as outputting non-existent procedure numbers or omitting percentage signs, this embodiment includes a rule-layer validator. This validator is executed after model generation to verify whether the output format conforms to predefined structural requirements, whether core judgment conclusions are limited to legally permissible expressions, whether error values ​​are complete and consistent with the original input verification data, and whether the referenced procedure numbers match the format recorded in the knowledge base. Furthermore, a random perturbation factor is added after a failed check to drive model regeneration. After two consecutive failures, the report is generated using a traditional template-filling method and marked as requiring manual review, while an anomaly log is recorded.

[0040] (3) Calculate the report hash value of the distributable file of the verification report, generate a data packet containing the report hash value and the original sampled data hash value, and write the data packet into the consortium blockchain through a smart contract.

[0041] Traditional electronic verification reports are easily tampered with, and the report itself cannot prove whether its content is consistent with the original sampling data of the verification device. Most existing blockchain evidence storage systems only store the hash value of the final electronic file. Writing the entire file to the blockchain would cause on-chain data bloat and high costs. However, simply hashing the report file and putting it on the blockchain can only verify that the report has not been tampered with, but it cannot prevent attacks that could modify the original data and regenerate a different but still compliant report.

[0042] Therefore, in this embodiment, after verification, the device immediately serializes the raw data according to a unified standard (e.g., unifying all floating-point numbers to double-precision format and appending the device serial number and timestamp), and calculates its SHA-256 hash value as the raw data fingerprint. In this example, the hash value calculation process is completed in the device's built-in trusted execution environment, and the calculation result is immediately stored in the device's secure storage area to prevent external tampering. In this example, the raw data includes not only the final displayed error and repeatability values, but also the millisecond-level raw pulse sequence or quality reading sequence recorded by the verification device during each injection test (e.g., acquiring 100 data points per second, with each injection lasting 30 seconds, resulting in 3000 raw floating-point numbers).

[0043] Subsequently, the original sampling data and the final generated PDF report are uploaded to the metering trusted storage cloud platform uniformly deployed by the regulatory authority. Before uploading, the file content is encrypted using the AES-256-GCM symmetric encryption algorithm to ensure storage security; and a SHA-256 hash value is generated for the encrypted file, serving as its unique object key within the storage cluster. Furthermore, the encrypted file generates a permanent Uniform Resource Identifier (URI) for later retrieval. Thus, off-chain storage addresses on-chain capacity bottlenecks while encryption ensures the protection of trade secrets.

[0044] In addition, in this embodiment, a dedicated metering and evidence storage smart contract is deployed on the consortium blockchain. This smart contract specifically maintains a global evidence storage record mapping table with the report hash as the primary key. During evidence storage, approximately 200 bytes of core fields, including the report hash (i.e., the SHA-256 of the complete PDF file), the original data hash, the operator's decentralized identity, the device number, the evidence storage timestamp, and the province code, are written into the contract. Upon receiving an evidence storage request, the smart contract automatically performs the following checks: timestamp validity (in this example, the time difference with the current block is set to no more than 5 minutes), original data fingerprint uniqueness (checking whether the original data fingerprint has been used), device and operation permission verification (determining the operator's decentralized identity based on the authorized whitelist maintained on the chain), and duplicate evidence storage verification (determining whether the final PDF report fingerprint is on the chain). Only when all checks pass will the data be written to the blockchain and the evidence storage event log be triggered.

[0045] In this example, each qualified inspector is assigned a unique W3C standard decentralized identity (DID), which is associated with an asymmetric key pair. The private key is stored in the inspector's secure hardware token, while the public key is recorded in the DID registration contract on the blockchain. Each time evidence is deposited, the inspector digitally signs the message body using their private key. The smart contract verifies the signature before execution, ensuring non-repudiation. The consortium blockchain is jointly operated by multiple institutions, including the provincial market supervision bureau and the metrology institute, using a practical Byzantine fault-tolerant consensus algorithm. This ensures system security and activity even if no more than one-third of the nodes malfunction or fail, with a stable block time of 1-3 seconds. In other embodiments, the regulatory body sets up observer nodes to synchronize all on-chain data for audit verification. Thus, joint operation by multiple institutions ensures that no single institution can tamper with historical records.

[0046] To prevent time-difference attacks where a qualified report is uploaded to the blockchain for verification before the original data is tampered with, the hash value of the original input data is calculated and recorded in the tamper-proof log inside the verification device before the report is generated. This ensures that the original data fingerprint is generated before the report fingerprint in the time series. Therefore, the smart contract can automatically verify this time series relationship by comparing the two timestamps. If an anomaly is detected (such as the original data hash timestamp being later than the report hash), it is automatically marked as a time series anomaly and a warning is issued.

[0047] Furthermore, since the fingerprint of the original sampling data is calculated and anchored before the verification device generates the report, while the report fingerprint is calculated after the report is generated, any attempt to modify the original data will result in a change to the original sampling data fingerprint. Consequently, an on-chain query will reveal that the device never stored the original data hash. Conversely, any attempt to tamper with the report after its generation will result in a mismatch between the PDF report fingerprint and the original data. By combining these two methods, the authenticity of both the original data and the report can be verified simultaneously.

[0048] (4) Push the data package and access address of the verification report to the metrology supervision platform.

[0049] After the report is generated and stored on the blockchain, to enable the metrology supervision platform to obtain the verification results in real time and automatically, in this embodiment, the supervision platform is triggered to push the data after the blockchain transaction returns a confirmation receipt (i.e., the transaction has been packaged and written into the block by the consensus node). The blockchain transaction hash is sent as an attachment during the push, allowing the supervision platform to immediately query the on-chain storage status through its observer node or RPC interface after receiving the data, thus confirming the authenticity of the data immediately. In other embodiments, considering that the push may fail due to network fluctuations, in this example, if the push fails, the push task is written to a local persistent retry queue, and a background thread retryes it every 30 seconds. If it still fails after 24 hours of continuous retries, an alarm is triggered to notify the system administrator for manual handling, thereby avoiding the loss of verification records due to momentary network fluctuations.

[0050] After successful evidence storage and push, the metadata is pushed to the provincial metrology supervision platform via a standard REST API. In this example, the pushed metadata includes the equipment ID, hydrogen refueling station name, verification date, verification conclusion (qualified / unqualified), off-chain storage URI of the report file, report hash, raw data hash, blockchain transaction hash, and operator DID.

[0051] Upon receiving the aforementioned metadata, the regulatory platform first verifies its completeness and then verifies the existence of a corresponding transaction hash record on the blockchain through its deployed blockchain observer nodes. Once verification is successful, a globally unique 12-digit traceability code is generated for the report, written into the platform's relational database, and associated with the report's metadata.

[0052] (5) Receive the report file to be verified, calculate the hash value of the report file to be verified and compare it with the hash value of the report stored on the chain for the first time. At the same time, compare the hash value of the original sampled data stored on the chain with the hash value of the original output of the verification device for the second time, and output the verification status according to the comparison result.

[0053] When regulators conduct verification, they upload a PDF report to the platform's backend. The platform calculates the report's SHA-256 value and then uses a blockchain query interface to check if a matching PDF report fingerprint exists. If found, the original fingerprint on the blockchain is further compared to the original fingerprint of the device's most recent verification on the platform, thus achieving verification.

[0054] Specifically, when the verification platform receives the PDF report to be verified, it first calculates the SHA-256 of the PDF and checks if a matching fingerprint exists on the blockchain for a first comparison. If a matching fingerprint exists, it further extracts the fingerprint of the original sampled data on the blockchain and performs a second comparison with the fingerprint of the data recorded in the original log of the verification device. When both the PDF report fingerprint and the original sampled data fingerprint match, it is determined that the report has not been tampered with and the original data is traceable. When the PDF report fingerprint matches but the original sampled data fingerprint does not match, it is determined that the report is correct but the original data is questionable. When the PDF report fingerprint does not match, it is determined that the report is not the original version.

[0055] This example uses the calibration of a hydrogen refueling machine at a hydrogen refueling station. First, the calibrator operates the edge calibration device, which automatically completes three refueling tests and generates a raw data sequence containing indication errors and repeatability. The security chip built into the calibration device calculates the SHA-256 hash value of this sequence and encapsulates all data into a structured JSON format. Then, the edge computing box (equipped with an RK3588 chip, 2GB RAM, and pre-installed Qwen-1.8B fine-tuning model) listens for new JSON files, reads the corresponding province code, retrieves the corresponding regulation fragment from the local regulation knowledge base, constructs prompt words, and adds JSON schema constraints. After the model outputs, the JSON is rendered into a Word document and converted to PDF format. The SHA-256 hash of the PDF file is then calculated, and a smart contract on the consortium blockchain is called, passing in the report hash, raw data hash, calibrator DID, device ID, timestamp, and other information. After confirmation by three consensus nodes, the transaction returns a success receipt and transaction hash. After successful on-chain processing, the report PDF is uploaded to the regulatory cloud and a URL is obtained. Then, the API of the corresponding regulatory platform is called to push metadata. During verification, the regulatory personnel upload the report PDF to the platform backend. The platform calculates the hash, and if a matching record is found on the blockchain, it shows that the data has not been tampered with and the original data is traceable, thus the verification is successful.

[0056] Although some preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the invention.

[0057] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this application and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. A method for generating and reliably storing verification reports for a metrological supervision platform, characterized in that, Includes the following steps: (1) Export structured verification metadata from the edge verification device, including the identification of the device being verified, verification result data, hash value of the original sampling data and province code; (2) Input the verification metadata into the lightweight large language model deployed on the edge verification device or local server. The lightweight large language model calls the corresponding template fragment from the local procedure knowledge base according to the province code, and constructs the template fragment and the verification result together into prompt words, driving the lightweight large language model to generate the corresponding verification report text and render it into a distributable file. (3) Calculate the report hash value of the distributable file of the inspection report, generate a data packet containing the report hash value and the original sampling data hash value, and write the data packet into the consortium blockchain through a smart contract; (4) Push the data package containing the verification report and the access address to the metrology supervision platform; (5) Receive the report file to be verified, calculate the hash value of the report file to be verified and compare it with the hash value of the report stored on the chain for the first time. At the same time, compare the hash value of the original sampled data stored on the chain with the hash value of the original output of the verification device for the second time, and output the verification status according to the comparison result.

2. The method for generating and reliably storing verification reports for a metrological supervision platform according to claim 1, characterized in that, In step (2), compliance history verification reports from multiple provinces are collected, and each verification report is broken down into structured inputs including province code and verification result data, and text outputs of corresponding verification conclusions, forming an instruction fine-tuning dataset.

3. The method for generating and reliably storing verification reports for a metrological supervision platform according to claim 2, characterized in that, In step (2), a pre-trained Transformer decoder model with no more than 1.8 billion parameters is selected as the base model. The parameters of the base model are fine-tuned based on the instruction fine-tuning dataset. After the fine-tuning is completed, a teacher model with more parameters than the base model is used to perform knowledge distillation on the base model.

4. The method for generating and reliably storing verification reports for a metrological supervision platform according to claim 1, characterized in that, In step (2), the local procedure knowledge base is a vector database or structured rule base independent of the lightweight large language model, and is indexed by the province code. Each index entry includes the name and number of the verification procedure, the tolerance threshold, the compliance judgment logic, the conclusion sentence and the formatting requirements.

5. The method for generating and reliably storing verification reports for a metrological supervision platform according to claim 1, characterized in that, In step (2), an output format constraint instruction is embedded in the prompt word to force the lightweight large language model to output the generated result according to the predefined JSON data structure; the JSON data structure includes a conclusion field, an error value field, and a reference procedure number field; and after the lightweight large language model outputs, a rule layer verification is performed on the corresponding JSON data structure.

6. The method for generating and reliably storing verification reports for a metrological supervision platform according to claim 1, characterized in that, In step (3), the evidence storage data package also includes the operator's decentralized identity identifier, the unique identifier of the device being inspected, the evidence storage timestamp, and the province code; the smart contract maintains a global evidence storage record mapping table with the report hash as the primary key.

7. The method for generating and reliably storing verification reports for a metrological supervision platform according to claim 6, characterized in that, In step (3), before the evidence storage data packet is written into the consortium blockchain, the absolute value between the evidence storage timestamp and the current block time of the blockchain is less than a preset threshold, the original sampling data hash value is not bound to other report hashes, the operator's decentralized identity belongs to the whitelist of the device being inspected, and the report hash is not stored, the evidence storage data packet is then written into the consortium blockchain.

8. The method for generating and reliably storing verification reports for a metrological supervision platform according to claim 7, characterized in that, In step (3), the consortium blockchain includes several consensus nodes jointly operated by multiple regulatory agencies, and the consensus nodes maintain the consistency of connected data by using the Byzantine fault-tolerant consensus algorithm.

9. The method for generating and reliably storing verification reports for a metrological supervision platform according to claim 1, characterized in that, In step (4), the metrology supervision platform generates a globally unique traceability code after receiving the data packet and access address of the verification report.

10. The method for generating and reliably storing verification reports for a metrological supervision platform according to claim 1, characterized in that, In step (5), when both the first comparison and the second comparison match, the output verification status is that the data has not been tampered with and the original data is traceable; when the first comparison matches but the second comparison does not match, the output verification status is that the report version is correct but the original data is questionable; when the first comparison does not match, the output verification status is that the report does not match the evidence record.

Images