An adaptive communication protocol system and implementation method for industrial fixture management

Abstract

The present application belongs to the technical field of jig management, and provides a self-adaptive communication protocol system and implementation method for industrial jig management, which comprises: a control box in communication connection with a jig and sensing components and / or executing components; a server in communication with the control box through an industrial network, for real-name data acquisition, permission closed-loop management, parameter change audit traceability. The communication message adopts a structured frame structure, including a frame start identifier, protocol negotiation information, a message identifier, a function code, an operator identity field, field description information, a variable-length service data payload, network address information, an integrity check field, and a frame end identifier. The function code uniquely indicates a service domain and a service operation type; the payload contains a self-description field. The server maintains a function code register and a field template, the field template defines a field identifier, a field type, a length rule, and optional attributes; the control box frames and sends according to the field template, and the server parses and returns a response message. The present application can solve the problems of data fragmentation, difficulty in real-time tracing, extensive permission control, and non-transparent parameter change in industrial field jig management.

Description

Technical Field

[0001] This invention relates to the field of jig management technology, and in particular to an adaptive communication protocol system and implementation method for industrial jig management. Background Technology

[0002] In precision manufacturing workshops, jigs are critical production tools, and their operational status, work data, operator information, and lifecycle management directly impact product quality and production efficiency. However, traditional jig management often relies on paper records or isolated local systems, making it difficult to unify and aggregate production and quality data, and preventing the formation of a closed loop of on-site information. This leads to problems such as difficulty in real-time traceability, lax access control, and a lack of transparent recording of parameter changes, affecting the level of management refinement and the efficiency of anomaly location.

[0003] On the other hand, while existing solutions include systems for fixture management, some are more focused on the management of design documents or change processes, making it difficult to cover the collection and interaction specifications of real-time operational data on the production site, and failing to meet the real-name traceability requirements for key processes. At the same time, it is also common to develop independent communication programs or private protocols for different fixture functions, which easily leads to protocol fragmentation and incompatibility. Adding new collection types or expanding fields often requires modifying the overall communication architecture, resulting in high maintenance costs, slow iteration, and high expansion risks. Summary of the Invention

[0004] In view of the above technical problems, the present invention provides an adaptive communication protocol system and implementation method for industrial fixture management. It aims to address the problems of data fragmentation, difficulty in real-time traceability, coarse access control and opaque parameter changes in industrial fixture management. It provides a communication mechanism that can support unified access, flexible expansion and reliable transmission of fixture field data and management instructions in complex industrial network environments, thereby improving the digital control and traceability capabilities of the entire fixture use process.

[0005] Other features and advantages of this disclosure will become apparent from the following detailed description, or may be learned in part from practice of this disclosure.

[0006] This invention discloses an adaptive communication protocol system for industrial fixture management, comprising: a control box deployed in the industrial field and communicatively connected to the fixture, wherein the control box is also communicatively connected to the fixture's sensing components and / or actuating components; and a server communicating with the control box via an industrial network; wherein the control box and the server communicate bidirectionally according to a communication protocol to achieve real-name data collection, closed-loop access control, and parameter change auditing and traceability for the fixture usage process; the communication protocol specifies that communication messages adopt a structured frame structure, wherein the frame structure includes at least, in transmission order, a frame start identifier, protocol negotiation information, a message identifier, a function code, an operator identity field, field description information, and a variable-length business data payload. The system includes network address information, integrity verification fields, and frame end identifiers; the function code uniquely indicates the service domain and service operation type; the variable-length service data payload includes several self-describing fields corresponding to the function code; the server is configured to establish a function code registry and maintain the mapping relationship between the function code and field templates, the field templates defining the field identifier, field type, length rules, and required and optional attributes of the self-describing fields corresponding to the function code; the control box is configured to generate the self-describing fields based on the field templates and assemble the communication message to send to the server; the server is configured to parse the communication message based on the field templates and return a response message containing the processing result.

[0007] Furthermore, the function code adopts a hierarchical encoding mechanism, which includes a domain identifier for representing a business domain and an operation identifier for representing a business operation. The server establishes isolated namespaces in the function code registry using the domain identifier and allocates non-conflicting sets of operation identifiers to different namespaces. The field description information carries a field template version identifier corresponding to the function code, so that the server can determine the parsing rules based on the field template version identifier and realize cross-version field evolution when parsing the communication message.

[0008] Furthermore, the server includes a template management module, which is configured to allow the control box to retrieve the registry of the function code and the field template corresponding to the function code registry when the control box goes online or a session is established. When the field template is updated, the module pushes incremental templates or template failure information to the control box through a configuration channel and selectively applies the update to different control boxes according to a gray-scale activation strategy. The control box includes a template caching module to cache the field templates and triggers a re-retrieval when the cache is missing or expired. This enables the control box to automatically assemble frames based on the updated field templates to access new service data types without changing the frame structure.

[0009] Furthermore, the protocol negotiation information includes the protocol version candidate set and capability list declared by the control box. The server is configured to select a session version according to the protocol version candidate set and return a list of required fields matching the session version and an explanation of incompatible items to the control box. When the server detects an unknown function code, an unknown field identifier, or a field template version identifier that does not match the session version while parsing the communication message, the server performs the following actions according to a preset compatibility policy: ignore the unknown field and continue processing the known field, fall back to the compatible field template version, or refuse to accept the message and carry the reason for rejection and correction guidance in the response message, so as to realize the protocol negotiation, downgrade, and executable compatibility processing rules.

[0010] Furthermore, the variable-length service data payload is composed of several self-describing fields. Each self-describing field includes at least a field identifier, a field length, and a field value. The field description information includes a field bitmap, an extension area offset, or a combination thereof. The field description information is used to indicate the existence, order, or segmentation position of the self-describing field in the variable-length service data payload. When writing the field value, the control box performs escaping processing on byte sequences that conflict with the frame start identifier or the frame end identifier. Both the server and the control box use a frame synchronization recovery state machine based on the frame start identifier, the field length, and the integrity verification field at the receiving end to achieve fast alignment under noise interference, abnormal frame discarding, and subsequent valid frame recovery.

[0011] Furthermore, the message identifier includes a unique sequence identifier or random identifier within the session, the integrity verification field includes a cyclic redundancy check value, and the communication message also includes an authentication field, which is any one or a combination of a message authentication code field and a digital signature field; the server is configured to perform error detection and anti-tampering verification based on the cyclic redundancy check value and the authentication field when receiving the communication message, and to perform replay protection and idempotent deduplication processing based on the message identifier; the response message carries the message identifier corresponding to the communication message and the acceptance result, so that the control box can complete confirmation, retransmission decision and audit accountability accordingly.

[0012] Furthermore, the control box includes a transmission scheduling module and an offline cache queue. The transmission scheduling module is configured to map the service events to be sent to different transmission levels according to preset priorities and enqueue them separately. For high-priority events, an immediate transmission strategy is adopted, and for low-priority events, a batch encapsulation strategy is adopted. When the network is unreachable or the session is abnormal, the offline cache queue persistently caches the communication messages and performs deduplication and retransmission according to the message identifier after the network is restored. If the acknowledgment message is not received, the message is retransmitted according to the backoff and retransmission strategy.

[0013] Furthermore, the function code includes an identification reporting function code for uploading workpiece identification information. The self-description field corresponding to the identification reporting function code includes at least an original identification field, a normalized identification field, a reader type field, and a reader quality index field. When generating the normalized identification field, the control box executes an identification normalization process. This normalization process includes: filtering noise characters or unifying separators in the original identification field; verifying the original identification field for check bits or length validity according to configurable verification rules; padding, trimming, or replacing the original identification field according to configurable prefix and suffix rules; and mapping the original identification field to a unified format according to configurable pattern matching rules, so that the server can perform cross-reader consistency tracing based on the normalized identification field and evaluate the collection reliability based on the reader quality index field.

[0014] Furthermore, the function codes also include a tool data function code for uploading tool operation data, a lifespan reporting function code for uploading fixture lifespan-related data, and a change audit function code for uploading parameter configuration modification records. The variable-length business data payload corresponding to the tool data function code includes a tool identification field, a control unit identification field, a workstation identification field, and a process parameter set field. The process parameter set field consists of several parameter self-description fields, and each parameter self-description field includes at least a parameter identifier, a parameter unit description, a parameter scale description, a parameter standard range, a parameter tolerance range, a parameter actual value, and a parameter judgment result. The server is configured to send a process parameter template associated with the product type or workstation type to the control box, enabling the control box to automatically switch the set of parameter self-description fields based on the process parameter template and generate a parameter based on the parameter standard range and the parameter tolerance range. The parameter determination result; the variable-length business data payload corresponding to the lifespan reporting function code includes job count information, peak process load information, environmental condition information, alarm statistics information, and maintenance record summary information. The server is configured to comprehensively evaluate the aforementioned information according to preset multi-factor evaluation rules to generate fixture health indicators, and return the remaining lifespan range and suggested maintenance actions in the response message; the variable-length business data payload corresponding to the change audit function code includes change item identifier, old value before change, new value after change, operator identity, change reason code, and approval credential field. After accepting the change, the server sends the effective time and rollback policy back to the control box and issues a rollback instruction when needed to restore the old value before change according to the rollback policy. At the same time, the server and the control box respectively record change link logs containing the approval credential field and the message identifier to form a closed-loop permission and two-way audit.

[0015] According to another aspect of the present invention, an adaptive communication protocol implementation method for industrial fixture management is provided, applied between a control box and a server, to implement the aforementioned adaptive communication protocol system for industrial fixture management, the method comprising: When the control box establishes a session with the server, it sends a handshake message to declare the set of supported protocol versions and the list of capabilities, and receives and caches the session version, the list of required fields, and the field templates associated with the function codes returned by the server. In response to business events, including card swipe, sensor data readiness, timing, alarm, or parameter configuration change, determine the function code corresponding to the business event and the set of fields matching the function code from the cached field template; Collect business data associated with the business event and operator identity information, and convert the business data into a set of self-descriptive fields consisting of field identifier, field length and field value according to the field template. Perform noise filtering, verification, prefix and suffix rule processing and pattern matching mapping on the workpiece identifier to generate a normalized identifier, and write the original identifier, the normalized identifier and the read head quality index into the corresponding self-descriptive fields. Generate a communication message frame, write a frame start identifier and a frame end identifier, and sequentially write the session version or its identifier, message identifier, function code, operator identity information, field description information, self-description field set, network address information and integrity check field between the frame start identifier and the frame end identifier, and perform escaping processing on byte sequences that conflict with the frame start identifier or the frame end identifier; The communication messages are added to the offline cache queue according to a preset priority and sent immediately or in batches according to the sending scheduling strategy. If no response message containing the message identifier is received, the message is retransmitted according to the backoff and retransmission strategy and retransmitted after the network is restored according to the message identifier. The response message is parsed to obtain the acceptance result, reason for missing template, downgrade guidance, effective time, rollback strategy or maintenance suggestion action, and the local status of the control box, execution instruction output, application parameter configuration or rollback command are updated accordingly, and a two-way audit log is recorded.

[0016] The technical solution disclosed herein has the following beneficial effects: Compared with existing technologies, this disclosure can carry multiple types of business data and management information for fixture management with a unified communication standard, enabling standardized aggregation and interaction of data from different sources under the same system, reducing the information silo problem caused by system fragmentation; at the same time, through an expansion mechanism oriented towards the evolution needs of industrial sites, new businesses or new fields can be integrated into the existing system at a lower cost of modification, thereby improving the continuous evolution capability and deployment efficiency of the fixture management system.

[0017] Furthermore, this system emphasizes the systematic improvement of data standardization and traceability capabilities. By consistently linking operational data with operator information, fixture identification, and other data, it enables traceability of production operations and quality data. Combined with communication response and robust design, it improves the reliability of data transmission and the certainty of anomaly handling in industrial network environments, thereby supporting subsequent data analysis and intelligent management applications, such as maintenance strategy optimization and refined process control. Attached image description; Figure 1 This is a structural block diagram of the adaptive communication protocol system for industrial fixture management as described in the embodiments of this specification; Figure 2 This is a schematic diagram of the frame structure in the embodiments of this specification. Detailed Implementation

[0019] The exemplary implementation will now be described more fully with reference to the accompanying drawings.

[0020] The accompanying drawings are merely illustrative of this disclosure. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted. It is understood that the scale of the various components in the drawings does not constitute a limitation of this disclosure.

[0021] like Figure 1-2 As shown in the embodiments of this specification, an adaptive communication protocol system for industrial fixture management is provided, including: a control box 101 deployed in the industrial field and communicatively connected to the fixture 100, wherein the control box 101 is also communicatively connected to the sensing components and / or execution components of the fixture 100; and a server 103 communicating with the control box 101 through an industrial network 102; wherein the control box 101 and the server 103 communicate bidirectionally according to a communication protocol to realize real-name data collection, closed-loop permission management, and parameter change audit traceability for the fixture usage process; the communication protocol stipulates that the communication messages adopt a structured frame structure, and the frame structure includes at least a frame start identifier, protocol negotiation information, message identifier, and function code in the transmission order. The system includes: operator identity field, field description information, variable-length service data payload, network address information, integrity verification field, and frame end identifier; function code is used to uniquely indicate the service domain and service operation type; variable-length service data payload includes several self-descriptive fields corresponding to the function code; the server is configured to establish a function code registry and maintain the mapping relationship between function codes and field templates, and the field template is used to define the field identifier, field type, length rules, and required and optional attributes of the self-descriptive fields corresponding to the function codes; the control box is configured to generate self-descriptive fields based on the field templates and assemble them into communication messages to be sent to the server, and the server is configured to parse the communication messages based on the field templates and return a response message containing the processing results.

[0022] This end-to-end closed-loop interaction transforms on-site events into a data chain that can be consistently understood by the system, uniformly stored, and traced, directly alleviating problems such as "data fragmentation, inability to trace in real time, coarse access control, and opaque parameter changes" caused by traditional on-site records. Identity information is transmitted along with business processes as a key context, giving business data a natural real-name attribute, facilitating the linking of production operations and quality data into a replayable traceability chain. Furthermore, the server side sets up clear acceptance and feedback mechanisms for each type of business, returning success or failure and the reason, solidifying "whether it has been confirmed by the system and whether remedial action is needed" into a deterministic result, forming an auditable closed loop from a management perspective. Simultaneously, the protocol's coverage extends beyond production parameters, encompassing the entire process of fixture binding, production data collection, equipment data collection, and management data collection. This allows a single mechanism to connect "personnel access authentication, fixture binding, production data, equipment data, and management data," reducing data silos and maintenance complexity caused by multiple proprietary protocols coexisting.

[0023] The value of structured messages lies in separating a stable framework from an evolving payload: fixed frame boundaries and basic fields provide a clear parsing starting point and consistent transmission semantics for industrial environments, while converging service differences into the variable parts, thus expanding new services without altering the underlying communication link. The text emphasizes the design philosophy of "fixed frame headers and trailers + variable payload and function code-driven," meaning that adding new services only requires defining new function codes and their data formats, adapting to the ever-increasing functional requirements during long-term iterations. This "function code-payload structure" decoupling also brings operational feasibility at the engineering level: when adding scenarios such as equipment anomaly alarm records, the process can be manifested as allocating new function codes, defining payload formats in the protocol, adding corresponding parsing modules to the server, and the control box calling the corresponding message construction function and filling in the content after detecting the event, thereby achieving rapid and standardized deployment.

[0024] The combination of self-describing fields and templated constraints within variable payloads elevates expansion from simply increasing length to a manageable evolution mechanism. Self-describing fields carry structural information through field identifiers and lengths, enabling servers to parse by field identifiers and allowing for the ignoring of unknown fields, thus enhancing backward compatibility and on-demand expansion capabilities. The addition of a "function code—field template / mapping table" distribution and caching mechanism allows control boxes to obtain and cache the latest mapping relationships upon going online. When the server releases new functions, it pushes them through a configuration channel, enabling control boxes to automatically frame according to templates and add new data types without relying on firmware upgrades. This "automatic discovery + gray-scale activation + compatibility detection" management mechanism is closer to the real-world engineering constraints of long-term industrial evolution. Simultaneously, combining message identifiers with response confirmation, idempotent deduplication, and replay protection strategies brings engineering challenges such as network outages, jitter, and duplicate reporting within the controllable scope of the protocol layer, improving field adaptability and data reliability. Combined with message verification and response mechanisms, it can detect transmission errors and ensure communication reliability through explicit feedback.

[0025] In practical operation, the example process demonstrates how this structured design enhances the determinism of parsing: after receiving the data, the server first parses the frame header, version, and function code. Then, based on the length indicator, it accurately extracts the fixture and workpiece identifiers, continues parsing subsequent data areas and storing them in the database, aligning them with process standards, and finally returns a response containing the processing results. This allows the field end to confirm and trigger subsequent actions. This "length indicator + structured format definition" approach also significantly improves data consistency and usability. For example, it allows for fine-grained format constraints on various types of data and association with work cards, fixture identifiers, and time information, thereby forming a full-chain traceability foundation covering production operations and quality data. In one embodiment, the function code adopts a hierarchical encoding mechanism, which includes a domain identifier for representing a business domain and an operation identifier for representing a business operation. The server establishes isolated namespaces in the function code registry based on the domain identifier and allocates a set of non-conflicting operation identifiers to different namespaces. The field description information carries a field template version identifier corresponding to the function code, so that the server can determine the parsing rules based on the field template version identifier when parsing communication messages and realize cross-version field evolution.

[0026] The core value of adopting layered coding and introducing namespaces lies in elevating the expansion capability from simply increasing enumeration values ​​to a manageable, systematic expansion: different business domains are naturally isolated through domain identifiers, avoiding function code conflicts and semantic overlaps when multiple teams or various types of fixtures evolve in parallel, thus reducing the risks of "protocol fragmentation, incompatibility, and maintenance difficulties" from the source; at the same time, the server side establishes isolated namespaces with domain identifiers and allocates sets of non-conflicting operation identifiers, enabling new business launches to be managed, authorized, and published by domain, and new functions only need to be registered in the corresponding namespace without disrupting the parsing and storage logic of existing business domains, thus better aligning with the engineering reality of "continuously increasing multiple functional requirements" in the long-term iteration process of industrial sites.

[0027] The purpose of carrying the field template version identifier in the field description information is to make "how to interpret the payload" explicit, avoiding parsing ambiguities caused by the inability to distinguish between field additions / deletions, changes in field types, or adjustments in field order based solely on the function code. When parsing communication messages, the server first selects the matching parsing rule based on the field template version identifier. Even if the field set of the same function code evolves in different versions, it can still accurately retrieve and store values ​​according to the version. When an unknown function code or a field template is missing, the executable compatibility strategy can clearly take the actions of ignoring, rolling back, or rejecting, and return the reason for the missing template when rejecting. This reduces the hidden quality problems of blind retries at the field end or "incorrect parsing and incorrect storage" of data, further improving the controllability and traceability of cross-version evolution.

[0028] In one embodiment, the server includes a template management module, which is configured to allow the control box to retrieve the registry of function codes and the field templates corresponding to the function code registry when the control box goes online or a session is established. When the field templates are updated, the module pushes incremental templates or template failure information to the control box through a configuration channel and selectively applies the update to different control boxes according to a gray-scale activation strategy. The control box includes a template caching module to cache field templates and triggers a re-retrieval when the cache is missing or expired. This enables the control box to automatically assemble frames based on the updated field templates to access new service data types without changing the frame structure.

[0029] By implementing extended capabilities into an executable management mechanism, new business operations can be transformed from one-time R&D modifications into a controllable configuration evolution: When the field terminal establishes a connection, it first obtains and caches the latest function code mapping table and field templates, so that subsequent framing and parsing no longer rely on hard coding, avoiding hidden quality problems such as "inconsistent field understanding, parsing ambiguity, and data entry drift" when different versions of endpoints coexist in the same workshop; When the server side releases new capabilities, it pushes incremental templates or failure prompts through the configuration channel, enabling the field terminal to directly use the new templates to organize data while keeping the underlying communication framework unchanged. From an engineering perspective, this is equivalent to "firmware upgrade-free extension", which is especially suitable for iterative scenarios in industrial fields where new data acquisition types and management data types are frequently added.

[0030] Introducing canary deployment and compatibility testing significantly reduces the risks of expanded deployment: new templates do not need to be applied to all control boxes at once, but can be selectively deployed to some devices or specific areas, facilitating verification of field integrity, parsing correctness, and server processing stability under real-world conditions; once incompatibility issues such as unregistered or missing templates are detected, the system can reject the application according to a preset policy and return the reason for the missing template, thus exposing the problem at the protocol layer rather than "silently parsing" at the business layer, improving fault location efficiency and preventing dirty data from polluting the tracing process. Simultaneously, cache missing or invalidation triggers a re-fetching, allowing control boxes to automatically recover to an usable state even after network disconnection and reconnection, configuration rollback, or template obsolescence, reducing manual intervention costs and improving on-site adaptability and system continuous evolution capabilities.

[0031] In one embodiment, the protocol negotiation information includes a candidate set of protocol versions and a list of capabilities declared by the control box. The server is configured to select a session version based on the candidate set of protocol versions and return a list of required fields matching the session version and a description of incompatible items to the control box. When the server detects an unknown function code, an unknown field identifier, or a field template version identifier that does not match the session version while parsing a communication message, the server performs the following actions according to a preset compatibility policy: ignore the unknown field and continue processing the known field, fall back to the compatible field template version, or refuse to accept the request and carry the reason for rejection and correction instructions in the response message. This achieves protocol negotiation, downgrading, and executable compatibility processing rules.

[0032] By incorporating version sets and capability declarations into the handshake phase, the semantic boundaries of the protocols available to both parties can be clearly defined at the outset of connection establishment. This avoids situations where the field end sends data in a higher version format while the server misinterprets it using a lower version, or where the server accepts data based on new field requirements while the field end cannot provide them, leading to repeated failures. The capability list can also be used to express optional capabilities such as whether self-description fields are supported, whether certain types of business data reporting are supported, and whether certain confirmation mechanisms are supported. This allows the server to differentiate between control boxes of different models or firmware generations within the same backend system, returning a list of required fields and descriptions of incompatible items in advance. This enables the control box to complete field completion, field trimming, or disabling of unsupported capabilities before sending, improving the success rate of the first communication and reducing the field maintenance pressure during gray-scale upgrades.

[0033] By encapsulating the handling strategies for unknown function codes, unknown field identifiers, and mismatched field template versions into executable rules, compatibility can be transformed from empirical conventions into deterministic processes: when encountering an unknown field, ignoring it and continuing to process known fields reduces the impact of new field deployments on older devices; when a template version mismatch is detected, reverting to a compatible template version ensures stable parsing for the same function in a multi-version environment; and rejecting cases that cannot be safely handled, along with the reason for rejection and correction guidelines, avoids hidden quality risks such as incorrect parsing and incorrect database entry, explicitly exposing problems at the protocol layer for rapid location and correction. This mechanism also supports negotiation and degradation, enabling a smooth transition when the protocol evolves from one version to another, making new feature integration closer to an engineering model of "defining rules and deploying."

[0034] In one embodiment, the variable-length service data payload consists of several self-describing fields. Each self-describing field includes at least a field identifier, a field length, and a field value. The field description information includes a field bitmap, an extension area offset, or a combination thereof. The field description information is used to indicate the existence, order, or segmentation position of the self-describing field in the variable-length service data payload. When writing field values, the control box performs escaping processing on byte sequences that conflict with the frame start identifier or frame end identifier. Both the server and the control box use a frame synchronization recovery state machine based on the frame start identifier, field length, and integrity check field at the receiving end to achieve fast alignment under noise interference, discarding of abnormal frames, and recovery of subsequent valid frames.

[0035] The use of a variable-length payload for self-describing fields transforms business data from "parsing based on fixed locations" to "parsing based on field semantics." This allows for continuous evolution when adding new fields or expanding field sets without requiring a complete overhaul of the existing parsing chain. New field organization rules can be defined within the payload, aligning with the recommendation to "upgrade the length indicator field to a stronger TLV / self-describing field mechanism, with each optional field carrying Type (field identifier) ​​+ Length + Value, allowing the receiver to parse by Type and ignore unknown fields." To ensure both flexible expansion and parsing efficiency, metadata such as field bitmaps or extension area offsets are introduced. This allows the receiver to "first determine which fields exist, then quickly locate the field block by offset," avoiding the overhead of linear field-by-field scanning. Furthermore, this can differentiate between the basic and extended field areas, making field evolution more akin to "on-demand expansion" rather than simply increasing string length.

[0036] In industrial environments where link issues such as noise, packet merging, and truncation are common, the escape / escape processing during the write phase and the frame synchronization recovery mechanism during the receive phase can significantly improve robustness. The role of escaping is to avoid conflicts between the byte sequence in the service data and the frame boundary marker, thereby reducing erroneous frames caused by misjudging the start and end of frames. The frame synchronization recovery state machine achieves fast alignment through the method of "frame header positioning - length reading - verification". When the verification fails or the length is abnormal, the abnormal frame is directly discarded and the state of searching for the frame header is returned, so that subsequent valid frames can continue to be correctly parsed. This type of mechanism is explicitly proposed in the recommendation to illustrate how to quickly recover from noise interference by relying on the frame header, length, and verification, avoiding a description that only stays at the level of conventional message splicing.

[0037] The checksum field serves both as an error detection tool and as a criterion for determining whether a frame is acceptable during synchronization recovery. In practice, a cumulative checksum method can be used: summing the bytes from the frame header to the checksum field and writing the least significant byte into the checksum field. For example, the approach could be to "calculate the cumulative sum from the second byte to the specified end byte, and use the least significant byte as the checksum to fill the specified position".

[0038] The corresponding standardized expression can be written as: ; in, Let N be the unsigned value of the i-th byte of the message, and let N be the sequence number of the last byte covered by the checksum calculation. The least significant bit of the result is written to the checksum field. Combined with the application of length indicators on the parsing side, this allows for the precise extraction of key fields by length before entering the data area to parse specific parameter values ​​and complete database entry and calibration, reducing the probability of misparsing caused by boundary drift. Simultaneously, the inclusion of checksums and a clear acknowledgment mechanism in the message helps improve communication reliability and diagnosability, facilitating rapid location and correction of transmission or format errors in abnormal situations.

[0039] In one embodiment, the message identifier includes a unique sequence identifier or random identifier within the session, the integrity check field includes a cyclic redundancy check value, and the communication message also includes an authentication field, which is any one or a combination of a message authentication code field and a digital signature field. The server is configured to perform error detection and anti-tampering verification based on the cyclic redundancy check value and the authentication field when receiving the communication message, and to perform replay protection and idempotent deduplication based on the message identifier. The response message carries the message identifier corresponding to the communication message and the acceptance result, so that the control box can complete the confirmation, retransmission decision and audit accountability accordingly.

[0040] The value of introducing a unique identifier within a session goes beyond simply "marking a message." More importantly, it brings common industrial issues such as duplicate reporting, network outage retransmission, and duplicate delivery caused by link jitter into a controllable framework. The server can use this identifier as an idempotent key, ensuring that duplicate requests with the same identifier are processed only once and return a consistent result. This avoids side effects such as duplicate data entry, duplicate counting, and duplicate alarms in an engineering environment where "offline caching queues, batch reporting, priority, and network outage retransmission" coexist. It also allows for more aggressive retransmission strategies without introducing data pollution. Furthermore, the processing results carried in the response message can be directly used as the basis for confirmation and subsequent actions at the field end (such as driving indicator lights, updating local status, or recording logs), elevating reliable transmission from "best effort" to "verifiable closed loop."

[0041] In terms of error detection and anti-tampering, Cyclic Redundancy Check (CRC) is suitable for undertaking the basic responsibility of "transmission error detection," while authentication fields are used to elevate "whether the data has been tampered with and whether it comes from a trusted endpoint" to verifiable facts: by introducing sequence numbers / message identifiers in the frame header or key field range, and in conjunction with CRC and message authentication codes or signature fields, it can simultaneously cover three types of risks: link errors, malicious tampering, and replay attacks. Among them, replay protection relies on the server's window management or deduplication table management of message identifiers, which can prevent attackers or abnormal network devices from re-injecting old messages to cause "historical state overwriting / repetitive operations," and put audit accountability on the evidence chain of "who initiated it, what was initiated, whether the server confirmed acceptance, and the reason for failure," thereby enhancing the credibility of real-name traceability and access control loop.

[0042] In one embodiment, the control box includes a transmission scheduling module and an offline buffer queue. The transmission scheduling module is configured to map the service events to be transmitted to different transmission levels according to preset priorities and enqueue them separately. For high-priority events, an immediate transmission strategy is adopted, and for low-priority events, a batch encapsulation strategy is adopted. When the network is unreachable or the session is abnormal, the offline buffer queue persistently buffers the communication packets and performs deduplication and retransmission according to the message identifier after the network is restored. If no acknowledgment packet is received, the packets are retransmitted according to the backoff and retransmission strategy.

[0043] By prioritizing and scheduling business events and combining real-time sending with batch encapsulation, the system can simultaneously ensure the real-time performance of critical events and the bandwidth efficiency of non-critical data on the same industrial network link. This avoids congestion caused by reporting all events in real time and delays in reporting critical information such as alarms and anomalies due to batch processing. This strategy is particularly suitable for scenarios where multiple sources of triggering occur simultaneously, such as card swiping, sensor data readiness, timing, and alarms. It can prioritize limited link resources for events that require rapid loop closure, while aggregated and transmitted statistical and summary data without affecting management objectives. This reduces the number of messages and protocol interaction overhead, thereby improving the overall throughput and stability of the industrial site. Offline persistent caching and deduplication retransmission after network recovery bring engineering challenges such as network outages, jitter, and session anomalies under control: when the network is unreachable, critical messages are reliably saved first, and then idempotent deduplication retransmission is performed according to message identifiers after recovery, which can simultaneously solve two common risks: "missed reports" and "duplicate entries into the database"; combined with retransmission according to the backoff strategy when no response is received, reliable transmission changes from "best effort to send" to "verifiable arrival", and in conjunction with an explicit response mechanism, after the server returns OK / Fail and the reason, the field terminal can use this to drive instructions, update the local status or record logs, forming an auditable confirmation link, further enhancing communication reliability and diagnostics.

[0044] In one embodiment, the function code includes an identification reporting function code for uploading workpiece identification information. The self-descriptive field corresponding to the identification reporting function code includes at least an original identification field, a normalized identification field, a reader type field, and a reader quality index field. The control box executes an identification normalization process when generating the normalized identification field. The identification normalization process includes: filtering noise characters or unifying delimiters in the original identification field; verifying the checksum or length validity of the original identification field according to configurable verification rules; padding, trimming, or replacing the original identification field according to configurable prefix and suffix rules; and mapping the original identification field to a unified format according to configurable pattern matching rules, so that the server can perform cross-reader consistency traceability based on the normalized identification field and evaluate the collection reliability based on the reader quality index field.

[0045] In a field environment with multiple readers operating in parallel, the same workpiece identifier may come from different acquisition channels such as barcodes, RFID, and visual codes. Furthermore, due to factors such as printing quality, light reflection, differences in reader models, and interference noise, the same workpiece may be identified as different strings. Uploading the original value and the normalized value simultaneously can preserve the original evidence for post-event verification and allow the backend to index, associate, and statistically analyze the data in a unified format. This transforms the traceability entry point from "accidental consistency relying on reader output" to "inevitable consistency relying on unified rules," significantly reducing the risk of data discrepancies across workstations and equipment.

[0046] The step-by-step design of the standardized process can address "reading errors" and "rule differences" separately: First, noise reduction and delimiter standardization are performed to reduce surface differences caused by barcode scanner line breaks, invisible characters, or mixed delimiters; then, check bits or length validity are verified according to configurable verification rules, ensuring that obviously erroneous identifiers are identified and corrected before entering the traceability chain, preventing cascading pollution after erroneous identifiers are written to the database; subsequently, prefix / suffix completion, trimming, or replacement is performed according to prefix / suffix rules, resolving prefix / suffix differences caused by different supply batches and workstation habits; finally, configurable regular expressions or pattern matching are used to map to a unified format, enabling consistent retrieval and association of old and new coding systems or multi-product family codes within the same traceability system. This combination of "noise reduction, check bits, prefix / suffix rules, and configurable regular expressions" allows rule evolution to remain at the configuration layer rather than being fixed in the code, facilitating rapid adjustments based on on-site changes.

[0047] By reporting the read head type and read head quality indicators along with the identification, the reliability of the data collection can be explicitly quantified and incorporated into the traceability loop. When quality anomalies or disputes arise during traceability, the backend can determine whether the problem is concentrated in a certain type of data collection device based on the read head type. Based on indicators such as confidence level and number of rereads, marginal data that is "barely read" can be identified and differentiated strategies can be adopted, such as prompting for rescanning, reducing the weight of the record in the automatic judgment, or triggering manual review. This transforms the risks that were originally hidden at the data collection end into variables that can be perceived and handled by the system, thereby improving the reliability and interpretability of the traceability link.

[0048] In one embodiment, the function code further includes a tool data function code for uploading tool operation data, a lifespan reporting function code for uploading fixture lifespan-related data, and a change audit function code for uploading parameter configuration modification records. The variable-length business data payload corresponding to the tool data function code includes a tool identification field, a control unit identification field, a workstation identification field, and a process parameter set field. The process parameter set field consists of several parameter self-description fields, and each parameter self-description field includes at least a parameter identifier, parameter unit description, parameter scale description, parameter standard range, parameter tolerance range, parameter actual value, and parameter judgment result. The server is configured to send process parameter templates associated with the product type or workstation type to the control box, enabling the control box to automatically switch the set of parameter self-description fields according to the process parameter template and adjust them according to the parameter standard range and parameter tolerance. The range generation parameter determination result; the variable-length business data payload corresponding to the lifespan reporting function code includes job count information, peak process load information, environmental condition information, alarm statistics information, and maintenance record summary information. The server is configured to comprehensively evaluate the aforementioned information according to preset multi-factor evaluation rules to generate fixture health indicators, and return the remaining lifespan range and suggested maintenance actions in the response message; the variable-length business data payload corresponding to the change audit function code includes change item identifier, old value before change, new value after change, operator identity, change reason code, and approval credential field. After accepting the change, the server sends the effective time and rollback policy back to the control box and issues a rollback command when necessary to restore the old value before the change according to the rollback policy. At the same time, the server and the control box respectively record change link logs containing approval credential field and message identifier to form a closed-loop permission and two-way audit.

[0049] By structuring tool operation data at the "parameter granularity" level, the backend no longer receives only a string of unusable raw values. Instead, it can directly transform each process dimension into a standardized record that is searchable, comparable, and statistically valid. This supports benchmarking analysis and anomaly localization across shifts, workstations, and tool models. In particular, treating "unit / decimal place, standard, tolerance, actual, and judgment" as the complete context of the same parameter helps avoid ambiguity caused by relying solely on the numerical value itself. It also moves the judgment logic forward to a rule layer mutually agreed upon by both the field and backend, allowing the backend to directly use it for quality traceability, yield correlation, and process capability analysis. Furthermore, by issuing parameter templates based on product type or workstation type, the field end can automatically adjust the set of parameters to be reported as production changes occur, without needing to frequently modify programs for different products. This is equivalent to binding the protocol with process management, reducing maintenance costs and error probability during line expansion, line changeover, and model changeover, and enhancing the engineering usability and creativity of the expansion mechanism.

[0050] If lifespan-related data is only compared based on thresholds, it often only yields coarse-grained conclusions of "whether limits have been exceeded," which is insufficient to support preventative maintenance and risk grading. Incorporating factors such as frequency, peak load, temperature, alarm count, and maintenance records into a comprehensive assessment creates a continuous health indicator. This allows for the early identification of conditions that are "not yet exceeded but have already deteriorated," shifting maintenance from reactive repair to preventative intervention and reducing the risk of sudden outages or quality fluctuations. Returning the assessment results in the form of "remaining lifespan range + recommended maintenance actions" enables field operations to trigger maintenance, inspection, or shutdown strategies deterministically, forming an executable closed loop, rather than simply storing a passive record in the database.

[0051] Without approval documentation and rollback mechanisms, parameter configuration modification records often only provide a "post-mortem" understanding of the changes, making it difficult to "controllably allow modifications, provide verifiable evidence for accountability, and recoverably correct errors." By retaining a structured pair of old and new values ​​in the change data and supplementing it with approval numbers / work order numbers / signatures, the "legality of the change" and the "content of the change" can be linked, facilitating a closed-loop authorization process based on verifiable evidence. Furthermore, the server's feedback of the effective time and rollback strategy, along with support for issuing rollback commands, allows for rapid restoration to a stable configuration when abnormal parameters cause quality risks, preventing prolonged operation with inherent problems. Simultaneously, both the server and the field end record link logs containing approval documentation and message identifiers, providing consistent audit trails on "who changed what, when, and on what basis; whether the system confirmed acceptance; and whether a rollback occurred," improving traceability credibility and reducing dispute resolution costs.

[0052] Based on the same idea, an adaptive communication protocol implementation method for industrial fixture management is provided, applied between the control box and the server, to realize the aforementioned adaptive communication protocol system for industrial fixture management. The method includes steps S1-S6: In step S1, when the control box establishes a session with the server, it sends a handshake message to declare the set of supported protocol versions and the list of capabilities, and receives and caches the session version, the list of required fields and the field template associated with the function code returned by the server. In step S2, in response to a business event, which includes card swiping, sensor data readiness, timing, alarm, or parameter configuration change, the function code corresponding to the business event and the set of fields matching the function code are determined from the cached field template. In step S3, business data associated with business events and operator identity information are collected, and the business data is converted into a set of self-descriptive fields consisting of field identifiers, field lengths and field values ​​according to the field template. Noise filtering, verification, prefix and suffix rule processing and pattern matching mapping are performed on the workpiece identifier to generate a normalized identifier, and the original identifier, normalized identifier and read head quality indicators are written into the corresponding self-descriptive fields. In step S4, a communication message frame is generated, and a frame start identifier and a frame end identifier are written. Between the frame start identifier and the frame end identifier, the session version or its identifier, message identifier, function code, operator identity information, field description information, self-description field set, network address information, and integrity check field are written in sequence. Byte sequences that conflict with the frame start identifier or the frame end identifier are escaped. In step S5, the communication message is added to the offline buffer queue according to the preset priority and sent immediately or in batches according to the sending scheduling strategy. If no response message containing the message identifier is received, it is retransmitted according to the backoff retransmission strategy and retransmitted according to the message identifier after the network is restored. In step S6, the response message is parsed to obtain the acceptance result, the reason for the missing template, the downgrade guidance, the effective time, the rollback strategy or maintenance suggestion action, and the local status of the control box, the execution instruction output, the application parameter configuration or rollback instruction, and the bidirectional audit log is recorded accordingly.

[0053] As demonstrated by the above embodiments, this invention can carry various types of business data and management information for fixture management using a unified communication standard. This enables standardized aggregation and interaction of data from different sources within the same system, reducing information silos caused by system fragmentation. Simultaneously, through an expansion mechanism oriented towards the evolving needs of industrial sites, new business processes or fields can be integrated into the existing system with lower modification costs, thereby improving the continuous evolution capability and deployment efficiency of the fixture management system. Furthermore, this invention emphasizes the systematic improvement of data standardization and traceability capabilities. By consistently associating operational data with operator information and fixture identifiers, it achieves link traceability of production operations and quality data. Combined with communication response and robust design, it improves the reliability of data transmission and the determinism of anomaly handling in industrial network environments, thereby supporting subsequent data analysis and intelligent management applications, such as maintenance strategy optimization and refined process control.

[0054] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein.

Claims

1. An adaptive communication protocol system for industrial fixture management, characterized in that, include: A control box deployed in an industrial site and communicatively connected to a fixture, wherein the control box is also communicatively connected to the fixture's sensing and / or actuating components; and a server communicating with the control box via an industrial network; wherein the control box and the server communicate bidirectionally according to a communication protocol to achieve real-name data collection, closed-loop access control, and parameter change auditing and traceability during fixture usage; the communication protocol specifies that communication messages adopt a structured frame structure, and the frame structure, in transmission order, includes at least a frame start identifier, protocol negotiation information, message identifier, function code, operator identity field, field description information, variable-length business data payload, network address information, and integrity check field. The function code is used to uniquely indicate the service domain and service operation type. The variable-length service data payload includes several self-describing fields corresponding to the function code. The server is configured to establish a function code registry and maintain the mapping relationship between the function code and the field template. The field template is used to define the field identifier, field type, length rules, and required and optional attributes of the self-describing field corresponding to the function code. The control box is configured to generate the self-describing field according to the field template and compose the communication message to send to the server. The server is configured to parse the communication message according to the field template and return a response message containing the processing result.

2. The adaptive communication protocol system for industrial fixture management according to claim 1, characterized in that, The function code adopts a hierarchical encoding mechanism, which includes a domain identifier for representing a business domain and an operation identifier for representing a business operation. The server establishes isolated namespaces in the registry of the function code using the domain identifier and allocates a set of non-conflicting operation identifiers to different namespaces. The field description information carries a field template version identifier corresponding to the function code, so that the server can determine the parsing rules based on the field template version identifier when parsing the communication message and realize cross-version field evolution.

3. The adaptive communication protocol system for industrial fixture management according to claim 1, characterized in that, The server includes a template management module, which is configured to allow the control box to retrieve the registry of the function code and the field template corresponding to the function code registry when the control box goes online or a session is established. When the field template is updated, the module pushes incremental templates or template failure information to the control box through a configured channel and selectively applies the update to different control boxes according to a gray-scale activation strategy. The control box includes a template caching module to cache the field templates and triggers a re-retrieval when the cache is missing or expired. This enables the control box to automatically assemble frames based on the updated field templates to access new service data types without changing the frame structure.

4. The adaptive communication protocol system for industrial fixture management according to claim 1, characterized in that, The protocol negotiation information includes the protocol version candidate set and capability list declared by the control box. The server is configured to select a session version according to the protocol version candidate set and return a list of required fields matching the session version and an explanation of incompatible items to the control box. When the server detects an unknown function code, an unknown field identifier, or a field template version identifier that does not match the session version while parsing the communication message, the server performs the following actions according to a preset compatibility policy: ignore the unknown field and continue processing the known field, fall back to the compatible field template version, or refuse to accept the message and carry the reason for rejection and correction instructions in the response message, so as to realize the protocol negotiation, downgrade, and executable compatibility processing rules.

5. The adaptive communication protocol system for industrial fixture management according to claim 1, characterized in that, The variable-length service data payload is composed of several self-describing fields. Each self-describing field includes at least a field identifier, a field length, and a field value. The field description information includes a field bitmap, an extension area offset, or a combination thereof. The field description information is used to indicate the existence, order, or segmentation position of the self-describing field in the variable-length service data payload. When writing the field value, the control box performs escaping processing on byte sequences that conflict with the frame start identifier or the frame end identifier. Both the server and the control box use a frame synchronization recovery state machine based on the frame start identifier, the field length, and the integrity verification field at the receiving end to achieve fast alignment under noise interference, abnormal frame discarding, and subsequent valid frame recovery.

6. The adaptive communication protocol system for industrial fixture management according to claim 1, characterized in that, The message identifier includes a unique sequence identifier or random identifier within the session. The integrity verification field includes a cyclic redundancy check value. The communication message also includes an authentication field, which is any one or a combination of a message authentication code field and a digital signature field. The server is configured to perform error detection and anti-tampering verification based on the cyclic redundancy check value and the authentication field when receiving the communication message, and to perform replay protection and idempotent deduplication based on the message identifier. The response message carries the message identifier corresponding to the communication message and the acceptance result, so that the control box can complete confirmation, retransmission decision and audit accountability accordingly.

7. The adaptive communication protocol system for industrial fixture management according to claim 1, characterized in that, The control box includes a sending scheduling module and an offline cache queue. The sending scheduling module is configured to map the business events to be sent to different transmission levels according to preset priorities and enqueue them separately. For high-priority events, an immediate sending strategy is adopted, and for low-priority events, a batch encapsulation strategy is adopted. When the network is unreachable or the session is abnormal, the offline cache queue persistently caches the communication message and performs deduplication and retransmission according to the message identifier after the network is restored. If the acknowledgment message is not received, it is retransmitted according to the backoff and retransmission strategy.

8. The adaptive communication protocol system for industrial fixture management according to claim 1, characterized in that, The function code includes an identification reporting function code for uploading workpiece identification information. The self-description field corresponding to the identification reporting function code includes at least an original identification field, a normalized identification field, a reader type field, and a reader quality index field. When generating the normalized identification field, the control box executes an identification normalization process. This normalization process includes: filtering noise characters or unifying separators in the original identification field; performing checksum verification or length validity verification on the original identification field according to configurable verification rules; padding, trimming, or replacing the original identification field according to configurable prefix and suffix rules; and mapping the original identification field to a unified format according to configurable pattern matching rules, so that the server can perform cross-reader consistency tracing based on the normalized identification field and evaluate the collection reliability based on the reader quality index field.

9. The adaptive communication protocol system for industrial fixture management according to claim 1, characterized in that, The function codes also include a tool data function code for uploading tool operation data, a lifespan reporting function code for uploading fixture lifespan-related data, and a change audit function code for uploading parameter configuration modification records. The variable-length business data payload corresponding to the tool data function code includes a tool identification field, a control unit identification field, a workstation identification field, and a process parameter set field. The process parameter set field consists of several parameter self-description fields, and each parameter self-description field includes at least a parameter identifier, a parameter unit description, a parameter scale description, a parameter standard range, a parameter tolerance range, a parameter actual value, and a parameter judgment result. The server is configured to send a process parameter template associated with the product type or workstation type to the control box, enabling the control box to automatically switch the set of parameter self-description fields according to the process parameter template and generate the parameter based on the parameter standard range and the parameter tolerance range. The number of judgment results; the variable-length business data payload corresponding to the lifespan reporting function code includes job count information, peak process load information, environmental condition information, alarm statistics information, and maintenance record summary information. The server is configured to comprehensively evaluate the aforementioned information according to preset multi-factor evaluation rules to generate fixture health indicators, and return the remaining lifespan range and suggested maintenance actions in the response message; the variable-length business data payload corresponding to the change audit function code includes change item identifier, old value before change, new value after change, operator identity, change reason code, and approval credential field. After accepting the change, the server sends the effective time and rollback policy back to the control box and issues a rollback instruction when needed to restore the old value before change according to the rollback policy. At the same time, the server and the control box respectively record change link logs containing the approval credential field and the message identifier to form a closed-loop permission and two-way audit.

10. A method for implementing an adaptive communication protocol for industrial fixture management, applied between a control box and a server, to implement the adaptive communication protocol system for industrial fixture management as described in any one of claims 1-9, characterized in that, The method includes: When the control box establishes a session with the server, it sends a handshake message to declare the set of supported protocol versions and the list of capabilities, and receives and caches the session version, the list of required fields, and the field templates associated with the function codes returned by the server. In response to business events, including card swipe, sensor data readiness, timing, alarm, or parameter configuration change, determine the function code corresponding to the business event and the set of fields matching the function code from the cached field template; Collect business data associated with the business event and operator identity information, and convert the business data into a set of self-descriptive fields consisting of field identifier, field length and field value according to the field template. Perform noise filtering, verification, prefix and suffix rule processing and pattern matching mapping on the workpiece identifier to generate a normalized identifier, and write the original identifier, the normalized identifier and the read head quality index into the corresponding self-descriptive fields. Generate a communication message frame, write a frame start identifier and a frame end identifier, and sequentially write the session version or its identifier, message identifier, function code, operator identity information, field description information, self-description field set, network address information and integrity check field between the frame start identifier and the frame end identifier, and perform escaping processing on byte sequences that conflict with the frame start identifier or the frame end identifier; The communication messages are added to the offline cache queue according to a preset priority and sent immediately or in batches according to the sending scheduling strategy. If no response message containing the message identifier is received, the message is retransmitted according to the backoff and retransmission strategy and retransmitted after the network is restored according to the message identifier. The response message is parsed to obtain the acceptance result, reason for missing template, downgrade guidance, effective time, rollback strategy or maintenance suggestion action, and the local status of the control box, execution instruction output, application parameter configuration or rollback command are updated accordingly, and a two-way audit log is recorded.

Images