Body intelligent robot edge MQTT message sending control method and device and medium

Abstract

The present application relates to the technical field of edge message sending control in communication between industrial Internet of Things and embodied intelligent robots, and discloses an embodied intelligent robot edge MQTT message sending control method, device and medium. The method takes the continuity of outbound communication of an edge gateway as a control target, performs field analysis and normalization on MQTT access messages to form a unified internal message structure, determines a topic, an output path and a sending priority based on the structure, freezes a normal queue sending window before link switching and retains sending context, identifies unconfirmed messages according to an acknowledgement state and message segmentation content after link recovery, performs supplementary transmission according to the priority and record order, and thus maintains sending continuity and an acknowledgement closed loop before and after link switching.

Description

Technical Field

[0001] This invention relates to the field of edge gateway message sending control technology in the communication between industrial Internet of Things and embodied intelligent robots, and particularly to an edge MQTT message sending control method, device and medium for embodied intelligent robots. Background Technology

[0002] In scenarios such as inspection, handling, assembly, collaborative processing, and remote operation and maintenance, embodied intelligent robots need to continuously exchange various types of messages, including control commands, status feedback, fault alarms, parameter configurations, and operation logs, between the robot body, edge nodes, local control units, and remote platforms. Because different types of messages have different requirements in terms of timeliness, reliability, and bandwidth consumption, the edge gateway must not only forward messages after access but also ensure the real-time transmission of control messages, the sequential transmission of ordinary messages, and continuous recovery after link anomalies.

[0003] The MQTT (Message Queuing Telemetry Transport) protocol is widely used for device access scenarios between robots and platforms due to its lightweight publish-subscribe model and flexible topic organization. However, in scenarios with multiple concurrent tasks, a large number of topics, and fluctuating network links, existing general-purpose software stacks typically process messages from different devices and of different categories in a unified message loop. This can easily lead to problems such as control messages being blocked by low-priority messages, difficulty in maintaining the sending context during link switching, duplicate or out-of-order sending after link recovery, and loss of unacknowledged messages during network outages. These issues affect the real-time performance and communication continuity of robot control messages.

[0004] In a type of industrial IoT and platform collaborative communication scenario, gateways often need to process both status acquisition messages from field devices and control, configuration, and maintenance messages from the platform. Without a unified topic mapping, priority scheduling, and anomaly recovery mechanism, field device messages and platform control messages are prone to interference, leading to increased control link latency, unbalanced transmission order during recovery, and redundant retransmissions consuming limited bandwidth. These problems are concentrated on the outbound message continuity control side of the edge gateway, primarily concerning transmission window, link switching, acknowledgment loop control, and retransmission order control, rather than on the work object location maintenance or backend database entry interpretation side.

[0005] In existing solutions, link switching, acknowledgment recording, and recovery retransmission often fall within different threads or different cache units, lacking unified control over sending window freezing, context continuation, and retransmission ordering. As a result, even if the message content has been interpreted for business purposes, the edge gateway may still experience duplicate transmissions, order imbalances, or broken acknowledgment loops during link jitter or network outage recovery phases. This indicates that the problem lies in insufficient control over outbound communication continuity, rather than in the maintenance of business object locations or the application-side database entry rules themselves. Summary of the Invention

[0006] This invention aims to provide a method, apparatus, and medium for controlling edge MQTT message transmission for embodied intelligent robots, in order to establish a continuous transmission control link for outbound communication to edge gateways, thereby solving the problem of the lack of a unified control basis for MQTT access messages during link switching, acknowledgment status continuation, and recovery retransmission sequencing.

[0007] To achieve the above objectives, this invention proposes an edge gateway processing scheme that uses a unified internal message structure as the basis for transmission control and transmission context maintenance and acknowledgment closed-loop maintenance as core constraints. The scheme organizes topic mapping, priority determination, queue transmission, link switching, acknowledgment status maintenance, and recovery retransmission into the same outbound transmission control link.

[0008] After receiving an MQTT access message, the edge gateway first performs field parsing and normalization, and then forms a unified internal message structure based on this. This structure records fields such as event identifier, device identifier, event type, timestamp, metadata, and payload, which are used by subsequent topic mapping, priority determination, and recovery processing.

[0009] The edge gateway determines the corresponding MQTT topic and target output path based on the unified internal message structure and preset topic mapping template, and determines the message sending priority based on message type, timeliness requirements or task status, and writes the message into the corresponding sending queue.

[0010] To maintain the continuity of the sending process, the edge gateway maintains a cache of the sending context, message identifier, acknowledgment status, and message segment content corresponding to the message after the message enters the sending process.

[0011] When the current communication link is detected to meet the switching conditions, the normal queue sending window is frozen, the sending context is preserved, and the link switching is performed to avoid the cross-sending of normal messages and recovery messages during the switching period.

[0012] After the link switch is completed or the link is restored, the edge gateway resumes the queue sending according to the sending context and continues to maintain the confirmation status of messages that have entered the sending process before the switch.

[0013] Upon receiving an acknowledgment message, the edge gateway updates the acknowledgment status of the corresponding message based on the message identifier. After the link switch is completed or the link is restored, it identifies unacknowledgment messages based on the sending context, acknowledgment status, and message segment content cache, and performs hierarchical retransmission according to message priority. Within the same priority, it performs ordered retransmission according to the record order.

[0014] Before a message enters the sending queue, basic verification, rate limiting, deduplication, queuing, or backpressure processing can be performed to improve the stability of subsequent sending.

[0015] In optional implementations, default device policies, device policies, event type or event category policies, and hotspot coverage policies can be superimposed to assist in adjusting rate limiting parameters, burst parameters, or scheduling weights. These policies are only used for auxiliary optimization of sending schedules and do not participate in unacknowledged message identification, acknowledgment status maintenance, or recovery of the main transmission chain.

[0016] The unified internal message structure, sending context, acknowledgment status, and recovery / retransmission establish processing associations around message identifiers, enabling topic mapping, queue sending, link switching, and recovery / retransmission to be executed continuously in the same processing link.

[0017] For example, an MQTT topic can be built according to the template / sys / {product_key} / {device_name} / {message_kind}, and the product type, device name, and message type from the unified internal message structure can be written into the corresponding topic segments.

[0018] For downlink messages, a command identifier can be used as the message identifier; for uplink messages, an event identifier can be used as the message identifier, so as to uniformly maintain the acknowledgment status and perform recovery retransmission.

[0019] In an optional implementation, the hotspot coverage strategy only makes temporary adjustments to the rate limiting parameters, burst parameters, or scheduling weights, without rewriting the event identifier field, device identifier field, event type field, MQTT topic, and target output path in the unified internal message structure.

[0020] In an optional implementation, for candidate strategies provided by external suggestion sources, the rate limiting parameters, burst parameters, or scheduling weights are updated only after the structural and semantic verifications are passed; the aforementioned processing does not change the message sending control main chain.

[0021] A unified internal message structure maps topic mapping, priority scheduling, and acknowledgment status index to the same message index, so that outbound messages no longer depend on scattered field interpretation before entering the sending queue, making it easier to form a single sending control entry point.

[0022] Hierarchical queues and sending windows work together to manage control, status, and log messages, allowing control messages to traverse congested paths first, while maintaining the windowed dequeue order for ordinary messages.

[0023] During the link switching phase, the sending context is preserved and the recovery of the normal queue is delayed. This can limit the impact of the switching to the current sending window and prevent the confirmation loop from being disrupted after the recovery message and the newly arrived message intersect.

[0024] Unacknowledged message identification and hierarchical orderly retransmission continue the transmission records before the handover during the recovery phase, so that the acknowledgment semantics, segmentation status and retransmission order of the same message remain continuous. Attached Figure Description

[0025] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0026] Figure 1 This is a schematic diagram of the overall process of the edge MQTT message sending control method for an embodied intelligent robot according to an embodiment of the present invention.

[0027] Figure 2 This is a schematic diagram illustrating the mapping relationship between the unified internal message structure and MQTT topics in one embodiment of the present invention.

[0028] Figure 3 This is a schematic diagram of the process for sending scheduling parameters to assist in optimization according to one embodiment of the present invention.

[0029] Figure 4 This is a schematic diagram of the candidate link scoring, handover determination, and transmission window freeze recovery process in one embodiment of the present invention.

[0030] Figure 5 This is a schematic diagram of the lifecycle state transition and final state update process of downlink commands in one embodiment of the present invention.

[0031] Figure 6 This is a schematic diagram illustrating the process of maintaining, updating the confirmation status, and retransmitting unacknowledged messages after a network outage or link switch, according to one embodiment of the present invention.

[0032] Figure 7 This is a schematic diagram illustrating the relationship between the unified internal message structure, sending context, confirmation status, and recovery / retransmission in one embodiment of the present invention.

[0033] Figure 8 This is a schematic diagram showing the composition and connection relationship of an edge MQTT message sending control device module in one embodiment of the present invention.

[0034] Figure 9 This is a schematic diagram of the edge MQTT message sending control device module in one embodiment of the present invention. Detailed Implementation

[0035] The present invention will be further described below with reference to the accompanying drawings and specific embodiments. It should be understood that the following embodiments are for illustrative purposes only and are not intended to limit the scope of protection of the present invention.

[0036] In this embodiment, the gateway is deployed between the field devices of the embodied intelligent robot, edge nodes, and the remote platform, undertaking the function of controlling the continuity of outbound messages from the edge. The gateway can run on industrial gateway devices, edge servers, industrial control computers, or embedded devices with network communication capabilities, and completes message reception, field parsing and normalization, topic mapping, priority determination, link switching, status maintenance, and recovery and retransmission through software programs. In the device implementation, the above processing is completed collaboratively by the message receiving module, parsing and mapping module, queue scheduling module, link switching module, status maintenance module, and recovery and retransmission module.

[0037] like Figure 8 As shown, the edge MQTT message sending control device may include a message receiving module, a parsing and mapping module, a queue scheduling module, a link switching module, a status maintenance module, and a recovery and retransmission module. The message receiving module is connected to the parsing and mapping module, the parsing and mapping module is connected to the queue scheduling module, the queue scheduling module is connected to the link switching module, the link switching module is connected to the status maintenance module, and the status maintenance module is connected to the recovery and retransmission module. These modules can be integrated into the same edge gateway device and operate collaboratively.

[0038] like Figure 9 As shown, the edge MQTT message sending control device may include a message receiving module, a parsing and mapping module, a queue scheduling module, a link switching module, a status maintenance module, and a recovery and retransmission module. Specifically, the message receiving module is responsible for receiving MQTT access messages reported by the embodied intelligent robot body, edge nodes, or associated control units; the parsing and mapping module is responsible for parsing and normalizing the fields of the access messages and determining the MQTT topic and target output path; the queue scheduling module is responsible for determining the sending priority based on message type, service quality level, or task status and performing queue writing and sending scheduling; the link switching module is responsible for link observation, switching determination, and switching execution; the status maintenance module is responsible for maintaining the acknowledgment status, message segment content caching, and sending context; and the recovery and retransmission module is responsible for identifying unacknowledged messages and performing hierarchical ordered retransmission.

[0039] like Figure 1As shown, the method flow may include: receiving the original MQTT access message; performing field parsing and field normalization to form a unified internal message structure; determining the target MQTT topic based on this structure and a preset topic mapping template; performing basic verification, rate limiting, deduplication, and queuing or backpressure processing as needed; determining the sending priority based on topic category, service quality level, message timeliness marker, and task status, and writing the message to the corresponding sending queue. When a link switching condition or fast switching event is detected, the ordinary queue sending window is frozen, the sending context is preserved, and the link switching is completed. After the message is sent, the message identifier, acknowledgment status, message segment content cache, and sending context are recorded; after receiving an acknowledgment message, the acknowledgment status is updated according to the command identifier, status field, and acknowledgment time. After the link is restored or switched, unacknowledgment messages are identified by combining the sending context, acknowledgment status, and message segment content cache, and are first retransmitted in a hierarchical manner according to priority, and then retransmitted in an orderly manner according to the recorded order within the same priority.

[0040] like Figure 2 As shown, after receiving an MQTT access message, the gateway performs field parsing and normalization to form a unified internal message structure. This structure can be configured with fields such as event identifier, device identifier, event type, timestamp, metadata, and payload. During normalization, the event identifier is preferentially taken from the unique identifier field in the MQTT access message, the device identifier is preferentially taken from the device identifier segment in the access topic, and the event type is preferentially taken from the business operation field; if the business operation field is missing, it is then degraded to take the method field. Subsequently, the target MQTT topic, service quality level, and target output path are determined based on the unified internal message structure and the preset topic mapping template.

[0041] The unified internal message structure does not require all local protocol fields in MQTT access messages to be elevated to top-level fields. Typically, event identifiers, device identifiers, and event types are retained as top-level fields, supplementary protocol information is written to the metadata field, and the original business message and unnormalized fields are retained in the payload field. The metadata field is an auxiliary field in the unified internal message structure used to record message source, original subject, access time, business operation field, method field, and other supplementary protocol information.

[0042] After field parsing and normalization, the gateway can perform ingress management in the following order: basic verification, rate limiting, deduplication, and queuing or backpressure. Basic verification mainly checks whether the device identifier, event identifier, message type, timestamp, and payload meet the basic requirements for entering the transmission link; rate limiting is used to control the global or device-level rate; deduplication is used to identify duplicate events within the most recent window.

[0043] Furthermore, basic validation can also cover field value range, timestamp freshness, and payload structure. That is, it needs to confirm that the message type field, status field, or method name is within the allowed range, the timestamp is not obviously too old or too new, and the business content field meets the preset object structure. The payload structure validation includes: verifying whether the payload is in valid JSON (JavaScript Object Notation) or Protocol Buffers format, verifying whether the payload contains business content fields, and verifying whether the payload size is within the allowed range. After passing the basic validation, the message then enters the subsequent rate limiting and deduplication path.

[0044] Optionally, queuing or backpressure processing can employ methods such as direct enqueueing, delayed enqueueing, replacing old messages, rejecting new messages, or waiting for retries. If the device-level queue depth reaches its limit, the edge gateway can select an appropriate retention strategy based on message priority and device criticality.

[0045] During the priority determination process, the gateway determines the sending priority based on the topic category, service quality level, message expiration flag, and current task status corresponding to the MQTT topic. Control commands, fault alarms, and interlock messages are determined to be high priority; status feedback and parameter synchronization messages are determined to be medium priority; and operation logs and maintenance messages are determined to be low priority. The gateway writes messages to a high-priority queue or a regular queue according to the sending priority. The high-priority queue is used to hold control and alarm topic messages, which have priority in scheduling. The regular queue is used to hold other messages besides high-priority messages, including at least status and log topic messages, and pauses the current sending window when a high-priority message is detected.

[0046] In another implementation, the task lifecycle stage can also be considered when determining priorities. When the equipment is in the startup, reset, workstation switching, interlock release, or fault recovery stage, the control commands and status confirmation messages related to that stage can be given higher priority.

[0047] In an optional implementation, the sending priority can also be combined with the default device policy, device policy, event type or event category policy and hotspot coverage policy to make auxiliary adjustments to the rate limiting parameters, burst parameters or scheduling weights; the aforementioned processing only serves to assist in sending scheduling optimization.

[0048] In this optional implementation, the hotspot coverage strategy can support runtime replacement or rate adjustment. Relevant inputs can come from configuration files or be issued at runtime; the foregoing does not change the processing order of field normalization, link switching, acknowledgment status maintenance, and recovery / retransmission.

[0049] For adjustment inputs issued at runtime or from external suggestion sources, the system first performs checks such as field integrity, threshold boundaries, scope conflicts, and version matching; the corresponding scheduling parameters are only updated after the checks pass.

[0050] If multiple temporary adjustments occur simultaneously, the best policy is selected based on its source, scope level, and expiration time. In this implementation, the scope level is divided into message level, event type level, device level, and global level according to the granularity of the policy impact, from fine to coarse. When multiple hotspot coverage policies occur simultaneously, policies with finer scope levels take precedence over policies with coarser scope levels, and policies with later expiration times within the same level take precedence.

[0051] When modeling a strategy, the default device strategy or the device strategy can be represented by a device strategy object, which can be configured with fields such as maximum transmission rate, burst capacity, deduplication time window, maximum queue depth, scheduling weight, and critical device flag; the aforementioned object is used to supplement scheduling parameters.

[0052] For example, the maximum transmission rate can be applied to ingress rate limiting or transmission rate limiting; burst capacity is used to provide a limited burst quota when there is a short-term increase in traffic.

[0053] The deduplication time window is used to limit the scope of duplicate event identification; the maximum queue depth is used to limit the upper limit of the device-level queue. When this upper limit is exceeded, processing actions such as rejection, replacement of old events, or backpressure waiting may be triggered.

[0054] Scheduling weights are used to adjust the proportion of messages sent by a device during the scheduling process.

[0055] Critical device markers are used to identify critical devices. In congested scenarios, this can be used to reserve a minimum transmission share for critical devices, increase their default priority, or prioritize their control messages.

[0056] For event type or event category strategies, they can be represented as entry category strategy and event strategy, respectively, to supplement scheduling parameters related to maximum transmission rate, burst capacity, or entry category.

[0057] For hotspot coverage strategies, information such as scope, device identifier, multiplier, and failure time can be recorded for temporary coverage of transmission scheduling parameters.

[0058] If the configuration file only provides the validity period without directly specifying the expiration time, the system can calculate the corresponding expiration time when the policy is loaded.

[0059] In runtime adjustment scenarios, the system first loads candidate configurations or adjusts inputs, and then performs structural and semantic checks; if the conditions are met, the corresponding scheduling parameters are updated; otherwise, the previous stable version is maintained.

[0060] Semantic validation can include checks on field dependencies, threshold upper and lower bounds, scope adaptation, and coverage boundaries; if it fails, the system continues to run on the previous stable version.

[0061] like Figure 3 As shown, the process for assisting in the optimization of sending scheduling parameters can be summarized as follows: First, the default device policy is loaded, and then the device policy and event policy are superimposed according to the hit situation; after a hotspot state is detected, the rate limiting parameters, burst parameters, or scheduling weights are temporarily overwritten; the relevant adjustments only take effect after verification. The aforementioned process only makes runtime corrections to the scheduling parameters and does not change the order of maintaining the sending context, acknowledgment status, and retransmission.

[0062] For example, a gateway can manage two or more candidate communication links among 5G, WiFi, and Ethernet links, and continuously collect latency, packet loss rate, bandwidth, and signal strength for each link. The gateway calculates link scores according to preset weights and window statistics, where latency and packet loss rate may have higher weights than bandwidth and signal strength. Automatic handover conditions may include observation window, dominance over multiple consecutive observation periods, score difference threshold, handover cooldown period, and fast handover events due to hard faults.

[0063] Before link switching, the gateway freezes the sending window of the ordinary queue and retains the sending context of the high-priority queue. After the switch, the sending of high-priority messages is restored first, followed by the sending of ordinary queues. The sending context of the aforementioned high-priority queue is a subset of the sending context of messages that have entered the current sending window. The sending context can record the message identifier, the position of the sent segment, the current acknowledgment status, and the target link identifier. When necessary, it can also supplement the recording of information such as the target device identifier, command type, command parameters, binding version identifier, configuration version identifier, command creation time, release time, and acknowledgment time. After link switching, the gateway, based on the sending context retained before the switch, combined with the acknowledgment status of the corresponding message and the message segment content cache, identifies unacknowledged messages that have not entered the completion final state, failure final state, or timeout final state, and performs hierarchical retransmission according to message priority and ordered retransmission according to the recorded order to restore the acknowledgment closed loop within the same outbound sending link.

[0064] Edge gateways use either time-weighted or window-weighted methods to calculate link scores. In control message scenarios, the weighting of latency and packet loss rate in the link score is increased; in log upload scenarios, the weighting of bandwidth is increased.

[0065] In this embodiment, link switching conditions include two categories: automatic switching conditions and fast switching events. The automatic switching condition is defined as follows: within a preset observation window, the link score of the first candidate link is higher than that of the current link for N consecutive observation periods, and the score difference exceeds a preset threshold; and the current time has exceeded a preset cooldown period since the last link switching completion time, where N is an integer greater than or equal to 2. The link switching cooldown period is used to restrict the two candidate links from repeatedly switching within a close score range. If the previous switching completion time has not exceeded the preset cooldown period, the edge gateway delays the switching decision. The fast switching event includes any of the following: the current link connection status becomes unreachable, no valid acknowledgment is received for a preset number of consecutive downlink commands, the packet loss rate exceeds a first threshold within a preset observation period, or the latency exceeds a second threshold within a preset observation period. When a fast switching event is detected, the cooldown period can be bypassed and fast switching can be performed directly. The preset number of times, the first threshold and the second threshold are given by the link switching parameters in the configuration file, and can be adjusted in stages within the preset upper and lower bounds according to the link fluctuation amplitude, the degree of confirmation timeout accumulation or the current message priority switching level within the continuous observation period; when the link quality recovers to the stable range and continues to reach the preset recovery time, the relevant parameters fall back to the corresponding basic configuration, and there is no reverse automatic switching during the cooling period.

[0066] like Figure 4 As shown, the edge gateway performs continuous observation and link score calculation on candidate links, and determines whether to perform automatic handover based on the observation window, dominance over multiple consecutive observation periods, score difference threshold, handover cooldown period, and fast handover events. When the handover conditions are met, the normal queue sending window is frozen first while the sending context of the high-priority queue is preserved, and then the target link handover is completed. After the handover is completed, high-priority message sending is resumed first, then normal queue sending is resumed, and the handover time, original link, target link, score difference, and recovery result are recorded. The aforementioned processing revolves around the continuous sending status of outbound messages on the edge gateway side.

[0067] When a network outage, link failure, link switching, or message acknowledgment timeout occurs, the gateway records the message identifier, acknowledgment status, sending context, and message segment content cache of the unacknowledgment message. Downlink commands use the command identifier as the message identifier, while uplink events use the event identifier. Upon receiving an acknowledgment message, the gateway updates the acknowledgment status based on the command identifier, status field, and acknowledgment time, and associates the updated acknowledgment status with the corresponding message segment content cache and sending context.

[0068] like Figure 5As shown, the downlink command lifecycle sequentially progresses through the creation state, governance approved state, successful issuance state, device confirmation state, and any one of the following final states: completion final state, failure final state, or timeout final state. If no valid feedback is received within a preset 30-second confirmation window, the command enters the timeout final state. The gateway updates the command status based on the command identifier, status field, and confirmation time, and writes the status change result into the confirmation status maintenance structure and audit log.

[0069] Based on the above command status transition, such as Figure 6 As shown, after network outage recovery, link restoration, or link switching is completed, the gateway identifies unacknowledged messages based on the confirmation status record, sending context, and message segment content cache. It prioritizes retransmitting control-related messages, then status-related messages, and finally log-related messages, executing retransmissions in the order recorded within the same priority level. Messages already confirmed remotely are not retransmitted. For messages with unknown confirmation status but high retransmission costs, the next retransmission round only begins when the waiting time reaches the preset threshold for the corresponding message category and the most recent retransmission round has not reached the preset threshold for the corresponding message category. Therefore, recovery processing is completed on the sending link side, without replacing the confirmation loop with other service processing chains.

[0070] In link degradation protection scenarios, when the edge gateway detects a continuous decline in the current link score but has not yet reached the immediate switching threshold, it can first implement rate limiting on the ordinary queue, reduce the batch sending window, or extend the dequeue interval for low-priority messages, while maintaining the normal transmission of high-priority control messages. If the degradation state continues to expand and meets the conditions for a fast switching event, then the complete process of freezing the ordinary queue sending window, preserving the sending context, and executing the link switching can be initiated. By introducing a degradation protection phase before the formal switching, the impact of short-term jitter on the overall message sending rhythm can be reduced, and unnecessary frequent switching can be minimized.

[0071] In topic governance scenarios, edge gateways can pre-establish a set of topic mapping templates for different robot subsystems, different device types, or different business topics. In addition to generating target MQTT topics, topic mapping templates can also be associated with topic-level service quality levels, reservation tags, target broker node identifiers, and exception fallback paths. When an incoming message lacks a complete business identifier, the system can perform template matching based on the device identifier, event type, and source connection information. If matching fails, the message is transferred to a queue of messages awaiting governance, where operations personnel or the upper-level management system supplement the topic mapping rules before reprocessing. During the period of matching failure, the message does not enter the formal sending link to avoid the incorrect forwarding of messages with incomplete topic generation.

[0072] In the context of sending window governance, edge gateways can set independent sending window limits, single batch sending quantities, and window reclamation conditions for control queues, status queues, and log queues, respectively. If high-priority messages continuously occupy the sending window, the system can delay the dequeueing of low-priority queues, but still gradually release low-priority messages during idle periods to avoid long-term accumulation causing a surge in instantaneous sending during the recovery phase. The window governance results, together with the link scoring results, determine the sending rhythm of different topics on different candidate links.

[0073] For messages exceeding a preset payload length threshold, the edge gateway can perform segmented transmission according to a fixed segment length or according to service field boundaries, and record the total number of segments, the current segment sequence number, the confirmed segment sequence number, and the remaining range of segments to be transmitted in the transmission context. The preset payload length threshold is determined based on the maximum message length of the MQTT protocol and the network MTU (Maximum Transmission Unit) value, and is preferably set to a preset value between 1KB and 8KB; the service field boundaries are the natural segmentation points of JSON objects or service data structures in the message payload. During recovery and retransmission, the system can prioritize loading segments that have not yet entered the confirmed state, rather than repeatedly loading the content of already confirmed segments, in order to reduce the proportion of duplicate transmissions of large payload messages after network outage recovery.

[0074] like Figure 7 As shown, the unified internal message structure is used to receive the message normalization result, the sending context is used to record the link information and sending status corresponding to the message, the acknowledgment status is used to identify the acknowledgment stage of the message, and the message segment content cache is used to support the retransmission of interrupted messages after network outage recovery or link switching. The recovery and retransmission processing identifies unacknowledged messages and determines the retransmission order based on the aforementioned information, thereby establishing closed-loop control around the continuity of sending a single message.

[0075] The edge gateway maintains a retransmission round count, last transmission time, and most recent acknowledgment result for unacknowledged messages. In this implementation, the retransmission round count refers to the number of times the same unacknowledged message has been retransmitted after network outage recovery or link switching. Each message maintains an independent retransmission round counter, initially set to 0, which increments by 1 after each retransmission. When the counter reaches the preset round threshold for the corresponding message category, automatic retransmission stops, and the message is transferred to the exception handling path. If a message fails to receive acknowledgment after multiple consecutive retransmission rounds before reaching the threshold, it can be marked as failed, held for manual acknowledgment, or transferred to the exception handling path based on the message type and current policy.

[0076] The offline data retention mechanism employs a combined approach of in-memory caching and persistent storage. The edge gateway first temporarily stores the messages to be acknowledged in the in-memory cache by device level. When the number of cached messages reaches a threshold, the cache waiting time reaches a threshold, the link failure persists, or the governance process is about to be overloaded, the messages to be acknowledged are written to either a PostgreSQL (PostgreSQL Object-Relational Database Management System) database or a TimescaleDB (TimescaleDB Time-Series SQL Database) database.

[0077] The messages awaiting acknowledgment in the memory buffer are organized into device buckets. Each device bucket includes at least the pending acknowledgment queue, the most recent acknowledgment time, the most recent timeout time, the most recent retransmission round, and the most recent link identifier. The persistent record includes at least the message identifier, message payload digest, priority, entry time, last sent time, current acknowledgment status, and the retransmission round to which it belongs.

[0078] When the edge gateway restarts or the governance process is reloaded, the system first reads message records in the pending, confirmed, or timed-out retry states from the database, and then compares them with the current active queue in memory to remove duplicates. For message records that exist in the database but not in memory, they are reloaded into the recovery and retransmission queue; for messages that exist in both the database and memory and have the same state, only the record with the most recent update time is retained.

[0079] As a field elevation rule, the unique identifier field can be mapped to the event identifier field, the device identifier segment in the access topic can be mapped to the device identifier field, the business operation field or method field can be mapped to the event type field, the system reception time can be mapped to the timestamp field, the original topic field, business operation field and method field can be written to the metadata field, and the business content field, status field and other unnormalized business fields can be retained in the payload field.

[0080] When an MQTT access message contains both a business operation field and a method field, the event type field is preferentially taken from the business operation field; if the business operation field is missing or empty, it is then degraded to be taken from the method field. If the access topic does not directly provide a device identifier field, the device identifier field can be determined by combining the access connection identifier, session binding information, or pre-defined device mapping relationships.

[0081] For example, for an MQTT access message with the subject / sys / KFR_PTC / PTC_MM_PAP_001 / post, KFR_PTC can be used as an example product type identifier segment, PTC_MM_PAP_001 can be used as an example device code and corresponding device identifier segment, and the payload contains the business operation field op=ProductInfo, the method field method=thing.Property.post, and the unique identifier field uuid=f75b73e6-fe87-4c0e-b080-4aa4d29ec32a. After normalization, the event identifier field `event_id` can be `f75b73e6-fe87-4c0e-b080-4aa4d29ec32a`, the device identifier field `device_id` can be `PTC_MM_PAP_001`, the event type field `event_type` can be `ProductInfo`, the timestamp field `timestamp` takes the time the message was received when it entered the gateway, the metadata field `metadata` writes the original topic field `topic`, the business operation field `op`, and the method field `method`, and the payload field `payload` retains the original business content.

[0082] As can be seen from the above typical examples, when different MQTT access messages are mapped to a unified internal message structure, the same set of field normalization rules are used: the event identifier field is preferentially derived from the unique identifier field, the device identifier field is derived from the device identifier segment in the MQTT topic, the event type field is preferentially derived from the business operation field, and degenerates into the method field when it is missing; the timestamp field takes the system reception time, the original topic field, business operation field and method field are written into the metadata field, and the remaining business original text is retained in the payload field.

[0083] In queue scheduling scenarios, edge gateways can maintain independent sending queues for control, status, and log topics, and configure different concurrent sending windows, batch dequeue thresholds, and acknowledgment waiting times for each queue. For control topics, priority is given to ensuring the sequential delivery of individual commands and the integrity of the acknowledgment loop; for status topics, small-batch continuous sending can be performed while meeting device-level sequence constraints; for log topics, time-slice supplementary sending is allowed within the network idle window to avoid log uploads continuously occupying high-priority link resources.

[0084] In one implementation of the confirmation governance mechanism, after receiving a confirmation message from a device, the edge gateway not only updates the confirmation status based on the command identifier or event identifier, but also simultaneously verifies the device identifier, topic category, confirmation time, link identifier, and message digest information. This reduces the interference of duplicate confirmations, late confirmations, or cross-link confirmations on status maintenance. When the system detects that the same message has already entered the final state and receives a duplicate confirmation again, it can update only the most recent confirmation time and retain the original final state result. When the confirmation content does not match the cache context, the confirmation is recorded as an abnormal confirmation sample for subsequent investigation of communication link jitter, out-of-order device receipts, or abnormal topic mapping issues.

[0085] In a persistent collaborative implementation, the edge gateway can manage messages to be confirmed by bucketing according to device, topic, or priority dimensions, and record the most recent sending time, most recent confirmation time, most recent retransmission round, and most recent link switch result for each bucket. For short-term fluctuation scenarios, only the memory cache can be retained and the data persistence can be delayed; for scenarios with continuous network outages, governance process overload, or cache quantity exceeding the threshold, the key records in the corresponding bucket are written to persistent storage. When reloading message records during the recovery phase, the system can first restore control topics by device dimension, then restore status topics and log topics, thereby ensuring that the recovery process is consistent with the priority governance boundaries during operation.

[0086] In one manual intervention implementation, when a message fails to reach a stable state (complete, failed, or timed out) after multiple rounds of retransmission, the edge gateway can mark the message as awaiting manual confirmation and freeze the corresponding automatic retransmission path, without freezing queues of other unrelated devices. After manual processing, the system can choose to continue retransmission, terminate retransmission, modify the target link and retransmit, or directly write the manual final state result based on the manual conclusion. By limiting manual processing to a single message or a single device bucket, local anomalies can be prevented from escalating into a global transmission shutdown.

[0087] In a reload recovery collaborative implementation, when the edge gateway governance process is upgraded, the policy process is reloaded, or the message governance module is hot-replaced, the system can first write the critical messages in the pending confirmation state, the current sending window snapshot, the latest state of the device bucket, and the most recently sent cursors of each priority level to persistent storage. After the reload is completed, the system first reads the persistent snapshot to restore the high-priority window, then restores the ordinary queue cursors, and limits the maximum concurrency of the ordinary queue in the early stage of recovery to avoid a short-term concentrated increase in pending traffic after the reload. If a message has already entered the manual confirmation path before the reload, the path is kept frozen during the recovery phase and will not be automatically released due to process reload. The system only reopens the automatic retransmission of the message when the manual processing result is written back or the subsequent confirmation record meets the stability judgment condition. This implementation allows the edge gateway to control the impact of the governance process reload at the sending window and pending confirmation message recovery level without interrupting the overall service access, and prevents it from spreading to a global link disorder.

[0088] In one implementation of anomaly isolation, the edge gateway, in addition to identifying normal and duplicate acknowledgments, can also classify and isolate cross-device acknowledgments, cross-topic acknowledgments, late acknowledgments, and acknowledgments with mismatched digests. For late acknowledgments that still match the original sending context, the system can update the most recent acknowledgment time and retain the original final state. For messages whose acknowledgment digests do not match the current sending context but have the same command identifier, the system can freeze the subsequent automatic retransmission path of the message and transfer the acknowledgment record to the anomaly acknowledgment sample set, awaiting manual verification or subsequent automatic review. For acknowledgments from incorrect devices, incorrect topics, or incorrect links, the system does not directly modify the original acknowledgment status, but only records link anomaly samples and topic anomaly samples for subsequent analysis of receipt crosstalk, proxy forwarding anomalies, or device receipt reuse issues. By separating the processing of anomaly acknowledgments from normal acknowledgments, the system can limit semantic anomalies in acknowledgments to a single message, a single device bucket, or a single topic without disrupting the normal sending link.

[0089] In a snapshot implementation of the sending window, the edge gateway can take a complete snapshot of the current sending window state before performing link switching or entering the degradation protection phase. The snapshot includes at least the current position of the high-priority queue, the current position of the ordinary queue, the device bucket identifier corresponding to each message awaiting acknowledgment, the range of sent segments within the window, the most recent acknowledgment time, and the current link identifier. After link recovery, the system first restores the correspondence between messages within the window and device buckets based on the snapshot, and then determines which messages remain awaiting acknowledgment, which messages enter the next round of retransmission, and which messages are only restored to the queue without being retransmitted, based on the sending context and acknowledgment status. If an inconsistency is detected between the snapshot record and the in-memory active queue during the recovery phase, the newer result of the sending context and acknowledgment status record is used as the recovery basis, and the inconsistency is written to the anomaly audit record. This implementation reduces problems such as duplicate dequeueing, window reclamation imbalance, or loss of device bucket state caused by blurred sending window boundaries before and after link switching.

[0090] In a device bucket scheduling implementation, the edge gateway can not only maintain a sending queue according to message priority, but also establish bucketed sending windows by device dimension within the same priority. Each device bucket records at least the number of currently available windows, the most recent sending time, the most recent acknowledgment time, the consecutive timeout count, and the most recent link switching result. During scheduling, the system first selects device buckets that meet the window conditions within the high-priority message range, and then retrieves messages to be sent from the corresponding buckets in the recorded order. If a device continuously occupies most of the sending windows of the same priority in multiple consecutive sending cycles, the edge gateway can temporarily reduce the window quota for its status or log messages while maintaining the normal sending of control messages for that device, and transfer the free quota to other device buckets waiting to send. By adding device bucket governance in addition to priority scheduling, the system can maintain the overall sending order of the outbound links of the same edge gateway in scenarios such as concurrent reporting by multiple robots, abnormal jitter of some devices, or continuous accumulation of messages to be sent by individual devices, avoiding the evolution of abnormal occupation by a single device into global sending starvation.

[0091] In a multi-agent node forwarding implementation, the edge gateway can simultaneously maintain independent sets of target output paths for local agent nodes, regional agent nodes, and remote cloud-side agent nodes. After determining the target topic using a unified internal message structure, the system can further select a specific output path based on agent node reachability, recent acknowledgment success rate, and current link level, and record the agent node identifier, receipt source identifier, and receipt validity range corresponding to this transmission in the transmission context. If an agent node continuously exhibits delayed receipts, duplicate acknowledgments, or cross-topic acknowledgments within a preset observation window, the edge gateway can temporarily mark the agent node as a restricted path, allowing only log-type topics to be forwarded through it, while control-type and status-type topics are preferentially redirected to other available paths. Once the agent node stabilizes within several consecutive observation periods, the restrictions are gradually lifted. This implementation is used to maintain semantic consistency of receipts and stability of transmission paths in a multi-level agent forwarding architecture, avoiding local agent anomalies from directly disrupting the main transmission link.

[0092] In a link degradation tiering implementation, the edge gateway can classify candidate link states into stable, mildly degraded, moderately degraded, and severely degraded tiers based on latency fluctuations, acknowledgment timeout rates, packet loss jitter frequency, and the proportion of control-related topics within the current window during a continuous observation period. In the stable tier, the existing window size and batch dequeue threshold are maintained; in the mildly degraded tier, only the concurrent window of the ordinary queue is reduced; in the moderately degraded tier, the minimum retention window for control-related topics is further increased, and the dequeue interval for log-related topics is extended; in the severely degraded tier, the ordinary queue is allowed to be frozen directly, triggering a fast handover decision. During link recovery, the system does not restore to the original window all at once, but first restores the minimum transmission capacity corresponding to control-related topics, and then gradually opens the transmission windows for status-related and log-related topics based on continuous acknowledgment results. By binding link degradation judgment with transmission window adjustment, the system can absorb link jitter impacts in advance before the formal handover, reducing the probability of short-term degradation being amplified into full retransmission.

[0093] In a cross-shift operation implementation, when the edge gateway experiences prolonged continuous operation, shift switching, or on-site network maintenance, the system can perform consistency checks on unacknowledged message buckets, window snapshots, link levels, and most recent retransmission results at preset intervals. If a device bucket is found to be in a state of high timeout, high retransmission, or high late acknowledgment for multiple periods, the system can first mark the bucket as a key observation bucket, reduce its ordinary message window, and write the corresponding statistical results into the audit log for subsequent operation and maintenance analysis. After the bucket's acknowledgment success rate recovers, late acknowledgment decreases, and link score stabilizes in subsequent observation periods, the system gradually restores its ordinary message window and retransmission rhythm. By introducing periodic checks and key bucket management in long-cycle operation scenarios, the edge gateway can absorb the impact of chronic network degradation, local device anomalies, and accumulated acknowledgment jitter on the main transmission link in advance, without waiting for the fault to spread before entering a large-scale link switch or full retransmission.

[0094] In a smooth exit implementation within a maintenance window, after on-site network maintenance, proxy node switching, or operational diagnostics are completed, the edge gateway does not immediately release all restricted buckets and ordinary queue windows. Instead, it first restores transmission capacity in stages based on the acknowledgment success rate, window reclamation speed, and retransmission completion rate within the most recent observation window. If consecutive timeouts or a concentrated increase in late acknowledgments occur again during the initial recovery phase, the system can roll back to the previous recovery level while retaining the current transmission context. This implementation is used to avoid secondary congestion caused by traffic backflow immediately after maintenance completion.

[0095] In a supplementary implementation of audit logging, the system can also write the window restoration level, the bucket flow restriction adjustment results, and key confirmed abnormal samples into the operation audit record, which can be used for subsequent retrospective evaluation and optimization of the sending continuity governance effect.

[0096] In a supplementary implementation of the acknowledgment statistics, the edge gateway can statistically analyze the acknowledgment success rate, late acknowledgment rate, duplicate acknowledgment rate, cross-topic acknowledgment rate, and average retransmission rounds by device bucket, topic category, and target proxy node, and save the statistical results in association with the current link level, window recovery level, and manual processing conclusions. This implementation provides a long-term quantitative basis for optimizing transmission continuity.

[0097] In a supplementary implementation of retransmission convergence, the system can also record the number of remaining unacknowledged messages after each round of retransmission, the number of device buckets still in a restricted state, the duration of the most recent window recycling, and the corresponding link level, and determine whether the recovery phase has returned to a stable transmission range.

[0098] When the success rate of control-type topic confirmation remains above the preset threshold, the proportion of late confirmations decreases, and the number of remaining unconfirmed messages continues to converge over multiple consecutive observation periods, the system can mark the current recovery stage as a stage to be exited from the recovery stage.

[0099] If, during the recovery phase, there is a concentrated increase in consecutive timeouts, cross-device confirmations, or mismatched receipt summaries, the aforementioned flag will be removed and the current restricted recovery mode will be maintained.

[0100] For device buckets that have entered the pending exit and recovery phase, the system can first restore their normal message window limit, and then observe for at least one confirmation cycle.

[0101] If no abnormal concentrated growth is detected during the observation period, the edge gateway can remove the restricted marker for the corresponding bucket.

[0102] The aforementioned exit determination results can be written into the audit log along with the switchover time, recovery batch number, and abnormal sample summary.

[0103] This record is used for subsequent verification to confirm whether the recovery and exit process is consistent with the actual sending stability.

[0104] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit the scope of protection of the present invention. Equivalent substitutions or modifications made by those skilled in the art without departing from the spirit and substance of the present invention should all fall within the scope of protection of the present invention.

Claims

1. A method for controlling edge MQTT message sending in an embodied intelligent robot, characterized in that, include: Receive MQTT access messages, perform field parsing and field normalization on the MQTT access messages, and generate a unified internal message structure; The unified internal message structure includes at least an event identifier field, a device identifier field, an event type field, a timestamp field, a metadata field, and a payload field, and serves as a shared control index for topic mapping, sending priority determination, acknowledgment status index, and recovery retransmission identification; Based on the preset topic mapping template and the unified internal message structure, the corresponding MQTT topic, target output path and message sending priority are determined, and the MQTT access message is written into the corresponding sending queue. After a message enters the sending process, maintain a cache of the sending context, message identifier, acknowledgment status, and message segment content corresponding to the sent message; When the current communication link is detected to meet the switching conditions, the normal queue sending window is frozen, the sending context is preserved, and the link switching is performed. After the link switch is completed or the link is restored, the queue is restored according to the sending context to maintain the continuity of outbound transmission before and after the link switch. Upon receiving a confirmation message, update the confirmation status of the corresponding message based on the message identifier; Based on the sending context, the confirmation status, and the message segment content cache, identify messages that have entered the sending process but have not been confirmed; Unacknowledged messages are retransmitted in a hierarchical manner according to message priority, and within the same priority, retransmission is performed in an ordered manner according to the record order.

2. The method according to claim 1, characterized in that, The field normalization process includes: Convert the service identifier, method name, parameter content, status information, unique identifier, timestamp, device identifier, event identifier, product type, device name, and message type fields in the MQTT access message into a preset field set; The preset field set includes at least the operation identifier field, method identifier field, business content field, status field, unique identifier field, timestamp field, device identifier field, event identifier field, product type identifier field, device name field, and message type field.

3. The method according to claim 1, characterized in that, The method for determining MQTT topics based on preset topic mapping templates is as follows: A hierarchical MQTT topic is constructed according to the preset topic mapping template of / sys / {product_key} / {device_name} / {message_kind}, and the product type, device name and message type in the unified internal message structure are mapped to the product type identifier segment, device name identifier segment and message type identifier segment respectively. Among them, product_key represents the product type identifier field, device_name represents the device name identifier field, and message_kind represents the message type identifier field.

4. The method according to claim 1, characterized in that, The sending priority is determined at least according to the classification of control topics, alarm topics, status feedback topics, and log topics; Control-related messages or alarm-related messages are written to a high-priority queue.

5. The method according to claim 1, characterized in that, The link switching and recovery process includes: The sending context includes at least the message identifier, the location of the sent segment, the current acknowledgment status, and the target link identifier; Freeze the sending window of the normal queue and preserve the sending context before performing link switching; After the link switch is completed, resume sending high-priority messages first, and then resume sending ordinary queues. Based on the message identifier, the position of the sent segment, the current confirmation status, and the target link identifier in the sending context, combined with the confirmation status of the corresponding message and the message segment content cache, the system identifies messages that have entered the sending process before the link switch but are still in the unconfirmed state. For messages in the unconfirmed state, the corresponding retransmission round is initiated based on the message type and retransmission conditions.

6. The method according to claim 1, characterized in that, Maintain the message identifier, acknowledgment status, and message segment content cache for unacknowledged messages, including: When sending an MQTT access message, the corresponding message identifier is recorded. After receiving the confirmation message, the confirmation status is updated according to the command identifier, status field and confirmation time. The updated confirmation status is cached and stored in association with the corresponding message segment content and sending context. Downlink messages use command identifiers as message identifiers, while uplink messages use event identifiers as message identifiers; If a message is not acknowledged within the preset acknowledgment time limit, the corresponding message will remain in the pending retransmission state. For consecutive unacknowledged messages, the exception handling path can be transferred according to the message category.

7. The method according to claim 1, characterized in that, After the field parsing and field normalization processes, basic verification, rate limiting, deduplication, and queuing or backpressure processing are performed on the MQTT access messages. The deduplication primary key includes at least a device identifier and an event identifier, and the rate limiting includes at least global rate limiting and device-level rate limiting.

8. The method according to claim 1, characterized in that, The determination of the sending priority can also be combined with device policies, event policies, or hotspot coverage policies to assist in the adjustment of rate limiting parameters, burst parameters, or scheduling weights; Among them, the hot spot coverage strategy is used to temporarily cover the rate limiting parameters, burst parameters or scheduling weights in the currently effective strategy, without modifying the event identifier field, device identifier field, event type field, MQTT topic and target output path in the unified internal message structure; When multiple hotspot coverage strategies are applied simultaneously, the effective strategy is determined according to the preset scope level and the time of failure.

9. A computer-readable storage medium having a computer program stored thereon, the computer program, when executed by a processor, implementing the method of claim 1.

10. An edge MQTT message sending control device for an embodied intelligent robot, characterized in that, include: The module includes a message receiving module, a parsing and mapping module, a queue scheduling module, a link switching module, a status maintenance module, and a recovery and retransmission module. The message receiving module, parsing mapping module, queue scheduling module, link switching module, and recovery and retransmission module are deployed on the edge gateway processor, and the state maintenance module corresponds to the memory cache and persistent storage unit. The message receiving module is used to receive MQTT access messages and input the MQTT access messages into the parsing and mapping module; The parsing and mapping module is used to perform field parsing and field normalization on the MQTT access message, generate a unified internal message structure, and determine the MQTT topic and target output path based on the unified internal message structure. The queue scheduling module is used to determine the message sending priority according to the unified internal message structure and write the MQTT access message into the corresponding sending queue. The link switching module is used to freeze the ordinary queue sending window, retain the sending context and perform link switching when the current communication link is detected to meet the switching conditions, and to resume queue sending after the link switching is completed or the link is restored. The status maintenance module is used to record the message identifier, confirmation status, message segment content cache and sending context after the message enters the sending process, and to update the confirmation status after receiving the confirmation message; The recovery and retransmission module is used to identify unacknowledged messages based on the sending context, the acknowledgment status, and the message segment content cache, and to perform hierarchical retransmission according to message priority and ordered retransmission according to record order; The status maintenance module uses command identifiers as message identifiers for downlink messages and event identifiers as message identifiers for uplink messages.

Images