An industrial data breakpoint continuation method, system and storage medium

Abstract

The application discloses an industrial data breakpoint continuation method, which comprises the following steps: a client takes a sampling serial number as the unique identifier of industrial data, encapsulates the industrial data and the serial number into a private protocol frame, and uploads the frame to a server, and stores the data and the serial number into a local cache, and stores the last successfully uploaded serial number into a nonvolatile storage; the client monitors the communication connection through a heartbeat mechanism, and reestablishes the connection when the connection is interrupted; after the recovery, the client reads the serial number from the nonvolatile storage and initiates a breakpoint continuation request; the server takes the serial number as an index to query a receiving state table, determines a missing serial number interval, and returns the client; the client retrieves the corresponding industrial data from the local cache according to the missing interval, reencapsulates the industrial data into a private protocol frame, and performs a retransmission; the local cache does not store complete protocol frames, and only stores industrial data and serial numbers. The application realizes low-cost, high-reliability, embedded storage suitable for industrial data breakpoint continuation, short recovery time and low data loss rate.

Description

Technical Field

[0001] This invention relates to the field of industrial Internet of Things (IoT) data transmission technology, and in particular to a method, system, and storage medium for resuming interrupted industrial data transmission. Background Technology

[0002] In the Industrial Internet of Things (IIoT) field, numerous industrial field devices (such as PLCs, sensors, and smart meters) need to continuously collect data and upload it to a host computer server for storage, analysis, and monitoring in a data center. When the transmission communication link during the upload is interrupted due to network outages or other reasons, the data upload process is disrupted, and data loss will occur if it is not re-uploaded. To address this, some existing solutions provide breakpoint resume functionality. However, existing breakpoint resume solutions have the following shortcomings: Firstly, existing breakpoint resume solutions mostly rely on byte offsets to locate the interruption point, such as the HTTP Range mechanism. However, industrial data uploads are performed in frames, and the byte offset-based resume method does not match the frame-level structure of industrial data. If it is adopted directly, additional mapping relationships need to be maintained, increasing server overhead.

[0003] Secondly, after a disconnection is restored, existing solutions typically require the server to compare the received data frame by frame to determine the missing data. When the amount of data is large, frame-by-frame comparison is inefficient.

[0004] Third, there is a prevailing technological mindset in the field of breakpoint resume transmission: to facilitate direct retransmission during retransmission, complete protocol frames are usually cached. However, industrial field devices are typically embedded systems with limited storage resources, and the erase / write lifespan of non-volatile storage (such as Flash) is limited. Cached complete protocol frames will accelerate the depletion of storage resources in high-frequency acquisition scenarios.

[0005] In summary, the existing technology lacks a solution for resuming interrupted data transmission on industrial embedded devices with limited storage resources that can efficiently locate missing data and whose caching strategy takes into account storage resource consumption. Summary of the Invention

[0006] To address the aforementioned technical problems, this invention provides an industrial data breakpoint resume method, system, and storage medium, which can effectively overcome the above-mentioned defects.

[0007] Specifically, in a first aspect, the present invention provides an industrial data breakpoint resume method, applied to a system including a host computer client and a host computer server, wherein the client is connected to industrial field equipment and includes local cache and local non-volatile storage, the method comprising: The client collects industrial data from industrial field equipment, and each sampling window of industrial data corresponds to a unique sampling sequence number; the industrial data and its corresponding sampling sequence number are encapsulated into a private protocol frame and uploaded to the server, and the industrial data and its corresponding sampling sequence number are stored in the local cache, and the sampling sequence number corresponding to the last successfully uploaded industrial data is stored in the local non-volatile storage; The client uses a heartbeat mechanism to determine whether the communication connection with the server is interrupted. If the connection is interrupted, the connection is re-established. After the connection is restored, the client reads the sampling sequence number corresponding to the last successfully uploaded industrial data from the local non-volatile storage and sends a resume request containing the sampling sequence number to the server. After receiving the breakpoint resume request, the server queries the reception status table using the sampling sequence number as an index, determines the sampling sequence number range whose status in the reception status table is not received, and returns the sampling sequence number range as a missing sequence number range to the client; wherein, the reception status table is used to record whether the private protocol frame corresponding to each sampling sequence number has been received by the server. The client retrieves industrial data corresponding to all serial numbers within the missing serial number range from the local cache according to the missing serial number range, re-encapsulates the industrial data and its corresponding sampling serial number into a private protocol frame for retransmission, thereby completing the interrupted transmission of industrial data. The local cache does not store complete private protocol frames, but only the industrial data and its corresponding sampling sequence number.

[0008] This invention directly locates missing data using the sampling sequence number as an index, eliminating the need to maintain a mapping table between byte offsets and sequence numbers. This results in low server memory overhead and reduced development complexity. By replacing frame-by-frame enumeration with missing sequence number intervals, the number of communication interactions is significantly reduced, and the average recovery time is only 2.5 seconds. The local cache does not store complete private protocol frames, but only industrial data and sequence numbers. Compared to the conventional approach of caching complete frames for direct retransmission, this effectively alleviates the storage pressure on embedded devices. The heartbeat, reconnection, resume transmission, and retransmission form a complete closed loop, significantly reducing the risk of data loss and achieving zero data loss when the cache is not overwritten.

[0009] Optionally, the private protocol frame includes a fixed-length header and a variable-length payload field, wherein the header consists of: The starting magic number field is 2 bytes long and has a fixed value of 0x5A5A. The protocol version field has a length of 1 byte. The command field has a length of 1 byte; The data length field is 2 bytes long and uses big-endian order, indicating the number of bytes in the payload field; The checksum field is 2 bytes long and is calculated using the CRC16_Modbus algorithm. Its polynomial is 0x8005, its initial value is 0xFFFF, and its output XOR value is 0xFFFF.

[0010] This invention significantly reduces protocol overhead by setting a fixed-length header, which is much smaller than the HTTP header in existing technologies, which typically exceed 500 bytes. It also sets up dual checks using the magic number 0x5A5A and CRC16_Modbus to ensure that the server accurately identifies frame boundaries and verifies data integrity, providing a security prerequisite for the accurate maintenance of the receive status table. The fixed frame structure simplifies and makes the protocol parsing logic more reliable, reducing the processing overhead of embedded devices.

[0011] Optionally, in the heartbeat mechanism, the client sends a heartbeat frame to the server every 30 seconds, and the server returns a heartbeat response frame to the client after receiving the heartbeat frame; if no heartbeat response frame is received for 3 consecutive times, the connection is determined to be interrupted. The reconnection is established using an exponential backoff strategy, which is as follows: the initial reconnection waiting time is 1 second, and the waiting time increases by 2 times after each failed reconnection until it reaches the upper limit of 60 seconds, after which it maintains a 60-second interval for continuous reconnection.

[0012] This invention can detect silent disconnections by setting a 30-second heartbeat cycle with 3 timeouts, that is, a maximum of 90 seconds. The detection delay is matched with the high-frequency data acquisition scenario in industrial applications, making the amount of data lost during the disconnection controllable. The exponential backoff strategy takes into account both rapid recovery and network protection, avoiding reconnection requests from exacerbating network congestion. The heartbeat mechanism can detect disconnections at the application layer, providing timely and reliable trigger signals for the resume process.

[0013] Optionally, the method by which the server determines the sampling sequence number range in the reception status table that is in a state of "not received" is specifically as follows: Starting from the sampling sequence number corresponding to the last successfully uploaded industrial data, the receiving status table is traversed from that sequence number onwards; Find the first sampling sequence number with a status of "not received" and continue searching until a sampling sequence number with a status of "received" is encountered or the end of the reception status table is reached. All unreceived sampling sequence numbers found are merged into the missing sequence number range.

[0014] This invention combines scattered unreceived states into continuous intervals, compressing the retransmission instruction from frame-by-frame enumeration to interval-based expression, significantly reducing the number of communication interactions between the server and the client; using the sequence number as the traversal basis, it is fully aligned with the frame-level semantics of industrial data, eliminating the need to maintain an additional mapping table; combined with the aforementioned interval-based retransmission, the measured disconnection recovery time is shortened to an average of 2.5 seconds.

[0015] Optionally, the local cache is a circular buffer implemented using a circular array, and each cache record contains a sampling sequence number, a timestamp, and industrial data; The client traverses the circular buffer according to the missing sequence number range, extracts the cache records corresponding to all sampled sequence numbers within the missing sequence number range, sorts them in ascending order of sampled sequence numbers, and re-encapsulates them into a private protocol frame for retransmission.

[0016] This invention uses a fixed-size circular array in a circular buffer, eliminating the need for dynamic memory allocation and avoiding memory fragmentation, making it suitable for resource-constrained embedded scenarios. Each cached record stores only the sequence number, timestamp, and industrial data, without storing the complete protocol frame, thus reducing storage usage. The circular structure indexed by the sequence number supports traversal queries by sequence number range, which, in conjunction with the aforementioned range merging algorithm, enables efficient retransmission of data.

[0017] Optionally, if the circular buffer cannot find the cache record corresponding to all the sampling sequence numbers in the missing sequence number interval, the client sends a data non-retransmission identifier frame to the server. After receiving the data non-retransmission flag frame, the server marks the sampling sequence number for which no cache record can be found as permanently missing in the reception status table and no longer initiates a retransmission request for that sampling sequence number.

[0018] This invention avoids infinite loops of retransmission requests and responses caused by data overwriting by clearly defining the exception handling path, thus ensuring the robustness of the protocol under extreme conditions. The permanent missing marker provides final state consistency, preventing the server from repeatedly requesting retransmission of overwritten data and reducing invalid communication overhead. It constitutes a complete cache management scheme, forming a logical closed loop from normal retransmission to exception handling.

[0019] Optionally, the local cache is located in memory, and the local non-volatile storage is a Flash memory. To extend the lifespan of the Flash memory during the storage of the sampling sequence number, the client adopts the following optimization strategy: The write operation of the sampling sequence number is first completed in the memory. After completion, the sampling sequence number data in the memory is batch synchronously transmitted to the Flash memory at a preset synchronization period or change number threshold. A change bitmap is used to record whether the sector in the Flash memory that stores the sampling sequence number has been modified. When synchronization is triggered, only the sector recorded as modified in the change bitmap is written to the Flash memory. A wear leveling algorithm is used to dynamically select the sector with the fewest erase / write cycles for writing the sampling sequence number; The system uses a log structure for storage, appending the sampling sequence number corresponding to newly uploaded industrial data as a new record, and periodically garbage collecting sectors where the proportion of invalid records exceeds a threshold. Each record written to the Flash memory includes a sampling sequence number, a timestamp, and a CRC32 check value; the same sampling sequence number is stored in two independent sectors as backups of each other.

[0020] This invention reduces the Flash write frequency from 100 times per second to 0.1 times per second through dual-buffered batch writing. Combined with incremental tracking of change bitmaps, it only writes to changed sectors, significantly reducing the number of erase / write operations. Wear leveling ensures that the number of erase / write operations is evenly distributed across all sectors, avoiding premature failure at a single point. The log structure and garbage collection avoid frequent erasures caused by in-place updates, further extending the lifespan. Dual backup and CRC32 verification ensure write security, allowing data to be recovered from the other copy if one copy is damaged. The five-layer optimization strategy works together to significantly extend the Flash lifespan, meeting the long-term service requirements of industrial equipment, and providing reliable breakpoint recording for the breakpoint resume function.

[0021] Optionally, the client and the server negotiate the protocol version through a handshake frame, specifically including: The client carries the protocol version number it supports in the handshake request frame; The server determines whether it supports the version number; if it does, it returns a handshake success response frame. If the server does not support the version number, a version error frame is returned, the payload of which carries a list of one or more protocol version numbers supported by the server. The client selects a matching protocol version from the list to re-initiate the handshake. If no common version is found, the error is recorded and manual intervention is requested.

[0022] This invention enables servers to be compatible with multiple protocol versions simultaneously. Older clients can continue to use lower versions to connect without upgrading, while new clients automatically use higher versions to enjoy new features, achieving smooth evolution and backward compatibility. Clear error feedback, i.e., a version list, allows clients to automatically downgrade and retry without manual intervention. It also provides a standardized version management mechanism for changes in private protocol frame formats, such as adding encrypted fields or extending headers.

[0023] In a second aspect, the present invention provides an industrial data breakpoint resume system, the system being used to execute the method as described in any one of the first aspects, the system comprising a host computer client and a host computer server, specifically including: The client is used to collect industrial data from industrial field equipment, assign a unique sampling sequence number to the industrial data of each sampling window, encapsulate the industrial data and its corresponding sampling sequence number into a private protocol frame and upload it to the server, monitor the communication connection status with the server through a heartbeat mechanism, re-establish the connection when the connection is interrupted, and store the industrial data and its corresponding sampling sequence number in a local cache, and store the sampling sequence number corresponding to the last successfully uploaded industrial data in local non-volatile storage. The server is used to receive and store the private protocol frames uploaded by the client, maintain a reception status table, query the reception status table according to the breakpoint resume request initiated by the client, and return the missing sequence number range to the client. The client and the server are directly connected via a standard TCP / IP network without any intermediate gateway layer.

[0024] This invention covers all the method steps described in the first aspect through a modular client design, and a modular server design supports large-scale concurrency; TCP / IP direct connection without intermediate gateways reduces end-to-end communication latency from 45ms in the HTTP scheme to 8ms, providing low-latency communication guarantee for high-frequency acquisition and rapid retransmission; the two-level architecture is simple, the system topology is clear, and fault location is fast.

[0025] In a third aspect, the present invention provides a computer-readable storage medium storing a computer program that, when executed by a processor, causes the processor to perform the steps of the method as described in any of the first aspects above.

[0026] This invention provides a method and system for resuming interrupted industrial data transmission, specifically by using the sampling sequence number as the unique identifier of the data frame. This allows the server to directly query the receiving status table using the sequence number as an index and return the missing sequence number range as a retransmission instruction to the client. This avoids the problem of needing to maintain additional mapping relationships in byte offset-based retransmission schemes, compressing the retransmission instruction from frame-by-frame enumeration to range-based expression. The number of communication interactions during the retransmission process is significantly reduced, enabling rapid and accurate location of missing data after disconnection recovery, and greatly reducing disconnection recovery time. Simultaneously, by using industrial data and its... The corresponding sampling sequence number is stored in a local cache (which does not store complete private protocol frames), and the last successfully uploaded sequence number is stored in local non-volatile storage. This avoids the ineffective use of storage resources caused by caching complete protocol frames, thus effectively alleviating the storage pressure on embedded devices. In conjunction with the client's heartbeat mechanism to determine whether the communication connection is interrupted and to read the last successfully uploaded sequence number from the local non-volatile storage to initiate a breakpoint resume request after the connection is restored, reliable breakpoint resume is achieved under the condition of limited storage resources on embedded devices, with an extremely low data loss rate. Attached Figure Description

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

[0028] Figure 1 A schematic diagram of a method for resuming interrupted industrial data transmission provided by the present invention; Figure 2 A schematic diagram of an industrial data breakpoint resume system provided by the present invention; Figure 3 An internal structural diagram of a computer device in one embodiment is shown. Detailed Implementation

[0029] To enable those skilled in the art to better understand the technical solutions of this invention, the technical solutions of the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this invention, and not all of them. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0030] References to "an embodiment," "an exemplary embodiment," etc., in this invention indicate that the described embodiment may include a specific feature, structure, or characteristic, but not every embodiment must include that specific feature, structure, or characteristic. Furthermore, these phrases do not necessarily refer to the same embodiment. Additionally, when a specific feature, structure, or characteristic is described in connection with an embodiment, it is assumed that, whether explicitly described or not, the influence of such feature, structure, or characteristic on other embodiments is within the knowledge of those skilled in the art.

[0031] It should be understood that the terms "length", "width", "upper", "lower", "front", "rear", "first", "second", "vertical", "horizontal", "top", "bottom", "inner", "outer", etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing the present invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on the present invention.

[0032] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this invention, "a plurality of" or "several" means two or more, unless otherwise explicitly specified.

[0033] It should be noted that the structures, proportions, sizes, etc., shown in the accompanying drawings of this specification are only for the purpose of assisting those skilled in the art in understanding and reading the content disclosed in the specification, and are not intended to limit the conditions under which the present invention can be implemented. Therefore, they have no substantial technical significance. Any modifications to the structure, changes in the proportions, or adjustments to the size, without affecting the effects and objectives that the present invention can produce, should still fall within the scope of the technical content disclosed in the present invention.

[0034] Please see Figure 1This invention provides a method for resuming interrupted industrial data transmission. The method is applied to a system including a host computer client and a host computer server. The client is connected to industrial field equipment and includes a local cache and local non-volatile storage. The method includes: the client collecting industrial data from the industrial field equipment, with each sampling window corresponding to a unique sampling sequence number; encapsulating the industrial data and its corresponding sampling sequence number into a private protocol frame and uploading it to the server; storing the industrial data and its corresponding sampling sequence number in the local cache; and storing the sampling sequence number corresponding to the last successfully uploaded industrial data in the local non-volatile storage; the client using a heartbeat mechanism to determine if the communication connection with the server is interrupted; if the connection is interrupted, re-establishing the connection; after the connection is restored, the client reading the last successfully uploaded data from the local non-volatile storage. The client uploads the sampling sequence number corresponding to the industrial data and sends a resume request containing that sampling sequence number to the server. Upon receiving the resume request, the server queries the reception status table using the sampling sequence number as an index to determine the sampling sequence number range whose status is "not received" and returns this range as the missing sequence number range to the client. The reception status table records whether the private protocol frame corresponding to each sampling sequence number has been received by the server. Based on the missing sequence number range, the client retrieves the industrial data corresponding to all sequences within the missing sequence number range from its local cache, repackages the industrial data and its corresponding sampling sequence number into a private protocol frame, and retransmits it, thus completing the resume transmission of the industrial data. The local cache does not store complete private protocol frames, only the industrial data and its corresponding sampling sequence number.

[0035] Understandably, the host computer client is deployed in the industrial field, communicating with industrial field devices such as PLCs, sensors, and smart meters to collect industrial data and interact with the host computer server. The host computer server is deployed in the data center to receive, process, and store data uploaded by the client. The local cache is a circular buffer (RAM) in memory, used to temporarily store recently collected industrial data and its corresponding sampling sequence number for retrieval during retransmission. Local non-volatile storage is preferably Flash memory, used to persistently store the sampling sequence number corresponding to the last successfully uploaded industrial data, ensuring that the breakpoint position is not lost after device restart. A receive status table is provided for each client, recording the receive status of each data frame using the sampling sequence number as the key. The host computer client and the host computer server use a standard TCP / IP network direct connection, without an intermediate gateway layer, to reduce system complexity and communication latency.

[0036] In one feasible implementation, the proprietary protocol frame in this embodiment includes a fixed-length header and a variable-length payload field. The header includes the following fields in sequence: 1) The starting magic number field is 2 bytes long and has a fixed value of 0x5A5A. This field is used by the receiver to locate the start position of the frame in the TCP byte stream. 0x5A5A is chosen as the magic number because it has good recognizability at the binary level (both 0x5A and 0x5A are easily distinguishable byte patterns), has a low collision probability, and can effectively reduce the false recognition rate.

[0037] 2) Protocol version field, 1 byte in length, is used to indicate the protocol version number used in the current frame. In this embodiment, the initial version number is 0x10, and the value of this field will be updated accordingly when the protocol is upgraded.

[0038] 3) Command word field, 1 byte in length, used to distinguish different frame types. In this embodiment, the frame types are defined as shown in Table 1 below:

[0039] Table 1. Definition of Private Protocol Frame Command Words 4) The data length field is 2 bytes long and uses big-endian (network byte order). It indicates the number of bytes in the payload field, with a maximum capacity of 65535 bytes. This field enables the receiver to correctly segment complete protocol frames from the TCP byte stream, avoiding packet fragmentation issues.

[0040] 5) Checksum field, 2 bytes in length, calculated using the CRC16_Modbus algorithm, with a polynomial of 0x8005, an initial value of 0xFFFF, and an output XOR value of 0xFFFF. The CRC16_Modbus algorithm is a widely used checksum algorithm in industrial communication, characterized by its fast calculation speed and strong error detection capability. This checksum field covers all bytes from the magic number to the end of the payload, used to verify whether bit errors or data tampering have occurred during data transmission.

[0041] The load field is a variable-length field that carries industrial data and its corresponding sampling sequence number. The length of the load is indicated by the data length field.

[0042] Based on the above, in a feasible implementation, the core process of the industrial data breakpoint resume method is as follows: S1. The host computer client collects real-time data from industrial field equipment according to a preset sampling period (e.g., 100Hz). Each collection yields a set of industrial data, such as sensor values ​​for temperature, pressure, and vibration. The client assigns a unique sampling sequence number (seq_id) to each set of collected industrial data. This sampling sequence number is a strictly incrementing integer starting from 0. The sequence number is automatically incremented by 1 for each new set of data collected, thus ensuring that each sampling window of industrial data corresponds to a unique sampling sequence number, providing accurate frame-level identification for subsequent breakpoint resume transmission.

[0043] S2. The client uses the collected industrial data and its corresponding sampling sequence number as the payload, assembles a complete private protocol frame according to the aforementioned private protocol frame format (command word is 0x02), calculates the CRC16_Modbus checksum and fills it into the checksum field, and sends it to the server through the established TCP connection. This complete private protocol frame only exists temporarily in memory during transmission and is discarded after transmission is completed, without being stored in any storage medium.

[0044] S3. To support possible subsequent retransmissions, the client stores the corresponding industrial data and its sampling sequence number in a local cache while completing frame encapsulation. The storage format is: seq_id (4 bytes) + timestamp (8 bytes) + data_len (2 bytes) + raw_data (N bytes). Here, timestamp is the millisecond-level Unix timestamp at the time of acquisition, and raw_data is the raw sensor sampling value.

[0045] It is important to note that the local cache does not store complete private protocol frames, meaning it does not store header information (magic number, version, command word, data length, checksum), but only the core information such as the original industrial data, sequence number, and timestamp. By storing the content but not the format, the amount of data in the cache is minimized, which significantly saves storage space compared to the conventional approach of caching complete frames for direct retransmission.

[0046] S4. Simultaneously, after each frame of data is successfully uploaded, the client stores the sampling sequence number corresponding to the last successfully uploaded industrial data to local non-volatile storage. This storage is an idempotent operation, meaning that it is only updated to the latest sequence number value after each successful upload. The local non-volatile storage is preferably Flash memory. Since Flash memory has a limited erase / write lifespan, this embodiment will describe in detail the lifespan optimization strategy for Flash writes later.

[0047] S5. The server continuously receives byte streams from the client via a TCP connection. During reception, the server scans the 0x5A5A magic number in the byte stream to locate the frame header, reads the header, and retrieves the corresponding number of bytes of payload based on the data length field to form a complete frame. Then, it recalculates the CRC16_Modbus checksum and compares it with the checksum carried in the frame. If the checksum passes, the server extracts the industrial data and sampling sequence number from the payload and updates the corresponding receive status table for that client.

[0048] The receive status table is an in-memory hash table maintained independently by the server for each client. It uses the sampling sequence number as the primary key and records whether the data frame corresponding to each sequence number has been successfully received, as well as auxiliary information such as the reception timestamp and data length. An example of the receive status table structure is shown in Table 2 below:

[0049] Table 2 Example of receiving status representation Once the server correctly receives a frame of data and writes the sampling sequence number into the receiving status table, it has completed the storage and processing of one frame of data and is ready to wait for the next frame to arrive.

[0050] It should be noted that for a frame of industrial data to be considered "successfully uploaded," the following conditions must be met simultaneously: 1. The server receives the complete private protocol frame sent by the client and verifies it using CRC16_Modbus checksum, confirming that no bit errors or data tampering occurred during transmission; 2. The server successfully extracts the industrial data and corresponding sampling sequence number from the payload, stores the industrial data in the time-series database, and writes the sampling sequence number into the receive status table maintained for the client, marking it as "received"; 3. The server returns an acknowledgment message (ACK) to the client, and the client successfully receives the acknowledgment message. All three conditions are indispensable. A frame is not considered successfully uploaded if only a TCP layer ACK is sent but the application layer has not completed the above processes, or if the server's CRC check fails and the frame is discarded. The corresponding sampling sequence number will not be recorded as "finally successfully uploaded."

[0051] Based on the above definition, the "sampling sequence number corresponding to the last successfully uploaded industrial data" refers to the sampling sequence number recorded in the client's local non-volatile storage, arranged in ascending order of sampling sequence number, and corresponding to the last industrial data that meets the above "successful upload" condition. Whenever the client receives a successful confirmation from the server for a frame of data, if the sequence number of that frame is greater than the currently recorded "last successfully uploaded" sequence number, the client updates the sequence number of that frame to the new "last successfully uploaded" sequence number and stores it in the local non-volatile storage. This value is retained after the device restarts and is used to inform the server of the breakpoint location during disconnection recovery.

[0052] In one feasible implementation, during data transmission intervals, the host computer client monitors whether the communication connection with the server is interrupted via a heartbeat mechanism. In this heartbeat mechanism, the client sends a heartbeat frame to the server every 30 seconds. Upon receiving a heartbeat frame, the server returns a heartbeat response frame to the client. If no heartbeat response frame is received three consecutive times, the connection is considered interrupted. Reconnection employs an exponential backoff strategy: the initial reconnection waiting time is 1 second, and the waiting time doubles after each failed reconnection, until a maximum of 60 seconds is reached, after which a 60-second interval is maintained for continuous reconnection. Details are as follows: The client sends a heartbeat frame (command word 0x03) to the server every 30 seconds. This heartbeat frame is a payload-free frame with a total length of 10 bytes. Upon receiving the heartbeat frame, the server immediately returns a heartbeat response frame (command word 0x83) to the client to confirm that the connection is still active. The client maintains a counter for consecutive heartbeat response frames not received. After each heartbeat frame is sent, the client waits for a response. If no response is received within a predetermined time, the counter is incremented by 1; if a response is received, the counter is reset to zero. If the client fails to receive a heartbeat response frame for three consecutive times, i.e., for a maximum of 90 seconds (30 seconds x 3), the communication connection is considered interrupted, triggering a reconnection process. Using three consecutive failures instead of a single failure to determine interruption is to filter out false positives caused by momentary network jitter: a single lost heartbeat frame does not necessarily mean the connection is broken; only three consecutive failures confirm connection failure, effectively improving the accuracy of the judgment.

[0053] In a preferred embodiment, the disconnection detection of the present invention is not limited to the heartbeat mechanism detection described above. Optionally, the following two auxiliary detection methods can be combined with the heartbeat mechanism detection to form a three-level disconnection detection mechanism to further improve the timeliness and reliability of disconnection sensing: Level 1 Auxiliary Detection: Socket Send Failure Detection. When a client calls the underlying socket's send() function to send data, if the TCP connection has been broken, the operating system will immediately return an error code, such as EPIPE or ECONNRESET. Upon catching this error, the client immediately determines that the connection has been interrupted. This level of detection is the fastest, capable of detecting connection drops almost in real-time when there is a need to send data.

[0054] The second level of auxiliary detection is the operating system's TCP disconnection event detection. When a TCP connection is closed due to reasons such as the peer closing the connection or network timeout, the operating system's TCP protocol stack notifies the application through socket events. The client can detect the connection disconnection within seconds by listening for socket events, such as receiving an RST or FIN packet.

[0055] The two auxiliary detection methods mentioned above correspond to high-speed detection and event-driven detection, respectively. The third level of detection, namely the aforementioned heartbeat mechanism detection, serves as a backup mechanism to cover silent disconnection scenarios where no data is sent or no system events are triggered, such as slow network cable failure or switch port malfunction without RST packets being sent. These three detection methods work independently; any one of them triggers a connection interruption, with the heartbeat timeout mechanism acting as a backup. Through this three-level collaborative detection architecture, connection interruptions can be detected promptly and reliably in various types of network fault scenarios.

[0056] Furthermore, the reconnection employs an exponential backoff strategy. This strategy involves an initial reconnection wait time of 1 second, which doubles after each failed reconnection attempt, i.e., 1 second, 2 seconds, 4 seconds, 8 seconds, 16 seconds, 32 seconds, 60 seconds, until reaching the maximum of 60 seconds. After reaching this maximum, reconnections are continuously attempted at 60-second intervals, never giving up, until the connection is restored. The reconnection interval sequence is: 1 second, 2 seconds, 4 seconds, 8 seconds, 16 seconds, 32 seconds, 60 seconds, 60 seconds, ...

[0057] Understandably, the purpose of adopting the exponential backoff strategy is to help restore communication as quickly as possible when the connection is just broken by quickly attempting to reconnect. If multiple reconnection attempts fail in succession, it indicates that the network may be in a faulty state for a long time. In this case, appropriately lengthening the reconnection interval can prevent the client from frequently initiating connection requests and reduce the ineffective occupation of network resources. Setting a 60-second limit can prevent the waiting time from growing indefinitely and ensure that the client can re-establish the connection within a reasonable time after the network is restored.

[0058] Understandably, the client first reads the sampling sequence number corresponding to the last successfully uploaded industrial data from its local non-volatile flash storage. This sequence number represents the breakpoint position at the time of the last interruption. For example, if the sequence number stored in the flash is 1001, it means that all data up to sequence number 1001 has been successfully uploaded. The client then sends a resume request frame (command word 0x05) to the server. The payload of this request frame carries the sampling sequence number (e.g., 1001) corresponding to the last successfully uploaded industrial data, informing the server that data up to 1001 has been successfully uploaded and requesting information on which data needs to be re-uploaded.

[0059] Furthermore, after receiving the resume request, the server determines the range of sampled sequence numbers in the reception status table that are in an unreceived state as follows: starting from the sampled sequence number corresponding to the last successfully uploaded industrial data, the server traverses the reception status table from that sequence number onwards; it searches for the first sampled sequence number in an unreceived state, and continues searching forward until it encounters a sampled sequence number in an received state or reaches the end of the reception status table; and it merges all the unreceived sampled sequence numbers found into a missing sequence number range.

[0060] Starting with the sampling sequence number (e.g., 1001), the server iterates through the client's corresponding receive status table after that sequence number to determine the data range that needs to be retransmitted. Specifically, the server starts iterating from sequence number 1001, searching for the first sampling sequence number with a status of "not received" (e.g., 1002), and continues searching until it encounters the first sampling sequence number with a status of "received" (e.g., 1021) or reaches the end of the receive status table. All consecutive "not received" sampling sequence numbers are then merged into a single missing sequence number range. For example, if 1002 to 1020 are all in the "not received" state and 1021 is in the "received" state, the resulting missing range is [1002, 1020]. If multiple non-contiguous missing segments exist (e.g., 1002-1003 missing, 1005-1006 missing, 1008 missing), then multiple missing ranges are constructed and returned. This continuous interval-based query method compresses the retransmission instruction from listing frame by frame (i.e., informing the client one by one, 1002, 1003, ...) to an interval-based expression (i.e., informing the client [1002, 1020] at once), significantly reducing the number of communication interactions. If no "unreceived" records are found after traversal, meaning all data has been completely received, the server returns a continuation confirmation frame (command word 0x85), and the client directly continues uploading new real-time data. Furthermore, the server encapsulates the determined missing sequence number interval in a retransmission request frame (command word 0x06) and returns it to the client.

[0061] In one feasible embodiment, the local cache is a circular buffer implemented using a circular array. Each cache record contains a sampling sequence number, a timestamp, and industrial data. The client traverses the circular buffer according to the missing sequence number range, extracts the cache records corresponding to all sampling sequence numbers within the missing sequence number range, sorts them in ascending order of sampling sequence number, and re-encapsulates them into a private protocol frame for retransmission.

[0062] Understandably, the client retrieves all industrial data corresponding to the missing sequence number range from the local cached circular buffer based on the missing sequence number range, such as [1002, 1020]. Specifically, it iterates through the circular buffer, searches for all cached records with sequence numbers in the range of 1002 to 1020. Each record contains seq_id, timestamp, and raw_data, arranged in ascending order of sequence number. Then, it re-encapsulates the industrial data and its corresponding sampling sequence number into a private protocol frame for retransmission, waiting for server confirmation after each frame is sent.

[0063] It is important to emphasize that the complete protocol frame is re-encapsulated during retransmission because the local buffer does not store the complete protocol frame (i.e., without the header and checksum). Instead, the header information and CRC16_Modbus checksum are recalculated during retransmission, and the complete private protocol frame is assembled before transmission. This invention, through its design of storing content and re-encapsulating during transmission, effectively saves storage space with minimal CPU computation.

[0064] Subsequently, after receiving each retransmitted frame, the server performs magic number positioning, CRC verification, and update the receive status table in the same way as normal upload.

[0065] Furthermore, after the server confirms that all data within the missing sequence number range has been successfully retransmitted, the client continues to upload new real-time data, with the sequence number continuously increasing from the next value after the end of the missing range.

[0066] The aforementioned local cache is a circular buffer implemented using a circular array, with configurable capacity; for example, it retains data from the most recent 30 minutes by default. Each cache record contains a sampling sequence number, a timestamp, and industrial data, stored in the following format: seq_id (4 bytes) | timestamp (8 bytes) | data_len (2 bytes) | raw_data (N bytes). This circular buffer maintains two pointers: a write pointer and a read pointer. Newly written data is stored at the write pointer position, and the write pointer advances. When the buffer is full, new data automatically overwrites the oldest data, eliminating the need for dynamic memory allocation and making it suitable for embedded scenarios with long-term continuous operation. This circular buffer organizes data using the sampling sequence number as an index, supporting traversal queries by sequence number range. It can efficiently respond to the data retrieval requirements in the aforementioned steps: given a missing sequence number range [1002, 1020], it searches for records with sequence numbers within this range in reverse order (or from the beginning) from the current position of the write pointer, extracts them, and sorts them in ascending order.

[0067] In this embodiment, if no cached record corresponding to all sampled sequence numbers within the missing sequence number range can be found in the circular buffer, the client sends a data non-retransmission flag frame to the server. After receiving the data non-retransmission flag frame, the server marks the sampled sequence number for which no cached record can be found as permanently missing in the reception status table and will not initiate a retransmission request for that sampled sequence number. Specifically: When a client needs to retransmit a certain interval, if the circular buffer cannot find the cached records corresponding to all sampled sequence numbers within the missing sequence number interval (meaning some data within that interval has been overwritten by new data), the client sends a data non-retransmission flag frame (command word 0x07) to the server. The payload of this frame carries a list of unfounded sequence numbers. Upon receiving the data non-retransmission flag frame, the server marks the sampled sequence numbers for which no cached records can be found as "permanently missing" in its receive state table and no longer initiates retransmission requests for those sequence numbers, thus avoiding an infinite loop of retransmission request-response deadlock between the client and server due to data overwriting. This invention ensures the consistency of the protocol's state under extreme conditions through a final state marking mechanism.

[0068] In addition, as an optional optimization, the most recent N key data entries can be retained in the Flash non-volatile storage as a secondary cache, and attempts can be made to recover from Flash when the memory cache is missing, so as to further improve data recoverability.

[0069] In one optional implementation, the local cache is located in memory, and the local non-volatile storage is Flash memory. To extend the lifespan of Flash memory during the storage of sampling sequence numbers, the client adopts the following optimization strategies: Write operations on sampling sequence numbers are first completed in memory, and after completion, the sampling sequence number data in memory is batch-synchronized and transferred to Flash memory at a preset synchronization period or change count threshold; a change bitmap is used to record whether the sectors storing sampling sequence numbers in Flash memory have been modified; when synchronization is triggered, only the sectors recorded as modified in the change bitmap are written to Flash memory; a wear leveling algorithm is used to dynamically select the sectors with the fewest erase / write cycles for writing sampling sequence numbers; a log structure is used for storage, appending the sampling sequence number corresponding to newly uploaded industrial data as a new record, and periodically garbage collecting sectors where the proportion of invalid records exceeds a threshold; each record written to Flash memory includes the sampling sequence number, timestamp, and CRC32 checksum; the same sampling sequence number is stored in two independent sectors as backups.

[0070] Understandably, the local cache resides in RAM, while the local non-volatile storage is Flash memory. Since industrial field devices typically employ embedded systems, their Flash memory has a limited write / erase cycle life; for example, industrial-grade NOR Flash typically has a lifespan of 100,000 cycles. In high-frequency data acquisition scenarios, the sampling sequence number in the Flash memory needs to be updated after each successful upload. Without optimization, the Flash memory may run out of lifespan within hours. Therefore, this embodiment employs the following optimization strategies to extend the lifespan of the Flash memory during the storage of the sampling sequence number: 1. Double-buffered batch write strategy: Write operations on the sampling sequence number are first completed in memory, rather than being directly written to Flash. Specifically, two mirrored copies, a main buffer and a shadow buffer, are maintained in memory. All write operations (i.e., updates to the sampling sequence number) are first completed in the main buffer in RAM. The sampling sequence number data in memory is then batch-synchronized and transferred to the Flash memory at a preset synchronization period (e.g., every 10 seconds) or a change count threshold (e.g., every 1000 changes), with the earlier condition taking precedence. The use of a dual-condition triggering of the synchronization period and the change count threshold is to prevent memory buffer overflow in high-frequency change scenarios (change count threshold triggering) and to prevent data from being lost due to prolonged retention in memory during power outages in low-frequency change scenarios. The synchronization period triggering balances data security and Flash write lifespan.

[0071] 2. Incremental Change Tracking Strategy: A change bitmap is used to record whether the sector in the Flash memory containing the sampling sequence number has been modified. The change bitmap is a bit array, where each bit corresponds to a sector in the Flash memory. When the data in that sector is modified in memory, the corresponding bit is set to 1. When synchronization is triggered, only the change bitmap is traversed, and the sectors recorded as modified in the change bitmap are written to the Flash memory, while unmodified sectors are skipped, thus avoiding the need to erase and write the entire Flash memory every time synchronization is performed.

[0072] 3. Wear leveling strategy: A wear leveling algorithm is employed to dynamically select the sector with the fewest erase / write cycles for writing sampling sequence numbers. Specifically, an erase / write count table is maintained for each physical sector. Each time a write operation is needed, the physical sector with the fewest erase / write cycles is selected from all available sectors, and its erase / write count is incremented by 1. When the erase / write count of a sector reaches a certain threshold, it is marked, and the writing frequency to that sector is reduced. Through this dynamic rotation, the erase / write cycles of all physical sectors are evenly distributed, significantly reducing the difference and preventing premature single-point damage caused by repeated writing of hot data to the same sector.

[0073] 4. Log structure storage and garbage collection strategy: A log-based storage structure is used, appending the sampling sequence number corresponding to newly uploaded industrial data as a new record. This means new data does not overwrite old data; instead, it is written to the end of the current write pointer, which then advances. This append-only writing method avoids the operations required for in-place updates: traditionally, in-place updates in Flash require reading the entire sector, modifying it, and then erasing and rewriting, resulting in significant overhead. This method greatly reduces the number of erasures.

[0074] Meanwhile, garbage collection is performed periodically on sectors where the proportion of invalid records exceeds a threshold. Specifically, the system monitors the ratio of valid to invalid records in each sector. When the proportion of invalid records (old sequence number records that have been overwritten by new records) in a sector exceeds a preset threshold (e.g., 50%), a garbage collection operation is triggered. The still valid records in that sector are migrated to a new free sector, and then the sector is erased and its space is freed up for subsequent writing.

[0075] 5. Data redundancy and integrity verification strategies: Each record written to the Flash memory includes a sampling sequence number, a timestamp, and a CRC32 checksum to ensure data integrity. The CRC32 checksum of the record is calculated during writing and stored along with the data. It is recalculated and compared during reading. If the checksum fails, it indicates that the data is corrupted and can be recovered from a backup.

[0076] The same sampling sequence number is stored in two independent sectors, serving as backups for each other. During writing, the first sector is written first, and only after successful writing is confirmed is the second sector written. During reading, the first sector is read first; if its data is corrupted (CRC check fails), the data is read from the second sector. This dual-backup mechanism effectively prevents the unique copy from being corrupted due to unexpected power outages during Flash writing, ensuring that the client can reliably read the breakpoint sequence number after a device restart, thus guaranteeing that the breakpoint resume function operates normally under any circumstances.

[0077] The five optimization strategies mentioned above work together to form a complete Flash lifespan optimization solution: dual buffering reduces the number of write operations, bitmap modification reduces the number of sectors written, wear leveling distributes wear evenly, log structure reduces erase operations, garbage collection reclaims invalid space, and dual backup CRC ensures data security. Overall, this significantly extends the Flash lifespan and meets the requirements for long-term service of industrial equipment.

[0078] In a preferred embodiment, this embodiment further introduces write merging and page caching strategies, as well as lifetime estimation and dynamic degradation strategies, for Flash memory optimization. The merging and page caching strategy combines multiple small writes into a single large write. Specifically, a page cache with a size of 4KB (aligned with the Flash physical page size) is set in memory, and the merging timeout is set to 500ms. When the page cache is full (4KB) or the timeout condition is triggered, the data in the page cache is written to a complete physical page of the Flash memory at once, avoiding the read, modify, and write overhead caused by frequent page-level partial writes. All writes are aligned to the Flash page size to avoid additional erase overhead caused by cross-page writes. The lifetime estimation and dynamic degradation strategy includes real-time monitoring of the erase / write count of each sector and automatic calculation of the remaining lifetime (in days) based on the current erase / write frequency. When the number of erase / write cycles reaches 80% of the lifespan, the system outputs a warning log; when it reaches 90%, the synchronization frequency is automatically reduced (e.g., from 10 seconds to 30 seconds) to slow down the wear and tear of the Flash memory and extend its remaining lifespan; when it reaches 95%, the system switches to read-only mode, prohibiting any write operations and protecting existing data from damage.

[0079] In one feasible implementation, the client and server negotiate protocol versions via handshake frames to ensure interoperability between clients and servers with different software versions. Specifically, this includes: the client carrying its supported protocol version number in the handshake request frame; the server determining whether it supports the version number; if supported, it returns a handshake success response frame; if the server does not support the version number, it returns a version error frame, the payload of which carries a list of one or more protocol version numbers supported by the server; the client selects a matching protocol version from the list and re-initiates the handshake; if no common version is found, the error is recorded and manual intervention is awaited. The specific version negotiation process is as follows: 1) Initiating a handshake. After the TCP connection is established and before the data is actually uploaded, the client first sends a handshake request frame (command word 0x01). The payload of this frame carries the protocol version number it supports (e.g., 0x10).

[0080] 2) Server Decision. After receiving the handshake request, the server extracts the protocol version number and determines whether it supports that version. If it does, it returns a handshake success response frame (command word 0x81), the connection is officially established, and the client begins uploading data.

[0081] 3) Version mismatch handling. If the server does not support the version number, it returns a version error frame (command word 0xF1). The payload of this frame carries a list of one or more protocol version numbers supported by the server (e.g., [0x10, 0x11, 0x12]), informing the client of the range of protocol versions currently accepted by the server.

[0082] 4) Client-side downgrade retry. Upon receiving a version error frame, the client parses the server's list of supported versions and selects a matching lower protocol version to re-initiate the handshake. If the client supports a version in the list, it resends the handshake request using that version. If no common version is found, an error is logged, and manual intervention is requested, such as upgrading the client software or contacting the administrator.

[0083] This negotiation mechanism enables the server to be compatible with multiple protocol versions simultaneously. Older clients can continue to use lower versions to connect without upgrading, while new clients automatically use higher versions to enjoy new features, achieving smooth protocol evolution and backward compatibility.

[0084] Please continue reading. Figure 2 This is a schematic diagram of an industrial data breakpoint resume system provided by the present invention. This system is used to perform tasks such as... Figure 1 The method described in any one of the industrial data breakpoint resume methods provided herein, wherein the system includes a host computer client 201 and a host computer server 202, specifically including: the client 201 for collecting industrial data, assigning a unique sampling sequence number to each industrial data, encapsulating the industrial data and its corresponding sampling sequence number into a private protocol frame and uploading it to the server 202, monitoring the communication connection status between the client and the server 202 through a heartbeat mechanism, re-establishing the connection when the connection is interrupted, and storing the industrial data and its corresponding sampling sequence number in a local cache, and storing the sampling sequence number corresponding to the last successfully uploaded industrial data in local non-volatile storage; the server 202 for receiving and storing the private protocol frame uploaded by the client 201, maintaining a reception status table, querying the reception status table according to the breakpoint resume request initiated by the client 201, and returning the missing sequence number range to the client 201; the client 201 and the server 202 are directly connected via a standard TCP / IP network without an intermediate gateway layer.

[0085] It is understandable that the present invention achieves the following beneficial effects by using the above method: 1. Low protocol overhead and high communication efficiency: This invention employs private TCP long-connection communication, eliminating the need to re-establish a TCP connection for each data transmission, thus avoiding the overhead of TCP three-way handshake and four-way handshake in HTTP / JSON schemes. Furthermore, the private protocol frame header is significantly smaller than the HTTP header. In a local area network environment (Gigabit Ethernet, RTT < 1ms), uploading 64-byte sensor data at a frequency of 100 data packets / second, the end-to-end latency using the HTTP / JSON short-connection scheme is approximately 45ms, while the end-to-end latency using this private TCP long-connection scheme is approximately 8ms, significantly improving communication efficiency.

[0086] 2. Fast connection recovery and high data integrity: This invention utilizes a heartbeat keep-alive mechanism and a three-level connection failure detection mechanism: transmission failure detection, TCP event detection, and heartbeat timeout backup detection. This enables timely detection of connection interruptions in various network failure scenarios. After connection recovery, the server uses a sequence number interval retransmission mechanism to replace frame-by-frame enumeration with missing sequence number intervals, significantly reducing the number of communication interactions. Actual connection recovery time is only 2.5 seconds, significantly reducing the risk of data loss and achieving zero data loss when the cache is not overwritten.

[0087] 3. Low storage resource consumption and long Flash lifespan: This invention stores only industrial data and its corresponding sampling sequence number (and timestamp) in the client's local cache, without storing complete private protocol frames. This avoids the unnecessary storage space occupation of redundant information such as headers and checksums in the protocol frames, effectively saving storage space in embedded devices. Furthermore, addressing the limitations of Flash memory's erase / write lifespan, five collaborative optimization strategies are employed: double-buffered batch writing, incremental change tracking, wear leveling, log structure storage and garbage collection, and dual backup and CRC32 checksum. These strategies significantly extend the Flash lifespan, meeting the requirements for long-term service in industrial equipment.

[0088] 4. Simple architecture and good maintainability: The client and server use a standard TCP / IP network for direct connection, eliminating the need for an intermediate gateway layer. This results in a clear system topology and rapid fault location. The proprietary protocol version field supports smooth protocol evolution, allowing the server to be compatible with multiple protocol versions simultaneously. Existing clients can continue operating without upgrades, facilitating long-term system maintenance and functional expansion. A single server supports multiple concurrent TCP connections, meeting the needs of multiple devices accessing the system simultaneously in industrial environments.

[0089] 5. Significantly Enhanced Communication Security: Utilizing a proprietary TCP application layer protocol, with proprietary frame format and verification algorithms, effectively avoids the data snooping and attack risks faced by public network protocols. The dual verification mechanism of the start magic number segment and CRC16 checksum can accurately identify illegal data frames and prevent malicious data injection.

[0090] Furthermore, Figure 3 An internal structural diagram of a computer device according to one embodiment is shown. This computer device can specifically be a terminal or a server. Figure 3As shown, the computer device includes a processor, memory, and network interface connected via a system bus. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system and may also store a computer program, which, when executed by the processor, causes the processor to implement the method described in this invention. The internal memory may also store a computer program, which, when executed by the processor, causes the processor to perform the method described in this invention. Those skilled in the art will understand that… Figure 3 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0091] In one embodiment, a computer-readable storage medium is provided storing a computer program that, when executed by a processor, causes the processor to perform the method of the present invention.

[0092] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments described above. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and RAMbus dynamic RAM (RDRAM), etc.

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

[0094] The above description is merely a specific implementation of this application and is not intended to limit the scope of protection of this application. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A method for resuming interrupted industrial data transmission, applied to a system including a host computer client and a host computer server, characterized in that, The client connects to industrial field devices and includes local cache and local non-volatile storage; the method includes: The client collects industrial data from industrial field equipment, and each sampling window of industrial data corresponds to a unique sampling sequence number; the industrial data and its corresponding sampling sequence number are encapsulated into a private protocol frame and uploaded to the server, and the industrial data and its corresponding sampling sequence number are stored in the local cache, and the sampling sequence number corresponding to the last successfully uploaded industrial data is stored in the local non-volatile storage; The client uses a heartbeat mechanism to determine whether the communication connection with the server is interrupted. If the connection is interrupted, the connection is re-established. After the connection is restored, the client reads the sampling sequence number corresponding to the last successfully uploaded industrial data from the local non-volatile storage and sends a resume request containing the sampling sequence number to the server. After receiving the breakpoint resume request, the server queries the reception status table using the sampling sequence number as an index, determines the sampling sequence number range whose status in the reception status table is not received, and returns the sampling sequence number range as a missing sequence number range to the client; wherein, the reception status table is used to record whether the private protocol frame corresponding to each sampling sequence number has been received by the server. The client retrieves industrial data corresponding to all serial numbers within the missing serial number range from the local cache according to the missing serial number range, re-encapsulates the industrial data and its corresponding sampling serial number into a private protocol frame for retransmission, thereby completing the interrupted transmission of industrial data. The local cache does not store complete private protocol frames, but only the industrial data and its corresponding sampling sequence number.

2. The industrial data breakpoint resume method according to claim 1, characterized in that, The proprietary protocol frame includes a fixed-length header and a variable-length payload field. The header consists of: The starting magic number field is 2 bytes long and has a fixed value of 0x5A5A. The protocol version field has a length of 1 byte. The command field has a length of 1 byte; The data length field is 2 bytes long and uses big-endian order, indicating the number of bytes in the payload field; The checksum field is 2 bytes long and is calculated using the CRC16_Modbus algorithm. Its polynomial is 0x8005, its initial value is 0xFFFF, and its output XOR value is 0xFFFF.

3. The method according to claim 1, characterized in that, In the heartbeat mechanism, the client sends a heartbeat frame to the server every 30 seconds, and the server returns a heartbeat response frame to the client after receiving the heartbeat frame. If no heartbeat response frame is received for three consecutive times, the connection is considered interrupted. The reconnection is established using an exponential backoff strategy, which is as follows: the initial reconnection waiting time is 1 second, and the waiting time increases by 2 times after each failed reconnection until it reaches the upper limit of 60 seconds, after which it maintains a 60-second interval for continuous reconnection.

4. The method according to claim 1, characterized in that, The method by which the server determines the sampling sequence number range in the reception status table that is not received is as follows: Starting from the sampling sequence number corresponding to the last successfully uploaded industrial data, the receiving status table is traversed from that sequence number onwards; Find the first sampling sequence number with a status of "not received" and continue searching until a sampling sequence number with a status of "received" is encountered or the end of the reception status table is reached. All unreceived sampling sequence numbers found are merged into the missing sequence number range.

5. The method according to claim 1, characterized in that, The local cache is a circular buffer implemented using a circular array, and each cache record contains a sampling sequence number, a timestamp, and industrial data. The client traverses the circular buffer according to the missing sequence number range, extracts the cache records corresponding to all sampled sequence numbers within the missing sequence number range, sorts them in ascending order of sampled sequence numbers, and re-encapsulates them into a private protocol frame for retransmission.

6. The method according to claim 5, characterized in that, If the circular buffer cannot find the cache record corresponding to all the sampled sequence numbers in the missing sequence number interval, the client sends a data non-retransmission identifier frame to the server. After receiving the data non-retransmission flag frame, the server marks the sampling sequence number for which no cache record can be found as permanently missing in the reception status table and no longer initiates a retransmission request for that sampling sequence number.

7. The method according to claim 1, characterized in that, The local cache is located in memory, and the local non-volatile storage is Flash memory. To extend the lifespan of the Flash memory during the storage of the sampling sequence number, the client adopts the following optimization strategy: The write operation of the sampling sequence number is first completed in the memory. After completion, the sampling sequence number data in the memory is batch synchronously transmitted to the Flash memory at a preset synchronization period or change number threshold. A change bitmap is used to record whether the sector in the Flash memory that stores the sampling sequence number has been modified. When synchronization is triggered, only the sector recorded as modified in the change bitmap is written to the Flash memory. A wear leveling algorithm is used to dynamically select the sector with the fewest erase / write cycles for writing the sampling sequence number; The system uses a log structure for storage, appending the sampling sequence number corresponding to newly uploaded industrial data as a new record, and periodically garbage collecting sectors where the proportion of invalid records exceeds a threshold. Each record written to the Flash memory includes a sampling sequence number, a timestamp, and a CRC32 check value; the same sampling sequence number is stored in two independent sectors as backups of each other.

8. The method according to claim 1, characterized in that, The client and the server negotiate the protocol version through a handshake frame, specifically including: The client carries the protocol version number it supports in the handshake request frame; The server determines whether it supports the version number; if it does, it returns a handshake success response frame. If the server does not support the version number, a version error frame is returned, the payload of which carries a list of one or more protocol version numbers supported by the server. The client selects a matching protocol version from the list to re-initiate the handshake. If no common version is found, the error is recorded and manual intervention is requested.

9. An industrial data breakpoint resume system, characterized in that, The system is used to perform the method as described in any one of claims 1 to 8, and the system includes a host computer client and a host computer server, specifically including: The client is used to collect industrial data from industrial field equipment, assign a unique sampling sequence number to the industrial data of each sampling window, encapsulate the industrial data and its corresponding sampling sequence number into a private protocol frame and upload it to the server, monitor the communication connection status with the server through a heartbeat mechanism, re-establish the connection when the connection is interrupted, and store the industrial data and its corresponding sampling sequence number in a local cache, and store the sampling sequence number corresponding to the last successfully uploaded industrial data in local non-volatile storage. The server is used to receive and store the private protocol frames uploaded by the client, maintain a reception status table, query the reception status table according to the breakpoint resume request initiated by the client, and return the missing sequence number range to the client. The client and the server are directly connected via a standard TCP / IP network without any intermediate gateway layer.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it causes the processor to perform the steps of the method as described in any one of claims 1 to 8.

Images