A method and system for industrial mobile node-oriented off-network data retransmission

Abstract

The present application relates to the technical field of industrial internet of things and edge computing, and particularly relates to a kind of network outage data supplement transmission method and system for industrial mobile node. Service data generated by industrial mobile node is received by edge computing unit, and device identification, metadata version, access instance lease epoch, start epoch and service category are determined. When connection is interrupted or metadata version is not confirmed to be receivable, write corresponding cache partition according to partition key. Send cache partition summary after connection is restored. Cloud platform determines version receiving state and lease receiving state according to cache partition summary, generates supplement transmission plan in combination with confirmed sequence number and access service load. Edge computing unit selects data for supplement transmission according to supplement transmission plan. The present application can solve or at least alleviate historical data decoding error and control state interference problems caused by cloud instance switching and service data model upgrading during network outage, and provides a kind of network outage data supplement transmission method and system for industrial mobile node.

Description

Technical Field

[0001] This invention relates to the fields of industrial Internet of Things and edge computing technology, and in particular to a method and system for retransmitting disconnected data for industrial mobile nodes. Background Technology

[0002] In flexible manufacturing, warehousing and logistics, smart mining, and industrial inspection scenarios, automated guided vehicles (AGVs), autonomous mobile robots, mining mobile devices, and inspection robots typically upload business data such as location, speed, status, alarms, task receipts, and configuration receipts to the cloud platform when performing transportation, inspection, or handling tasks via onboard controllers and edge computing units. When industrial mobile nodes enter areas with dense shelving, underground passages, tunnels, shielded rooms, or areas with dense metal equipment, the communication connection between the edge computing unit and the cloud platform may be interrupted. The edge computing unit typically writes the unuploaded data to a local cache and continues to send it after the connection is restored.

[0003] Existing processing methods typically fall into three categories: The first category uses publish-subscribe protocols or message queue protocols to store unacknowledged messages and continues sending them after the connection is restored. The second category uses a metadata version table to record the business data model version and decodes the received data on the cloud platform according to the current version. The third category uses a service instance lease mechanism to determine the current access service instance, which then receives the data after the connection is restored. These methods address connection restoration, metadata version management, and service instance switching respectively. However, when both access service instance switching and business data model upgrades occur simultaneously during a network outage, cached data may still carry the old lease epoch and old metadata version.

[0004] In the above scenarios, if the edge computing unit directly retransmits cached data after the connection is restored, the cloud platform may decode the old version data according to the new version field structure or the new version field semantics, and the old unit field and the old enumeration field will be written into the current business table. If the edge computing unit restarts during the network outage, the cached data sequence number may be reassigned from the initial value. When the cloud platform performs deduplication based only on the device identifier and sequence number, duplicate writing or conflict writing may occur. If the control confirmation data generated during the processing cycle of the old access service instance is processed as the current confirmation data by the current access service instance, the control state machine may be advanced by the old confirmation data. If the metadata version of the security-related fields has not been synchronized, the emergency stop state, collision state, or security gate state may be queued with historical data and wait for decoding.

[0005] The above problems arise because existing network outage resume mechanisms typically treat cached data as continuous data within the same logical session, controlling retransmission only based on device identifiers and sequence numbers. They fail to incorporate access instance lease periods and edge startup epochs into the cache partition key to differentiate the processing cycles of different access service instances and the sequence number space before and after edge restarts. Furthermore, existing version management often focuses on consistency checks of field structures, lacking independent summary descriptions for semantic changes such as field units, proportional coefficients, and enumerated versions. This makes it difficult for the cloud platform to promptly identify semantic inconsistencies during decoding. Additionally, during network outages, cloud platform upgrades to business data models and switching of access instances often do not correlate with historical data cached at the edge, lacking isolated paths for old lease period control confirmation data and configuration receipt data. Summary of the Invention

[0006] To achieve the above-mentioned objectives, this invention provides a method and system for retransmitting data lost during network outages for industrial mobile nodes, which can solve or at least mitigate the problems of historical data decoding errors and control state interference caused by cloud instance switching and business data model upgrades during network outages.

[0007] To achieve the above objectives, the present invention provides the following technical solution: a method for retransmitting disconnected data for industrial mobile nodes, comprising: The edge computing unit receives service data generated by industrial mobile nodes and determines the device identifier, metadata version, access instance lease epoch, startup epoch, and service category corresponding to the service data; wherein, the startup epoch is generated by the edge computing unit at startup and is used to distinguish the data sequence number space before and after the edge computing unit restarts; When the connection between the edge computing unit and the cloud platform is interrupted, or when the metadata version has not yet been confirmed as receivable by the cloud platform, the service data is written to the local cache partition according to the partition key composed of the device identifier, the metadata version, the access instance lease epoch, and the startup epoch. The service category is used for data diversion processing within the cache partition and does not participate in the composition of the partition key. After the connection is restored, the edge computing unit reports a cache partition summary to the cloud platform; The cloud platform determines the version reception status and lease reception status of each cache partition based on the cache partition summary, and generates a retransmission plan; The edge computing unit performs data retransmission according to the retransmission plan. When the lease reception status is invalid, control confirmation data and configuration receipt data do not participate in the current control status advancement.

[0008] To further realize the present invention, the following technical solutions may be preferred: Preferably, when the edge computing unit receives business data generated by the industrial mobile node, it also generates summary information carrying structural and semantic features based on the metadata version. The summary information includes a structural summary and a semantic summary. The structural summary is generated based on field name, field type, field order, and field length, and is used to characterize changes in field structure. The semantic summary is generated based on field identifier, field unit, scale factor, offset, enumeration mapping version, and field meaning tag, and is used to characterize changes in field semantics.

[0009] Preferably, the cache partition summary includes the partition key, the structure summary, the semantic summary, the data volume, the sequence number range, and the business category distribution. The partition key is composed of the device identifier, metadata version, access instance lease epoch, and startup epoch. The business category distribution is used to characterize the amount or proportion of data of different business categories within the corresponding cache partition.

[0010] Preferably, writing the business data to the local cache partition according to the partition key includes: The cached records containing the sequence number, structure summary, semantic summary, the business category, payload summary, and original payload are written to the cache partition in sequence number order; When the local cache space reaches a preset level, the cached record is evicted based on a retention score calculated by weighting business importance, version reception status score, lease status score, and cache dwell time.

[0011] Preferably, the version reception status is determined in the following manner: If the cloud platform has a corresponding metadata version and the structural digest and semantic digest are consistent, it is determined to be acceptable; When the cloud platform has a corresponding metadata version with consistent structural digests but inconsistent semantic digests, it is determined that the semantics are pending confirmation. If the corresponding metadata version does not exist on the cloud platform, but a bridging record is matched in the version compatibility table, it is determined to be bridgingable; If the corresponding metadata version does not exist on the cloud platform and no bridging record is matched, it is determined to be pending synchronization.

[0012] Preferably, the lease acceptance status is determined in the following manner: The lease epoch of the access instance corresponding to the cache partition is compared with the currently maintained valid lease epoch of the cloud platform. If they match, it is determined to be valid; if they do not match, it is determined to be invalid.

[0013] Preferably, the retransmission plan is generated in the following manner: Based on the maximum consecutive acknowledgment number of each cache partition, the version reception status, the lease reception status, and the access service load, a retransmission window is determined for each cache partition. The access service load includes at least one of the following: the length of the pending retransmission queue of the current access service module, the number of available processing threads, the processing throughput, the CPU utilization rate, the memory utilization rate, and the network transmission or reception bandwidth utilization rate. The retransmission window includes a start sequence number and an end sequence number. The start sequence number is the sequence number of the first unacknowledged cache record after the maximum consecutive acknowledgment sequence number of the corresponding cache partition. The end sequence number is determined based on the access service load, the version reception status, and the lease reception status. When the version reception status is bridgeable, the corresponding field mapping identifier is carried in the retransmission plan; When the lease receipt status is invalid and the service category is a control confirmation or configuration receipt, no retransmission window is generated for the corresponding cache partition to advance the current control status.

[0014] Preferably, the step of the edge computing unit performing data retransmission according to the retransmission plan includes: For cache partitions with a version reception status of "acceptable", send cache data according to the retransmission window. For cache partitions with a version reception status of bridgeable, old version data is sent, and the cloud platform converts and decodes it according to the field mapping rules corresponding to the field mapping identifier. For cache partitions whose version reception status is pending synchronization, respond to the metadata request from the cloud platform and do not send business payloads for the time being.

[0015] Preferably, the step of the edge computing unit performing data retransmission according to the retransmission plan further includes: For cache partitions with invalid lease acceptance status, the edge computing unit generates derived status observation records for data with the service category of control confirmation and sends them to the cloud platform, which then writes the derived status observation records into the device's historical status trajectory. The edge computing unit marks the data with the service category of configuration receipt as being retransmitted and sends it to the cloud platform, which then performs auditing and storage on the data with the configuration receipt category without updating the current configuration status. When the version reception status is pending synchronization and there is a cached record with an urgent flag, the edge computing unit reads the security status field from the original payload according to the preset security field mapping table, generates a security micro-message, and sends it to the cloud platform first. The cloud platform then performs security event processing on the security micro-message.

[0016] A data transmission recovery system for industrial mobile nodes after network outages, comprising an edge computing unit and a cloud platform; The edge computing unit includes a data receiving module, a version identification module, a cache partitioning module, a retransmission execution module, and a security field mapping module. The output of the data receiving module is connected to the inputs of the version identification module and the cache partitioning module, and is used to receive service data generated by industrial mobile nodes. The version identification module is used to determine the metadata version corresponding to the service data and generate a structure digest and a semantic digest. The cache partitioning module is used to write the service data to a local cache partition according to a partition key during network outages. The input of the retransmission execution module is connected to the output of the cache partitioning module, and is used to select data from the corresponding cache partition and send it to the cloud platform according to the retransmission plan. The security field mapping module is connected to the retransmission execution module and is used to generate a secure micro-message when the metadata version reception status of the service data is pending synchronization. The cloud platform includes an access service module, a metadata management module, a lease management module, a version compatibility management module, a retransmission plan generation module, an idempotent processing module, and a security processing module. The input of the access service module is communicatively connected to the output of the retransmission execution module, used to receive cache partition summaries and retransmission data. The input of the metadata management module is connected to the output of the access service module, used to determine the version reception status. The input of the lease management module is connected to the output of the access service module, used to determine the lease reception status. The version compatibility management module is connected to the metadata management module, used to maintain a version compatibility relationship table to provide field mapping rules. The input of the retransmission plan generation module is connected to the outputs of both the metadata management module and the lease management module, used to generate a retransmission plan. The input of the idempotent processing module is connected to the output of the access service module, used to perform deduplication processing on the received retransmission data. The security processing module is connected to the access service module, used to receive and process the security micro-messages.

[0017] The beneficial effects of this invention are: This invention enables data cached during network outages to be differentiated according to version status, lease status, and restart status after connection recovery by setting metadata version, access instance lease epoch, and startup epoch in the cache partition key; it allows the cloud platform to distinguish cached data with the same field structure but different field units, proportional coefficients, or enumeration meanings through the reporting of structural and semantic digests; it allows older version data with compatibility relationships to enter the corresponding storage path after conversion by field mapping rules through version bridging processing; it prevents control confirmation data and configuration receipt data within the old access instance cycle from entering the current control state's progress process by using business category diversion under lease invalidation status; it distinguishes sequence number rollback data after edge computing unit restart by using startup epoch and payload digest in idempotency judgment; and it allows the emergency stop status, collision status, or security gate status of metadata version pending synchronization to be read separately and sent to the security processing module through a security field mapping table and security micro-messages. Attached Figure Description

[0018] Figure 1 This is a schematic diagram of the system architecture of the present invention.

[0019] Figure 2 This is a schematic diagram of the main flow of the method of the present invention.

[0020] Figure 3 This is a schematic diagram of the process by which the cloud platform of the present invention determines the metadata version reception status.

[0021] Figure 4 This is a schematic diagram of the business category differentiation processing flow under the invalid lease state of the present invention.

[0022] Figure 5 This is a schematic diagram of the secure micro-message generation process of the present invention. Detailed Implementation

[0023] In the description of this invention, it should also be noted that, unless otherwise explicitly specified and limited, the terms "set," "install," "connect," and "link" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0024] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0025] In this embodiment, the access instance lease epoch is issued by the cloud platform when the edge computing unit registers or establishes a session, and is updated when an access service instance switch occurs on the cloud platform side. The access instance lease epoch is used to identify the processing cycle of the currently valid access service instance on the cloud platform and is not used to replace the device authentication of the industrial mobile node. The startup epoch is generated by the edge computing unit each time it powers on or restarts the software, based on the current timestamp or a local persistent counter. It remains unchanged within one operating cycle and is used to distinguish the sequence number space generated before and after the edge computing unit restarts, avoiding the cloud platform misjudging new data after the restart as duplicate data due to sequence number rollback. Example 1

[0026] This embodiment provides a data recovery system for industrial mobile nodes in the event of a network outage. See also... Figure 1 As shown, the system includes an edge computing unit deployed on an industrial mobile node and a cloud platform deployed in a data center. The edge computing unit and the cloud platform interact via a wireless network. The industrial mobile node can be at least one of an automated guided vehicle, an autonomous mobile robot, a mining mobile device, or an inspection robot. When the industrial mobile node enters a signal-blocked area during task execution, a network interruption occurs. During the network outage, the industrial mobile node continues to generate sensor data, operating status data, alarm data, task execution receipts, control confirmation data, and configuration receipt data. This data is temporarily stored locally by the edge computing unit and retransmitted to the cloud platform after the connection is restored.

[0027] See Figure 1As shown, the edge computing unit includes a data receiving module, a version identification module, a cache partitioning module, a retransmission execution module, a feedback processing module, and a security field mapping module. The data receiving module receives business data generated by sensors, controllers, actuators, or vehicle control systems on the industrial mobile node. This business data includes at least one of telemetry data, alarm data, control confirmation data, configuration receipt data, and operation log data. The output of the data receiving module is connected to the input of the version identification module and the input of the cache partitioning module, and is used to transmit the received business data to the version identification module and the cache partitioning module. The version identification module identifies the metadata version identifier corresponding to the business data and generates a structural digest and a semantic digest based on the metadata content. The structural digest is generated based on field name, field type, field order, and field length. The semantic digest is generated based on field identifier, field unit, scale factor, offset, enumerated mapping version, and field meaning tag. Specifically, the structural digest and the semantic digest can be generated using a preset hash algorithm, such as SHA-256, SM3, or other hash algorithms capable of generating digest values. This invention is not limited to a specific hash algorithm. The structural digest and the semantic digest are calculated independently to allow the cloud platform to distinguish cases where the field structure remains unchanged but the field unit, proportional coefficient, or enumeration meaning changes. The cache partitioning module is used to write the data to be sent into the local cache according to the partition key during the connection interruption between the edge computing unit and the cloud platform. Different partition keys correspond to different cache partitions. The partition key is a combination key composed of device identifier, metadata version, access instance lease epoch, and startup epoch. The service category does not participate in the composition of the partition key but serves as a classification field recorded in the cache partition for subsequent retransmission plan generation, lease invalidity diversion, and audit processing. The input end of the retransmission execution module is connected to the output end of the cache partitioning module and is used to select data from the specified cache partition for transmission according to the retransmission plan issued by the cloud platform. The feedback processing module is used to receive confirmation information, version reception status, lease reception status, and next round of retransmission plan returned by the cloud platform. The security field mapping module is connected to the retransmission execution module and is used to read the security status field from the original payload and generate a security micro-message according to a preset security field mapping table when the metadata version reception status of the business data is pending synchronization. The security field mapping table is independent of the current application layer business metadata version and remains stable within a preset device model and version range. It is used to read a specified security status value from a predetermined security status field in the original payload when the business data model cannot be decoded temporarily.

[0028] See also Figure 1As shown, the cloud platform includes an access service module, a metadata management module, a lease management module, a version compatibility management module, an idempotent processing module, a retransmission plan generation module, a confirmation feedback module, and a security processing module. The input of the access service module is communicatively connected to the output of the retransmission execution module, and is used to receive data, cache partition summaries, and secure micro-messages sent by the edge computing unit. The input of the metadata management module is connected to the output of the access service module, and is used to determine the version reception status of each cache partition based on the cache partition summary. The metadata management module maintains a metadata version table, which records the structure summary, semantic summary, and version reception status of each metadata version. The version reception status includes receiveable, pending synchronization, bridging, semantic confirmation pending, and decommissioned. The input of the lease management module is connected to the output of the access service module, and is used to determine the lease reception status of each cache partition based on the cache partition summary. The lease management module maintains the lease epoch of the currently valid access service instance. The access instance lease epoch is used to identify the processing cycle of the currently valid access service instance of the cloud platform and is not used to replace the device identity authentication of the industrial mobile node. The version compatibility management module is connected to the metadata management module and is used to maintain a version compatibility relationship table. This table records field mapping rules, unit conversion rules, default value rules, and applicable device models between old and new versions. The input of the retransmission plan generation module is connected to the output of both the metadata management module and the lease management module, and is used to generate a retransmission plan based on the metadata version reception status, lease reception status, confirmed sequence number, service category, and access service load. The input of the idempotent processing module is connected to the output of the access service module and is used to determine whether the received data has been processed based on the device identifier, metadata version, startup epoch, sequence number, and payload digest. The confirmation feedback module is used to return confirmation information, version status, lease status, and the next round of retransmission plan to the edge computing unit. The security processing module is connected to the access service module and is used to receive and process the security micro-messages.

[0029] In one specific implementation, the edge computing unit logically partitions the cached data using a composite key as the partition key. The partition key K is composed of the device identifier (device_id), metadata version (config_version), access instance lease epoch (lease_epoch), and boot epoch (boot_epoch), and can be represented as K = (device_id, config_version, lease_epoch, boot_epoch). Here, device_id is the device identifier, config_version is the metadata version, lease_epoch is the access instance lease epoch, and boot_epoch is the boot epoch of the edge computing unit. The boot epoch is used to distinguish cached data generated before and after the edge computing unit restarts, avoiding ambiguity in the cloud platform's idempotency judgment caused by sequence number rollback.

[0030] Each cache record in each cache partition includes a sequence number, a structure summary, a semantic summary, a service category, a payload summary, an expiration time, an event timestamp, the original payload, an emergency flag, and a motion state snapshot. The service category includes at least telemetry, alarm, control confirmation, and configuration receipt categories. The emergency flag is used to identify whether the cache record is associated with chassis emergency stop, collision trigger, or other physical safety events. Example 2

[0031] This embodiment provides a method for retransmitting data lost due to network outages. The method is implemented based on the system described in Embodiment 1. See also... Figure 2 As shown, the method includes the following steps.

[0032] Step S1: Edge computing unit generates cache records The edge computing unit receives service data generated by industrial mobile nodes and determines the device identifier, metadata version, access instance lease epoch, startup epoch, and service category corresponding to the service data, and generates a sequence number, structure digest, semantic digest, payload digest, and event timestamp.

[0033] Specifically, the data receiving module receives the business data generated by the industrial mobile node and obtains the device identifier. The version identification module identifies the metadata version corresponding to the business data and calculates the structural digest and semantic digest based on the metadata content.

[0034] The structure digest is generated based on the field name (field_name), field type (field_type), field order (field_order), and field length (field_length). Specifically, the edge computing unit can combine the field name, field type, field order, and field length according to a preset field arrangement rule, and generate a structure digest (structure_digest) using a preset hash algorithm to characterize changes in field structure. The preset hash algorithm can be SHA-256, SM3, or other hash algorithms capable of generating digest values; this invention is not limited to a specific hash algorithm.

[0035] The semantic digest is generated based on the field identifier (field_id), field unit (unit), scale (scale), offset (offset), enumeration map version (enum_map_version), and meaning tag (meaning_tag). Specifically, the edge computing unit can combine the field identifier, field unit, scale, offset, enumeration map version, and meaning tag according to a preset field arrangement rule, and generate a semantic digest (semantic_digest) using a preset hash algorithm to characterize the semantic changes of the field. The preset hash algorithm can be SHA-256, SM3, or other hash algorithms capable of generating digest values; this invention is not limited to a specific hash algorithm.

[0036] Accordingly, the edge computing unit assigns an incrementing sequence number to data under the same device identifier and generates a payload summary for that data. The edge computing unit obtains the current access instance lease epoch, which is issued by the cloud platform or obtained from the most recent valid interaction feedback. The edge computing unit determines the service category based on the data source, data topic, or data type, including telemetry, alarm, control confirmation, and configuration receipt categories. The edge computing unit records the event timestamp associated with the data, which can be the device generation time, controller event time, edge reception time, or cache write time. When the event timestamp is not the device generation time, the edge computing unit records the time source identifier. Optionally, the edge computing unit records a motion state snapshot at the time the data is generated, which includes at least one of velocity, acceleration, steering angular velocity, or change in direction.

[0037] Step S2: Edge computing units establish partitioned caches When the connection is interrupted or the metadata version has not yet been confirmed as acceptable by the cloud platform, the service data is written to the corresponding cache partition according to the partition key composed of the device identifier, the metadata version, the access instance lease epoch, and the startup epoch. The service category is written to the corresponding cache partition as a cache record field and does not participate in the composition of the partition key.

[0038] Specifically, the edge computing unit determines the connection status with the cloud platform. If the connection is unavailable, or if the connection is available but the metadata version of the current service data has not been confirmed as acceptable by the cloud platform, the edge computing unit writes the service data into its local cache. The cache partitioning module locates or creates the corresponding cache partition according to the partition key K, which is composed of the device identifier (device_id), metadata version (config_version), access instance lease epoch (lease_epoch), and boot epoch (boot_epoch), and writes the cache records into the corresponding cache partitions in sequence; wherein, the partition key K can be represented as K = (device_id, config_version, lease_epoch, boot_epoch). If records with the same sequence number and the same payload digest appear, one record is retained and its confirmation status is updated. The edge computing unit logically groups multiple cache partitions under the same device identifier into one partition group to facilitate status aggregation and reporting.

[0039] Furthermore, when the local cache space reaches a preset level, the edge computing unit evicts cached records based on their retention scores. The retention score is calculated by weighting factors such as business importance, version reception status, lease status, security-related flags, cache dwell time, and record space usage; the weights are configured by the system. The edge computing unit prioritizes evicting records with low retention scores.

[0040] Step S3: The cloud platform receives the cache partition summary and determines the status. After the connection is restored, a cache partition summary is sent, and the cloud platform determines the version reception status and lease reception status based on the cache partition summary.

[0041] Specifically, after the connection is restored, the edge computing unit reports a cache partition summary to the cloud platform. The cache partition summary includes the partition key, data volume, sequence number range, structure summary, semantic summary, and service category distribution of each cache partition. The edge computing unit can group multiple cache partitions under the same device identifier into a partition group and report the partition key, data volume, sequence number range, structure summary, semantic summary, and service category distribution of each cache partition to the cloud platform in batches.

[0042] The cloud platform's metadata management module determines the version reception status of the cache partition based on the reported config_version, structure digest, and semantic digest. See also... Figure 3 As shown, the determination of the version reception status includes: if the metadata version exists in the cloud and the structure digest and semantic digest are consistent, then the version is marked as receivable; if the metadata version exists in the cloud, the structure digest is consistent but the semantic digest is inconsistent, then the version is marked as semantics pending confirmation, business decoding is not performed temporarily, and the edge computing unit is requested to update the semantic information; if the metadata version does not exist in the cloud, but the cloud platform can match a bridging record in the version compatibility relationship table based on the metadata version identifier, structure digest, semantic digest, device model or the minimum metadata description reported by the edge computing unit, then the version is marked as bridgingable; if the metadata version does not exist in the cloud and there is no bridging record, then the version is marked as pending synchronization, and a metadata request instruction is generated.

[0043] The cloud platform's lease management module compares the reported lease_epoch with the current valid lease epoch. If they match, the cache partition lease is marked as valid; if they do not match, the cache partition lease is marked as invalid, and the inconsistency status between the reported lease epoch and the current valid lease epoch, along with the corresponding epoch identifier, is recorded.

[0044] Step S4: The cloud platform generates a retransmission plan. The cloud platform determines the version reception status and lease reception status based on the cache partition summary, and generates a retransmission plan by combining the confirmed sequence number, service category and access service load. The access service load includes at least one of the following: the length of the pending retransmission queue of the current access service module, the number of available processing threads, the processing throughput, the CPU utilization rate, the memory utilization rate and the network sending or receiving bandwidth utilization rate.

[0045] Specifically, the idempotency processing module of the cloud platform constructs an idempotency key I based on the device identifier (device_id), metadata version (config_version), boot epoch (boot_epoch), sequence number (seq), and payload digest (payload_hash). The idempotency key I can be represented as I = (device_id, config_version, boot_epoch, seq, payload_hash), and is used to determine whether the received data has been processed.

[0046] The cloud platform calculates the maximum consecutive confirmation number for each cache partition. If sequence numbers 1 to n in a cache partition have been confirmed and sequence number n+1 has not been confirmed, then the maximum consecutive confirmation number for that cache partition is n.

[0047] In this embodiment, the access service load is used to characterize the availability and congestion level of the cloud platform's current access service module in processing retransmission data. The access service load includes at least one of the following: pending retransmission queue length, available processing threads, processing throughput, CPU utilization, memory utilization, and network transmit or receive bandwidth utilization. The cloud platform dynamically adjusts the retransmission window size of each cache partition based on the access service load; when the pending retransmission queue length, CPU utilization, memory utilization, or network bandwidth utilization exceeds a corresponding preset threshold, the current retransmission window is reduced; when the available processing threads or processing throughput is higher than a corresponding preset threshold, the current retransmission window is increased.

[0048] The retransmission plan generation module generates a retransmission plan for each cache partition based on the version reception status, lease reception status, confirmed sequence number, service category, and access service load. The retransmission plan includes a partition key, confirmed sequence number, receivable version table, version table to be synchronized table, bridging version table and corresponding field mapping identifiers, semantic unconfirmed status, valid lease epoch, retransmission window, service quality level cap, and a list of non-degradable service categories. The retransmission window starts with the sequence number of the first unconfirmed data after the confirmed sequence number and ends with the sequence number corresponding to the maximum number of data items allowed for retransmission in this round. The maximum number of data items allowed for retransmission in this round is determined based on the access service load, service category, version reception status, and lease reception status. When the length of the pending retransmission queue, CPU utilization, memory utilization, or network bandwidth utilization exceeds the corresponding preset threshold, the maximum number of data items allowed for retransmission in this round is reduced; when the number of available processing threads or processing throughput is higher than the corresponding preset threshold, the maximum number of data items allowed for retransmission in this round is increased.

[0049] Furthermore, for cache partitions with a bridgeable version status, the retransmission plan carries the corresponding field mapping identifier. After receiving old version data, the cloud platform converts and decodes it according to the field mapping rules pre-stored in the version compatibility table. The field mapping rules include field name mapping rules, unit conversion rules, and default value rules for fields that do not exist in the old version. For fields added in the new version but not present in the old version, the field mapping rules can be set to default value, null value, or pending confirmation mark. Fields set to pending confirmation mark do not participate in control state advancement. When the lease reception status is invalid and the business category is control confirmation or configuration receipt, no retransmission window is generated to advance the control state.

[0050] Step S5: The edge computing unit executes the retransmission plan. The edge computing unit selects data for retransmission according to the retransmission plan. When the lease reception status is invalid, control confirmation data and configuration receipt data are prohibited from entering the current control status process, while telemetry data that meets the version reception conditions are allowed to enter the historical retransmission path.

[0051] Specifically, the edge computing unit receives the retransmission plan and cleans up locally confirmed data according to the acknowledgment number in the retransmission plan. For cache partitions with an acceptable version status, the edge computing unit selects and sends data according to the retransmission window. For cache partitions with a bridging version status, the edge computing unit sends old version data according to the retransmission window, and the cloud platform receives it and converts and decodes it according to the field mapping rules. For cache partitions with a pending synchronization version status, the edge computing unit does not send the service payload for the time being, but first responds to the cloud platform's metadata request and sends the corresponding metadata or minimum metadata description.

[0052] See Figure 4 As shown, for cache partitions with invalid leases, the edge computing unit and the cloud platform perform differentiated processing according to business categories. For data categorized as telemetry, if the version reception status is receivable or bridging and has not expired, retransmission is allowed, and the data enters the historical data storage path after retransmission. For data categorized as alarms, if it is within a preset late arrival time window, it enters the alarm review path. After verification that it matches the current device status, event time, and deduplication records, alarm notifications or status flags are allowed to be triggered. If it exceeds the late arrival time window, only the data is retransmitted to the historical alarm database, without triggering real-time alarm linkage. For data categorized as control confirmation, the edge computing unit does not change its original business category. Instead, it extracts fields that can independently characterize the physical state from the original payload of the data. These fields include at least one of the following: end effector absolute position, fork height, current chassis speed, load weight, or clamp opening / closing status. A derived state observation record carrying an old lease source tag is generated. This derived state observation record is sent to the cloud platform during this round of retransmission. The cloud platform writes the derived state observation record into the device's historical state trajectory according to the event time it carries, without overwriting the current real-time state or triggering control state machine transitions. For data categorized as configuration receipt, the edge computing unit marks it for retransmission and sends it to the cloud platform. The cloud platform writes it into the audit database but does not use it to update the current configuration state.

[0053] See Figure 5As shown, for cached records with an urgent flag and a version status of "awaiting synchronization," the edge computing unit initiates a security field mapping module. This module verifies whether the source metadata version of the cached data falls within the applicable source metadata version range recorded in a preset security field mapping table, and performs payload verification according to the verification rules recorded in the security field mapping table. The security field mapping table includes device model, mapping table version, applicable source metadata version range, byte offset, bit offset, field length, end-order identifier, security status type, and verification rules. After successful verification, the security field mapping module reads the value of the security status field from the original payload of the cached data according to the byte offset, bit offset, field length, and end-order identifier recorded in the security field mapping table, generating a security micro-message. This security micro-message includes device identifier, event time, source metadata version, mapping table version, security status type, security status value, and verification information. The security micro-message is preferentially sent to the cloud platform at a security service quality level no lower than a preset level, without being limited by the current historical retransmission window. When the source metadata version does not fall within the applicable source metadata version range or the verification fails, the edge computing unit does not generate the security micro-message and keeps the corresponding cached data in a state of pending synchronization.

[0054] During historical retransmission, if the edge computing unit generates new high-priority urgent data locally, or receives a priority sending instruction from the cloud platform, the retransmission execution module suspends the sending of the current historical retransmission window and inserts the urgent data into the front of the sending queue for priority sending. The retransmission execution module determines the actual sending service quality level for each data item according to the service quality level cap and the list of non-degradable service categories in the retransmission plan, maintaining the original service quality level for non-degradable service categories without lowering their service quality level.

[0055] Step S6: The cloud platform provides feedback on the processing results and updates the status. After receiving the retransmitted data, the cloud platform's idempotent processing module determines whether the data has been processed based on an idempotent key composed of the device identifier, metadata version, startup epoch, sequence number, and payload digest. If the idempotent key already exists, the business data is not rewritten; only the confirmation sequence number or confirmation status is updated. For unprocessed data with an acceptable version status, the cloud platform performs business decoding according to the corresponding metadata. For unprocessed data with a bridging version status, the cloud platform decodes it after conversion according to field mapping rules. For derived state observation records, the cloud platform writes them into the device's historical state trajectory or uses them for digital twin model correction based on the event time they carry, without overwriting the current real-time state or triggering control state machine transitions. For secure micro-messages, the security processing module performs deduplication and frequency limiting processing, and writes the processing results into the security event record.

[0056] The confirmation feedback module updates the confirmation sequence number, version reception status, lease reception status, retransmission window, and service quality level upper limit of each cache partition, generates the next round of retransmission plan, and returns to step S4 to form a retransmission control closed loop.

[0057] Example 3: AGV Network Disconnection Retransmission Application Case This embodiment uses an automated guided vehicle (AGV) in a warehousing scenario as an example to illustrate the processing procedure of the present invention. When performing a handling task, the AGV enters a densely packed shelving area and disconnects from the cloud platform for approximately 8 minutes. During the network outage, the AGV continues to generate location telemetry data, fork height data, task execution receipts, alarm data, and configuration receipt data, which are written to the local cache by the edge computing unit. Before the network outage, the lease epoch of the currently valid access service instance on the cloud platform was E12, and the business data model version was V1. During the network outage, the cloud platform switches to a backup instance due to a failure of the primary service instance, and the current valid lease epoch becomes E13; simultaneously, the cloud platform upgrades the business data model from V1 to V2, where the location field is changed from millimeters to meters, and a load status field is added.

[0058] After the connection is restored, the edge computing unit reports a cache partition summary to the cloud platform. The cache partition summary shows that the partition key is (device_id=AGV_01, config_version=V1, lease_epoch=E12, boot_epoch=B03). The partition includes several records of telemetry data, alarm data, control confirmation data, and configuration receipt data.

[0059] The cloud platform determines that V1 is a bridgeable version based on the version compatibility table and includes a field mapping identifier in the retransmission plan. The field mapping rules include: the location field in version V1 is mapped to the location field in version V2 using a conversion rule of dividing by 1000; the payload status field added in version V2 is set as a pending confirmation marker and does not participate in control state advancement. Because the lease epoch E12 carried by the partition key is inconsistent with the currently valid lease epoch E13, the cloud platform marks the cache partition as having an invalid lease. In the retransmission plan, telemetry data is allowed to enter the historical retransmission path, while control confirmation and configuration receipt data are prohibited from advancing to the current control state.

[0060] The retransmission execution module retransmits telemetry data according to the retransmission plan. The cloud platform converts V1 data to V2 format according to field mapping rules and writes it into historical data storage. For control confirmation data, the retransmission execution module extracts the fork height and end effector absolute position from the original load, generating a derived state observation record carrying the old lease source marker E12. The cloud platform writes the derived state observation record into the equipment's historical state trajectory according to event time, without overwriting the current real-time state of the automated guided vehicle or triggering control state machine transitions. For configuration receipt data, the cloud platform writes it to the audit database without updating the current configuration state.

[0061] During the retransmission process, the edge computing unit detects a cached record with an emergency flag, corresponding to a chassis emergency stop event that occurred during the network outage. The security field mapping module confirms that the source version V1 belongs to the applicable source metadata version range of the security field mapping table and passes the verification, reads the value of the emergency stop status field, and generates a security micro-message. After receiving the security micro-message, the cloud platform directly routes it to the security processing module and records it as a security event.

[0062] Through the above processing, the old version data of the automated guided vehicle during the network outage is bridged, decoded and stored in the database. Control confirmation data under the old lease does not advance the current control state. Critical safety status is reported first before the business data model is fully synchronized. Conflicts between network outage historical data and the current control process are effectively isolated.

[0063] In one optional implementation, the cloud platform sets different time windows for different business categories. When the difference between the cached event timestamp and the current time exceeds the time window for the corresponding business category, telemetry data is written to the historical database, alarm data is written to the historical alarm database without triggering real-time linkage, control confirmation data is written to the audit database without advancing the control status, and configuration receipt data is written to the audit database without updating the current configuration status.

[0064] In one optional implementation, when the cloud platform receives data from multiple edge computing units targeting the same device identifier and sequence number, the cloud platform compares the payload digests. If the payload digests match, the earliest arriving data is retained and acknowledged; if the payload digests do not match, the receiving path is determined based on the edge computing unit's priority configuration, lease status, and service category, or the data is marked as conflict pending acknowledgment.

[0065] In one optional implementation, the edge computing unit can report cache partition summaries in batches according to device identifier, service category and version status, and the cloud platform can gradually generate a retransmission plan based on the batch summaries.

[0066] In one optional implementation, the cloud platform performs deduplication and frequency limiting on security micro-messages of the same security status type. When the same device repeatedly reports the same security status value within a preset time window, the cloud platform retains only the first or the latest security micro-message and updates the security event record.

[0067] verify Test Equipment and Scenario: The prototype consists of an automated guided vehicle (AGV) mobile platform, an onboard ARM edge computing unit, an LTE communication module, and a data center-side cloud platform. Monitoring points are located at the CAN bus interface of the AGV chassis controller. Log recording covers the entire process of cache partition key generation, structural and semantic digest calculation, retransmission plan issuance, and data routing. Clock drift is introduced during testing to simulate real sensor time deviations.

[0068] In the first scenario, there was no version upgrade or instance switch during the network outage. The cache partition version reception status was determined to be receivable. After retransmission, it was confirmed by idempotent key verification, and no duplicate write records were found. In the second scenario, the field unit changed while the field structure remained unchanged during the network outage. The reported structural digest was consistent with the cloud platform's stored record, but the semantic digest was inconsistent. The cloud platform determined the version reception status to be semantically pending confirmation, paused decoding, and retransmitted after semantic update. In the third scenario, there was a version upgrade and instance switch during the network outage. The version was determined to be bridgingable and the lease was determined to be invalid. Control confirmation data generated derived state observation records and wrote them into the historical trajectory. The control state machine did not experience any erroneous transitions. In the fourth scenario, a chassis emergency stop occurred during the network outage, and the business model had no bridging records. Security micro-messages were sent with priority at the preset security service quality level, and the cloud platform security event record was successfully generated. In the fifth scenario, the network outage data was restored after the edge computing unit restarted. The idempotent key included the startup epoch. The two batches of data before and after the restart were confirmed separately, and no erroneous discarding or duplicate writing occurred due to sequence number rollback.

[0069] In the comparative test group, a conventional breakpoint resumption strategy was adopted. After the connection was restored, all cached data was sent directly according to the local cache sequence number, and the cloud platform did not distinguish between metadata version reception status and lease reception status. During access service instance switching, control confirmation data entered the current task confirmation processing queue in the comparative test group, resulting in records awaiting manual review. During business data model upgrades, the old version location field in the comparative test group was decoded using the current version unit, resulting in numerical anomalies. In the test group using this embodiment's solution, no abnormal control state machine transition records or field unit conversion anomalies were observed under the above conditions. The test logs still showed fluctuations in retransmission completion time and minor changes in event arrival order due to link instability in the early stages of wireless network recovery, but these did not affect the implementation of the aforementioned functions and effects.

[0070] The above are merely preferred embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A method for retransmitting disconnected data for industrial mobile nodes, characterized in that, include: The edge computing unit receives service data generated by industrial mobile nodes and determines the device identifier, metadata version, access instance lease epoch, startup epoch, and service category corresponding to the service data; wherein, the startup epoch is generated by the edge computing unit at startup and is used to distinguish the data sequence number space before and after the edge computing unit restarts; When the connection between the edge computing unit and the cloud platform is interrupted, or when the metadata version has not yet been confirmed as receivable by the cloud platform, the service data is written to the local cache partition according to the partition key composed of the device identifier, the metadata version, the access instance lease epoch, and the startup epoch. The service category is used for data diversion processing within the cache partition and does not participate in the composition of the partition key. After the connection is restored, the edge computing unit reports a cache partition summary to the cloud platform; The cloud platform determines the version reception status and lease reception status of each cache partition based on the cache partition summary, and generates a retransmission plan; The edge computing unit performs data retransmission according to the retransmission plan. When the lease reception status is invalid, control confirmation data and configuration receipt data do not participate in the current control status advancement.

2. The method according to claim 1, characterized in that, When the edge computing unit receives business data generated by the industrial mobile node, it also generates summary information carrying structural and semantic features based on the metadata version. The summary information includes a structural summary and a semantic summary. The structural summary is generated based on field name, field type, field order, and field length, and is used to characterize changes in field structure. The semantic summary is generated based on field identifier, field unit, scale factor, offset, enumeration mapping version, and field meaning tag, and is used to characterize changes in field semantics.

3. The method according to claim 2, characterized in that, The cache partition summary includes the partition key, the structure summary, the semantic summary, the data volume, the sequence number range, and the business category distribution. The partition key consists of the device identifier, metadata version, access instance lease epoch, and startup epoch. The business category distribution is used to characterize the amount or proportion of data of different business categories within the corresponding cache partition.

4. The method according to claim 1, characterized in that, The step of writing the business data to the local cache partition according to the partition key includes: The cached records containing the sequence number, structure summary, semantic summary, the business category, payload summary, and original payload are written to the cache partition in sequence number order; When the local cache space reaches a preset level, the cached record is evicted based on a retention score calculated by weighting business importance, version reception status score, lease status score, and cache dwell time.

5. The method according to claim 1, characterized in that, The version reception status is determined in the following manner: If the cloud platform has a corresponding metadata version and the structural digest and semantic digest are consistent, it is determined to be acceptable; When the cloud platform has a corresponding metadata version with consistent structural digests but inconsistent semantic digests, it is determined that the semantics are pending confirmation. If the corresponding metadata version does not exist on the cloud platform, but a bridging record is matched in the version compatibility table, it is determined to be bridgingable; If the corresponding metadata version does not exist on the cloud platform and no bridging record is matched, it is determined to be pending synchronization.

6. The method according to claim 1, characterized in that, The lease acceptance status is determined in the following manner: The lease epoch of the access instance corresponding to the cache partition is compared with the currently maintained valid lease epoch of the cloud platform. If they match, it is determined to be valid; if they do not match, it is determined to be invalid.

7. The method according to claim 1, characterized in that, The retransmission plan is generated in the following manner: Based on the maximum consecutive acknowledgment number of each cache partition, the version reception status, the lease reception status, and the access service load, a retransmission window is determined for each cache partition. The access service load includes at least one of the following: the length of the pending retransmission queue of the current access service module, the number of available processing threads, the processing throughput, the CPU utilization rate, the memory utilization rate, and the network transmission or reception bandwidth utilization rate. The retransmission window includes a start sequence number and an end sequence number. The start sequence number is the sequence number of the first unacknowledged cache record after the maximum consecutive acknowledgment sequence number of the corresponding cache partition. The end sequence number is determined based on the access service load, the version reception status, and the lease reception status. When the version reception status is bridgeable, the corresponding field mapping identifier is carried in the retransmission plan; When the lease receipt status is invalid and the service category is a control confirmation or configuration receipt, no retransmission window is generated for the corresponding cache partition to advance the current control status.

8. The method according to claim 7, characterized in that, The data retransmission performed by the edge computing unit according to the retransmission plan includes: For cache partitions with a version reception status of "acceptable", send cache data according to the retransmission window. For cache partitions with a version reception status of bridgeable, old version data is sent, and the cloud platform converts and decodes it according to the field mapping rules corresponding to the field mapping identifier. For cache partitions whose version reception status is pending synchronization, respond to the metadata request from the cloud platform and do not send business payloads for the time being.

9. The method according to claim 1, characterized in that, The step of the edge computing unit performing data retransmission according to the retransmission plan also includes: For cache partitions with invalid lease acceptance status, the edge computing unit generates derived status observation records for data with the service category of control confirmation and sends them to the cloud platform, which then writes the derived status observation records into the device's historical status trajectory. The edge computing unit marks the data with the service category of configuration receipt as being retransmitted and sends it to the cloud platform, which then performs auditing and storage on the data with the configuration receipt category without updating the current configuration status. When the version reception status is pending synchronization and there is a cached record with an urgent flag, the edge computing unit reads the security status field from the original payload according to the preset security field mapping table, generates a security micro-message, and sends it to the cloud platform first. The cloud platform then performs security event processing on the security micro-message.

10. A data retransmission system for industrial mobile nodes in the event of a network outage, characterized in that, Including edge computing units and cloud platforms; The edge computing unit includes a data receiving module, a version identification module, a cache partitioning module, a retransmission execution module, and a security field mapping module. The output of the data receiving module is connected to the inputs of the version identification module and the cache partitioning module, and is used to receive service data generated by industrial mobile nodes. The version identification module is used to determine the metadata version corresponding to the service data and generate a structure digest and a semantic digest. The cache partitioning module is used to write the service data to a local cache partition according to the partition key during network outages. The input of the retransmission execution module is connected to the output of the cache partition module, and is used to select data from the corresponding cache partition according to the retransmission plan and send it to the cloud platform; the security field mapping module is connected to the retransmission execution module, and is used to generate a security micro-message when the metadata version reception status of the business data is pending synchronization; The cloud platform includes an access service module, a metadata management module, a lease management module, a version compatibility management module, a retransmission plan generation module, an idempotent processing module, and a security processing module. The input end of the access service module is communicatively connected to the output end of the retransmission execution module, and is used to receive cache partition summaries and retransmission data. The input end of the metadata management module is connected to the output end of the access service module, and is used to determine the version reception status. The input terminal of the lease management module is connected to the output terminal of the access service module, and is used to determine the lease acceptance status; The version compatibility management module is connected to the metadata management module and is used to maintain a version compatibility relationship table to provide field mapping rules; the input end of the retransmission plan generation module is connected to the output end of the metadata management module and the output end of the lease management module respectively, and is used to generate a retransmission plan; the input end of the idempotency processing module is connected to the output end of the access service module and is used to perform deduplication processing on the received retransmission data; the security processing module is connected to the access service module and is used to receive and process the security micro-message.

Images