Intelligent production workshop data acquisition and processing method based on Internet of Things

Abstract

The invention relates to the field of data processing and intelligent manufacturing of the Internet of Things, and provides an intelligent production workshop data acquisition and processing method based on the Internet of Things. The platform registers an equipment baseline list of a station identifier, a gateway identifier, an event code field, a batch identifier field and a timestamp resolution field and gates an acquisition channel; a gateway interacts with a reference clock service according to a time synchronization period to form a time synchronization sample, a platform fits an affine correction model to generate a correction timestamp, and clock effective and non-anchor point marks are generated according to a residual threshold; the platform generates time uncertainty according to round-trip delay, queue waiting delay and timestamp resolution, and generates station internal order relation constraints based on event code mapping; the platform divides alignment windows according to correction timestamps and batch identifications, selects anchor points according to time uncertainty ranking, resolutions conflicts in combination with sequence relation constraints, and outputs cross-station alignment timelines and alignment reason codes; and through semantic dimension verification, drift rollback, quality gating and evidence chain packaging, the traceability chain can be rechecked.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) data processing and intelligent manufacturing technology, specifically to a method for data acquisition and processing in an intelligent production workshop based on the Internet of Things. Background Technology

[0002] Flexible manufacturing workshops, as a common organizational form for discrete manufacturing and multi-variety, small-batch production, typically exhibit characteristics of multi-workstation distribution, parallel operation of multiple devices, and cross-process collaboration. In this scenario, devices are often connected and collected separately by different gateways, resulting in inconsistent timestamp sources on the device side. Furthermore, network links are susceptible to instability factors such as jitter, buffer queuing, and retransmissions. Simultaneously, field naming and units of measurement can drift with device firmware upgrades and process changes. Without adding dedicated synchronization hardware or modifying existing device protocols, it is difficult to simultaneously achieve stable data collection across workstations, unified semantic processing, and reliable time sequence alignment. This can easily lead to situations where "data exists but cannot be used for quality traceability," such as broken traceability chains, out-of-order events, and unit mismatches.

[0003] Currently, existing technologies typically employ a pipelined approach of gateway-side protocol acquisition and platform-side centralized processing: the gateway collects industrial communication protocol data and uploads it to a message queue or data platform; the platform performs field mapping, extraction, transformation, and cleaning to ensure that data from different sources meets a unified entry standard; time alignment often uses the gateway's reception time as the alignment benchmark, or uses network time protocols for clock synchronization; quality traceability relies heavily on the correlation query between database logs and business tables, and uses sampling verification methods to assist in verification when necessary, thus forming a processing chain of "collection—upload—cleaning—entry—query" to solve the problems in the above scenarios.

[0004] However, the aforementioned existing technologies face challenges in stability and verifiability under conditions of multiple gateways and multiple clocks: relying solely on reception time or coarse-grained time synchronization easily introduces event out-of-order and time drift during network jitter, buffer queuing, and retransmission triggering, making it difficult to establish stable alignment relationships for cross-workstation events in the same batch or process, and posing a risk of misconnection or disconnection in the traceability chain; simultaneously, if the platform-side field mapping and cleaning processing lacks constraints and locking mechanisms for field versions, unit calibers, and firmware changes, semantic inconsistencies and unit mismatches are likely to occur after process switching or firmware upgrades; furthermore, traceability typically remains at the level of log and business table association, lacking verifiable event chain evidence organization methods and data credibility markers, resulting in a lack of verifiable evidence for time sequence and semantic consistency in the traceability process. Therefore, this invention proposes an IoT-based intelligent production workshop data acquisition and processing method to solve the aforementioned problems. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this invention provides a data acquisition and processing method for intelligent production workshops based on the Internet of Things, thereby solving the problems mentioned in the background section.

[0006] To achieve the above objectives, the present invention provides the following technical solution:

[0007] S1. The platform registers a baseline list of devices including workstation identifier, gateway identifier, event code field, batch identifier field and timestamp resolution field. The acquisition channel is enabled when the event code field and batch identifier field are successfully registered. The acquisition channel is disabled and a reason code is written when the registration fails.

[0008] S2. Each gateway interacts with the reference clock service at a period of 5 to 30 seconds to generate time synchronization sample pairs;

[0009] S3. The platform generates an affine correction model for the gateway clock based on time samples, and generates clock validity flags and non-anchor flags based on residual gating, thereby converting the original timestamp t into a corrected timestamp t*.

[0010] S4. The gateway parses the device message, generates a collection record, and writes the original timestamp t. The platform generates a correction timestamp t* for the collection record and generates a time uncertainty σt according to a fixed caliber.

[0011] S5. The platform reads the field value of the event code field as the event code and generates the sequence relationship constraint set for the same workstation and the same batch based on the event code mapping relationship;

[0012] S6. The platform reads the field value of the batch identifier field as the batch identifier, and divides the collected records into alignment windows of 0.5 seconds to 5 seconds according to the correction timestamp t* and the batch identifier. Within the window, the records are sorted in ascending order by σt and the first record of the sort is selected as the anchor event. The platform performs conflict resolution on the collected records within the window according to the order relation constraint set, generates a cross-workstation alignment timeline and outputs the alignment reason code.

[0013] Furthermore, in step S2, the time synchronization sample pair includes the request sequence number seq, the gateway local send timestamp t_send, the gateway local receive timestamp t_recv, the reference receive timestamp t_ref_recv, and the reference send timestamp t_ref_send; the gateway associates t_send and t_recv with the same seq to generate the round-trip time RTT=t_recv−t_send, and maintains the time synchronization sample containing seq, t_send, t_recv, t_ref_recv, and t_ref_send within a 5-minute to 15-minute drift update window.

[0014] Furthermore, step S3 includes: ,in, This is the original timestamp; To correct the timestamp; , The drift factor and offset of the gateway's local clock relative to the reference clock;

[0015] The drift coefficient 'a' and offset 'b' of the gateway local clock relative to the reference clock satisfy the residual gating condition. The residual gating condition is as follows: the platform calculates the residual sequence based on the fitted sample and takes the 95th percentile value r_95 of the residual sequence. It is compared with the residual threshold R_th read from the clock configuration table. If r_95 is not greater than R_th, the clock validity flag is set to valid and the non-anchor flag is set to no. If r_95 is greater than R_th, the previous model parameters are used and the non-anchor flag is set to yes and a reason code is written.

[0016] Furthermore, in step S4, the gateway writes an enqueue timestamp t_enqueue when a packet enters the sending queue and a dequeue timestamp t_dequeue when a packet leaves the sending queue, and generates queue waiting delay samples according to t_queue=t_dequeue−t_enqueue;

[0017] The platform takes the 95th percentile value q_95 of the queue waiting delay sample, and sums half of the 95th percentile value of RTT, q_95 and half of the timestamp resolution Res to generate σt and write it into the acquisition record.

[0018] Furthermore, the event code mapping relationship described in step S5 is provided by an event code mapping table, which registers the process start event code and the process end event code. The platform reads the field value of the event code field from the collection records of the same workstation and the same batch as the event code. When the event code is equal to the process start event code, the order index OrderIdx is written as 1, and when the event code is equal to the process end event code, the order index OrderIdx is written as 2. The platform writes "the record with OrderIdx of 1 precedes the record with OrderIdx of 2" into the order relationship constraint set and generates a constraint status field. When no OrderIdx of 1 is read in the same batch of the same workstation and OrderIdx of 2 is read, the constraint status is set to invalid and the reason code ORD_MISS_START is written. When two or more OrderIdx of 1 or two or more OrderIdx of 2 are read in the same batch of the same workstation, the constraint status is set to invalid and the reason code ORD_DUP_EVENT is written.

[0019] Furthermore, step S6, conflict resolution, includes: when the order relation constraint indicates that the t* of the preceding record is not earlier than the t* of the following record, adjusting the alignment time of the following record to the alignment time of the preceding record plus a fixed interval Δ, where Δ is read from the alignment parameter table and has a value of 1 millisecond; the platform then compares the adjusted alignment time with the confidence interval of the following record. In comparison, if the value falls within the confidence interval, an alignment reason code is written and the alignment status is set to available; if the value does not fall within the confidence interval, an alignment reason code is written and the alignment status is set to require review and not merged into the main timeline.

[0020] Furthermore, before executing step S6, the following steps are performed: the platform establishes a semantic registry, which includes a field identifier FieldId, a unit identifier UnitId, a dimensional identifier DimId, a conversion rule ConvRule, a semantic version number SemVer, an applicable firmware version number range, and an applicable process version number range; the platform reads FieldId, UnitId, firmware version number, and process version number from the collected records to locate SemVer, and performs unit conversion on the original values ​​according to ConvRule to generate a standard unit value StdVal, and then performs a consistency check on the uploaded dimensional identifier and DimId; if the check passes, StdVal and SemVer are written and the semantic isolation flag is set to no; if the check fails, a semantic inconsistency reason code is written and the semantic isolation flag is set to yes. Further, according to claim 1, the platform writes the standard unit value StdVal, the semantic version number SemVer, and the semantic isolation flag into the collected records;

[0021] After the data collection records are written, within the 1- to 7-day drift detection window, the same field identifier FieldId is used as the key to perform drift determination on changes in unit identifier, changes in dimensional identifier, and StdVal distribution differences in the data collection records. The platform reads the mean and standard deviation of distribution differences from the historical stable segment statistics table and determines the distribution difference threshold as the sum of the mean and three times the standard deviation of distribution differences. When the drift determination is not triggered, SemVer remains unchanged and a non-triggered status code is written. When the drift determination is triggered, the platform rolls back SemVer to the previous semantic version number and writes a rollback reason code. If the rollback is successful, the semantic isolation flag is set to no; if the rollback fails, the semantic isolation flag is set to yes and an isolation reason code is written.

[0022] Furthermore, after the semantic isolation flag is written into the collection record, the platform generates a quality score Q for the collection record based on the integrity score, consistency score, and timeliness score, where the consistency score is obtained by mapping the semantic isolation flag; the platform reads the weights from the traceability failure reason statistics table and solidifies them into weight version numbers, and reads the 15th percentile value from the Q distribution statistics table of the past 30 days as the trigger threshold t_Q and writes it into the collection record;

[0023] When the platform sorts the data in ascending order by σt within the window and selects the first record as the anchor event in step S6, the sorting and selection are performed only on the acquisition records that simultaneously meet the conditions of clock validity, non-anchor point, semantic isolation flag not being set, and quality gating comparison result being passed. The quality gating comparison is performed by the platform comparing Q with t_Q and outputting pass or fail. When there are no acquisition records in the window that meet the conditions, the window is set to be reviewed and a window-level reason code is written.

[0024] Furthermore, the collected records include a correction timestamp t*, a semantic version number SemVer, a quality score Q, a time uncertainty σt, and an alignment reason code;

[0025] The platform concatenates the collected records in a fixed field order (t*, SemVer, Q, σt, original payload summary PayloadHash, and alignment reason code) to generate a record summary input string. A hash operation is then performed on this input string to obtain the record summary. The platform links adjacent record summaries in a chain to generate an evidence chain, aligning the collected records across workstations in the timeline. The platform generates batch summary roots and evidence pointers for the record summary set in batches of 1000 to 50000 records and writes them into the results. The original payload summary PayloadHash is obtained by performing a hash operation on the original payload field of the collected records in a fixed byte sequence.

[0026] When the batch summary root recalculation verification is consistent, the evidence pointer is output; when the batch summary root recalculation verification is inconsistent, the alignment timeline of the corresponding batch is frozen and the evidence breakage reason code is written.

[0027] This invention provides a method for data acquisition and processing in an intelligent production workshop based on the Internet of Things (IoT). It has the following beneficial effects:

[0028] 1. The cross-workstation event timeline has verifiable alignment criteria. A correction timestamp is generated by fitting an affine correction model to the time sample, and a time uncertainty is generated for each acquisition record. Then, anchor points are selected by sorting according to time uncertainty within the alignment window and the alignment reason code is output, so that the cross-workstation alignment results have a traceable record of "anchor point source - uncertainty - conflict resolution path".

[0029] 2. Improve alignment stability under conditions of multiple gateways, multiple clocks, network jitter, and retransmissions. Clock validity and non-anchor point flags are generated through residual gating, and non-anchor point records are excluded during anchor point selection. Simultaneously, conflicts within the window are resolved by incorporating workstation-level sequence constraints, ensuring clear gating branches and handling rules for alignment under out-of-order and drift conditions.

[0030] 3. Alignment failures have reachable exit points and explainable reasons. When baseline registration fails, residual gating fails, order relation constraints are not met, conflict resolution results in the failure to fall within the confidence interval, or there are no available anchor points within the window, a reason code and a "requires review" status are output to close the failure path and prevent the process from ending in an implicit discard manner. Attached Figure Description

[0031] Figure 1 This is a schematic diagram of the deployment and data flow of the "gateway-workstation-platform-reference clock service" on the workshop side in Embodiment 1 of the present invention;

[0032] Figure 2 This is a flowchart of semantic positioning and dimensional verification in Embodiment 2 of the present invention. Detailed Implementation

[0033] To enable those skilled in the art to understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are some, but not all, of the embodiments of the present invention. Other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort should fall within the scope of protection of the present invention.

[0034] The present invention will now be described in detail with reference to the accompanying drawings:

[0035] Example 1: A data acquisition and processing method for an IoT-based smart production workshop, aligning the timeline of cross-workstation events across multiple gateways and clocks. The specific implementation is as follows:

[0036] Taking a discrete process in a flexible manufacturing workshop as an example, the workshop is equipped with three workstations: the first workstation, the second workstation, and the third workstation. The devices at the first and second workstations are connected to gateway one and gateway two, respectively, while the device at the third workstation is connected to gateway three. Each gateway accesses the reference clock service on the platform side via an existing industrial Ethernet connection, while the device-side protocol remains unchanged. No additional dedicated synchronization hardware is required in the workshop. Figure 1 This embodiment generates cross-workstation aligned timelines by using a "quantifiable clock correction model, a single record time uncertainty field, workstation-level sequence constraints, and window-level anchor point selection and conflict handling".

[0037] S1: Register the equipment baseline list and solidify the data acquisition constraints

[0038] The platform registers a set of fields for each workstation in the equipment baseline list table. The fields are listed as follows: workstation identifier, equipment identifier, gateway identifier, event code field, batch identifier field, sampling period field, and timestamp resolution field. The platform solidifies the above field set into the baseline version number BaseVer and writes BaseVer into the acquisition channel registration record.

[0039] When the event code field and batch identifier field exist in the acquisition channel registration record, the platform sets the status of the acquisition channel to "enabled".

[0040] When the registration record of a data acquisition channel is missing an event code field or a batch identifier field, the platform sets the status of the data acquisition channel to "to be completed" and writes the reason code BASE_MISS_FIELD. The data acquisition channel will not proceed to the subsequent alignment steps.

[0041] S2: The gateway performs time synchronization detection and generates time synchronization sample pairs.

[0042] Each gateway registers the time synchronization probe period Tsync in its local scheduled task table, with Tsync ranging from 5 seconds to 30 seconds; the gateway triggers a time synchronization probe once per Tsync, executing sequentially:

[0043] The gateway generates a time synchronization request packet ProbeReq, and writes the request sequence number field seq and the local sending timestamp field t_send;

[0044] The gateway sends the ProbeReq to the platform-side reference clock service;

[0045] The reference clock service writes the reference receive timestamp field t_ref_recv upon receiving and the reference send timestamp field t_ref_send upon responding, and sends back the ProbeResp.

[0046] The gateway writes the local receive timestamp field t_recv when receiving ProbeResp;

[0047] The gateway writes {seq,t_send,t_recv,t_ref_recv,t_ref_send} into the time-matching sample table.

[0048] The gateway associates the field with the same seq, generates a round-trip time RTT=t_recv−t_send, and maintains a set of time synchronization samples within the drift update window W_sync; W_sync is between 5 minutes and 15 minutes.

[0049] S3: Fit the affine correction model and perform residual gating.

[0050] The gateway sorts the time-series samples within W_sync in ascending order of RTT, takes the 95th percentile value rtt_95, and retains samples whose RTT is less than or equal to rtt_95. For each retained sample, a reference estimated timestamp t_ref_est is generated. The generation method is to subtract half of the RTT from t_ref_recv to obtain t_ref_est, and write (t_send, t_ref_est) as a fitted sample pair into the fitted sample table.

[0051] The platform performs least-squares fitting on the fitted sample table to obtain the drift coefficients a and offset b, and fixes the clock model version number ClkVer; the platform converts the gateway's original timestamp t to the corrected timestamp t* using the following formula:

[0052]

[0053] Where t is the original timestamp generated by the gateway; t* is the converted corrected timestamp; a is the drift coefficient; and b is the offset. The platform calculates the residual r for each fitted sample pair.

[0054] Take the 95th percentile value r_95 of the residual sequence and read the residual threshold R_th from the clock configuration table.

[0055] When r_95≤R_th, the platform sets the clock validity flag ClockValid to "valid" and allows the gateway record to participate in anchor point selection.

[0056] When r_95 > R_th, the platform uses the a and b corresponding to the previous ClkVer to generate t*, sets the NonAnchor flag of the gateway to "yes", and writes the reason code CLK_RES_EXCEED.

[0057] S4: Generate a single data collection record and write it into the time uncertainty field σt.

[0058] The gateway parses each device protocol message to obtain the event code field and batch identifier field, and writes the original timestamp t when the message arrives at the gateway parsing thread. The gateway writes the enqueue timestamp and dequeue timestamp of the message entering the sending queue into the queue waiting delay sample, which is defined as t_queue = t_dequeue − t_enqueue. The platform uses W_sync as the statistical window and sorts the queue waiting delay samples in ascending order, taking the 95th percentile value q_95.

[0059] Here, t_queue represents the waiting time of the message in the sending queue, and t_enqueue represents the moment when the message enters the sending queue.

[0060] The platform obtains rtt_95 from S103 and reads the timestamp resolution Res from the device baseline list. The platform generates a time uncertainty field σt for each acquisition record according to a fixed standard. The generation method is to add half of rtt_95, q_95 and half of Res to obtain σt, and write {t,t*,σt,ClkVer,ClockValid,NonAnchor} into the acquisition record Rec.

[0061] S5: Generate a set of workstation-level sequence relation constraints from event codes and solidify the constraint version.

[0062] The platform registers the correspondence between "process start event code" and "process end event code" in the event code mapping table; the platform reads the event code field from the collection records of the same workstation and the same batch:

[0063] When the event code equals the process start event code, the OrderIdx field of the record is set to 1;

[0064] When the event code equals the process end event code, the OrderIdx field of the record is set to 2;

[0065] The platform solidifies the "record with OrderIdx = 1 precedes the record with OrderIdx = 2" into an order relation constraint and generates a constraint version number OrdVer, which is written to the constraint table.

[0066] When only OrderIdx is 2 and no OrderIdx is 1 in the same batch at the same workstation, the platform writes the reason code ORD_MISS_START and sets the constraint status of that batch and workstation to "constraint not valid".

[0067] When multiple OrderIdx values ​​of 1 or 2 appear in the same batch at the same workstation, the platform writes the reason code ORD_DUP_EVENT and sets the constraint status of that batch and workstation to "constraint not valid".

[0068] S6: Generate cross-station aligned timelines for double-layer alignment and output alignment reason codes.

[0069] The platform reads the coarse alignment window w_align from the alignment window configuration table, with w_align ranging from 0.5 seconds to 5 seconds; the platform groups the collected records by the batch identifier field and calculates the window index WinIdx for each record.

[0070]

[0071] Aggregate records from the same batch and the same WinIdx into a window set WinSet.

[0072] The platform performs anchor point selection and conflict handling for each WinSet:

[0073] Anchor candidate set generation: Select records from WinSet where ClockValid is "valid" and NonAnchor is "no" to form a candidate set; when the candidate set is empty, the platform marks WinSet as "no trusted anchors", writes the reason code ANCHOR_EMPTY and enters the output branch of step 4.

[0074] Anchor selection: Sort the candidate set in ascending order by σt, select the record with the first sort as the anchor event AnchorRec, write the anchor flag IsAnchor as "yes", and write the anchor source gateway identifier and ClkVer.

[0075] Conflict handling and order relationship projection: The platform reads the order relationship constraints of records from the same workstation and batch within WinSet according to OrdVer, and arranges them in ascending order by OrderIdx. When "the t* of the preceding record is greater than or equal to the t* of the following record", the platform writes the AlignTime field of the following record as the AlignTime field of the preceding record plus a fixed interval Δ, where Δ is registered as 1 millisecond in the alignment parameter table. Then, it compares AlignTime with the confidence interval [t*−σt, t*+σt] of the following record item by item.

[0076] When AlignTime falls within the confidence interval, the platform writes the reason code ALIGN_PROJECT_OK;

[0077] When AlignTime does not fall within the confidence interval, the platform writes the reason code ALIGN_CONFLICT and sets the alignment status of the record to "requires review". The record is not incorporated into the main chain timeline.

[0078] Output branch: The platform will arrange the records that meet the "alignment status is available" in ascending order of AlignTime to form a cross-workstation alignment timeline TL, and retain {batch identifier, workstation identifier, gateway identifier, t, t*, σt, ClkVer, OrdVer, alignment reason code} for each record in the TL; when the window set is marked as "no trusted anchor", the platform will still output the TL but set the window-level reason code to ANCHOR_EMPTY, and set the alignment status of all records in the window to "requires review".

[0079] Through the above S1 to S6, this embodiment, under the conditions of multiple gateways and multiple clocks, network jitter and buffer retransmission, uses quantifiable clock correction and single record time uncertainty fields as input boundaries, and combines workstation intra-sequence relationship constraints and window anchor point selection rules to generate cross-workstation aligned timelines and alignment reason codes, so that cross-workstation events of the same batch and the same process have verifiable time sequence alignment results and abnormal branch outputs.

[0080] Example 2: This example introduces an alignment enhancement closed loop of semantic versioning and quality gating based on Example 1. The specific implementation is as follows:

[0081] In the cross-workstation alignment timeline generation process described in Example 1, the platform can output the cross-workstation alignment timeline based on the corrected timestamp and time uncertainty. However, after equipment firmware upgrades or process switching in the workshop, the unit identifiers or dimensional standards of some equipment's uploaded fields change. If the platform still uses fixed field mapping, the meaning of the same-named fields will change without being detected in time, thus incorporating semantically mismatched records into the alignment timeline and causing misconnections. To solve this problem, this embodiment adds semantic registration, drift detection, quality scoring, and evidence chain recording to the acquisition record Rec and alignment timeline TL in Example 1, making semantic mismatches preventable and traceable, and subjecting the selection of alignment anchor points to quality gating constraints.

[0082] Data carrier reuse and new fields

[0083] The Rec field of the data collection record used in Example 1 is as follows: Batch Identifier, Workstation Identifier, Gateway Identifier, Field Identifier, Original Value, Original Timestamp t, Correction Timestamp t*, Time Uncertainty σt, Alignment Reason Code.

[0084] The following Rec fields have been added: Semantic Version Number SemVer, Standard Unit Value StdVal, Quality Score Q, Semantic Status Code SemCode, Quality Status Code QCode, and Evidence Pointer EPtr.

[0085] New configuration tables and registry entries added: Semantic Registry SemReg, Drift Detection Configuration Table, Quality Score Configuration Table, and Evidence Chain Configuration Table.

[0086] S1: Establish a semantic registry and fix the semantic version number.

[0087] The platform registers a semantic registry (SemReg) for each field identifier. SemReg lists the following fields: FieldId, UnitId, DimId, ConvRule, Semantic Version Number (SemVer), Applicable Firmware Version Range, and Applicable Process Version Range. The platform then writes the SemReg to the successfully registered batch to generate the semantic registration version number (SemRegVer).

[0088] Registration path: When the same FieldId corresponds to only one set of {UnitId,DimId,ConvRule,SemVer} within the same applicable firmware version number range and the same applicable process version number range, the platform will register the set as a valid semantic entry.

[0089] Registration failure path: When multiple semantic entries appear for the same FieldId within the same applicable firmware version number range and the same applicable process version number range, the platform writes the reason code SEM_DUP_RULE and sets the FieldId to "pending verification". The collection record corresponding to the FieldId will not enter the semantic conversion and alignment main chain.

[0090] S2: Receive the collection records from Example 1 and bind the semantic version.

[0091] The platform reads the FieldId, UnitId, Process Version Number, and Firmware Version Number from the acquisition record Rec output in Example 1; the platform locates and matches semantic entries in SemReg according to {FieldId, Firmware Version Number, Process Version Number}, and writes the located SemVer into Rec.

[0092] Location via path: When a unique semantic entry is located, the platform writes SemVer and sets SemCode to SEM_OK.

[0093] If a semantic entry is not located, the platform sets the SemCode to SEM_NO_RULE and sets the Rec to "semantic isolation". This Rec will not participate in the generation of the alignment anchor candidate set. If multiple semantic entries are located, the platform sets the SemCode to SEM_MULTI_RULE and sets the Rec to "semantic isolation".

[0094] S3: Perform unit conversion and dimensional consistency verification based on semantic entries.

[0095] The platform executes each Rec with SemCode SEM_OK one by one: reads the ConvRule corresponding to SemVer in SemReg, performs unit conversion on the original value according to ConvRule to generate the standard unit value StdVal; the platform reads DimId in SemReg and performs consistency verification with the unit identifier sent by Rec.

[0096] Validation passed: When the units are consistent, the platform writes StdVal to Rec and sets SemCode to SEM_NORM_OK.

[0097] Paths that fail verification: When the units are inconsistent, the platform sets SemCode to SEM_DIM_MISMATCH and sets the Rec to "semantic isolation", and writes the semantic inconsistency reason code to prevent the Rec from participating in the generation of alignment anchor candidate sets.

[0098] S4: Drift detection and automatic backoff or isolation

[0099] The platform reads the drift detection window w_d from the drift detection configuration table, where w_d ranges from 1 to 7 days; the platform aggregates Rec within window w_d using {FieldId, workstation identifier} as the key to form a field window sample set; the platform performs three types of drift judgment on the field window sample set:

[0100] Unit ID change determination: compare the set of values ​​of the UnitId sequence within the comparison window;

[0101] Determining changes in dimensional identifiers: Compare the set of values ​​for the DimId sequence within the comparison window;

[0102] Distribution difference determination: Calculate the distribution difference measure for the StdVal sequence within the window, and read the mean difference and standard deviation of the difference from the historical stable segment statistics table. Generate the difference threshold t_d by "summing the mean difference with three times the standard deviation of the difference".

[0103] Path not triggered: If none of the three types of determinations are triggered, the platform writes the drift status code DRIFT_NONE.

[0104] Trigger Path Determination: Upon triggering of any determination, the platform generates a drift event record and writes a drift status code; the platform executes the following actions in sequence:

[0105] The platform locates the previous semantic version number PrevSemVer in SemReg and writes PrevSemVer into the fallback table;

[0106] When PrevSemVer is locatable and ConvRule is available, the platform will roll back the SemVer of Rec in the current window to PrevSemVer and set SemCode to SEM_ROLLBACK.

[0107] When PrevSemVer is unlocatable or ConvRule is unavailable, the platform sets the FieldId to isolated and sets SemCode to SEM_ISOLATE, and the Rec corresponding to the FieldId does not enter the alignment main chain.

[0108] S5: Quality Score Q Generation and Gating Flag Writing

[0109] The platform reads the calculation methods and weight version numbers of the three types of scores from the quality scoring configuration table: completeness score, consistency score, and timeliness score; the platform generates a score for each Rec item.

[0110] The integrity score is mapped from the missing test rate statistics. The missing test rate statistics use {FieldId, workstation identifier, window index WinIdx} as the key to count the number of records that should have been received and the number of records that were actually received in the window.

[0111] The consistency score is obtained by mapping the SemCode generated by S203 and S204. When SemCode is SEM_NORM_OK, the consistency pass level is taken; when SemCode is SEM_DIM_MISMATCH or SEM_ISOLATE, the consistency failure level is taken.

[0112] The timeliness score is obtained by mapping the arrival delay statistics. The arrival delay is generated by the difference between the Rec reception time and t* and summarized within the window.

[0113] The platform performs a weighted summation of the three categories of scores according to the weight corresponding to the version number to generate a quality score Q, and writes Q and QCode into Rec. The platform reads the 15th percentile value from the Q distribution statistics table of the past 30 days as the trigger threshold t_Q, and writes t_Q into the quality gating table.

[0114] Gating path: When Q is not less than t_Q and SemCode is in SEM_NORM_OK or SEM_ROLLBACK, the platform sets the Rec to "quality available".

[0115] Gating the path not to pass: When Q is lower than t_Q or SemCode is in SEM_DIM_MISMATCH, SEM_ISOLATE, or SEM_NO_RULE, the platform sets the Rec to "quality limited" and writes it to the QCode and reason code set.

[0116] S6: Quality Gated Driven Anchor Point Candidate Set and Retransmission Priority

[0117] Before selecting anchor points within the window in Implementation Example 1, the platform adds a gating condition when generating an anchor point candidate set for each WinSet: only Recs with "clock valid flag is valid, NonAnchor is not, semantic isolation flag is not, and quality available flag is yes" are allowed to enter the anchor point candidate set; when the anchor point candidate set is empty, the platform writes the alignment reason code ANCHOR_EMPTY_QSEM to the WinSet and sets the WinSet as a "window that needs to be reviewed".

[0118] The gateway reads the retransmission trigger threshold from the retransmission configuration table. When the number of windows with Q lower than t_Q in a continuous window reaches the trigger quantity, the gateway increases the retransmission priority of the message corresponding to the FieldId and performs batch retransmission. After receiving the retransmission record, the platform re-executes S202 to S205 and rebuilds the anchor point candidate set for the corresponding WinSet.

[0119] Re-transmission effective path: When a candidate record with usable quality and non-isolated semantics appears in the WinSet after re-transmission, the platform restores anchor point selection and outputs the updated alignment reason code.

[0120] Path where re-upload is ineffective: If there are still no candidate records after re-upload, the platform maintains the "required review window" status and writes the reason code RETRY_NO_ANCHOR.

[0121] S7: Chain of Evidence Records and Batch Digest Root Generation

[0122] The platform reads the batch size B from the evidence chain configuration table, with B ranging from 1000 to 50000 records. For each Rec record, the platform concatenates field values ​​in a fixed field order to generate a record digest input string. The fields are listed in the following order: t*, SemVer, SemCode, Q, QCode, σt, original payload digest PayloadHash, and alignment reason code. The platform performs chained linking on the record digests to generate an evidence chain, and generates a batch digest root Hash and an evidence pointer EPtr for each batch of record digests. The platform then writes the EPtr into the Rec record.

[0123] Verification passed: When the platform performs a recalculation verification on the batch summary root and finds it consistent, the evidence status of that batch is set to valid.

[0124] Paths that fail verification: When the platform recalculates the batch summary root and finds it inconsistent, the evidence status is set to invalid and the reason code EVID_BROKEN is written. The timeline output of this batch is frozen as "for review only".

[0125] S8: Output a result packet carrying semantic and quality flags.

[0126] The platform encapsulates the alignment timeline TL output in Example 1 and the field set generated in this example into a result package R. The result package R lists the following fields: TL, σt, SemVer, SemCode, Q, QCode, Evidence Pointer EPtr, and Alignment Reason Code. The platform outputs R according to the interface contract.

[0127] Successful output path: The platform generates an index and binds the index to EPtr, writing it into the index table.

[0128] Output failure path: The platform writes the failure reason code R_WRITE_FAIL and sets the batch to the final failure state. Subsequent traceability interfaces only read the failure flag and reason code set.

[0129] Through S1 to S8, this embodiment, based on the cross-workstation alignment mechanism of embodiment 1, solidifies semantic version number, dimensional verification, drift rollback or isolation, quality scoring gating and evidence chain records to the collection record granularity, and forwards semantic isolation and quality gating to the anchor point candidate set generation, so that silent mismatches can still be blocked from entering the alignment main chain after equipment upgrades or process switching, and the root cause of the problem can be located through cause code and evidence pointer.

[0130] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A method for data acquisition and processing in an intelligent production workshop based on the Internet of Things, characterized in that, The gateway and platform work together to execute the following steps: S1. The platform registers a baseline list of devices including workstation identifier, gateway identifier, event code field, batch identifier field and timestamp resolution field. The acquisition channel is enabled when the event code field and batch identifier field are successfully registered. The acquisition channel is disabled and a reason code is written when the registration fails. S2. Each gateway interacts with the reference clock service at a period of 5 to 30 seconds to generate time synchronization sample pairs; S3. The platform generates an affine correction model for the gateway clock based on time samples, and generates clock validity flags and non-anchor flags based on residual gating, thereby converting the original timestamp t into a corrected timestamp t*. S4. The gateway parses the device message, generates a collection record, and writes the original timestamp t. The platform generates a correction timestamp t* for the collection record and generates a time uncertainty σt according to a fixed caliber. S5. The platform reads the field value of the event code field as the event code and generates the sequence relationship constraint set for the same workstation and the same batch based on the event code mapping relationship; S6. The platform reads the field value of the batch identifier field as the batch identifier, and divides the collected records into alignment windows of 0.5 seconds to 5 seconds according to the correction timestamp t* and the batch identifier. Within the window, the records are sorted in ascending order by σt and the first record of the sort is selected as the anchor event. The platform performs conflict resolution on the collected records within the window according to the order relation constraint set, generates a cross-workstation alignment timeline and outputs the alignment reason code.

2. The method according to claim 1, characterized in that, In step S2, the time synchronization sample pair includes the request sequence number seq, the gateway local send timestamp t_send, the gateway local receive timestamp t_recv, the reference receive timestamp t_ref_recv, and the reference send timestamp t_ref_send. The gateway associates t_send and t_recv with the same seq to generate the round-trip time RTT = t_recv − t_send, and maintains the time synchronization sample containing seq, t_send, t_recv, t_ref_recv, and t_ref_send within a 5-minute to 15-minute drift update window.

3. The method according to claim 1, wherein step S3 comprises: ,in, This is the original timestamp; To correct the timestamp; , The drift factor and offset of the gateway's local clock relative to the reference clock; The drift coefficient 'a' and offset 'b' of the gateway local clock relative to the reference clock satisfy the residual gating condition. The residual gating condition is as follows: the platform calculates the residual sequence based on the fitted sample and takes the 95th percentile value r_95 of the residual sequence. It is compared with the residual threshold R_th read from the clock configuration table. If r_95 is not greater than R_th, the clock validity flag is set to valid and the non-anchor flag is set to no. If r_95 is greater than R_th, the previous model parameters are used and the non-anchor flag is set to yes and a reason code is written.

4. The method according to claim 1, characterized in that, In step S4, the gateway writes an enqueue timestamp t_enqueue when a packet enters the sending queue and a dequeue timestamp t_dequeue when a packet leaves the sending queue, and generates queue waiting delay samples according to t_queue=t_dequeue−t_enqueue; The platform takes the 95th percentile value q_95 of the queue waiting delay sample, and sums half of the 95th percentile value of RTT, q_95 and half of the timestamp resolution Res to generate σt and write it into the acquisition record.

5. The method according to claim 1, characterized in that, The event code mapping relationship described in step S5 is provided by the event code mapping table, which registers the process start event code and the process end event code. The platform reads the field value of the event code field from the collection records of the same workstation and the same batch as the event code. When the event code is equal to the process start event code, the order index OrderIdx is written as 1, and when the event code is equal to the process end event code, the order index OrderIdx is written as 2. The platform writes "the record with OrderIdx of 1 precedes the record with OrderIdx of 2" into the order relationship constraint set and generates a constraint status field. When no OrderIdx of 1 is read in the same workstation and the same batch, but OrderIdx of 2 is read, the constraint status is set to invalid and the reason code ORD_MISS_START is written. When two or more OrderIdx of 1 or two or more OrderIdx of 2 are read in the same workstation and the same batch, the constraint status is set to invalid and the reason code ORD_DUP_EVENT is written.

6. The method according to claim 1, characterized in that, Step S6, conflict resolution, includes: when the order relation constraint indicates that the t* of the preceding record is not earlier than the t* of the following record, adjusting the alignment time of the following record to the alignment time of the preceding record plus a fixed interval Δ, where Δ is read from the alignment parameter table and has a value of 1 millisecond; the platform then compares the adjusted alignment time with the confidence interval of the following record. In comparison, if the value falls within the confidence interval, an alignment reason code is written and the alignment status is set to available; if the value does not fall within the confidence interval, an alignment reason code is written and the alignment status is set to require review and not merged into the main timeline.

7. The method according to claim 1, characterized in that, Before executing step S6, the following steps are also performed: The platform establishes a semantic registry, which includes field identifier FieldId, unit identifier UnitId, dimensional identifier DimId, conversion rule ConvRule, semantic version number SemVer, applicable firmware version number range, and applicable process version number range. The platform reads FieldId, UnitId, firmware version number, and process version number from the collected records to locate SemVer, and performs unit conversion on the original value according to ConvRule to generate the standard unit value StdVal. Then, it performs consistency verification between the uploaded dimensional identifier and DimId. If the verification passes, it writes StdVal and SemVer and sets the semantic isolation flag to no. If the verification fails, it writes the semantic inconsistency reason code and sets the semantic isolation flag to yes.

8. The method according to claim 1, characterized in that, The platform writes the standard unit value StdVal, semantic version number SemVer, and semantic isolation flag into the collection record; After the data collection records are written, within the 1- to 7-day drift detection window, the same field identifier FieldId is used as the key to perform drift determination on changes in unit identifier, changes in dimensional identifier, and StdVal distribution differences in the data collection records. The platform reads the mean and standard deviation of distribution differences from the historical stable segment statistics table and determines the distribution difference threshold as the sum of the mean and three times the standard deviation of distribution differences. When the drift determination is not triggered, SemVer remains unchanged and a non-triggered status code is written. When the drift determination is triggered, the platform rolls back SemVer to the previous semantic version number and writes a rollback reason code. If the rollback is successful, the semantic isolation flag is set to no; if the rollback fails, the semantic isolation flag is set to yes and an isolation reason code is written.

9. The method according to claim 1, characterized in that, After the semantic isolation flag is written into the collection record, the platform generates a quality score Q for the collection record based on the integrity score, consistency score, and timeliness score, where the consistency score is obtained by mapping the semantic isolation flag; the platform reads the weights from the traceability failure reason statistics table and solidifies them into weight version numbers, and reads the 15th percentile value from the Q distribution statistics table of the past 30 days as the trigger threshold t_Q and writes it into the collection record. When the platform sorts the data in ascending order by σt within the window and selects the first record as the anchor event in step S6, the sorting and selection are performed only on the acquisition records that simultaneously meet the conditions of clock validity, non-anchor point, semantic isolation flag not being set, and quality gating comparison result being passed. The quality gating comparison is performed by the platform comparing Q with t_Q and outputting pass or fail. When there are no acquisition records in the window that meet the conditions, the window is set to be reviewed and a window-level reason code is written.

10. The method according to claim 9, characterized in that, The collection record includes a correction timestamp t*, a semantic version number SemVer, a quality score Q, a time uncertainty σt, and an alignment reason code; The platform concatenates the collected records in a fixed field order (t*, SemVer, Q, σt, original payload summary PayloadHash, and alignment reason code) to generate a record summary input string. A hash operation is then performed on this input string to obtain the record summary. The platform links adjacent record summaries in a chain to generate an evidence chain, aligning the collected records across workstations in the timeline. The platform generates batch summary roots and evidence pointers for the record summary set in batches of 1000 to 50000 records and writes them into the results. The original payload summary PayloadHash is obtained by performing a hash operation on the original payload field of the collected records in a fixed byte sequence. When the batch summary root recalculation verification is consistent, the evidence pointer is output; when the batch summary root recalculation verification is inconsistent, the alignment timeline of the corresponding batch is frozen and the evidence breakage reason code is written.

Images