A magnitude traceability data acquisition management system

Abstract

This application relates to the field of measurement traceability data management technology, and discloses a measurement traceability data acquisition and management system. The invention includes an event fragment construction module, a constraint graph generation module, a historical closure inversion module, and a conflict annotation and write-back module. The event fragment construction module acquires measurement collection data and multi-source traceability association records, and outputs measurement data anchor points and versioned traceability event fragments. The constraint graph generation module outputs historical valid intervals, submission visible intervals, and typified traceability constraint graphs. The historical closure inversion module outputs historical traceability chain snapshots and competing candidate chains around the target historical time point. The conflict annotation and write-back module outputs conflict source labels and performs historical snapshot write-back and historical snapshot index update. This system can improve the consistency, reproducibility, and audit efficiency of traceability chain reconstruction at a specified historical time point.

Description

Technical Field

[0001] This application relates to the field of measurement traceability data management technology, and in particular to a measurement traceability data acquisition and management system. Background Technology

[0002] In third-party metrology and calibration laboratories, pharmaceutical production lines, automotive parts testing lines, semiconductor manufacturing workshops, and periodic inspection management platforms for equipment such as electricity meters, pressure gauges, and temperature sensors, data collection and management for metrological traceability has become a fundamental aspect of ensuring the reliability and traceability of measurement results. Existing technologies typically record measurement data, calibration certificates, standard instrument information, correction parameters, and validity information separately through online data acquisition terminals, equipment ledger systems, certificate management systems, and laboratory information management systems. The system then displays related data in a linked manner based on equipment number, certificate number, and time range in the query interface. In some scenarios, the system also saves calibration record change logs, certificate upload records, and manual data entry records to meet subsequent audit and quality review needs. For example, in the online metrology scenario for pharmaceutical filling equipment, on-site sensors continuously output measurement values. Laboratory calibration personnel then upload certificate files, equipment maintenance personnel enter the correction parameters after maintenance, and management personnel ultimately query the traceability basis of the equipment during a specific batch of production through the ledger interface. For example, in the electricity meter verification platform, verification results, standard meter replacement records and certificate revision records may be stored in different data tables or even different business systems. On the surface, the system has the ability to collect, store, query and export data, but its underlying structure is still mainly based on scattered records and static associations. It mainly relies on certificate validity period matching, current status splicing and log tracing to generate traceability descriptions.

[0003] However, existing technologies still present a significant technical problem in the data acquisition and management of measurement traceability: once measurement data has been collected and business conclusions have been reached, the system struggles to accurately reconstruct the actual valid traceability status of that data at a specified historical point in time. In particular, it is difficult to further reconstruct whether the entire traceability chain related to that data was closed and consistent at that time. This problem arises because existing systems mostly focus on recording data update times and current relationships, with insufficient management of business activation times, revocation times, replacement times, and historical version snapshots. Certificate files, standard reference relationships, environment correction tables, measurement method versions, and personnel authorization status are scattered across different sources, and queries often involve directly concatenating data based on the current status or roughly filtering by time range. Consequently, when certificates are uploaded late, standards are replaced before entry, correction parameters are only partially revised, or old correction relationships are not cleared after maintenance and restoration, even if the system can display that a measurement data point is associated with a certificate, it is difficult to prove whether the certificate and its upstream references were truly valid at the time of collection. In practical applications, the traceability descriptions exported from the same batch of test results on different dates may not be consistent. Auditors may find it difficult to confirm the historical basis, and it may be difficult to form a stable, unique and reproducible historical caliber when tracing accountability for quality accidents. Therefore, there is an urgent need for a quantitative traceability data collection and management solution that can uniformly organize and reconstruct the historical data, traceability nodes, relationship edges and their historical effective intervals. Summary of the Invention

[0004] This application proposes a measurement traceability data acquisition and management system to address the problems raised in the background art.

[0005] To achieve the above objectives, this application adopts the following technical solution: a measurement traceability data acquisition and management system, comprising:

[0006] The event fragment construction module acquires the collected measurement data and multi-source traceability records, performs unified timescale conversion on the collected measurement data, performs versioning organization on the multi-source traceability records, and outputs the measurement data anchor point and versioned traceability event fragment.

[0007] The constraint graph generation module obtains versioned traceability event fragments, performs historical valid interval construction, commit visible interval construction, and constraint relationship organization on the versioned traceability event fragments, and outputs historical valid intervals, commit visible intervals, and typed traceability constraint graphs.

[0008] The historical closure inversion module obtains the target historical time point and the typified source constraint graph, performs interval intersection and closure inversion on the typified source constraint graph, and outputs a historical source chain snapshot and competing candidate chains;

[0009] The conflict labeling and write-back module obtains historical source chain snapshots and competing candidate chains, performs conflict detection and conflict labeling on the historical source chain snapshots and competing candidate chains, outputs conflict source tags, and performs historical snapshot write-back and historical snapshot index update.

[0010] Furthermore, the measurement data collected should include at least the equipment identifier, measurement item identifier, time of collection, time of system entry, and measurement result; the multi-source traceability and association records should include at least the equipment certificate record, standard reference record, correction parameter record, method version record, and authorization status record.

[0011] Specifically, the equipment certificate record includes at least the certificate identifier, corresponding equipment identifier, service effective start time, service effective end time, system entry time, and revocation or replacement time; the standard reference record includes at least the upstream standard identifier, corresponding equipment identifier, service effective start time, service effective end time, system entry time, and upstream reference information; the correction parameter record includes at least the corresponding object identifier, corresponding equipment identifier, service effective start time, service effective end time, system entry time, and correction parameter association information; the method version record includes at least the corresponding object identifier, corresponding equipment identifier, service effective start time, service effective end time, system entry time, and method version association information; the authorization status record includes at least the corresponding object identifier, service effective start time, service effective end time, and system entry time; and the measurement value acquisition data and multi-source traceability association record also include a source identifier used to characterize the source of the record acquisition or writing.

[0012] Furthermore, the event fragment construction module performs a unified timestamp conversion on the collected data. Specifically, it extracts the collection time, business start time, business end time, system entry time, and cancellation or replacement time from the collected data and multi-source traceability association records as the original timestamps.

[0013] For original timestamps with time zone identifiers, conversion is performed according to a unified time zone standard. For original timestamps without time zone identifiers, the conversion is performed after supplementing according to the default time zone corresponding to the record source. Then, clock deviation correction is performed on the original timestamps based on the statistical results of the time difference between the system entry time and the corresponding original timestamp in the same record source. Subsequently, discretization processing is performed based on the maximum value among the minimum recording interval of the time field of the quantitative data collection, the minimum recording interval of the system entry time, and the minimum time interval of the adjacent synchronization time fields of the multi-source traceability and association records, in order to obtain a unified time scale.

[0014] Furthermore, the event fragment construction module performs versioned organization on the multi-source traceability and association records. Specifically, it constructs a measurement data anchor point for each measurement data acquisition based on the device identifier, measurement project identifier, and unified timescale corresponding to the acquisition time. It then filters records from the multi-source traceability and association records that match the device identifier corresponding to the measurement data anchor point, or whose upstream reference information, correction parameter association information, or method version association information points to the device identifier corresponding to the measurement data anchor point. The filtered records are then categorized according to device certificate, standard reference, correction parameter, method version, and authorization status. Within each object category, a business version sequence is formed based on the business activation start time, and a submission version sequence is formed based on the system entry time. Based on the business version sequence and the submission version sequence, version succession, substitution, and overriding relationships are identified to generate versioned traceability event fragments.

[0015] Furthermore, the constraint graph generation module constructs historical valid intervals and submission visible intervals based on versioned traceability event fragments. Specifically, for each versioned traceability event fragment, a historical valid interval is constructed using the business activation start time and business activation end time, and a submission visible interval is constructed using the system entry time and the cancellation or replacement time. When the business activation end time is missing, the first subsequent versioned traceability event fragment with a business activation start time later than the current versioned traceability event fragment's business activation start time is retrieved under the same object category and record category, and the business activation start time of the first subsequent versioned traceability event fragment is used to fill in the endpoint of the historical valid interval. When the cancellation or replacement time is missing, the first subsequent versioned traceability event fragment with a system entry time later than the current versioned traceability event fragment's system entry time is retrieved under the same object category and record category, and the system entry time of the first subsequent versioned traceability event fragment is used to fill in the endpoint of the submission visible interval. When no first subsequent versioned traceability event fragment is found, the current system time corresponding to the generation of the historical valid interval and submission visible interval is used as the filler value for the missing endpoint.

[0016] Furthermore, the constraint graph generation module constructs a typed tracing constraint graph. Specifically, it uses quantitative data anchor points as the association starting points and versioned tracing event fragments as graph nodes to establish slot hierarchies based on device certificates, standard references, correction parameters, method versions, and authorization status. It then performs object connection checks, upstream reference connection checks, and version inheritance checks on versioned tracing event fragments in adjacent slot hierarchies. Only node connection edges that pass the object connection check, upstream reference connection check, and version inheritance check are retained to generate the typed tracing constraint graph.

[0017] Furthermore, the historical closure inversion module performs interval intersection on the typified source tracing constraint graph. Specifically, it constructs a query time window around the target historical time point and based on the basic time granularity; it selects versioned source tracing event fragments that intersect with the query time window as candidate versioned source tracing event fragments; and then performs slot aggregation on the candidate versioned source tracing event fragments according to device certificate, standard reference, correction parameter, method version, and authorization status, and deletes redundant fragments in the same slot whose historical valid interval is covered by other candidate versioned source tracing event fragments and whose system entry time is later.

[0018] Furthermore, the historical closure inversion module performs closure inversion on candidate versioned traceability event fragments. Specifically, it performs path expansion along the node connection edges in the typed traceability constraint graph. During the path expansion process, it performs common effective coverage checks, object connection checks, and upstream reference connection checks on adjacent candidate versioned traceability event fragments and deletes candidate paths that fail the checks. The candidate paths that pass the checks are organized into candidate historical traceability chains, and historical traceability chain snapshots and competing candidate chains are determined first from the candidate historical traceability chains that simultaneously cover the slots corresponding to device certificates, standard references, correction parameters, method versions, and authorization status.

[0019] Furthermore, the conflict annotation and write-back module performs conflict detection and conflict annotation on the historical traceability chain snapshot and the competing candidate chain. Specifically, it performs a slot-by-slot comparison of the historical traceability chain snapshot and the competing candidate chain according to device certificate, standard reference, correction parameters, method version, and authorization status. When the historical valid interval of the corresponding versioned traceability event fragment in the competing candidate chain covers the target historical time point and its system entry time is later than the target historical time point, a late revision label is generated. When there is a subsequent versioned traceability event fragment with a later system entry time and a substitution relationship with the corresponding versioned traceability event fragment in the historical traceability chain snapshot under the same object classification and the same slot, an upstream substitution label is generated. When adjacent versioned traceability event fragments in the historical traceability chain snapshot do not have continuous common valid coverage within the query time window, an interval break label is generated.

[0020] Furthermore, the conflict annotation and write-back module performs historical snapshot write-back and historical snapshot index update. Specifically, it writes the historical source chain snapshot, competing candidate chain, conflict source label, and target historical time point to the historical snapshot database, and establishes the association between the historical source chain snapshot and the quantitative data anchor point. The historical snapshot index update includes object index update, time index update, and version index update, so that subsequent historical queries can locate the corresponding historical snapshot record based on the quantitative data anchor point and the target historical time point, and return the versioned source event fragments and conflict source labels in the historical snapshot record.

[0021] The beneficial effects of this invention are as follows:

[0022] This invention, by acquiring measurement data and multi-source traceability records, performs unified timescale conversion and versioned organization to form measurement data anchors and versioned traceability event fragments. This solves the problems of inconsistent time bases, mixed version relationships, and difficulty in stably linking measurement data with historical data, thus providing a unified time and object basis for subsequent historical reconstruction. Furthermore, by constructing historical valid intervals, submitting visible intervals, and typified traceability constraint graphs, it addresses the issues of historical caliber drift and confusion between business valid boundaries and system visible boundaries caused by existing systems only splicing data according to the current state. This effectively incorporates both business historical constraints and system record constraints into the same traceability structure. Results: By performing interval intersection and closure inversion around the target historical time point, the system outputs a historical source chain snapshot and competing candidate chains, solving the problems of difficulty in closing and reconstructing the source chain at a specified historical time point and inconsistency in historical basis at different query time points. This improves the stability, reproducibility, and traceability of historical source tracing results. By performing conflict detection, conflict annotation, historical snapshot write-back, and historical snapshot index update on the historical source chain snapshot and competing candidate chains, the system solves the problems of difficulty in locating conflict sources such as late revisions, upstream substitutions, and interval breaks, and the lack of direct retrieval basis for subsequent auditing and review. This improves the ability to interpret anomalies, review efficiency, and consistency of historical queries. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort:

[0024] Figure 1 This is a system framework diagram of the present invention;

[0025] Figure 2 This is a flowchart of the history closure inversion module of the present invention. Detailed Implementation

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

[0027] Example

[0028] like Figure 1 and Figure 2 As shown, the present invention discloses a data acquisition and management system for traceability of measurement values, including: an event fragment construction module, a constraint diagram generation module, a historical closure inversion module, and a conflict annotation and write-back module.

[0029] In one implementation, the event fragment construction module is used to acquire the measurement value collection data and multi-source traceability association records, perform unified time scale conversion on the time fields in the measurement value collection data and multi-source traceability association records, and perform versioned organization around the measurement value collection data. It outputs measurement value data anchor points and versioned traceability event fragments as the input basis for subsequent construction of historical valid intervals, construction of submission visible intervals, and generation of typified traceability constraint graphs. This module first completes the unified time scale conversion and then completes the versioned organization.

[0030] Furthermore, in this embodiment, the actual queryable state is used to characterize whether a certain versioned traceability event fragment simultaneously meets the business history establishment condition and the system history visibility condition at the target historical time point. Specifically, for any versioned traceability event fragment, it is first determined whether the target historical time point falls within the historical valid interval corresponding to the versioned traceability event fragment, and then it is determined whether the target historical time point falls within the submission visibility interval corresponding to the versioned traceability event fragment. When both conditions are met simultaneously, it is determined that the versioned traceability event fragment is in an actually queryable state at the target historical time point. When the target historical time point only falls within the historical valid interval but not within the submission visibility interval, it indicates that the fragment has been established in the business history but has not yet entered the system visibility range at the target historical time point, and the fragment does not enter the queryable candidate set of the target historical time point. When the target historical time point only falls within the submission visibility interval but not within the historical valid interval, it indicates that although the fragment has entered the system record range, it has not yet constituted a valid state at that time in the business history, and the fragment also does not enter the queryable candidate set of the target historical time point.

[0031] The measurement data acquisition data includes at least the equipment identifier, measurement item identifier, acquisition time, system entry time, and measurement result; the multi-source traceability association record includes at least the equipment certificate record, standard reference record, correction parameter record, method version record, and authorization status record, and retains the corresponding object identifier, service effective start time, service effective end time, system entry time, and relationship information corresponding to the record category; the measurement data acquisition data and multi-source traceability association record also retain the source identifier, which is used to characterize the source of the record acquisition or writing. The measurement result retains the original physical dimension storage in this module and only participates in the association as the anchor attribute of the measurement data. It does not participate in the unified time scale conversion, time difference statistics, and interval calculation.

[0032] Specifically, the event fragment construction module first extracts the time of data collection, the start time of business activation, the end time of business activation, the system entry time, and the time of cancellation or replacement as the original timestamps. For original timestamps with time zone identifiers, conversion is performed according to the unified time zone standard. For original timestamps without time zone identifiers, the default time zone is retrieved from the preset source configuration table based on the source identifier before conversion is performed. After time zone unification is completed, source-level time offset correction is performed on the original business system source and the structured interface synchronization source that meets the requirements of continuous online push, single-hop write, no cache queue backlog, and no batch supplementary entry. For attachment parsing source, manual entry source, and structured interface synchronization source with cache queue backlog, batch supplementary entry, or periodic centralized write, only time zone unification is performed, and source-level time offset correction is not performed.

[0033] The specific method for source-level time offset correction is as follows: Extract time difference samples between the original timestamp and the system entry time from the most recent consecutive valid records under the same source identifier. The number of samples is preferably 10 to 100. When the number of valid samples is not less than 10, and the time difference fluctuation after removing outliers does not exceed twice the base time granularity, use the median difference as the time offset for the current batch of that source. Then, use this time offset to perform a unified translation correction on the original timestamps under the same source. When the number of samples is less than 10, or the time difference fluctuation exceeds twice the base time granularity, only the time zone uniformity result is retained and marked as to be corrected. Outlier removal preferably uses the median absolute deviation method. Subsequently, the minimum recording interval of the time field of the collected data, the minimum recording interval of the system entry time, and the minimum time interval of the adjacent synchronization time fields of the multi-source traceability related records are statistically analyzed. The maximum value among the three is taken as the base time granularity, and then the time field is discretized based on this base time granularity. A unified timescale is obtained, preferably represented as a time index value discretized according to the basic time granularity. The scenario type is preferably determined based on the source identifier and writing mode. Specifically, the basic time granularity is preferably 1 second to 1 minute in online acquisition scenarios, 1 minute to 1 hour in batch synchronization scenarios, 1 hour to 1 day in periodic inspection scenarios, and 1 to 30 days in low-frequency audit archiving scenarios. The unified reference starting time is preferably the standard time corresponding to the earliest valid record in the current system's historical database. When building the database for the first time, the unified reference starting time is preferably the standard time corresponding to the earliest original timestamp in the current batch of data. After completing the above preparations, for each original timestamp, the unified reference starting time is first subtracted from the time value after correction for unified time zone and source-level time offset. Then, the resulting time difference is divided by the basic time granularity, and the result is converted into a discrete time index value, thus obtaining the unified timescale. After this processing, the subsequent historical valid interval, submission visible interval, and query time window are all formed and calculated within the same time space.

[0034] After completing the unified timescale conversion, the event fragment construction module constructs a measurement data anchor point around each measurement data acquisition. The measurement data anchor point is preferably determined by the device identifier, measurement item identifier, and the unified timescale corresponding to the acquisition time. When multiple measurement data acquisitions exist under the same device identifier, measurement item identifier, and unified timescale, it is first determined whether they constitute duplicate writing. The preferred method for determining duplicate writing is: consistent source identifiers, measurement result differences not exceeding the smallest resolvable unit corresponding to the device resolution, and system entry time intervals not exceeding one basic time granularity. The device resolution is preferably derived from the range resolution field in the device file table. When the field is missing in the archive table, the smallest resolution unit corresponding to the number of digits retained in the measurement result is used as a substitute. For records that are duplicated, only one master record is retained, and the remaining records are written to the duplicate record set. The master record is preferably determined according to the priority of the source identifier, the integrity of the core fields, and the order of system entry time. Among them, the original business system source is higher than the structured interface synchronization source, higher than the attachment parsing source, and higher than the manual entry source. The core fields preferably include the device identifier, measurement item identifier, acquisition time, system entry time, and measurement result. Through this processing, the measurement data anchor can be stably mapped to the specific device, specific measurement item, and specific acquisition unit.

[0035] After the measurement data anchor is established, the event fragment construction module performs versioning organization on the multi-source traceability and association records. Specifically, it first filters records that match the device identifier corresponding to the measurement data anchor. For records that do not directly carry the corresponding device identifier but carry upstream reference information, correction parameter association information, or method version association information, it performs association pointing judgment according to the pre-set object association table. When the association field can fall to the device identifier corresponding to the measurement data anchor within a mapping depth of no more than 3 levels, the record is considered to be associated with the measurement data anchor. After filtering, objects are categorized according to device certificate, standard reference, correction parameter, method version, and authorization status. Within each object category, a business version sequence and a submission version sequence are simultaneously formed. The business version sequence is arranged in ascending order of the business activation start time, and the submission version sequence is arranged in ascending order of the system entry time. Subsequently, version succession, substitution, and overriding relationships are identified based on the dual sequences. To ensure uniqueness, the priority is to determine the relationship in the order of overriding, substitution, and version succession, using mutual exclusion rules. Retaining a unique relationship: When the business validity period of the later record completely covers the business validity period of the earlier record, it is determined to be a coverage relationship; when the coverage relationship is not established, when the business validity start time of the later record falls within the business validity period of the earlier record, or when the business validity start times of the two records are the same and the system entry time of the later record is later, it is determined to be a substitution relationship; when neither of the above two types of relationships is established, when the later record and the earlier record belong to the same record category and the business validity start time is later than the business validity start time of the earlier record, but does not fall within the business validity period of the earlier record, it is determined to be a version succession relationship. When the business validity termination time of the earlier record is missing, substitution relationship is prioritized only when the system entry time of the later record is not later than the system entry time of the current value data anchor point; otherwise, it is temporarily recorded as a pending succession relationship. The pending succession relationship will be further solidified into a version succession relationship or substitution relationship in the subsequent historical valid interval construction stage after the business validity end point is supplemented by the first subsequent version traceability event fragment.

[0036] After the relationship identification is completed, the event fragment construction module generates versioned traceability event fragments. Each versioned traceability event fragment corresponds to one quantitative data anchor point, one object category, and one valid record that has passed the filtering. Preferably, each versioned traceability event fragment carries the following fields: the event type field corresponding to the record category, the object identifier used to uniquely indicate the associated object, the version identifier used to distinguish the evolution order of similar events, the upstream reference information used to characterize the upstream reference relationship, the semantic slot identifier used to characterize the processing level, the source identifier, the business effective start time, the business effective end time, the system entry time, and the revocation or replacement time.

[0037] In this implementation, device certificates, standard references, correction parameters, method versions, and authorization status utilize the relationship and time information from their corresponding records. To ensure the feasibility of subsequent processing, this implementation sets thresholds for core essential fields for each type of record: device certificate records preferably include at least a certificate identifier, a corresponding device identifier, a business activation start time, and a system entry time; standard reference records preferably include at least an upstream standard identifier, a corresponding device identifier, a system entry time, and upstream reference information; correction parameter records and method version records preferably include at least a corresponding object identifier, a corresponding device identifier, a system entry time, and corresponding association information; authorization status records preferably include at least a corresponding object identifier, a business activation start time, and a system entry time. Records lacking any of these core essential fields will not be generated into versioned versions that can participate in subsequent processing. The traceability event fragments are only written to the record set to be reviewed. For records that pass the core required field threshold, the field completeness characterization value is formed by the proportion of the number of valid fields that are not empty, have a valid format, and pass the source consistency check to the total number of required fields for that record category. In other words, the total number of required fields that a record should theoretically contain is first determined according to the record category. Then, the number of fields that have been successfully parsed and verified in the current record is counted. Finally, the number of valid fields is divided by the total number of required fields to obtain a field completeness characterization value between 0 and 1. Versioned traceability event fragments with a field completeness characterization value lower than 0.50 are only included in the candidate set and not in the priority closure set, but are still retained as candidate fragments for manual review. Versioned traceability event fragments with a field completeness characterization value not lower than 0.50 can be included in the priority closure set.

[0038] Meanwhile, a source credibility level is formed based on the source identifier. Preferably, in scenarios with existing historical calibration samples, the data is categorized according to the consistency rate of manual review, the field backfilling correction rate, and the record cancellation rate over the past three months. In scenarios lacking historical calibration samples, a fixed mapping rule pre-written into a parameter table can be used as the default implementation. The source mapping for the original business system is 1.00, the source mapping for the structured interface synchronization is 0.90, the source mapping for the attachment parsing is 0.70, the source mapping for manual entry is 0.60, and the source mapping for unknown sources is 0.50. The meaning of this fixed mapping rule is: first, identify the source identifier of the current versioned traceability event fragment, and then read the source credibility level value corresponding to the source identifier from the pre-set mapping table. The source credibility level does not change whether the versioned traceability event fragment is generated, but only serves as an auxiliary basis for subsequent historical closure inversion and conflict interpretation. Records with a source credibility level lower than 0.30 are only retained when there are no other similar records.

[0039] Through the above processing, the event fragment construction module finally outputs the value data anchor point and the associated versioned traceability event fragment set. This output retains the unified time basis, object association basis, and version evolution basis, providing an input basis for subsequent construction of historical valid intervals, construction of submission visible intervals, generation of typed traceability constraint graphs, and historical closure inversion.

[0040] In one implementation, the constraint graph generation module receives the value data anchor points and versioned traceability event fragments output by the event fragment construction module. Based on the versioned traceability event fragments, it constructs historical valid intervals and submission visible intervals, and organizes them into a typified traceability constraint graph. This graph serves as the structured input for the subsequent historical closure inversion module to perform interval intersection and closure inversion. This module acquires the versioned traceability event fragments, performs historical valid interval construction, submission visible interval construction, and constraint relationship organization on the versioned traceability event fragments, and outputs the historical valid intervals, submission visible intervals, and the typified traceability constraint graph. Here, the value data... Anchor points in this module are used only as the root node and associated starting point of the graph, and do not participate in interval endpoint completion or node validity determination. Versioned traceability event fragments are used as direct processing objects in this module for interval construction, subsequent retrieval, and graph edge generation. The start time of business activation, the end time of business activation, the system entry time, and the cancellation or replacement time have all been converted into discrete time index values ​​in a unified time scale space by the event fragment construction module when entering this module. Therefore, all time comparisons, interval construction, interval overlap judgments, and order judgments in this module are completed in the unified time scale space, and the original timestamps are no longer used directly.

[0041] Specifically, the constraint graph generation module first constructs a historical valid interval for each versioned traceability event fragment. The historical valid interval is used to represent the effective time range of the corresponding versioned traceability event fragment in the real business history. The starting point of the interval is the business effective start time of the versioned traceability event fragment, and the ending point of the interval is preferably the business effective end time of the versioned traceability event fragment. When the business effective end time exists, the constraint graph generation module directly constructs the historical valid interval with the business effective start time and the business effective end time. When the business effective end time is missing, the constraint graph generation module retrieves the first subsequent versioned traceability event fragment under the same object classification and the same record category.

[0042] Object classification follows the classification results output by the event fragment construction module. Record categories are limited to the corresponding categories in device certificate, standard reference, correction parameter, method version, and authorization status. "Successor" preferably refers to versioned traceability event fragments whose system entry time is later than the current versioned traceability event fragment's system entry time, and which have a confirmed version succession, replacement, or overriding relationship with the current versioned traceability event fragment. "First" is preferably determined in ascending order of system entry time. When there are more than one successor versioned traceability event fragment with the same system entry time, it is then determined in ascending order of business effective start time. If the business effective start time is still the same, it is determined by the priority of the source identifier. The priority of the source identifier is preferably the original business system source, which is higher than the structured interface synchronization source, which is higher than the attachment parsing source, which is higher than the manual entry source. If the source identifier is still the same, it is determined in ascending order of the version identifier sort value. When the version identifier is missing or the version identifier sort value is the same, it is determined in ascending order of the record primary key.

[0043] To avoid introducing distant and irrelevant subsequent records when there are too many historical versions, the retrieval depth of the first subsequent versioned traceability event fragment is preferably limited to within the next 20 versioned traceability event fragments. When the number of subsequent versioned traceability event fragments exceeds 20, only the 20 candidate fragments whose system entry time is closest to the current versioned traceability event fragment are selected. After the first subsequent versioned traceability event fragment is retrieved, the constraint graph generation module uses the business effective start time of the first subsequent versioned traceability event fragment as the endpoint of the historical valid interval of the current versioned traceability event fragment. If the first subsequent versioned traceability event fragment is not retrieved, the current unified system time is used as the temporary endpoint of the historical valid interval. The current unified system time is calculated by converting the current standard time of the system according to the same time base as the unified time scale conversion. Therefore, it also belongs to the discrete time index value in the unified time scale space and can directly participate in the interval endpoint expression. The temporary endpoint here is only used for the expression of open intervals in the current graph generation batch or the current query batch and is not written back to the original record as a permanent endpoint.

[0044] After constructing the historical valid interval, the constraint graph generation module further constructs a submission visible interval for each versioned traceability event fragment. The submission visible interval characterizes the time range within which the corresponding versioned traceability event fragment can be retrieved, observed, and replaced or revoked by subsequent records within the system. The starting point of the interval is the system entry time, and the ending point is preferably the revocation or replacement time. When a revocation or replacement time exists, the constraint graph generation module directly constructs the submission visible interval using the system entry time and the revocation or replacement time. When a revocation or replacement time is missing, the constraint graph generation module still retrieves the first subsequent versioned traceability event fragment under the same object classification and the same record category, and uses the first subsequent versioned traceability event fragment's... The system entry time serves as the endpoint of the current versioned traceability event fragment submission visibility interval. When no subsequent versioned traceability event fragment is found, the current unified system time is used as the temporary endpoint of the submission visibility interval. Through the above processing, the historical valid interval reflects the effective boundary in the real business history, and the submission visibility interval reflects the visible boundary and alternative boundary within the system. The two are determined by the business time field and the system time field, respectively, and together they affect the node attribute settings in the subsequent typed traceability constraint diagram, enabling the subsequent historical closure inversion module to distinguish between versioned traceability event fragments that are already valid in the business but were entered late in the system and versioned traceability event fragments that have appeared in the system but have not yet constituted the current valid state in the business.

[0045] After all historical valid intervals and commit visible intervals are constructed, the constraint graph generation module generates a typed traceability constraint graph. The input of the typed traceability constraint graph includes quantity data anchors, versioned traceability event fragments, historical valid intervals, and commit visible intervals. The output is a graph structure containing node sets, hierarchical relationships, and edge constraint relationships. Specifically, the constraint graph generation module incorporates quantity data anchors as the root nodes of the graph structure and versioned traceability event fragments as business nodes. Quantity data anchors only establish Level 1 connections with versioned traceability event fragments corresponding to the device certificate record category. When a device certificate record category is missing, quantity data anchors are allowed to establish alternative Level 1 connections with versioned traceability event fragments corresponding to the standard reference record category. Quantity data anchors do not directly traverse connections to correction parameters, method versions, and authorization states. The corresponding versioned traceability event fragments are then used as business nodes in the constraint graph generation module. Five slot levels are established based on five record categories: device certificate, standard reference, correction parameter, method version, and authorization status. The device certificate level receives versioned traceability event fragments directly corresponding to the current certificate status of the device. The standard reference level receives upstream standard references related to the target device certificate or verification process. The correction parameter level receives correction parameter records applicable to the current measurement value processing. The method version level receives the corresponding method version records for the current measurement value processing or verification process. The authorization status level receives the corresponding authorization status records when executing the corresponding measurement value processing or verification process. These slot levels are used to limit the business order and connection range of nodes in the graph, and are not used to redefine record categories.

[0046] After the slot hierarchy is established, the constraint graph generation module performs connection validity checks on the versioned traceability event fragments in adjacent slot hierarchies, and only retains the node connection edges that pass the check. The connection validity check includes at least object connection check, upstream reference connection check, and version inheritance check, and is performed in the following order: object connection check, upstream reference connection check, and version inheritance check. The reason for adopting this order is that the object ownership relationship constitutes the most basic connection premise; when the object ownership relationship is not valid, neither the upstream reference relationship nor the version relationship can form a valid traceability chain; after the object ownership relationship is valid, it is then determined whether the upstream reference relationship is closed; after both the object ownership relationship and the upstream reference relationship are valid, it is then determined whether the version relationship and the connection direction are consistent with the confirmed historical evolution relationship in the system.

[0047] The object connection check is used to confirm whether versioned traceability event fragments in two adjacent slot levels are on the same traceable object path. Preferably, the object connection check is considered passed when the object identifier of the later versioned traceability event fragment is the same as the object identifier of the earlier versioned traceability event fragment, or when the object identifier of the later versioned traceability event fragment can be mapped to the object identifier of the earlier versioned traceability event fragment through a pre-defined object association table, or when both belong to the same device object, the same upstream standard object, or the same method version association object. The upstream reference connection check is used to confirm whether the upstream reference information carried by the later versioned traceability event fragment can point to the earlier versioned traceability event fragment. Preferably, when the upstream reference information carried by the later versioned traceability event fragment is on the same traceable object path, the object connection check is considered passed when the object identifier of the later versioned traceability event fragment is the same as the object identifier of the earlier versioned traceability event fragment. If the upstream reference information is consistent with the object identifier of the previous versioned traceability event fragment, or consistent with the version identifier of the previous versioned traceability event fragment, or can point to the object identifier of the previous versioned traceability event fragment after mapping through the pre-set object association table, the upstream reference connection check is deemed to pass. The version succession check is used to confirm that there is no conflict in the connection direction and business order of the versioned traceability event fragments in two adjacent slot levels. Preferably, when the system entry time of the later versioned traceability event fragment is not earlier than the system entry time of the earlier versioned traceability event fragment, and there is no record category mismatch, version direction reversal, or conflict with the confirmed version succession relationship, substitution relationship, or overriding relationship between the two, the version succession check is deemed to pass.

[0048] After all three checks are completed, the constraint graph generation module generates a binary connection result for each node to be connected. When the object connection check, upstream reference connection check, and version inheritance check all pass, it is determined that the node pair to be connected is allowed to establish a historical tracing relationship, and the corresponding node connection edge is retained. When any check fails, it is determined that the node pair to be connected is not allowed to establish a historical tracing relationship, and the corresponding node connection edge is deleted. The reason why the constraint graph generation module uses binary connection results is that the task of this module is to generate candidate constraint edges that can be directly called in subsequent historical closure inversion. It only needs to answer whether historical tracing relationships are allowed. More granular connection competition, path priority, and candidate chain sorting are not handled in this module, but are handled in the subsequent historical closure inversion module and conflict annotation and write-back module. In order to ensure subsequent traceability, the constraint graph generation module adds a connection legality source mark to the retained node connection edge. The connection legality source mark includes at least one or more of the following: object connection passed, upstream reference connection passed, and version inheritance passed. It is used to characterize the basis for why the current node connection edge is retained.

[0049] When a versioned traceability event fragment fails to form any node connection edges that pass the connection validity check in adjacent slot levels, the constraint graph generation module still retains the versioned traceability event fragment as a graph node and marks it as an isolated node. To avoid a large accumulation of low-quality nodes in the graph, the retention threshold for isolated nodes is preferably that the field completeness characterization value of the versioned traceability event fragment is not lower than 0.50. Versioned traceability event fragments with a field completeness characterization value lower than 0.50 are not included in the graph node set, but are only retained in the manual review candidate set. Versioned traceability event fragments retained as isolated nodes do not participate in the priority closure path generation, but can be used as non-closure candidates or manual review candidates in the subsequent historical closure inversion module, thereby ensuring that the original valid records are not directly discarded in the graph generation stage due to excessively strict graph edge constraints.

[0050] To ensure the executability and uniqueness of the output results of the typified source tracing constraint graph, the constraint graph generation module adds necessary attributes to graph nodes and edges. For graph nodes, at least the following attributes are added: value data anchor point identifier, event type field, object identifier, version identifier, semantic slot identifier, source identifier, historical valid interval, and submission visible interval. This allows the subsequent historical closure inversion module to directly perform interval intersection, candidate filtering, and path expansion based on node attributes. For graph edges, at least the following attributes are added: start node identifier, end node identifier, edge connection direction, and connection legality source marker. This allows the subsequent historical closure inversion module to determine whether the current connection has a clear source, correct direction, and a legal business basis when expanding the path. Value data anchor points only serve as root nodes in the graph and no longer function as business nodes. Versioned source tracing event fragments only serve as business nodes in the graph and no longer function as graph edges or temporary index objects. The business effective start time, business effective end time, system entry time, and cancellation or replacement time in this module only represent discrete time index values ​​in a unified time scale space and are no longer used as original timestamps.

[0051] Through the above processing, the constraint graph generation module completes three consecutive layers of processing: First, it constructs a valid historical interval based on versioned source traceability event fragments; second, it constructs a submission visibility interval based on versioned source traceability event fragments; finally, it generates a typified source traceability constraint graph with the value data anchor point as the root node, the versioned source traceability event fragments as business nodes, and the node connection edges after passing object connection checks, upstream reference connection checks, and version inheritance checks as constraints. This typified source traceability constraint graph simultaneously includes the valid boundaries of nodes in the business history, the visibility boundaries of nodes in the system, and edge constraints that allow the establishment of historical source traceability relationships. This provides a structured input basis for the subsequent historical closure inversion module to screen candidate versioned source traceability event fragments around the target historical time point, determine historical source traceability chain snapshots, and competitive candidate chains.

[0052] In one implementation, the historical closure inversion module receives the value data anchor point, the typified source constraint graph, the historical valid interval, and the submission visible interval. It then performs interval intersection, candidate path expansion, and closure inversion around the target historical time point, outputting a historical source chain snapshot and a competing candidate chain. This module acquires the target historical time point and the typified source constraint graph, performs interval intersection and closure inversion on the typified source constraint graph, and outputs a historical source chain snapshot and a competing candidate chain. Here, the value data anchor point serves as the root node object of the current value data to be interpreted, and the typified source constraint graph serves as the path expansion. The structured basis for edge constraint calls is used. The historical valid interval is used to represent the valid boundary of the versioned traceability event fragment in the business history, and the submission visible interval is used to represent the visible boundary of the versioned traceability event fragment in the system. Since the event fragment construction module has completed the unified time scale conversion, the target historical time point, query time window endpoint, historical valid interval endpoint, and submission visible interval endpoint are all discrete time index values ​​in the unified time scale space. All subsequent time differences, interval lengths, interval overlap lengths, and order judgments are completed in the unified time scale space, and the original timestamp is no longer directly called.

[0053] Specifically, the historical closed inversion module first reads the target historical time point and reads the time tolerance half-width from the system parameter table. It then constructs a query time window centered on the target historical time point. The time tolerance half-width is preferably selected from the discrete time index increment corresponding to 1 to 3 basic time granularities. The specific value is determined jointly based on the source-level time jitter statistics and the upper bound of the cross-system synchronization deviation. The source-level time jitter statistics are preferably calculated using the time difference sample between the original timestamps of the most recent consecutive valid records under the same source identifier and the system entry time, and preferably using the median absolute deviation value after outlier removal as the jitter statistics result. When the source-level time jitter statistics are no greater than 1 basic time granularity and the upper bound of the cross-system synchronization deviation is no greater than 1 basic time granularity, it is judged as a low jitter scenario, and the time tolerance half-width is taken as 1 basic time granularity. When the source-level time jitter statistics are greater than 1 basic time granularity but no greater than 2 basic time granularities, or the upper bound of the cross-system synchronization deviation is greater than 1 basic time granularity but no greater than 2 basic time granularities, it is judged as a medium jitter scenario, and the time tolerance half-width is taken as 2 basic time granularities. When the source-level time jitter statistics are greater than 2 basic time granularities, or the upper bound of the cross-system synchronization deviation is greater than 2 basic time granularities, it is judged as a high jitter scenario, and the time tolerance half-width is taken as 3 basic time granularities. The left boundary of the query time window is obtained by subtracting the time tolerance half-width from the target historical time point, and the right boundary is obtained by adding the time tolerance half-width to the target historical time point. To avoid standardization anomalies due to excessively small query time window length, this implementation introduces a time stability term. The time stability term is preferably taken as the discrete time index increment corresponding to one base time granularity. Subsequent standardization processes involving query time window length, query time window half-width, and overlap ratio are all performed by adding the time stability term to the corresponding time amount.

[0054] After the query time window is constructed, the historical closure inversion module filters candidate versioned tracing event fragments from the typified tracing constraint diagram. The filtering rules are as follows: First, it is determined whether there is a non-empty intersection between the historical valid interval of the versioned tracing event fragment and the query time window to identify whether the fragment has a basis for business history near the target historical time point; then, it is determined whether there is a non-empty intersection between the submission visibility interval of the versioned tracing event fragment and the query time window to identify whether the fragment has entered the system's historical visibility range near the target historical time point; when there is a non-empty intersection between the historical valid interval and the query time window, and also a non-empty intersection between the submission visibility interval and the query time window, the versioned tracing event fragment is retained as a candidate versioned tracing event fragment; when either of the above two conditions is not met, the versioned tracing event fragment is removed from the candidate set. After completing the first round of filtering, the historical closure inversion module aggregates the candidate versioned tracing event fragments according to five slots: device certificate, standard reference, correction parameters, method version, and authorization status.

[0055] After the candidate versioned tracing event fragments are formed, the history closure inversion module first quantifies the node-level features. The first node-level feature is the node's historical validity result, which characterizes the sufficiency of the historical validity of the current candidate versioned tracing event fragment near the target historical time point. Its formation process includes three parts: time validity result, field completeness result, and source credibility result. Specifically, first, the overlap length between the historical valid interval of the candidate versioned tracing event fragment and the query time window is calculated, and this overlap length is divided by the sum of the query time window length and the time stability term to obtain the time validity result. Then, the field completeness representation value and source credibility level output by the event fragment construction module are read. When the field completeness representation value is lower than 0.50, the current candidate versioned tracing event fragment is determined not to enter the priority ranking set and is only retained as a candidate fragment for manual review. When the field completeness representation value is not lower than 0.50, the time validity result, field completeness representation value, and source credibility level are weighted and combined according to preset weights to obtain the node historical validity result. The preferred weight for the time validity result is 0.50, the preferred weight for the field completeness representation value is 0.30, and the preferred weight for the source credibility level is 0.20, with the sum of the three weights being 1. The resulting node historical validity result is a dimensionless result value between 0 and 1. The larger the value, the more suitable the current candidate versioned tracing event fragment is as a priority interpretation candidate at the target historical time point.

[0056] The second node-level feature is the late revision prompt result. This result characterizes the extent to which a candidate versioned traceability event fragment, while covering the target historical time point in business history, entered the system record range later than the target historical time point. This result is used for subsequent conflict interpretation and manual review prompts, and is not directly used to negate the validity of the current candidate versioned traceability event fragment's business history. Specifically, it first determines whether the system entry time of the candidate versioned traceability event fragment is later than the target historical time point. When the system entry time is not later than the target historical time point, the late revision prompt result is 0. When the system entry time is later than the target historical time point, the time difference between the system entry time and the target historical time point is used as the degree of late revision. This degree of late revision is then divided by the sum of the time tolerance half-width and the time stability term to obtain the standardized late revision prompt result. When this result is greater than 1, it is preferable to truncate it to 1. The resulting late revision prompt is a dimensionless result value between 0 and 1. The larger the value, the more likely the current candidate version traceability event fragment belongs to a supplementary recording, supplementary transmission, or late revision fragment that entered the system after the target historical time point.

[0057] The third node-level feature is the same-slot ambiguity result. This result characterizes whether multiple competing interpretation fragments covering the target's historical time point exist simultaneously in the slot containing the current candidate versioned tracing event fragment. This result represents the distinguishability and degree of interpretation ambiguity in the current slot and is not directly used as a basis for reducing candidate fragment quality. Specifically, within the slot containing the current candidate versioned tracing event fragment, the number of candidate versioned tracing event fragments that share the same semantic slot identifier and simultaneously satisfy the conditions of a non-empty intersection between the historical valid interval and the query time window, and a non-empty intersection between the submission visibility interval and the query time window, is counted. This number is recorded as the number of valid candidates in the same slot. When the number of valid candidates in the same slot is 1, the same-slot ambiguity result is 0. When the number of valid candidates in the same slot is greater than 1, the number of valid candidates in the same slot minus 1 is used as the number of competing interpretations. The number of competing interpretations is then divided by the number of valid candidates in the same slot to obtain the same-slot ambiguity result. The resulting ambiguity results for the same slot are dimensionless values ​​between 0 and 1. The larger the value, the more alternative interpretations exist for the current slot at the target historical point in time. Therefore, a higher level of ambiguity warning needs to be given in subsequent snapshot credibility assessments and manual review prompts.

[0058] After the node-level feature calculation is completed, the history closure inversion module calculates the edge-level features, namely the edge-level temporal compatibility. The edge-level temporal compatibility is used to characterize the degree to which two adjacent candidate versioned tracing event fragments are simultaneously valid and the edge constraints are legal near the target historical time point. The calculation process is as follows: First, read the connection legality source marker of the current node's connecting edge. When the connection legality source marker indicates that the object connection check, upstream reference connection check, and version inheritance check have all passed, the semantic compatibility result of the edge is taken as passed. Then, calculate the common overlap length of the historical valid interval of the candidate versioned tracing event fragments at both ends of the edge and the query time window, and divide the common overlap length by the sum of the query time window length and the time stability term to obtain the standardized common validity ratio. Finally, multiply the common validity ratio by the semantic compatibility result to obtain the edge-level temporal compatibility. Since the semantic compatibility result is expressed in a binary way in this module, it is 1 when it passes and 0 when it fails. Therefore, the edge-level temporal compatibility value is between 0 and 1.

[0059] It should be noted that the node history validity result is a node-level evaluation metric used to reflect the local validity strength of a single candidate versioned tracing event fragment near the target historical time point; the edge-level temporal compatibility is an edge-level evaluation metric used to reflect the degree of common validity of adjacent candidate versioned tracing event fragments near the target historical time point and the degree of edge constraint closure. Although both are related to time coverage, they have different levels of influence and do not constitute simple duplicate measurements.

[0060] After all node and edge features are formed, the historical closure inversion module performs candidate path expansion and closure inversion. Specifically, using the magnitude data anchor point as the root node, it performs path expansion along the node connection edges in the typified tracing constraint graph in the order of device certificate, standard reference, correction parameters, method version, and authorization status. During path expansion, for each slot level, it performs common effective coverage checks, object connection checks, and upstream reference connection checks on adjacent candidate versioned tracing event fragments. The common effective coverage check is used to confirm that the historical effective intervals of two adjacent candidate versioned tracing event fragments have continuous overlap within the query time window. The object connection check and upstream reference connection check directly call the edge constraint results already confirmed by the constraint graph generation module. When any check fails, the current path... Terminate and delete; when all checks pass, retain the current path and continue to expand to the next slot level. After expanding all levels, the system obtains several candidate historical traceability chains covering different slot combinations. To ensure that the output results can be directly used as input for the subsequent conflict annotation and write-back modules, the historical closure inversion module prioritizes determining historical traceability chain snapshots and competing candidate chains from candidate historical traceability chains that simultaneously cover the five slots of device certificate, standard reference, correction parameters, method version, and authorization status. When there are no candidate historical traceability chains that simultaneously cover the five slots, it is allowed to determine some closed candidate chains from candidate historical traceability chains that cover the device certificate, standard reference, and at least one auxiliary slot directly related to the current value processing, and generate slot missing prompt labels in the subsequent conflict annotation and write-back modules.

[0061] After the priority interpretation set is formed, the history closure inversion module calculates the chain-level ranking result for each candidate historical tracing chain. The chain-level ranking result is used to establish a sequential order among multiple candidate historical tracing chains and is not used to represent specific physical quantities. Specifically, a weighted summation is performed on the node history establishment results of all candidate versioned tracing event fragments in the chain to obtain a summary result of node establishment; a weighted summation is performed on the edge-level temporal compatibility of all node connecting edges in the chain to obtain a summary result of edge-level compatibility; a weighted summation is performed on the same slot ambiguity results of all candidate versioned tracing event fragments in the chain, and the resulting result is converted into a slot determination result, wherein the slot determination result is preferably 1 minus the weighted sum of the same slot ambiguity results; subsequently, a weighted summation is performed on the late revision prompt results of all candidate versioned tracing event fragments in the chain, and this is used as a priority reference for subsequent conflict interpretation, and is not directly used as a deduction item in the chain-level ranking result. Finally, the node establishment summary results, edge-level compatibility summary results, and slot determination results are weighted and combined according to preset weights to obtain the chain-level ranking result of the current candidate historical tracing chain.

[0062] After the chain-level score is calculated, the historical closure inversion module selects the candidate historical tracing chain with the highest chain-level ranking result from the priority interpretation set as a snapshot of the historical tracing chain of the target quantitative data at the target historical time point. At the same time, among the candidate historical tracing chains that cover all 5 slots and differ from the historical tracing chain snapshot in at least 1 slot or 1 edge, the one with the second highest chain-level score is selected as a competing candidate chain. Subsequently, the node sequence, edge sequence, and slot coverage result corresponding to the historical tracing chain snapshot are solidified as the priority interpretation result of the current quantitative data anchor point at the target historical time point. Through this process, the historical closure inversion module outputs both the historical tracing chain snapshot and the competing candidate chain, which can uniquely correspond to the specific quantitative data anchor point, the specific target historical time point, and the specific slot combination. This provides direct input for the subsequent conflict labeling and write-back module to generate late revision labels, upstream substitution labels, and interval break labels.

[0063] Through the above processing, the history closure inversion module completes four consecutive layers of processing: First, it constructs a query time window around the target historical point in time and based on the time tolerance half-width to filter candidate versioned tracing event fragments; second, it calculates the node history establishment result, late revision prompt result, ambiguity result in the same slot, and edge-level temporal compatibility; then, it expands along the execution path of the typed tracing constraint graph to form a candidate historical tracing chain that simultaneously covers 5 slots; finally, it determines the historical tracing chain snapshot and competing candidate chains based on the chain-level score. Thus, the history closure inversion module provides the subsequent conflict annotation and write-back module with a clear structure, well-defined boundaries, and directly callable historical interpretation results.

[0064] In one implementation, the conflict labeling and write-back module receives the historical source chain snapshot and competing candidate chain output by the historical closure inversion module, performs conflict detection and conflict labeling on the historical source chain snapshot and competing candidate chain, outputs conflict source tags, and writes the historical source chain snapshot, competing candidate chain, conflict source tags, and target historical time point into the historical snapshot database. Simultaneously, it performs a historical snapshot index update. This module is consistent with the finalized claims. Its input objects are the historical source chain snapshot, competing candidate chain, target historical time point, and the query time window already formed by the historical closure inversion module. Its output objects are the conflict source tags and the historical snapshot record after write-back. Here, the historical source chain snapshot is based on the target historical time point. The priority historical interpretation results formed at historical time points, and the competing candidate chains are secondary historical interpretation results that simultaneously cover five slots (device certificate, standard reference, correction parameters, method version, and authorization status) with the historical traceability chain snapshot, and differ from each other in at least one slot or one edge. The quantitative data anchor points, candidate versioned traceability event fragments, node historical establishment results, late revision prompt results, ambiguous results in the same slot, edge-level temporal compatibility, chain-level sorting results, and query time windows all use the results already formed in the previous module. Based on this, this module further forms snapshot credibility, late revision strength, upstream substitution strength, interval break strength, and conflict source labels, and performs historical snapshot write-back and historical snapshot index update.

[0065] Specifically, the conflict annotation and write-back module first reads the historical tracing chain snapshot and its chain-level ranking results already determined by the historical closure inversion module, and further reads the competing candidate chains and their chain-level ranking results. Then, it calculates the snapshot credibility, which characterizes the degree of separation between the historical tracing chain snapshot and the competing candidate chains. Its calculation form is as follows:

[0066] ;

[0067] When no competing candidate chains are formed, the snapshot credibility is taken from the chain-level ranking result corresponding to the historical traceability chain snapshot. Since the historical tracing chain snapshot is determined according to the highest principle of chain-level ranking, and the competing candidate chains are determined according to the second highest principle of chain-level ranking, and the chain-level ranking results are limited to the range of 0 to 1, the following condition is met when competing candidate chains exist. Thus, 0 ≤ Γ ≤ 1; when no competing candidate chains are formed, Similarly, 0 ≤ Γ ≤ 1 is satisfied. The higher the snapshot credibility, the more obvious the distinction between the historical traceability chain snapshot and the competing candidate chain, and the clearer the current priority interpretation result; the lower the snapshot credibility, the closer the competition between the two candidate chains, or the lower the chain-level ranking result of the current historical traceability chain snapshot itself, and the more necessary it is to combine the conflict source label and the slot missing prompt label for further interpretation.

[0068] After the snapshot credibility is established, the conflict annotation and write-back module further calculates the late revision strength. The late revision strength is used to characterize the degree to which candidate versioned tracing event fragments in the historical tracing chain snapshot, although covering the target historical point in business history, appear in the system significantly later than the target historical point in time. Its calculation form is as follows:

[0069] ;

[0070] in, Indicates the intensity of the delayed revision. This indicates the candidate historical traceability chain corresponding to the historical traceability chain snapshot. Indicates the first in the chain A candidate versioned traceability event fragment This indicates a late revision suggestion result that has already been generated in the history closure inversion module for the candidate versioned tracing event fragment, due to... The standardization has been completed in the historical closed inversion module, with values ​​ranging from 0 to 1. Therefore, the late revision intensity is also in the range of 0 to 1. The basis for using the maximum value aggregation here is that the late revision label should reflect the most significant late risk in the entire historical traceability chain snapshot. As long as there is a significant late entry in the key slots within the chain, it is enough to affect the interpretation of the target historical point in time.

[0071] After the late revision strength is formed, the conflict annotation and write-back module further calculates the upstream substitution strength. The upstream substitution strength is used to characterize whether, under the same object identifier, the same semantic slot identifier, and the same upstream reference information, there exists a competing fragment with a later system entry time and a source credibility level no lower than the current fragment, thus forming a late entry competition with substitution significance. Its calculation form is as follows:

[0072] ;

[0073] in, Indicates the intensity of upstream substitution. This represents the set of candidate versioned tracing event fragments in a historical tracing chain snapshot. Represents a set Any candidate versioned tracing event fragment in the data, This indicates a fragment of a candidate versioned tracing event. A set of competing segments that share the same object identifier, the same semantic slot identifier, the same upstream reference information, and whose system entry time is later. Represents the set of competing fragments Any competing segment in These represent candidate versioned tracing event fragments. Competition segment The corresponding historical valid interval, Indicates the query time window. Represents the time-steady term. These represent candidate versioned tracing event fragments. Competition segment The credibility of the source The indicator function takes a value of 1 when the confidence level of the competing fragment source is not lower than that of the current fragment source, and a value of 0 otherwise. The time stability term follows the definition in the historical closed inversion module, and preferably takes the discrete time index increment corresponding to 1 basic time granularity.

[0074] The calculation logic of this formula is as follows: First, for each candidate versioned tracing event fragment in the historical tracing chain snapshot... Retrieve a set of competing segments that meet the criteria of having the same object identifier, the same semantic slot identifier, the same upstream reference information, and a later system entry time. Next, calculate the overlap ratio of the current segment, competing segments, and query time window; then, use the source credibility level comparison results to remove competing segments whose source credibility level is significantly lower than that of the current segment before adding them; then, in the set of competing segments corresponding to the current segment... The maximum common overlap result that meets the conditions is selected; finally, the maximum value is selected from all candidate versioned tracing event fragments corresponding to the historical tracing chain snapshot. Through the above processing, Used to characterize the most significant post-entry substitution risk in the entire historical traceability chain snapshot, it does not employ average aggregation, thus preventing the dilution of key substitution positions by multiple low-risk segments. Since the common overlap ratio is a dimensionless quantity between 0 and 1, the indicator function only takes the values ​​0 or 1. Located in the interval between 0 and 1, and The larger the value, the more significant the risk of high-credibility subsequent data entry substitution exists in the current historical traceability snapshot.

[0075] After the upstream substitution intensity is formed, the conflict annotation and write-back module continues to calculate the interval fracture intensity. The interval fracture intensity is used to characterize the degree to which adjacent candidate versioned tracing event fragments within the historical tracing chain snapshot lack continuous common effective coverage near the target historical time point. Its calculation form is as follows:

[0076] ;

[0077] in, Indicates the fracture strength of the interval. This represents the set of edges that are actually retained and participate in path fixing within the historical traceability chain snapshot. This indicates the number of edges in the set. This indicates a fragment of a candidate versioned tracing event. The edge, These represent the historical valid intervals of two adjacent candidate versioned tracing event fragments. Indicates the query time window. The time-stability term is represented by the following calculation logic: First, for each edge actually retained within the historical traceability chain snapshot, calculate the common overlap ratio between the historical valid intervals of the candidate versioned traceability event fragments at both ends and the query time window; then, calculate the average of the common overlap ratios of all edges; finally, subtract this average value from 1 to obtain the interval break strength. Since the common overlap ratio of each edge is in the range of 0 to 1, the interval break strength is also in the range of 0 to 1. Here, the complement of the average common coverage is used to characterize the break strength in order to evaluate the degree of breakage from the perspective of the global continuity of the entire historical traceability chain snapshot.

[0078] After the snapshot confidence, late revision strength, upstream substitution strength, and interval break strength are all determined, the conflict labeling and write-back module generates conflict source labels based on the threshold comparison results. The threshold system includes late revision threshold, upstream substitution threshold, interval break threshold, and confidence threshold. The four types of thresholds preferably use historical manually reviewed samples as the calibration set, traversing the range from 0 to 1 with a step size of 0.05. The set of thresholds that optimizes both conflict label recognition accuracy and snapshot pass rate is selected and written into the system parameter table. The number of historical manually reviewed samples is preferably no less than 500 sets. When the number of samples is less than 500 sets, the previous round of calibration thresholds is used. When there are no previous round of calibration thresholds, the initial threshold set is used, where the late revision threshold is preferably 0.40, the upstream substitution threshold is preferably 0.35, the interval break threshold is preferably 0.30, and the confidence threshold is preferably 0. 20. The initial thresholds in this set reflect the differences in risk sensitivity in real-world scenarios: when the intensity of late revision and upstream substitution reaches a moderate or higher level, it is sufficient to affect the historical interpretation, so the thresholds are slightly higher; when the intensity of interval break reaches a moderate level, it already affects the chain continuity, so the thresholds are slightly lower; snapshot credibility is used to identify situations where the distinction between the optimal chain and competing chains is not obvious, so the value is the lowest. The specific label generation rules are as follows: when the intensity of late revision is greater than or equal to the late revision threshold, a late revision label is generated; when the intensity of upstream substitution is greater than or equal to the upstream substitution threshold, an upstream substitution label is generated; when the intensity of interval break is greater than or equal to the interval break threshold, an interval break label is generated; when the snapshot credibility is less than the credibility threshold, a low-credibility snapshot label is generated. If the same historical traceability chain snapshot simultaneously meets the triggering conditions of multiple types of labels, multiple conflict source labels are allowed to be output simultaneously.

[0079] After the conflict source label is generated, the conflict annotation and write-back module performs historical snapshot write-back and historical snapshot index update. Specifically, it first writes the historical tracing chain snapshot, competing candidate chain, historical tracing chain snapshot chain-level score, snapshot credibility, conflict source label, and key event fragment identifiers that triggered the conflict source label into the historical snapshot library, and establishes a one-to-one association between historical tracing chain snapshots and quantitative data anchors. The key event fragment identifier preferably refers to the candidate versioned tracing event fragment identifier that has obtained an extreme value in the calculation of late revision strength, upstream substitution strength, or interval fracture strength, or that has caused the threshold to be triggered. After the write-back is completed, the historical snapshot index is updated, which includes object index update, The system performs time index updates and version index updates. The object index update is used to build an object index based on the quantitative data anchor point, the time index update is used to build a time index based on the target historical time point, and the version index update is used to build a version index based on the versioned traceability event fragments contained in the historical traceability chain snapshot. When the system receives a historical query request for the same quantitative data anchor point and the same target historical time point again, it will preferably first locate the corresponding historical snapshot record based on the object index and time index, and then return the versioned traceability event fragments and conflict source tags in the historical snapshot record based on the version index. This reduces the risk of result drift caused by repeated full graph search, repeated closure inversion, and repeated conflict analysis.

[0080] Through the above processing, the conflict labeling and write-back module completes three consecutive layers of processing: First, it calculates snapshot credibility, late revision strength, upstream substitution strength, and interval break strength based on historical source chain snapshots and competing candidate chains; second, it generates late revision labels, upstream substitution labels, interval break labels, and low-credibility snapshot labels based on threshold comparison results; finally, it writes the historical source chain snapshots, competing candidate chains, snapshot credibility, conflict source labels, and key event fragment identifiers back to the historical snapshot library, and simultaneously performs object index updates, time index updates, and version index updates. Thus, the system can form traceable, searchable, and reproducible historical snapshot records around the target historical point in time, and provide conflict source labels corresponding to the historical snapshot records.

[0081] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A measurement traceability data acquisition and management system, characterized in that, include: The event fragment construction module acquires the collected measurement data and multi-source traceability records, performs unified timescale conversion on the collected measurement data, performs versioning organization on the multi-source traceability records, and outputs the measurement data anchor point and versioned traceability event fragment. The constraint graph generation module obtains versioned traceability event fragments, performs historical valid interval construction, commit visible interval construction, and constraint relationship organization on the versioned traceability event fragments, and outputs historical valid intervals, commit visible intervals, and typed traceability constraint graphs. The historical closure inversion module obtains the target historical time point and the typified source constraint graph, performs interval intersection and closure inversion on the typified source constraint graph, and outputs a historical source chain snapshot and competing candidate chains; The conflict labeling and write-back module obtains historical source chain snapshots and competing candidate chains, performs conflict detection and conflict labeling on the historical source chain snapshots and competing candidate chains, outputs conflict source tags, and performs historical snapshot write-back and historical snapshot index update.

2. The measurement traceability data acquisition and management system according to claim 1, characterized in that, The acquired measurement data should include at least the equipment identifier, measurement item identifier, acquisition time, system entry time, and measurement result; the multi-source traceability and association records should include at least the equipment certificate record, standard reference record, correction parameter record, method version record, and authorization status record; Specifically, the equipment certificate record includes at least the certificate identifier, corresponding equipment identifier, service effective start time, service effective end time, system entry time, and revocation or replacement time; the standard reference record includes at least the upstream standard identifier, corresponding equipment identifier, service effective start time, service effective end time, system entry time, and upstream reference information; the correction parameter record includes at least the corresponding object identifier, corresponding equipment identifier, service effective start time, service effective end time, system entry time, and correction parameter association information; the method version record includes at least the corresponding object identifier, corresponding equipment identifier, service effective start time, service effective end time, system entry time, and method version association information; the authorization status record includes at least the corresponding object identifier, service effective start time, service effective end time, and system entry time; and the measurement value acquisition data and multi-source traceability association record also include a source identifier used to characterize the source of the record acquisition or writing.

3. The measurement traceability data acquisition and management system according to claim 2, characterized in that, The event fragment construction module performs a unified timestamp conversion on the collected data. Specifically, it extracts the collection occurrence time, business start time, business end time, system entry time, and cancellation or replacement time from the collected data and multi-source traceability association records as the original timestamps. For original timestamps with time zone identifiers, conversion is performed according to a unified time zone standard. For original timestamps without time zone identifiers, the conversion is performed after supplementing according to the default time zone corresponding to the record source. Then, clock deviation correction is performed on the original timestamps based on the statistical results of the time difference between the system entry time and the corresponding original timestamp in the same record source. Subsequently, discretization processing is performed based on the maximum value among the minimum recording interval of the time field of the quantitative data collection, the minimum recording interval of the system entry time, and the minimum time interval of the adjacent synchronization time fields of the multi-source traceability and association records, in order to obtain a unified time scale.

4. The measurement traceability data acquisition and management system according to claim 3, characterized in that, The event fragment construction module performs versioned organization on multi-source traceability and association records. Specifically, it collects data around each measurement value and constructs measurement value data anchors according to the unified time scale corresponding to the device identifier, measurement item identifier, and the time of collection. From the multi-source traceability and association records, records that match the device identifier corresponding to the measurement data anchor point, or whose upstream reference information, correction parameter association information, or method version association information points to the device identifier corresponding to the measurement data anchor point, are selected. The selected records are categorized into objects according to device certificate, standard reference, correction parameter, method version, and authorization status. Within each object category, a business version sequence is formed according to the start time of business activation, and a submission version sequence is formed according to the system entry time. Based on the business version sequence and the submission version sequence, version succession, substitution, and overriding relationships are identified to generate versioned traceability event fragments.

5. The measurement traceability data acquisition and management system according to claim 4, characterized in that, The constraint diagram generation module constructs historical valid intervals and submission visible intervals based on versioned traceability event fragments. Specifically, for each versioned traceability event fragment, it constructs a historical valid interval using the business effective start time and the business effective end time, and constructs a submission visible interval using the system entry time and the cancellation or replacement time. When the time of service activation or termination is missing, the first subsequent versioned traceability event fragment whose service activation start time is later than the current versioned traceability event fragment's service activation start time is retrieved under the same object category and the same record category, and the service activation start time of the first subsequent versioned traceability event fragment is used to fill in the end point of the historical valid interval; when the time of cancellation or replacement is missing, the first subsequent versioned traceability event fragment whose system entry time is later than the current versioned traceability event fragment's system entry time is retrieved under the same object category and the same record category, and the system entry time of the first subsequent versioned traceability event fragment is used to fill in the end point of the submission visible interval; When the first subsequent versioned traceability event fragment is not found, the current system time corresponding to the generation of the historical valid interval and the submission of the visible interval is used as the missing endpoint padding value.

6. The measurement traceability data acquisition and management system according to claim 5, characterized in that, The constraint graph generation module constructs a typed traceability constraint graph. The specific operation is as follows: using the value data anchor point as the association starting point, using the versioned traceability event fragment as the graph node, and establishing a slot hierarchy according to the device certificate, standard reference, correction parameter, method version and authorization status. Perform object connection checks, upstream reference connection checks, and version inheritance checks on versioned tracing event fragments in adjacent slot levels; retain only the node connection edges that pass the object connection check, upstream reference connection check, and version inheritance check to generate a typed tracing constraint graph.

7. The measurement traceability data acquisition and management system according to claim 6, characterized in that, The historical closure inversion module performs interval intersection on the typified source tracing constraint graph. Specifically, it constructs a query time window around the target historical time point and based on the basic time granularity; it selects versioned source tracing event fragments that intersect with the query time window as candidate versioned source tracing event fragments; and then performs slot aggregation on the candidate versioned source tracing event fragments according to device certificate, standard reference, correction parameter, method version, and authorization status, and deletes redundant fragments in the same slot whose historical valid interval is covered by other candidate versioned source tracing event fragments and whose system entry time is later.

8. The measurement traceability data acquisition and management system according to claim 7, characterized in that, The historical closure inversion module performs closure inversion on candidate versioned traceability event fragments. Specifically, it performs path expansion along the node connection edges in the typed traceability constraint graph. During the path expansion process, it performs common effective coverage checks, object connection checks, and upstream reference connection checks on adjacent candidate versioned traceability event fragments and deletes candidate paths that fail the checks. The candidate paths that pass the checks are organized into candidate historical traceability chains, and historical traceability chain snapshots and competing candidate chains are determined first from the candidate historical traceability chains that simultaneously cover the slots corresponding to device certificates, standard references, correction parameters, method versions, and authorization status.

9. A measurement traceability data acquisition and management system according to claim 8, characterized in that, The conflict annotation and write-back module performs conflict detection and annotation on historical traceability chain snapshots and competing candidate chains. Specifically, it compares the historical traceability chain snapshots and competing candidate chains slot by slot according to device certificates, standard references, correction parameters, method versions, and authorization status. When the historical valid interval of the corresponding versioned traceability event fragment in the competing candidate chain covers the target historical time point and its system entry time is later than the target historical time point, a late revision label is generated. When there is a subsequent versioned traceability event fragment with a later system entry time and a substitution relationship with the corresponding versioned traceability event fragment in the historical traceability chain snapshot under the same object classification and the same slot, an upstream substitution label is generated. When adjacent versioned traceability event fragments in the historical traceability chain snapshot do not have continuous common valid coverage within the query time window, an interval break label is generated.

10. A measurement traceability data acquisition and management system according to claim 9, characterized in that, The conflict annotation and write-back module performs historical snapshot write-back and historical snapshot index update. Specifically, it writes the historical source chain snapshot, competing candidate chain, conflict source label, and target historical time point to the historical snapshot database and establishes the association between the historical source chain snapshot and the quantitative data anchor point. The historical snapshot index update includes object index update, time index update, and version index update, so that subsequent historical queries can locate the corresponding historical snapshot record based on the quantitative data anchor point and the target historical time point, and return the versioned source event fragment and conflict source label in the historical snapshot record.

Images