A method and system for quality analysis of raw measurement data of a gauge instrument

Abstract

This invention relates to the field of industrial manufacturing quality management and measurement technology, and specifically discloses a method and system for quality analysis of raw measurement data from measuring instruments. The invention solves the problem of inconsistent access for measuring instruments from multiple brands, with multiple interface types, and multiple protocols by automatically identifying interface types and communication protocols through a pre-deployed dynamic protocol adaptation engine and calling a matching adapter to receive raw data frames. By writing the raw byte sequence into a buffer and generating a data integrity fingerprint before parsing, the invention addresses the issue of raw measurement data being easily tampered with and its authenticity not being guaranteed during transmission and processing. Furthermore, by extracting the unique identifier of the device and performing matching verification based on a pre-established device database, subsequent data frames are discarded if a match fails, thus resolving the problem of unreliable data due to unidentified device identity, expired calibration status, or unauthorized device access.

Description

Technical Field

[0001] This invention relates to the field of industrial manufacturing quality management and measurement technology, and in particular to a method and system for quality analysis of raw measurement data of measuring instruments. Background Technology

[0002] In the manufacturing industry, especially in the precision manufacturing sector, quality management and control, as well as SPC statistical analysis, are among the core technologies for transitioning from "traditional factories" to "intelligent manufacturing."

[0003] Existing quality analysis software in China mainly focuses on statistical analysis, process control, quality monitoring, and trend early warning in the manufacturing process. However, in terms of key measurement data acquisition methods and data sources, most software uses a single acquisition method and cannot yet integrate and acquire data from multiple measuring tools and professional measuring equipment.

[0004] In quality monitoring based on industrial IoT data acquisition gateways, the gateways are used to connect data from devices such as PLCs, sensors, and CNC machine tools to the cloud using protocols such as Modbus, OPC-UA, and MQTT.

[0005] Existing similar technologies primarily target fixed, large equipment and require access via industrial devices (PLCs, machine tools, sensors), necessitating a complete set of external hardware, such as multi-protocol adapters, for data upload to a SCADA / MES platform. The SPC analysis software in such systems is mostly hosted on dedicated brand mainframes and control units, and the data acquisition and analysis targets are not handheld measuring instruments (calipers, micrometers, coordinate measuring machines, image analyzers, etc.), thus limiting the data range. For example, CN112068517B uses an online SPC control system to transmit abnormal data to an APC (Advanced Process Control) system in real time, enabling automatic correction of process parameters and avoiding the lag problem of purely post-event analysis. The data mainly consists of field signals (I / O modules), such as analog quantities (4~20mA, 0~10V) and digital quantities (control switches, relays, solenoid valves, control valves), without involving dimensional parameters.

[0006] In the field of Statistical Process Control (SPC) software, existing technologies mainly consist of foreign companies such as Minitab, InfinityQS, and Q-DAS, as well as some domestic SPC software. Most existing domestic SPC software technologies directly embed and use foreign professional analysis software. This approach focuses on analysis and algorithmic logic, but cannot handle or be compatible with multiple data sources, and largely neglects the initial data acquisition and standardization processes.

[0007] Most existing patented technologies focus on acquiring standard data sources, primarily through manual entry and spreadsheet import. A small number allow direct use of collected data, but the access methods are limited, resulting in poor compatibility. Dedicated drivers are available only for specific brands (such as Mitutoyo), and typically only support RS232 wired serial port reception of data from digital calipers and micrometers, lacking support for unified access via Bluetooth BLE and USB-HID. The data coverage is narrow, making it difficult to support real-world scenarios. Each device requires separate driver and serial port parameter configuration, lacking automatic device type identification capabilities. CN113723781A and CN101477358A primarily provide methods for calculating and monitoring classification control limits for different types of production data (non-continuous, autocorrelated, non-normal, and normal distributions), and for dynamic control of the production process. The focus is on classifying, issuing warnings, and making judgments based on the analyzed data. However, the product data source is triggered by the user module, using manual entry or device input, but the specific type of device input, acquisition, and processing logic are not explained, and cross-brand, multi-protocol unified access is not addressed.

[0008] The LIMS (Laboratory Information Management System) primarily targets testing organizations / laboratories, not manufacturing sites, serving as their data management system. It manages testing tasks, samples, and reports, and partially supports instrument data interfaces. However, instrument interface support is limited, with brand barriers present. It requires the use of host machines and software equipped with branded instruments for document and report output, mainly relying on manual data entry and specific instrument-specific interfaces. There is currently no technology available for integrating report data from multiple instrument types.

[0009] In summary, although SPC and quality analysis are very important, existing technologies for the field of measuring instruments in manufacturing have not achieved smooth data and process integration in terms of the comprehensiveness of interfaces, protocols and data access, and the complete data analysis chain. This makes it difficult to achieve complete and comprehensive quality analysis, resulting in problems such as vacuum areas and data that can be manipulated by humans. Summary of the Invention

[0010] To overcome the problems in existing measuring instrument data processing, such as the inability to achieve and be compatible with multiple data sources, which makes it difficult to conduct complete and comprehensive quality analysis, this invention provides a method and system for quality analysis of raw measurement data of measuring instruments.

[0011] In a first aspect, the present invention provides a method for quality analysis of raw measurement data from measuring instruments, comprising:

[0012] S1: Through a pre-deployed dynamic protocol adaptation engine, automatically identify the interface type and communication protocol of the connected measuring instrument, and call the adapter that matches the interface type and communication protocol to receive the raw data frames sent by the measuring instrument. S2: Before receiving the original data frame and performing any parsing operation on the original data frame, write the complete original byte sequence into the buffer and perform a one-way hash operation on the original byte sequence to generate a data integrity fingerprint; S3: Extract the unique identifier of the measuring instrument, and match and verify the unique identifier of the instrument according to the pre-established equipment archive. If the match fails, discard the subsequently received data frames. S4: Perform protocol parsing on the verified original data frame to extract the measurement values, and encapsulate the measurement values, the original byte sequence, the data integrity fingerprint, the device unique identifier, and the receiving timestamp into a standardized measurement data unit; S5: Based on the sample range specified by the user instruction, read the standardized measurement data unit and execute the quality analysis algorithm to generate quality analysis results.

[0013] According to a specific implementation, in the above method, in step S1, the dynamic protocol adaptation engine completes the device discovery, connection and data reading of the measuring instrument in user mode by calling the native hardware access interface function of the operating system. The interface types include any one or more of the following: serial port, USB interface, industrial fieldbus interface, Bluetooth interface and Wi-Fi interface, file monitoring interface and application programming interface; The dynamic protocol adaptation engine automatically identifies the interface type and communication protocol through the following steps: The port identification information of the device when it is connected is collected to construct a port feature vector; the port identification information includes any one or more of the following: port number, port type, device manufacturer identifier, product identifier, baud rate configuration, data bits, stop bits, and parity bits. Based on a pre-defined port feature matching rule base, a preliminary judgment is made to determine the candidate interface type; For devices initially identified as serial or Bluetooth, handshake messages or broadcast packet data are collected, and message feature vectors are extracted. The message feature vectors include any one or more of the following: message header byte sequence, data length distribution pattern, command code frequency, verification algorithm type, and response delay.

[0014] According to one specific implementation, in the above method, the dynamic protocol adaptation engine further performs the following steps: The extracted message feature vectors are compared with the protocol feature templates in the pre-established protocol feature library to calculate similarity. When the calculated similarity is greater than a preset threshold, the current protocol is identified as the target protocol, and secondary verification is performed. The secondary verification includes: sending a standard query command to the device, verifying whether the response format conforms to the protocol specification, and checking the device information field in the response; When the secondary verification passes, the final protocol type is confirmed; The preset threshold is 0.75; the protocol feature library includes feature templates for custom manufacturer protocols, Modbus RTU protocols, HID protocols, and custom Bluetooth protocols; each feature template includes message header features, data length range, verification algorithm type, and typical command code information.

[0015] According to a specific implementation, in the above method, in step S2, the original byte sequence and the data integrity fingerprint are stored together as two fields in the same storage record. After the protocol parsing is completed in step S4, the parsed measurement value is stored in the same record along with the original byte sequence and the data integrity fingerprint. When it is necessary to verify the correctness of the measurement value, the original byte sequence is read from the storage and the protocol parsing is re-executed. The value obtained from the re-parsing is compared with the stored measurement value.

[0016] According to a specific implementation, in the above method, in step S3, the device archive contains unique device identifiers, registration status, and calibration validity information; the matching verification includes: The system checks whether the unique identifier of the device exists in the device database. If it exists, it further verifies whether the registration status is registered and whether the calibration validity period is valid. If the unique identifier of the device does not exist, is not registered, or the calibration validity period has expired, it is determined that the match has failed, and the reason for rejection is recorded. Subsequent data frames received from the device are discarded according to the reason for rejection.

[0017] According to one specific implementation, in the above method, the standardized measurement data unit encapsulated in S4 is a structured data object, which includes at least the following fields: The record identifier field is used to uniquely identify this measurement record; The device identifier field is used to store the unique identifier of the device; The measurement value field is used to store the measurement value and its unit of measurement; The timestamp field is used to store the received timestamp of the measurement data, which is a high-precision absolute time value. The integrity fingerprint field is used to store the data integrity fingerprint; The quality tag field is used to store the verification status of this data.

[0018] According to one specific implementation, in the above method, the quality analysis algorithm in S5 includes a process capability analysis algorithm or a statistical process control chart drawing algorithm.

[0019] According to one specific implementation, the above method further includes a data buffer distribution step between S4 and S5: Write the encapsulated standardized measurement data unit into a persistent message queue and publish the data unit to the specified topic of the message queue; Multiple downstream modules subscribe to the topic, and when the message queue receives a new data unit, it sends a copy of the data unit to each subscriber respectively; Specifically, the write operation to the message queue is executed asynchronously with the processing operation of the downstream module. Once the write operation is completed, it returns immediately without waiting for the processing result of the downstream module.

[0020] According to a specific implementation, in the above method, the protocol parsing in S4 employs a sliding window frame synchronization recovery mechanism, including: The parser maintains byte index pointers and reads the original byte sequence sequentially; When a frame header identifier of a known frame format cannot be matched at the current index position, the index pointer is moved one byte forward, and the matching of the frame header is retried from the new position. Repeat the above movement operation until a valid frame header is matched or the number of movements exceeds the preset threshold. If the threshold is exceeded, discard the current data frame and reset the parser state.

[0021] Secondly, the present invention provides a system for quality analysis of raw measurement data from measuring instruments, comprising: The protocol adaptation engine module is used to automatically identify the interface type and communication protocol of the connected measuring instruments through a pre-deployed dynamic protocol adaptation engine, and call the adapter that matches the interface type and communication protocol to receive the raw data frames sent by the measuring instruments. The original data preservation module is used to write the complete original byte sequence into a buffer and perform a one-way hash operation on the original byte sequence to generate a data integrity fingerprint before receiving the original data frame and performing any parsing operation on the original data frame. The equipment verification module is used to extract the unique equipment identifier of the measuring instrument, and to match and verify the unique equipment identifier according to the pre-established equipment archive. If the match fails, the subsequently received data frames are discarded. The standardization processing module is used to perform protocol parsing on the verified original data frame to extract measurement values, and encapsulate the measurement values, the original byte sequence, the data integrity fingerprint, the device unique identifier and the receiving timestamp into a standardized measurement data unit. The quality analysis module is used to read the standardized measurement data unit according to the sample range specified by the user instruction, execute the quality analysis algorithm, and generate quality analysis results.

[0022] Compared with the prior art, the beneficial effects of the present invention are as follows: This invention solves the problem of inconsistent access for multi-brand, multi-interface, and multi-protocol measuring instruments by automatically identifying interface types and communication protocols through a pre-deployed dynamic protocol adaptation engine and calling matching adapters to receive raw data frames. It eliminates data silos and reduces the hardware cost and complexity of system deployment by eliminating the need for dedicated hardware acquisition boxes or drivers. Furthermore, by writing the raw byte sequence into a buffer and generating a data integrity fingerprint before parsing, this invention addresses the issue of easily tampered raw measurement data and the inability to guarantee its authenticity during transmission and processing. It ensures that the data stored in the system is completely consistent with the actual output of the measuring instruments, providing irrefutable original evidence for subsequent quality analysis. Finally, by extracting the unique device identifier and performing matching verification based on a pre-established device database, discarding subsequent data frames if a match fails, this invention solves the problem of unreliable data due to unidentifiable device identities, expired calibration status, or unauthorized device access, achieving proactive prevention from the data source. Finally, by encapsulating measurement values, raw byte sequences, data integrity fingerprints, unique device identifiers, and timestamps into standardized measurement data units and performing quality analysis, this invention solves the problem of disconnect between raw data and quality analysis, and the low reliability of analysis conclusions, achieving automated analysis based on real and traceable raw data. Attached Figure Description

[0023] Figure 1 A flowchart illustrating a method for quality analysis of raw measurement data from measuring instruments provided by this invention; Figure 2 A schematic diagram illustrating the workflow of the dynamic protocol adaptation engine provided in this embodiment of the invention; Figure 3 This is a schematic diagram of quality analysis provided for an embodiment of the present invention. Detailed Implementation

[0024] The present invention will now be described in further detail with reference to specific embodiments. However, this should not be construed as limiting the scope of the present invention to the following embodiments; all technologies implemented based on the content of the present invention fall within the scope of the present invention.

[0025] Unless otherwise specified, in the description of specific embodiments of the present invention, "several", "more than", or "a number of" represent at least two. The number can be any number, such as two, three, four, five, six, seven, eight, or nine, and can even exceed nine.

[0026] Furthermore, in the description of the technical solution of this invention, unless otherwise explicitly specified / limited / restricted, the terms "set up," "install," "connect," "link," "provided with," "laid out," and "arranged" should be interpreted broadly. For example, they can refer to fixed connections, detachable connections, or integral connections; they can refer to connection methods commonly used in the art, such as welding, riveting, bolting, and threaded connections. Such connections can be mechanical, electrical, or communication connections; they can be direct connections or indirect connections through an intermediate medium; and they can refer to the internal communication between two components.

[0027] In the description of this invention, measuring instruments are fundamental tools for quality management in the manufacturing industry, including digital vernier calipers, digital micrometers, digital torque wrenches, digital height gauges, lever indicators, thread gauges, video measuring instruments, coordinate measuring machines, thickness gauges, etc. More new specialized instruments are also being used more and more widely, creating an urgent need for simple and quick acquisition of all inspection data for data analysis.

[0028] With the advancement of digital manufacturing, an increasing number of measuring instruments have acquired digital electronic output capabilities, theoretically enabling the direct transmission of measurement data to computer systems for recording and analysis. However, existing technologies face the following fundamental problems in achieving this goal.

[0029] First, different brands and models of measuring instruments use different data output interfaces, including Modbus / OPC-UA for industrial gateways, RS232 serial ports, USB-HID (human-machine interface devices), Bluetooth BLE, and proprietary communication protocols defined by each brand. For example, if a company uses calipers from brand A (RS232), micrometers from brand B (Bluetooth), height gauges from brand C (USB), and coordinate measuring machines from brand D (file transfer), it needs four sets of software to collect data separately, making unified data management impossible.

[0030] However, the reality is far more complex than described above. The number and types of devices requiring connection far exceed the scope outlined. The communication logic of different brands of measuring instruments varies significantly. For example, Mitutoyo measuring instruments, widely used in precision machining and automotive manufacturing, have unique timing requirements for their Digimatic interface protocol. Yokogawa's GP series emphasizes intelligent touch operation and multi-channel integration, and its data flow typically follows higher-level network transmission protocols. Existing data acquisition software usually only supports one or a few interface types. For instance, it may only support RS232 wired serial ports, not Bluetooth BLE, USB-HID multi-mode unified access, and cannot connect to professional instruments. Furthermore, software products for branded measuring instruments can only access data acquisition from hardware devices of that brand.

[0031] Overall, the system suffers from poor compatibility, limited access methods, and dedicated drivers for specific brands (such as Mitutoyo). There is no universal solution for cross-brand unified access, leading to severe data silos. Users are forced to configure different acquisition software and system environments for measuring instruments with multiple interfaces, types, and brands. Each device requires separate driver and serial port parameter configuration, and there is no automatic device type identification capability, resulting in scattered data storage and chaotic management. The system is also limited and requires significant investment, necessitating the deployment of multiple independent systems, storage of data in various formats, or the development of programs by coders, which requires a lengthy investment. During a full-parameter measurement, operators must continuously perform manual transcription and copying, making the data acquisition process cumbersome and inefficient.

[0032] Secondly, most existing tool and instrument data acquisition software only supports the Windows operating system, making it difficult to run on other mainstream systems and mobile platforms, such as Android tablets, iOS devices, and Linux industrial PCs. With the increasing trend of mobile manufacturing, operators are increasingly using mobile terminals for on-site inspections, and the limitations of existing software platforms have become a significant obstacle to the implementation of digital measurement.

[0033] Furthermore, due to the aforementioned issues, the instrument software is installed and used on different platform environments, and there are significant differences in data structures and formats, making the development of a unified system quite challenging.

[0034] Furthermore, most existing technologies require additional hardware, such as protocol adapters, to collect proprietary interface protocol data. Quality analysis in some cases necessitates the purchase of a host workstation with embedded SPC software, resulting in high overall costs. Currently, there is no method using pure software / programmatic approaches to directly call hardware interfaces for sensing access and data reading.

[0035] Furthermore, existing SPC software and MES quality modules struggle to directly collect data from all measuring instruments due to the aforementioned reasons. They primarily rely on manual button presses or manual data entry by operators, along with manual import and upload of report files. This data transfer from measuring instruments to the system involves numerous manual interventions. Because of this manual transfer and import, the original data may be subject to human modification, leading to errors in identification and import, and resulting in misjudgments and other risks. It cannot be guaranteed that the data received by the system will be completely consistent with the actual measurement values ​​of the measuring instruments, and differences in data frame formats between different brands of measuring instruments can lead to direct parsing errors.

[0036] Furthermore, after receiving measurement data, existing acquisition software can hardly identify which specific measuring instrument the data comes from. After receiving the data, it does not verify the legitimacy of the data source device (no equipment file, no calibration status verification). When a certain measuring instrument has system errors, its calibration has expired, or it is replaced by an unauthorized device, the system cannot identify and intercept it, resulting in untrusted data being mixed into quality records. There is no management of measuring instrument-specific attributes such as calibration status, unique ID, and measurement type.

[0037] Similarly, the analysis function and data acquisition function of existing quality analysis software (such as SPC software) are coupled in the same software, and cannot be used as an independent data access layer for unified calling by other systems and modules. Moreover, it usually only supports measuring instruments of specific brands, and cannot perform unified quality analysis on data from measuring instruments of different brands and different types. This makes it difficult to achieve complete quality analysis for the whole process and all links of products. Due to manual intervention in the data acquisition process, the originality and authenticity of the data used for analysis cannot be guaranteed, and the credibility of the analysis conclusion is questionable.

[0038] Furthermore, existing analysis software has complex operation, and the analysis process is tedious and time-consuming. In most cases, only a single parameter can be analyzed separately at one time, and several pre-configurations are required. Many operations are performed based on imported Excel data forms. For example, it is necessary to set the rows or columns of specific sample data in the specified table, and the result can only be viewed after complex settings. Only one statistical analysis dimension can be viewed at a time. To view other analysis charts or conclusions, the above process needs to be repeated. To filter more historical parameter data for analysis, it is difficult to meet a variety of custom condition combinations, and the overall analysis efficiency is relatively low.

[0039] Finally, in addition to the inability to guarantee the authenticity of the original data, in the analysis process of the prior art, there are also situations of manual intervention. Some software allows people to artificially remove and delete sample data, such as out-of-tolerance and undesirable data, or manually input and set parameter standards before performing analysis, which has excessively high operability and freedom. As a result, for the same data sample, the final analysis result may be completely different, and its scientificity and confidence are questionable.

[0040] In summary, in the data access link of the quality analysis system, full-volume data acquisition of measuring instruments from common mainstream testing equipment has not been realized. Most analysis platforms can only collect device data of a single type. Measurement data is mainly divided into three categories, each with its own software platform, and it is difficult to achieve connectivity due to reasons such as data formats, operating systems, and transmission protocols.

[0041] (1) Large fixed industrial equipment, such as laser measuring machines, sensors, instruments, etc., transmit data through industrial control protocol interfaces.

[0042] (2) Measuring tools: The equipment manufacturer's software can only receive and collect data from measuring tools of its own brand. There are many brands, and if multiple brands of measuring tools are used simultaneously, the data cannot be integrated. Manual entry is the only option.

[0043] (3) For professional testing instruments, such as coordinate measuring machines and optical testing instruments, the report file formats vary greatly due to the different host systems installed by different manufacturers. If some instrument manufacturers do not open their API interfaces, the data in the obtained reports must be transcribed or imported into the analysis software manually.

[0044] In other words, existing technologies cannot simultaneously achieve data integration from all common testing equipment and measuring tools, nor can they collect, store, and analyze data from testing equipment and digital measuring tools. There is a lack of a systematic technical solution that can unify the access, standardize the processing, and perform quality analysis of raw measurement data from measuring instruments across platforms, brands, interface types, and protocols. This multi-brand, cross-platform situation has led to serious data silos, and the integration, storage, and authenticity verification of raw measurement records have become bottlenecks restricting the improvement of quality management efficiency.

[0045] Furthermore, traditional measurement data processing methods often rely on manual recording or closed software from a single brand. This approach suffers from significant lag when processing heterogeneous data across platforms, and the integrity of the original data is difficult to guarantee legally during transmission.

[0046] This invention provides a method and system for unified access and quality analysis of multi-type raw measurement data of measuring tools and instruments across platforms, aiming to solve problems in the prior art such as fragmented interfaces of measuring tools and instruments, poor cross-platform compatibility, inability to guarantee the originality of data, unknown device identity, and separation of raw data and quality analysis.

[0047] The core objective and technical solution of this invention comprises three layers: Layer 1: Protocol adaptation engine, enabling unified access to various types of measuring instruments and meters. This invention implements a method for cross-platform hardware device communication without relying on operating system kernel drivers, using pure application-layer code. Through low-level code logic, it directly perceives driver interfaces, data protocols, and tool types. It automatically determines device types based on characteristics such as device descriptors, broadcast frames, and handshake messages. For each interface type and protocol, it writes independent adaptation module processes to parse and convert raw data frames from different sources into a unified, standardized measurement data structure, achieving unified processing.

[0048] Second layer: Cross-platform device management and original data integrity preservation mechanism The system uses an equipment file system to identify and verify the legitimacy of measuring tools and instruments. It also uses a raw data receiving and archiving mechanism to ensure the originality of the data. A cross-platform operating architecture has been designed to support multiple operating system environments such as Windows, Android, iOS, and Linux.

[0049] The system receives raw measurement values ​​directly from the equipment and gauges, without any manual intervention. It generates a data fingerprint the instant the data is received, enabling real-time analysis and early warning, and ensuring complete consistency between the data used in subsequent analysis and the equipment's output. This is fundamentally different from the manual input or triggering methods used in existing SPC software.

[0050] Third layer: Multi-device, cross-type quality analysis engine based on raw data Above the unified access layer, a quality analysis engine is built that can perform key indicator calculations, process capability analysis, control charts, trend analysis, and equipment measurement consistency analysis on raw data from different brands and types of measuring instruments, and output reliable quality analysis results.

[0051] In particular, for consistency analysis between equipment, when the same inspection item is measured by multiple measuring instruments of different brands, the system can save the instrument's identity and can be used to analyze the differences in measurement results between different devices, identify equipment system errors, and perform MSA analysis.

[0052] The technical solution provided by this invention can be applied to quality inspection and management scenarios in various manufacturing enterprises. For example, in a precision machining workshop, a Mitutoyo digital caliper (communicationd via RS232 serial port), a domestic brand Bluetooth digital micrometer, and a Hexagon coordinate measuring machine (outputting measurement reports via file) are deployed simultaneously. The quality engineer in the workshop uses an industrial tablet computer (Android operating system) and an industrial control computer (Windows operating system) with the system of this invention installed. The system of this invention can run on both platforms simultaneously, uniformly access the data of all the measuring instruments, and perform real-time quality analysis.

[0053] The specific implementation process of this invention is described in detail below.

[0054] Please refer to Figure 1 This document illustrates a flowchart of a method for analyzing the quality of raw measurement data from measuring instruments, provided by the present invention. This method is applied to computing devices with hardware communication interfaces (such as the aforementioned industrial tablet PCs or industrial control computers), and specifically includes the following steps.

[0055] S1: Through a pre-deployed dynamic protocol adaptation engine, automatically identify the interface type and communication protocol of the connected measuring instrument, and call the adapter that matches the interface type and communication protocol to receive the raw data frames sent by the measuring instrument.

[0056] In this step, the computing device automatically identifies the interface type and communication protocol of the connected measuring instrument through its internally deployed dynamic protocol adapter engine. This engine pre-writes independent adapters for each supported interface type and brand protocol. When a measuring instrument powers on or establishes a physical connection with the computing device, the dynamic protocol adapter engine detects the device's online status by polling the operating system interface or listening for device mount events.

[0057] The engine first identifies the device's interface type. Interface types include wired interfaces (such as serial ports, USB interfaces, industrial fieldbus interfaces like Modbus or OPC-UA), wireless interfaces (such as Bluetooth interfaces, Wi-Fi interfaces), file monitoring interfaces, and application programming interfaces (APIs). Based on the identified interface type, the engine calls a set of adapters matching that interface type and attempts to establish a handshake communication with the device one by one according to priority. Once an adapter successfully parses the characteristic data returned by the device, the communication protocol is confirmed. That adapter then establishes a dedicated data channel with the measuring instrument and begins receiving its raw data frames.

[0058] For example, when the interface type is a Bluetooth interface, the dynamic protocol adaptation engine performs the following operations: calls the Bluetooth scanning function provided by the operating system to obtain broadcast frames broadcast by surrounding Bluetooth devices in active scanning mode; parses the device's hardware address, service identifier, and manufacturer-defined data from the broadcast frames; performs a comprehensive score on the above information according to a preset feature library, and automatically determines the device type based on the score result; calls the GATT connection function to establish a connection and subscribes to the notification attributes of the measurement data feature values; when a notification event is received, extracts the original data frame from the event parameters.

[0059] For example, when the interface type is a file monitoring interface, the adapter continuously monitors a specified directory in the operating system. When a new or updated measurement data file (such as a CSV file exported from a coordinate measuring machine or a proprietary format report) is detected, the adapter reads the contents of the file and extracts the raw data frame from the file's data records or directly extracts the measurement values. When the interface type is an application programming interface (API), the adapter calls the standardized data interface (such as a REST API or SDK) provided by the instrument manufacturer, obtains the real-time measurement data stream through periodic polling or registered callbacks, and extracts the raw data frame from it. Through the above pure software approach, this system can complete the data access of Bluetooth measuring instruments without any hardware conversion box, reducing deployment costs and complexity.

[0060] S2: Before receiving the original data frame and performing any parsing operation on the original data frame, write the complete original byte sequence into the buffer and perform a one-way hash operation on the original byte sequence to generate a data integrity fingerprint.

[0061] In this embodiment of the invention, this step is the crucial reception and encapsulation stage. After the dynamic protocol adaptation engine successfully receives a complete raw data frame in step S1, it immediately performs the following preservation operation before performing any parsing, cleaning, or transformation operations on the data frame.

[0062] The engine first writes the received complete raw byte sequence (e.g., a set of hexadecimal values ​​received from a micrometer) without any modification to a dedicated buffer in the computing device's memory. This buffer is independent of subsequent parsing modules, ensuring that the integrity of the raw byte sequence is not affected by subsequent processing.

[0063] Next, the engine performs a cryptographic one-way hash operation on the original byte sequence in the buffer. In a preferred implementation, the SHA-256 algorithm is used. The engine calls the standard SHA-256 hash function, taking the byte sequence as input, to calculate a fixed-length (256-bit) hash value, typically represented as a 64-bit hexadecimal string; this is the data integrity fingerprint. This fingerprint uniquely corresponds to the original byte sequence; any minor alteration to the original bytes will result in a recalculated fingerprint that does not match the original fingerprint.

[0064] The original byte sequence and the data integrity fingerprint are stored as two fields in the same storage record, and are also stored in the same record along with the subsequently parsed measurement values. When it is necessary to verify the correctness of the measurement values ​​(e.g., in quality disputes or audit scenarios), the system reads the original byte sequence from storage, re-executes the protocol parsing, and compares the re-parsed values ​​with the stored measurement values. If they match, it proves that the measurement values ​​have not been tampered with; if they do not match, it indicates that the data may be abnormal.

[0065] By sealing and hashing the data the moment it enters the system, this invention generates an unalterable original certificate for each measurement data point. This mechanism fundamentally ensures that the data used for subsequent system processing and analysis is completely consistent with the actual output data of the measuring instruments, eliminating the risk of human modification or input errors at the source of the data chain.

[0066] S3: Extract the unique identifier of the measuring instrument, and perform matching verification on the unique identifier of the instrument according to the pre-established equipment archive. If the matching fails, discard the subsequently received data frames.

[0067] Specifically, after the original data is preserved, the system begins to verify whether the measuring instrument that generated the data is a legitimate and reliable device. The system extracts its unique device identifier from the device information identified in step S1. For Bluetooth devices, this identifier can be its MAC address; for serial port devices, it can be its serial number; for USB devices, it can be a combination of the manufacturer identifier and product identifier in its device descriptor.

[0068] The system uses the device's unique identifier as the query key and sends it to a pre-established device database for matching and verification. The device database can be a database stored locally or on a remote server, containing information such as the device's unique identifier, registration status, and calibration validity period.

[0069] The specific logic for the matching verification is as follows: First, the system queries the device archive to see if a record matching the device's unique identifier exists. If not, the matching is deemed a failure. If it exists, the system further verifies whether the record's registration status is registered. If not registered, the matching is deemed a failure. If registered, the system obtains the current system time and compares it with the calibration validity period timestamp in the record. If the current time is later than the calibration validity period, the matching is deemed a failure.

[0070] If any of the above conditions are not met, the system determines that the match has failed. At this point, the system generates a rejection reason (e.g., device not registered, calibration expired, etc.) and records this rejection reason along with the device identifier. Subsequently, for any subsequent data frames received from this device, the system will immediately discard them based on the rejection reason after receiving them in step S1, without proceeding to step S2 or any subsequent processing flow. Only when all verifications pass can the device's data frames continue to flow to step S4. This device verification mechanism intercepts unregistered, expired, or illegally replaced measuring instruments at the data source, preventing unreliable data from entering the quality analysis system and achieving proactive quality risk control.

[0071] S4: Perform protocol parsing on the verified original data frame to extract the measurement values, and encapsulate the measurement values, the original byte sequence, the data integrity fingerprint, the device unique identifier, and the receiving timestamp into a standardized measurement data unit.

[0072] Specifically, for the raw data frame verified in step S3, the system retrieves it from the buffer and hands it over to the corresponding protocol parser for processing. This parser invokes the appropriate parsing algorithm based on the brand protocol type identified in step S1. After successfully extracting the measurement values, the system enters the standardization and encapsulation stage. The system creates a standardized measurement data unit. This data unit is a structured data object containing at least the following six fields: Record Identifier Field: Used to uniquely identify this measurement record, such as a globally unique identifier.

[0073] Device Identifier Field: Used to store the unique device identifier obtained from step S3.

[0074] Measurement value field: Used to store the parsed measurement values ​​and their corresponding units of measurement.

[0075] Timestamp field: Used to store the received timestamp of the measurement data. The received timestamp is a high-precision absolute time value, such as a timestamp containing year, month, day, hour, minute, second and nanoseconds read from a high-precision clock.

[0076] Integrity fingerprint field: Used to store the data integrity fingerprint (e.g., a hexadecimal string of the SHA-256 hash value) generated in step S2.

[0077] Quality Tag Field: Used to store the validation status of this data, such as validated, unvalidated, or validation failed enumeration values.

[0078] At this point, all the heterogeneous raw data, whether from serial calipers, Bluetooth micrometers, or files exported from coordinate measuring machines or pushed through API interfaces, have been transformed into standardized measurement data units with consistent structure and complete content.

[0079] To ensure the system's robustness in complex industrial environments, this application employs a sliding window frame synchronization recovery mechanism in protocol parsing. Electromagnetic interference in industrial settings can cause garbled characters or data loss in serial communication. When reading the raw byte sequence, the parser maintains a dynamic byte index pointer. It sequentially attempts to match the known frame header identifier (e.g., a specific hexadecimal value) of the gauge protocol at the current position. If a match fails, the parser does not immediately report an error and terminate; instead, it moves the index pointer one byte forward and re-attempts to match the frame header from the new position. This sliding window process continues until a valid frame header is successfully matched, or the number of index pointer movements exceeds a preset threshold (e.g., the maximum frame length is moved). If the frame header is still not found after exceeding the threshold, the parser determines that the current data frame is corrupted, discards it, and resets its internal state to prepare for processing the next data frame. This mechanism ensures that a single communication failure on a single device will not cause the entire acquisition service to crash, nor will it affect the data acquisition of other gauges connected to the same computing device.

[0080] S5: Based on the sample range specified by the user instruction, read the standardized measurement data unit and execute the quality analysis algorithm to generate quality analysis results.

[0081] Specifically, the system performs quality analysis based on instructions input by users (such as quality engineers) through a graphical user interface. The user instructions specify the sample range for analysis, such as querying all measurement data within the last 30 days for a product model with a specific process (precision machining) and a diameter as the detection parameter.

[0082] Upon receiving the instruction, the system reads standardized measurement data units that meet the criteria from persistent storage (such as a time-series optimized database system) to form a sample dataset. Then, the system invokes its built-in quality analysis algorithm engine. This engine executes various algorithms, including process capability analysis and statistical process control chart (SPC) plotting, based on data characteristics and user selections.

[0083] Optionally, the quality analysis algorithm includes a process capability analysis algorithm. This algorithm groups the sample dataset according to the user-inputted group size parameter (e.g., each subgroup contains 5 samples). Next, it calculates the statistical characteristics of the sample dataset, including mean, standard deviation, maximum, and minimum values. Then, it calculates overall capability indicators (e.g., overall process capability index and overall nonconforming rate) and within-group capability indicators (e.g., within-group process capability index and within-group nonconforming rate) based on specification limits. Finally, the system displays the calculated indicators and corresponding performance dashboard data to the user in a dashboard format.

[0084] Optionally, the quality analysis algorithm includes a statistical process control chart plotting algorithm. This algorithm calculates the center line, upper control limit, and lower control limit of the control chart based on the distribution characteristics of the sample data or the control chart type specified by the user. For example, for a mean-range control chart, the system looks up the corresponding control chart coefficients according to the subgroup size, then calculates the center line and control limits for the mean chart, and the center line and control limits for the range chart. Finally, the system generates a sequence of coordinate points for front-end rendering, rendering the statistics of each subgroup as a point sequence along with the control limits onto the control chart. The system triggers an alert when any point exceeds the control limits, or when multiple consecutive points appear on the same side of the center line, or when other statistical anomalies occur.

[0085] Since the analysis in this invention is based on standardized measurement data units with original timestamps and protected by originality preservation and equipment verification, the analysis conclusions can truly reflect the actual quality level of the production process and have good reliability. Between S4 and S5, to address the data writing bottleneck in high-concurrency industrial scenarios (e.g., multiple measurement stations simultaneously reporting data at high frequencies), this invention also introduces a data buffering and distribution step.

[0086] The system does not directly write the standardized measurement data units generated by S4 to final storage. Instead, it first writes them to a persistent message queue. The system publishes the data unit to a designated topic in the message queue. Simultaneously, multiple downstream modules (such as the real-time dashboard display module, quality analysis module, historical data storage module, and alarm module) subscribe to this topic. When the message queue receives a new data unit, it sends a copy to each subscriber module.

[0087] In this architecture, the operation of writing to the message queue is executed asynchronously with the processing operations of the downstream modules. Once the acquisition thread executing S4 successfully writes the data to the message queue, its task is complete, and the thread immediately returns to prepare to receive the next data frame, without waiting for the storage module to complete disk writing or the analysis module to complete complex calculations. This decoupled architecture of acquisition and storage ensures that even under the impact of high-frequency measurement data streams, the acquisition end will not experience blockage or data loss.

[0088] Alternatively, in one specific implementation, the present invention may be further implemented in the following manner to optimize the system architecture, improve data processing performance and robustness.

[0089] The present invention can implement the above technical solution in the form of a multi-layered computer architecture.

[0090] Specifically, the system can be divided into a six-layer architecture: The device access layer supports various brands and types of equipment, including RS232 gauges, USB gauges, BLE gauges, and professional instruments. This is achieved through workstations / mobile tablets with an installed software acquisition app and parsing engine. The cross-platform operation layer is developed and adapted to mainstream desktop and mobile operating system platforms, including but not limited to Windows, Android, iOS, Linux, and a unified API abstraction layer. Users can integrate data and perform functions such as mobile tablet inspection and sampling, workstation cross-platform inspection data acquisition, and real-time and historical data analysis on web pages / large screens. The dynamic protocol adaptation engine layer is not limited to industrial gateways using Modbus / OPC-UA or RS232 serial ports, which can only connect to one or two types of devices. Through underlying software code, the system continuously monitors instrument and tool connectivity, interface status, thread listening, and data packets. The system now features multi-interface and channel tool and device identification and registration, hot loading, channel adaptation, concurrent scheduling, type judgment, complete capture, and protocol data parsing, with raw data being received and immediately archived. A standardized data processing encapsulation layer addresses the limitations and challenges of integrating multiple protocols and format measurement data in existing technologies. The system's acquisition module separately processes the data formats of existing mainstream flow instruments, and its acquisition module development achieves a unified data structure and complex processes such as measurement data fingerprinting. A data buffering and management layer asynchronously processes and exports integrated measurement data, ensuring the integrity of acquired data in high-concurrency environments. The system employs a special database and architecture design to ensure that large amounts of high-concurrency data can be quickly used for subsequent analysis and storage, avoiding delays, congestion, and lag. The quality analysis and output layer includes the system's analysis module, encompassing integrity verification, query retrieval, standard comparison, automatic judgment, indicator algorithms, and chart plotting. Based on user-specified conditions, it extracts, groups, calculates, plots, analyzes conclusions, and exports reports of raw measurement data. It enables real-time analysis and allows for the retrieval of historical data for deeper analysis, root cause identification, and decision guidance.

[0091] Specifically, this invention adopts a cross-platform operating architecture, building a unified API abstraction layer above the operating system hardware access layer to solve the differences in underlying interfaces such as Bluetooth access, serial port access, and USB access across different operating systems. The unified abstraction layer defines unified interface specifications for device discovery, connection, and data reception. Specific adaptation code for these interface specifications is implemented for each platform. Meanwhile, upper-layer code calls the unified interface without being aware of platform differences. The protocol adaptation engine layer and all its code can be reused across platforms, while the underlying platform adaptation code is implemented separately for each platform.

[0092] For software-level protocol adaptation and parsing engines, existing instrument data acquisition solutions typically rely on dedicated hardware acquisition boxes (such as USB-to-serial hardware, proprietary protocol adapters and interfaces, etc.), increasing hardware costs and deployment complexity. This invention, however, allows data acquisition from all measuring instruments to be achieved simply by calling the operating system's hardware access interface through a pure software program, utilizing only the communication interface built into the computer or mobile terminal.

[0093] Please refer to Figure 2 This diagram illustrates the workflow of the dynamic protocol adaptation engine provided in this embodiment of the invention. The protocol adaptation and parsing engine is one of the core technologies of the system. Its core principle is to replace traditional dedicated hardware acquisition devices with pure software programs. Through low-level library methods, it directly calls the hardware access interfaces provided by various operating system platforms, completing the sensing, connection, data reading, and protocol parsing of measuring instruments in user space. This eliminates the need to install kernel-level drivers or forcibly configure dedicated hardware acquisition boxes. The system can also accommodate hardware acquisition boxes, enabling a single host to simultaneously access data from more measuring devices, thus improving efficiency.

[0094] Traditional solutions typically employ a technical path of measuring instrument - dedicated hardware acquisition box - USB / Ethernet port - PC software. This path relies on a hardware middleware layer, resulting in high costs, complex deployment, and platform limitations. The embodiments of this invention adopt a technical path of measuring instrument - operating system native interface - underlying library (user space) - protocol parsing engine. This is a purely software implementation with zero hardware dependency, cross-platform compatibility, and immediate usability.

[0095] Specifically, the protocol adaptation engine in this embodiment of the invention employs a single ownership transfer mechanism for the original data frame. After the original data frame is read from the hardware interface, its memory ownership belongs exclusively to the sealing module. Before the sealing operation is completed and a hash fingerprint is generated, no other module can obtain write access to this memory region. This mechanism is enforced at the logical level through program architecture design, rather than relying on runtime locks or mutexes, fundamentally eliminating the possibility of the original data being accidentally modified before sealing.

[0096] Furthermore, the frame format parsing module of this invention employs a boundary-safe byte sequence access mechanism. When parsing raw data frames from unknown brand gauges, the system performs index boundary verification for each byte access operation. If the access index exceeds the actual length of the data frame, the system returns a parsing error instead of continuing execution. This ensures that parsing raw data frames of any format and length will not cause system crashes or memory access out-of-bounds errors due to frame format abnormalities. This mechanism enables the system to safely process non-standard data frames from unknown brand gauges and supports the secure implementation of the automatic frame format learning function.

[0097] Furthermore, the platform hardware access abstraction layer of this invention adopts a compile-time static distribution mechanism. Addressing the differences in hardware access interfaces across different operating system platforms, the system selects the corresponding specific implementation based on the target platform during the compilation phase. The generated executable code does not contain runtime platform decision branches or virtual function call overhead, making the execution efficiency of the hardware access path equivalent to directly calling the operating system's native API. This mechanism ensures that in real-time data acquisition scenarios in industrial settings, the end-to-end latency from the sending of data frames by the measuring instrument to the completion of system reception and storage does not exceed 5 milliseconds.

[0098] In one possible implementation, the protocol adaptation engine of this invention is compiled into a self-contained native binary program. The program runs without relying on any external virtual machine, interpreter, or managed runtime environment, supporting the compilation of the same source code into native binaries for multiple platform environments, such as Windows, Linux, macOS, and Android, achieving true cross-platform code reuse. All dependent libraries are statically linked to the executable file during compilation, requiring only a single executable file to be copied to the target device for deployment. This feature enables the system to run normally on embedded Linux industrial control computers with memory resources as low as 64MB and no graphical interface, meeting the deployment requirements of industrial control equipment in manufacturing sites.

[0099] The multi-device concurrent data acquisition mechanism of this invention adopts a non-blocking asynchronous event-driven architecture. The system establishes an independent asynchronous data receiving task for each connected measuring instrument. While waiting for device data, each task does not occupy processor resources. When any device sends a data frame, the corresponding task is awakened and processed immediately, returning to a waiting state after processing. This architecture enables the system to maintain active connections with multiple measuring instruments simultaneously on a single processing thread, supporting concurrent data acquisition from no fewer than 32 measuring instruments without increasing processor core usage.

[0100] Specifically, the overall architecture of the protocol adaptation engine can be divided into four layers, which are the key core of this invention. The first layer is the device environment awareness layer, the second layer is the raw data encapsulation layer, the third layer is the custom identification parser, and the fourth layer is the protocol management layer. The core of this module lies in shielding hardware differences and using the above four-layer architecture to unify RS232, USB-HID, BLE, and even file streams, solving the pain point of existing technologies in "how to obtain clean byte streams from non-standard hardware from different manufacturers".

[0101] For the device environment awareness layer, the system continuously monitors and polls the interfaces of various platforms to sense the online status of devices. The logic is: instead of passively waiting, it actively polls or listens for mounting events. Although existing technologies have some software-level libraries that directly access hardware, they lack dedicated logic for protocol parsing, device identification, and data security specific to the measuring instrument scenario. This invention uses a combination of a general library and measuring instrument-specific logic, writing a custom logic for each type and protocol tool to solve the access and identification logic of common measuring instruments, adapting to current mainstream interfaces, and achieving integrated access. This architecture layer includes a fast retrieval method for system paths and hardware identifiers, and at the hardware awareness level, it dynamically identifies connected serial port devices, HID keyboards, and other devices.

[0102] For USB hot-plugging, access is via the system event sensing port, facilitating subsequent processing of HID device input / output reports. For example, in Windows: RegisterDeviceNotification. For Bluetooth device online / disconnection, broadcast packets are acquired to identify the UUID / Manufacture ID and MAC code via BLE Scan. For serial port device online, changes in the system COM port are monitored to identify serial device access. Cross-platform serial port operation and communication are supported. For file service paths, the target folder path is monitored, and the generation of sensing report files is polled, collected, and data parsed and identified. For API interfaces, online sensing instruments and data transmission are identified via the open interface and the system's configured API address.

[0103] For the raw data storage layer, the raw data preservation mechanism of this invention is one of the key technical features and designs that distinguishes it from all existing data acquisition software. The focus is on ensuring that the data stored in the system is completely consistent with the actual output source data of the measuring instruments, and that it cannot be tampered with afterward. This ensures the absolute authenticity and integrity of the data, whether at the front-end user operation level or the database level. A threaded task approach is adopted, starting an independent coroutine for each sensed device, enabling concurrent data acquisition from multiple devices.

[0104] The specific implementation process is as follows: When all the adapted algorithm modules are triggered, that is, after the first-layer recognition device goes online / connects, the engine immediately performs data sealing, which is a key step to ensure the originality of the data. At this time, the sealed data has not yet been parsed or processed. The sealed data uses a hash algorithm to generate a unique index for the original data, binding key data such as the current system operator, the tool's unique ID, the tool type, and the timestamp.

[0105] Technical process of preservation mechanism: ① Immediate Encapsulation Upon Receipt: Upon triggering the adaptation callback, the system writes the original data frame and the received timestamp into a temporary buffer before performing any parsing or processing. This ensures the original byte sequence is completely preserved and unaffected by subsequent parsing. This design is tailored for high-concurrency data scenarios in industrial applications, enabling the system to store data without delay or congestion even when multiple, distributed acquisition points are simultaneously transmitting data at high frequencies.

[0106] ② Original Frame Hash: In the same operation where the original data frame is written to the buffer, the SHA-256 hash value of the original frame is calculated immediately and stored simultaneously with the original frame. Any subsequent modification to the original frame will cause the hash verification to fail.

[0107] ③ Dual storage of parsed values ​​and original frames: The system simultaneously stores the original data frame and the parsed measurement value, both linked by the same record ID. When there is doubt about the parsing result, it can be re-verified using the original frame, ensuring the transparency, traceability, and verifiability of the parsing process. See the subsequent parser description for the parsing logic.

[0108] ④ Core Storage Logic: Timestamp + Device ID. The system is designed so that every piece of data captured from the hardware interface is encapsulated into a time-series data packet. The device ID addresses the question of "who," while the timestamp addresses the question of "when." Industrial data begins to lose its timeliness the moment it leaves the hardware; including a timestamp accurate to the millisecond is the sole credential for subsequent analysis and anomaly tracing.

[0109] During the sealing process, the ownership mechanism of this invention ensures that the byte sequence will not be accidentally modified during transmission. This guarantees at the language level that the original frame cannot be tampered with after sealing. This compile-time guarantee is something that similar systems cannot provide. Most existing systems rely on the self-discipline of programmers and runtime checks, while this mechanism eliminates such risks at compile time.

[0110] For the custom dynamic protocol parsing engine, when the device perception layer detects a device connection or online status, it automatically triggers the "Device On" event. Based on the interface specification-driven adapter plug-in mechanism, the dynamic protocol parsing engine algorithm matches the appropriate protocol engine according to the platform, interface source, data characteristics, and device identity for data collection and parsing. The acquisition end confirms which manufacturer's protocol is being used by sending commands or observing heartbeat packet characteristics. If a match fails, the logic automatically switches to the next parsing attempt.

[0111] In existing measurement applications, multiple brands are involved (such as foreign brands Mitutoyo and Yokogawa, and various domestic measuring tool brands). The system has constructed an adaptive semantic mapping operator, namely the adaptive operator, which realizes an automatic protocol identification and semantic mapping method based on feature matching according to a preset knowledge base. It automatically identifies the message and protocol data frame structure of the access device, and stores the acquired data frames using an encrypted fingerprint algorithm and puts them into a subsequent buffer pool for input into the standardized algorithm module for further processing.

[0112] The analytical features include automatic identification of the type of measuring instrument and data frame rules for various brands of measuring instruments. Specifically, due to the different reporting and transmission mechanisms of various interface protocol tools, the system performs data cleaning (filtering out hardware-generated interference and noise), measurement data interception, and identifies specific rules such as end characters and newline characters before saving the data, based on a preset custom algorithm module.

[0113] ① Implementation of the combinatorial sub-logic of the dynamic protocol parsing engine This invention establishes an instruction feature library, storing function combination method libraries and regular expression template strings for various measuring instruments. During the data access phase, the parsing engine dynamically loads templates associated with the current device ID, and achieves decoupling and transformation of non-standard data by segmenting and mapping the original message and capturing its fields.

[0114] For example, if manufacturer A's data is in hexadecimal serial port format, and manufacturer B's data is in ASCII string format (HID), the system first enters the platform interface branch based on perception. The next step involves using a function composition library; that is, the system has already written a minimal parsing engine for each type of manufacturer data, enabling feature recognition and attempting to match multiple feature codes. The parsing rules (offset, length, data type) are written in a configuration file to implement judgment and parsing.

[0115] This invention designs an open dynamic protocol parsing engine extension interface, which can continuously add new interface types or brand protocols by adding new algorithm modules.

[0116] ② Cross-platform serial port algorithm It supports the detection and extraction of serial port data through port enumeration, baud rate setting, and data reading and writing, and performs device type identification, gauge device protocol parsing, and frame format learning. For example, it can detect data frame end characters (such as \r\n) to determine the completion of a data transmission.

[0117] In a preferred embodiment of the present invention, cross-platform support includes mainstream operating system platforms such as Windows (via WinRT BLE API), Linux (via BlueZ D-Bus API), macOS and iOS (via CoreBluetooth framework), and Android (via AndroidBLE API).

[0118] ③ Cross-platform USB algorithm Implement a cross-platform USB low-level access algorithm to perform device enumeration, descriptor reading, gauge device identification, endpoint transmission, etc., and with the parsing module, complete HID file report parsing, measurement value extraction, etc.

[0119] ④ Cross-platform Bluetooth BLE algorithm The cross-platform Bluetooth BLE access module identifies measuring instruments by actively scanning BLE broadcast frames on mainstream desktop and mobile operating system platforms, establishes a GATT connection, subscribes to Notify notifications of measurement data feature values, and receives and parses measurement data frames sent by the measuring instruments.

[0120] In a preferred embodiment of the present invention, cross-platform support includes mainstream operating system platforms such as Windows (via WinRT BLE API), Linux (via BlueZ D-Bus API), macOS and iOS (via CoreBluetooth framework), and Android (via AndroidBLE API).

[0121] ⑤ File report monitoring and parsing algorithm For situations where the instrument is in a local encrypted and isolated network environment and the instrument does not have an open API interface and cannot collect data through conventional network or serial port methods, the system has built a directory monitoring and file parsing algorithm. The instrument generates reports and automatically saves them to the target server folder / gateway / local folder, etc. After the system monitors and polls, it obtains the file and automatically starts the parsing process.

[0122] ⑥ API Acquisition and Parsing Algorithm The system uses the instrument system's API interface to identify when sensing instruments are online and when data is transmitted, and processes the transmitted data packets.

[0123] The dynamic protocol parsing engine provided in this invention will be described and explained in detail below with reference to specific implementation methods. I. Automatic Identification Mechanism for Interface Type and Communication Protocol Specifically, the dynamic protocol adaptation engine achieves automatic identification of interface types and communication protocols through multi-dimensional feature fusion, including the following steps: First, collect port identification information when the device is connected and construct a port feature vector. Port identification information includes any one or more of the following: port number, port type, device manufacturer identifier, product identifier, baud rate configuration, data bits, stop bits, and parity bits.

[0124] Specifically, the system port identification information when the device is connected is collected, including: port number, port type, device VID / PID, serial port baud rate configuration, etc.; a port feature vector is constructed: V_port = {port_id, port_type, vid, pid, baud_rate, data_bits, stop_bits, parity}; secondly, a preliminary judgment is made based on the preset port feature matching rule base to determine the candidate interface type.

[0125] Specifically, if port_type=USB, vid=0x10C4, and pid=0xEA60, it is determined to be a Silicon Labs CP2102 USB to serial port device; If port_type=USB, vid=0x1A86, and pid=0x7523, it is determined to be a CH340 USB to serial port device. If port_type=BLUETOOTH and port_id contains "BLE", it is determined to be a Bluetooth Low Energy device; If port_type=SERIAL and port_id matches "COM\d+", it is determined to be a serial port device; Third, for devices initially identified as serial or Bluetooth, collect handshake messages or broadcast packet data and extract message feature vectors.

[0126] Specifically, for devices initially identified as serial / Bluetooth devices, handshake message collection is performed; For types initially identified as file service / API interfaces, collect initial data packets; Extract the message feature vector: V_packet = {header_byte_seq, data_len_pattern, cmd_code_freq, checksum_algo, response_delay}; Message feature extraction methods: Collect 10 consecutive interactive messages and count the frequency of the message header byte sequence. Analyze the data length distribution patterns: fixed length / range length / variable length; Statistical analysis of the frequency of command codes; Verification algorithms: CRC8 / CRC16 / CRC32 / XOR check / SUM check; Fourth, the extracted message feature vectors are compared with the protocol feature templates in the pre-established protocol feature library to calculate the similarity.

[0127] Specifically, a protocol feature library is constructed, which includes, but is not limited to, typical protocol feature templates as shown in Table 1.

[0128] Table 1. Typical Protocol Feature Template Diagram

[0129] The API interface uses standard interface data with defined constraints, requiring no feature library matching; the file path listening method is for file data parsing, and a parsing library is built according to different file types, which is not included in this protocol feature library.

[0130] Calculate feature similarity: Sim(V_packet, V_template) = Σ(w_i |V_packet[i] - V_template[i]| / V_template[i]); When the similarity threshold θ > 0.75, it is determined to be the corresponding protocol; fifth, perform secondary verification. Secondary verification includes: sending a standard query command to the device (such as reading device information), verifying whether the response format conforms to the protocol specification, and checking the device information field in the response.

[0131] Specifically, for the top 2-3 protocols with the highest matching degree, secondary verification is performed: Send a standard query command (such as "read device information"); Verify that the response format conforms to the protocol specifications; Check the device model, firmware version, and other fields in the response; Once the secondary verification passes, the final protocol type is confirmed; II. Specific Data Examples Example 1: USB to Serial Port Table Connection System event triggered: Windows RegisterDeviceNotification received a notification that a USB device was inserted; Port scan: New port COM5 detected, port type USB, VID / PID identified and obtained, VID0x10C4, PID0xEA60; Preliminary judgment: The device is a CP2102 USB to serial port device from a certain manufacturer. It is known that it supports multiple data bit configurations: 5 / 6 / 7 / 8 bits, 1 / 1.5 / 2 stop bits, none / odd / even / marked / spaced parity bits, and baud rate of 300bps-3Mbps. Handshake message collection: Send: 0x55 0xAA 0x01 0x00 0x00 0x00 0x00, Received response: 0x55 0xAA 0x03 0x10 0x02 0x00 0x08 0x00 0x00; Feature extraction: The message header is 0x55 0xAA, with a fixed length of 9 bytes, and the 7th byte is CRC16; Protocol matching: 0.92% match with the custom protocol feature library; Secondary verification: Send the "Read Device Information" command, and the response will include the "EDM-350" model information; Final confirmation: Load the custom protocol parser; Example 2: Bluetooth Low Energy Gauge Access System event triggered: BLE Scan detected a new device broadcast packet; Broadcast packet analysis: UUID0xFFE0, Manufacturer ID0x004C, MACAA:BB:CC:DD:EE:FF; Preliminary assessment: Matched with Bluetooth UART service. GATT Service Discovery: After connection, service 0xFFE0 is discovered, with characteristic 0xFFE1 (read / write). Handshake message collection: Send: 0xAA 0xBB 0x01, Received response: 0xAA 0xBB 0x02 0x16 0x20; Feature extraction: Message header 0xAA 0xBB, length 10-20 bytes, CRC8 checksum; Protocol matching: 0.88% match with the custom Bluetooth protocol feature library; Secondary verification: Send: Read firmware version command, the response includes "V1.2.3" version information; Final confirmation: Loading a custom Bluetooth protocol parser; Example 3: Serial port sensor / humidity and thermometer connection System event triggered: Windows RegisterDeviceNotification received a serial device insertion notification; Port scan: New port COM3 detected, port type SERIAL, baud rate 115200; Preliminary assessment: Matches serial port device; Handshake message acquisition: Send "0x55 0xAA 0x01" three times consecutively, and receive the response "0x55 0xAA 0x02 0x000x00 0x00 0x00 0x00 0x00"; Feature extraction: The message header is 0x55 0xAA, with a fixed length of 9 bytes and no checksum. Protocol matching: Match score with custom feature library is 0.65 (does not meet threshold); Extended matching: Try Modbus RTU feature library, matching degree 0.72; Secondary verification: Send Modbus function code 0x03 command, and the response conforms to the Modbus format; Final confirmation: Load the Modbus RTU protocol parser; Example 4: File service access System event triggered: The file monitoring service detected the creation of a new file, such as C:\data\measurement_20260526_143025.dat; Document feature extraction: Filename parsing: The format is measurement_YYYYMMDD_HHmmss.dat; File size: 1024 bytes; File header: 0x4D 0x45 0x41 0x53 ("MEAS" ASCII); Preliminary result: Matches measurement data file; Data packet acquisition: Read file content and extract the first 100 bytes; Feature extraction: The data length is fixed at 1024 bytes, and the 10th to 12th bytes are CRC16; Protocol matching: 0.85% match with the custom file protocol feature library; Final confirmation: Load file protocol parser; Example 5: HTTP API Access System event trigger: Scheduled task triggers API polling; API Request: Send a GET request to a configured address such as http: / / 192.168.1.100:8080 / api / v1 / device / status; Response message collection: Received a JSON format response {"device_id":"DEV001","device_type":"OSCILLOSCOPE","data":"..."}; Feature extraction: Response format: JSON; Device type field: device_type; Data field: data; Preliminary result: Matches HTTP API interface; Protocol matching: Match the protocol type based on the device_type field value; Final confirmation: The corresponding API interface documentation standard is loaded and parsed; Through the aforementioned specific identification algorithms / mechanisms, automatic identification and protocol adaptation of cross-platform and multi-type instruments and equipment are achieved, avoiding the problem of manual configuration of protocol types in existing technologies, and improving the intelligence level and efficiency of data access.

[0132] ⑦ Zero-copy data transfer mechanism This invention employs a zero-copy data transfer mechanism to avoid unnecessary memory copying operations during protocol parsing, ensuring that the single-core processor utilization does not exceed 15% when processing 10,000 measurement messages per second, and guaranteeing that the end-to-end latency of data acquisition and processing remains stable at the millisecond level. Through a compile-time protocol format verification mechanism, type consistency verification of the protocol parsing logic is performed during the compilation phase before system deployment, eliminating parsing errors caused by protocol format mismatches at runtime. A high-performance computing engine ensures statistical accuracy, achieving tens of millions of protocol unpacking operations per second, providing real-time, high-precision data input.

[0133] ⑧ Error Recovery The protocol parsing of this invention employs a sliding window frame synchronization recovery mechanism. When serial communication generates garbled characters due to electromagnetic interference, static electricity, or a momentary power outage, the parser, upon detecting that the current byte sequence does not conform to any known frame format, does not immediately report an error and exit. Instead, it slides the reading window one byte forward and retryes frame header matching until a valid frame start position is found or the maximum number of retries is exceeded. This mechanism ensures that communication anomalies in a single gauge do not affect the normal acquisition of other gauges. The acquisition service automatically recovers when encountering communication garbled characters, without requiring manual intervention to restart.

[0134] For the protocol management layer, this architecture manages device and tool protocols, serves as the engine algorithm management platform, and retains system scalability modules. It performs unified concurrent scheduling, algorithm adaptation, and identity recognition, and through data queries with the system database of electronic instrument and equipment records, it implements modules such as equipment record management and legality verification, raw data preservation and hash fingerprinting, and standardized processing of measurement values.

[0135] The standardized data processing encapsulation layer is one of the core components of the invention algorithm. It receives the parsed measurement data transmitted by the protocol algorithm engine in the previous step, and performs standardized processing on heterogeneous data from different manufacturers, platforms, and devices (e.g., hexadecimal floating-point numbers from manufacturer A, ASCII strings from manufacturer B, etc.), transforming them into a standardized and clean structure.

[0136] 1. Processing Mechanism The system has built a large number of binary bit manipulation tools to process data from various brands' custom proprietary protocols (such as various industrial instruments and equipment). During processing, it preserves the original accuracy, ensuring that important data from lean measurements are not discarded, thus preventing errors. The processed data is then converted into standardized data encapsulation, packaged into a standardized data encoding format, and sent to the buffer processing layer.

[0137] The raw bytes captured in real time are parsed locally and encapsulated into standardized structured data units, which are then written to a persistent message buffer queue to ensure zero-loss data storage during high-frequency industrial data acquisition.

[0138] 2. Standardized Measurement Data Unit Structure Definition (1) Required fields (must be included in every record) First, there are data traceability identifiers, including a record identifier that uniquely identifies this record and a device identifier that uniquely identifies the device from which the data originated. Second, there is measurement result information, including the measurement value after protocol parsing and its corresponding unit of measurement. Third, there is time and integrity proof, including a data reception timestamp with nanosecond precision and a hash fingerprint value calculated from the original data frame; both together constitute proof of the immutability of this measurement data. Fourth, there is a data quality marker, indicating the verification status of this data. These four types of information constitute the minimum complete set of standardized measurement data units. Downstream functional modules consume data based on this minimum complete set without needing to access the original data frame or re-execute protocol parsing.

[0139] (2) Optional fields When the system is configured with production context information, the standardized measurement data unit also needs to be supplemented with context fields such as product identifier, task identifier, process node code, operator identifier, inspection standard parameters, and judgment result to form an extended data unit, which is used to support the construction of the entire process data chain.

[0140] Furthermore, in industrial scenarios, dozens of sensors and a dozen data acquisition workstations may be connected simultaneously, resulting in high-frequency and out-of-order data, requiring guarantees against packet loss and low latency. Considering the high concurrency and high availability pressure in industrial settings, this invention constructs an asynchronous buffer architecture that decouples data acquisition and storage. The core of this architecture lies in its reactive / streaming approach, ensuring that high-frequency data is not lost.

[0141] Specifically, this invention employs a publish-subscribe broadcast mechanism to achieve real-time multi-channel distribution of measurement data. After data is written to the buffer queue, the system simultaneously broadcasts data update notifications to multiple subscribers. Each subscriber (including the real-time dashboard display module, quality analysis module, alarm module, etc.) consumes data independently without affecting others. Adding a new subscriber does not require modification to the acquisition layer code; it only needs to subscribe to the corresponding data topic to receive data, achieving complete decoupling between the acquisition layer and the consumption layer. This mechanism ensures that the delay from the completion of measurement data acquisition to the receipt of notifications by downstream modules does not exceed 50 milliseconds.

[0142] This invention employs a completely decoupled design between the acquisition layer and the business layer. The acquisition module is only responsible for receiving, sealing, and queuing raw data, without containing any business logic. The business module only consumes standardized data from the buffer queue and does not directly access the hardware interface. The two layers of code can be developed, deployed, and upgraded independently; a failure in one layer does not affect the normal operation of the other. Specifically, the system sets up a persistent message buffer queue between the hardware data acquisition layer and the data storage layer. The acquisition layer writes the raw measurement data to the buffer queue and returns immediately without waiting for the storage layer to complete processing. The storage layer asynchronously consumes data from the buffer queue and writes it to persistent storage.

[0143] The buffer queue employs a disk persistence mechanism. Data written to the buffer queue is considered safe; even if the backend storage service is temporarily unavailable, the data in the buffer queue will not be lost and will automatically resume consumption once the storage service is restored. This architecture fundamentally decouples the acquisition rate from the storage rate, enabling the system to guarantee zero data loss in high-frequency industrial acquisition scenarios. It achieves millisecond-level real-time data acquisition and asynchronous reporting, fundamentally solving the three most troublesome problems in industrial measurement: stability, real-time performance, and complexity.

[0144] Existing industrial measurement systems typically employ a synchronous request-response architecture, where data acquisition and data storage operations are performed serially along the same execution path. The acquisition module remains in a waiting state before writing data to the database. When multiple measuring instruments generate measurement data simultaneously, the database write operation becomes a system bottleneck, leading to a backlog in the acquisition queue and, in severe cases, data loss. Furthermore, existing systems often write measurement data directly to transaction tables in relational databases. Each write triggers an index update and transaction commit, resulting in severe database lock contention in high-frequency write scenarios. Write latency increases linearly with concurrency, failing to meet the real-time requirements of industrial environments.

[0145] The persistent storage layer of this invention employs a time-series optimized relational storage structure. Addressing the characteristics of high-frequency writing, time-series querying, and historical data backtracking in industrial measurement data, the storage layer uses a partitioned table structure with timestamps as the primary index. It automatically partitions data by time range, allowing historical data queries to scan only the corresponding time partition without requiring a full table scan. The storage layer simultaneously maintains device identifier and product identifier indexes, supporting fast retrieval by device or product. This storage structure ensures that, with a cumulative storage of no less than 100 million measurement records, the response time for a single traceability query does not exceed 2 seconds.

[0146] Based on the aforementioned asynchronous buffer processing layer, this invention eliminates the impact of garbage collection pauses on real-time data acquisition through a deterministic memory management mechanism. In industrial scenarios where the system runs continuously for over 72 hours, no service interruptions due to memory management occur. Through the multi-replica persistence mechanism of the buffer queue, even if a single storage node fails, the data flow remains uninterrupted. Upon recovery of the failed node, data consumption automatically resumes from the breakpoint without loss of any measurement data. Furthermore, by utilizing the sequential disk write mechanism of the buffer queue, leveraging the near-memory write performance of disk sequential writes, the system's persistent throughput can reach at least 1 million measurement records per second, meeting the high-frequency acquisition needs of large-scale industrial environments. Simultaneously, most logical errors in protocol parsing are eliminated during the compilation phase. The system's decoupling mechanism ensures that the acquisition code does not need to know about the business logic code, allowing each part to perform its function independently. This prevents a single undecoupled logical problem from causing the entire system to crash or freeze.

[0147] For the quality analysis and data output layer, automatic cleaning and asynchronous writing logic for measurement data have been completed. Standardized measurement data units contain necessary fields uniformly defined within the system, and downstream modules consume data based on the same data unit specification. At the underlying level, verification and sliding window denoising are implemented to ensure that high-quality and uniform standard data enters the database.

[0148] 1. Main calling modules (1) Storage module: Calls storage logic to write to the time-series database. (2) Judgment module: Calls the product process standard module to make real-time judgments on the measurement data. (3) Analysis module: Calls the SPC algorithm to perform quality analysis, graphic drawing, CPK and other index calculations on the client and web page. Pushes to the large screen, etc., for real-time monitoring. (4) Early warning and notification module: According to user settings, if an abnormality, defect or other conditions are judged, a notification signal, API alarm command, etc. are sent. (5) System transmission: Data can be packaged and transmitted to other management and business systems to solve the problem of measurement data being difficult to transmit, integrate and share.

[0149] 2. Quality Analysis Engine The quality analysis engine performs analysis based on standardized raw measurement data after unified access. Since the data source has been verified by the device and its originality, authenticity, and accuracy are guaranteed, and it carries time-series timestamps, the analysis conclusions are supported by a complete data trust chain. Although the algorithms for key indicators and charts in quality analysis are open industry standards, most existing domestic systems directly use or embed foreign software technology packages in their plugins without optimizing the analysis algorithms, resulting in limitations such as low analysis efficiency, rigid functions, and limited dimensions.

[0150] The core innovation of this invention lies in the automated analysis process based on raw data. Because the measured values ​​inherently possess a time sequence, the order of the analysis subgroups cannot be changed. The order and changes of the data and subgroups directly determine the trend and controllability of the analysis results, making it extremely important during the analysis process. This process is handled by the system taking the actual timestamp order and automatically performing calculations to ensure the reliability and accuracy of the results. The quality analysis module will be described in detail below.

[0151] Because the raw data is complete and comprehensive, the system can perform rapid analysis from multiple dimensions, such as product, task, and time range, with flexible and user-friendly operation. The system supports real-time analysis of single tasks / single products or multiple tasks / multiple products, as well as historical inspection data analysis with custom conditions. Historical analysis allows for comprehensive analysis of inspection parameters for specific processes over a given time range. It filters measurement data within a specified product, process, inspection parameter, and time range based on selected conditions, calculates key indicators such as process capability indices, and generates analytical charts. The specific data flow is as follows: To filter data within a specified range, the first step is to determine the type of measurement data. Different types require different analysis methods and algorithms. The invention's analysis results output includes key data dashboard indicators and multiple analysis charts.

[0152] When the data is attribute-based, the system provides calculations such as the non-conformance rate. When the data is numerical, the system first extracts the measurement data into an array according to the settings, similar to a dataset: D = {x1, x2, ..., x...} n (n is the sample size), query the process standard data to obtain the calculation benchmark for the analysis indicators.

[0153] ① Process data, such as standard deviation, mean, maximum value, minimum value, etc.

[0154] ② Overall capability: Based on the subgroup size selected by the user, the overall process variation is captured as a variable input, including the variation between subgroups. Capability indicators for evaluating overall capability include standard deviation, PP, PPL, PPU, PPK, PPM, etc.

[0155] ③ Within-group capability: The algorithm calculates within-group capability, i.e., the actual performance within a subgroup, evaluating the relationship between the expanded process data and specification limits. This analysis indicates whether the process is centered and has reached the target value. It includes within-group capability rating, within-group standard deviation, CP, CPL, CPU, CPK, and PPM.

[0156] ④ Performance dashboard: upper and lower limits of PPM (observational, overall, and intra-group) specifications for different types, calculate the probability of non-conforming products in each dimension, and conduct quality control at different time ranges and levels to ensure that quality standards are met and costs and efficiency are optimized during the production process.

[0157] ⑤ The system can simultaneously output 8 types of analysis charts, such as Figure 3 As shown, it includes area control chart SPC, process capability CPA chart (histogram of normal fit), pass rate chart, run chart, X-bar-R control chart (mean, range), X-bar-S control chart (mean, standard deviation), etc.

[0158] On the other hand, embodiments of the present invention also provide a system for quality analysis of raw measurement data from measuring instruments, which is used to perform the above-described method. This system includes multiple functional modules, specifically: The protocol adaptation engine module is used to automatically identify the interface type and communication protocol of the connected measuring instruments through a pre-deployed dynamic protocol adaptation engine, and call the adapter that matches the interface type and communication protocol to receive the raw data frames sent by the measuring instruments. The original data preservation module is used to write the complete original byte sequence into a buffer and perform a one-way hash operation on the original byte sequence to generate a data integrity fingerprint before receiving the original data frame and performing any parsing operation on the original data frame. The equipment verification module is used to extract the unique equipment identifier of the measuring instrument, and to match and verify the unique equipment identifier according to the pre-established equipment archive. If the match fails, the subsequently received data frames are discarded. The standardization processing module is used to perform protocol parsing on the verified original data frame to extract measurement values, and encapsulate the measurement values, the original byte sequence, the data integrity fingerprint, the device unique identifier and the receiving timestamp into a standardized measurement data unit. The quality analysis module is used to read the standardized measurement data unit according to the sample range specified by the user instruction, execute the quality analysis algorithm, and generate quality analysis results.

[0159] In an exemplary hardware implementation, the system can be represented as an electronic device. This electronic device includes a processor, such as an industrial-grade ARM-based processor or an x86-based central processing unit, memory including random access memory and read-only memory, and multiple hardware communication interfaces, such as a Bluetooth module, a USB host controller, and a UART serial port controller. The memory stores a computer program. When the processor executes the computer program, it instantiates the aforementioned functional modules, including: a protocol adaptation engine module, a raw data preservation module, a device verification module, a standardization processing module, and a quality analysis module. The operational logic of these modules corresponds to S1 to S5 in the aforementioned method implementation, and will not be elaborated further here. The computer program can also be stored in a computer-readable storage medium, such as a flash drive or solid-state drive, for distribution or deployment.

[0160] Through the above specific implementation methods, those skilled in the art can clearly understand that the technical solution provided by the embodiments of the present invention effectively solves the fundamental problems in the prior art, such as fragmented access to measuring instrument data, lack of data authenticity guarantee, and unknown device identity, through a series of mechanisms such as pure software protocol adaptation, immediate sealing upon receipt, and device file verification. It achieves highly reliable, cross-platform, real-time unified access and analysis of quality data, and has significant progress and practical value.

[0161] Specifically, this invention solves the problem of inconsistent access for multi-brand, multi-interface, and multi-protocol measuring instruments by automatically identifying interface types and communication protocols through a pre-deployed dynamic protocol adaptation engine and calling the matching adapter to receive raw data frames. This eliminates data silos and reduces the hardware cost and complexity of system deployment by eliminating the need for dedicated hardware acquisition boxes or drivers. Furthermore, by writing the raw byte sequence into a buffer and generating a data integrity fingerprint before parsing, this invention addresses the issue of easily tampered raw measurement data and the inability to guarantee its authenticity during transmission and processing. This ensures that the data stored in the system is completely consistent with the actual output of the measuring instruments, providing irrefutable original evidence for subsequent quality analysis. Finally, by extracting the unique device identifier and performing matching verification based on a pre-established device database, discarding subsequent data frames if the matching fails, this invention solves the problem of unreliable data due to unidentifiable device identities, expired calibration status, or unauthorized device access, achieving proactive prevention from the data source. Finally, by encapsulating measurement values, raw byte sequences, data integrity fingerprints, unique device identifiers, and timestamps into standardized measurement data units and performing quality analysis, this invention solves the problem of the separation between raw data and quality analysis, and the low reliability of analysis conclusions, achieving automated analysis based on real and traceable raw data.

[0162] This invention improves the integrity and reliability of measurement data, reduces errors and management costs caused by manual intervention, and enhances the real-time automation level of quality analysis and the scientific rigor and reliability of analytical conclusions.

[0163] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for quality analysis of raw measurement data from measuring instruments, characterized in that, include: S1: Through a pre-deployed dynamic protocol adaptation engine, automatically identify the interface type and communication protocol of the connected measuring instrument, and call the adapter that matches the interface type and communication protocol to receive the raw data frames sent by the measuring instrument. S2: Before receiving the original data frame and performing any parsing operation on the original data frame, write the complete original byte sequence into the buffer and perform a one-way hash operation on the original byte sequence to generate a data integrity fingerprint; S3: Extract the unique identifier of the measuring instrument, and match and verify the unique identifier of the instrument according to the pre-established equipment archive. If the match fails, discard the subsequently received data frames. S4: Perform protocol parsing on the verified original data frame to extract the measurement values, and encapsulate the measurement values, the original byte sequence, the data integrity fingerprint, the device unique identifier, and the receiving timestamp into a standardized measurement data unit; S5: Based on the sample range specified by the user instruction, read the standardized measurement data unit and execute the quality analysis algorithm to generate quality analysis results.

2. The method for quality analysis of raw measurement data of measuring instruments according to claim 1, characterized in that, In S1, the dynamic protocol adaptation engine completes the device discovery, connection and data reading of the measuring instrument in user space by calling the native hardware access interface function of the operating system. The interface types include any one or more of the following: serial port, USB interface, industrial fieldbus interface, Bluetooth interface and Wi-Fi interface, file monitoring interface and application programming interface; The dynamic protocol adaptation engine automatically identifies the interface type and communication protocol through the following steps: The port identification information of the device when it is connected is collected to construct a port feature vector; the port identification information includes any one or more of the following: port number, port type, device manufacturer identifier, product identifier, baud rate configuration, data bits, stop bits, and parity bits. Based on a pre-defined port feature matching rule base, a preliminary judgment is made to determine the candidate interface type; For devices initially identified as serial or Bluetooth, handshake messages or broadcast packet data are collected, and message feature vectors are extracted. The message feature vectors include any one or more of the following: message header byte sequence, data length distribution pattern, command code frequency, verification algorithm type, and response delay.

3. The method for quality analysis of raw measurement data of measuring instruments according to claim 2, characterized in that, The dynamic protocol adaptation engine also performs the following steps: The extracted message feature vectors are compared with the protocol feature templates in the pre-established protocol feature library to calculate similarity. When the calculated similarity is greater than a preset threshold, the current protocol is identified as the target protocol, and secondary verification is performed. The secondary verification includes: sending a standard query command to the device, verifying whether the response format conforms to the protocol specification, and checking the device information field in the response; When the secondary verification passes, the final protocol type is confirmed; The preset threshold is 0.75; the protocol feature library includes feature templates for custom manufacturer protocols, Modbus RTU protocols, HID protocols, and custom Bluetooth protocols; each feature template includes message header features, data length range, verification algorithm type, and typical command code information.

4. The method for quality analysis of raw measurement data of measuring instruments according to claim 1, characterized in that, In step S2, the original byte sequence and the data integrity fingerprint are stored together as two fields in the same storage record. After the protocol parsing is completed in step S4, the parsed measurement value, the original byte sequence, and the data integrity fingerprint are stored in the same record. When it is necessary to verify the correctness of the measured value, the original byte sequence is read from storage and the protocol parsing is re-executed. The re-parsed value is then compared with the stored measured value.

5. The method for quality analysis of raw measurement data of measuring instruments according to claim 1, characterized in that, In step S3, the device database contains unique device identifiers, registration status, and calibration validity information; the matching verification includes: The system checks whether the unique identifier of the device exists in the device database. If it exists, it further verifies whether the registration status is registered and whether the calibration validity period is valid. If the unique identifier of the device does not exist, is not registered, or the calibration validity period has expired, it is determined that the match has failed, and the reason for rejection is recorded. Subsequent data frames received from the device are discarded according to the reason for rejection.

6. The method for quality analysis of raw measurement data of measuring instruments according to claim 1, characterized in that, The standardized measurement data unit encapsulated in S4 is a structured data object, which contains at least the following fields: The record identifier field is used to uniquely identify this measurement record; The device identifier field is used to store the unique identifier of the device; The measurement value field is used to store the measurement value and its unit of measurement; The timestamp field is used to store the received timestamp of the measurement data, which is a high-precision absolute time value. The integrity fingerprint field is used to store the data integrity fingerprint; The quality tag field is used to store the verification status of this data.

7. The method for quality analysis of raw measurement data of measuring instruments according to claim 1, characterized in that, The quality analysis algorithm in S5 includes a process capability analysis algorithm or a statistical process control chart drawing algorithm.

8. The method for quality analysis of raw measurement data of measuring instruments according to claim 1, characterized in that, The method further includes a data buffer distribution step between S4 and S5: Write the encapsulated standardized measurement data unit into a persistent message queue and publish the data unit to the specified topic of the message queue; Multiple downstream modules subscribe to the topic, and when the message queue receives a new data unit, it sends a copy of the data unit to each subscriber respectively; Specifically, the write operation to the message queue is executed asynchronously with the processing operation of the downstream module. Once the write operation is completed, it returns immediately without waiting for the processing result of the downstream module.

9. The method for quality analysis of raw measurement data of measuring instruments according to claim 1, characterized in that, The protocol parsing in S4 employs a sliding window frame synchronization recovery mechanism, including: The parser maintains byte index pointers and reads the original byte sequence sequentially; When a frame header identifier of a known frame format cannot be matched at the current index position, the index pointer is moved one byte forward, and the matching of the frame header is retried from the new position. Repeat the above movement operation until a valid frame header is matched or the number of movements exceeds the preset threshold. If the threshold is exceeded, discard the current data frame and reset the parser state.

10. A system for quality analysis of raw measurement data from measuring instruments, characterized in that, include: The protocol adaptation engine module is used to automatically identify the interface type and communication protocol of the connected measuring instruments through a pre-deployed dynamic protocol adaptation engine, and call the adapter that matches the interface type and communication protocol to receive the raw data frames sent by the measuring instruments. The original data preservation module is used to write the complete original byte sequence into a buffer and perform a one-way hash operation on the original byte sequence to generate a data integrity fingerprint before receiving the original data frame and performing any parsing operation on the original data frame. The equipment verification module is used to extract the unique equipment identifier of the measuring instrument, and to match and verify the unique equipment identifier according to the pre-established equipment archive. If the match fails, the subsequently received data frames are discarded. The standardization processing module is used to perform protocol parsing on the verified original data frame to extract measurement values, and encapsulate the measurement values, the original byte sequence, the data integrity fingerprint, the device unique identifier and the receiving timestamp into a standardized measurement data unit. The quality analysis module is used to read the standardized measurement data unit according to the sample range specified by the user instruction, execute the quality analysis algorithm, and generate quality analysis results.

Images