Robot exhibition hall linkage control method, device and equipment and storage medium

Abstract

The invention discloses a robot exhibition hall linkage control method, apparatus and device, and a storage medium. The method comprises the steps of receiving a task instruction sent by a robot and obtaining a demand of the task instruction; obtaining a protocol adaptation degree vector and a weight vector based on a demand, calculating the comprehensive adaptation degree of each candidate protocol, and selecting the protocol with the highest comprehensive adaptation degree as a transmission protocol; sending a control instruction corresponding to the task instruction to equipment in the exhibition hall by using a transmission protocol; when it is detected that the network connection with the cloud server is interrupted, the control instruction serves as a network disconnection event to be cached to a local database; when detecting that the network connection is recovered, performing conflict resolution and combination on the cached network disconnection events; when the encrypted update script is received, performing verification and compatibility judgment on the update script; and after verification and compatibility judgment are passed, loading the update script to replace the currently running script. According to the method, the reliability, the real-time performance and the operation and maintenance efficiency of the system are effectively improved.

Description

Technical Field

[0001] This invention relates to the field of robotics, and in particular to a method, apparatus, equipment, and storage medium for the linkage control of a robot exhibition hall. Background Technology

[0002] With the deep integration of IoT technology and intelligent robots, IoT smart exhibition halls have become an important scenario for showcasing scientific and technological achievements and enhancing interactive experiences. The core requirement is to achieve efficient linkage control between robots and various exhibition hall equipment such as large-screen players and interactive booths. Multi-protocol heterogeneous network adaptation, reliable operation in offline conditions, and flexible script updates are key technical supports to ensure the linkage effect.

[0003] Regarding multi-protocol routing, existing technologies have proposed solutions for dynamic protocol allocation, such as the AI ​​dynamic multi-protocol allocation technology disclosed in CN120512720A. This technology prioritizes protocols based solely on channel quality and throughput, thereby enabling dynamic protocol selection. However, robot task instructions in exhibition hall scenarios have significantly differentiated requirements, with different instructions having varying demands for real-time performance, bandwidth, and power consumption. Existing technologies do not involve explicit formulaic routing with three-dimensional weights for robot instructions, resulting in a single protocol selection dimension. This makes it impossible to dynamically weight and adapt to different robot task types, thus failing to meet the transmission requirements of diverse task instructions.

[0004] In the field of edge-side network outage caching, CN115220901A discloses an edge-side network outage caching technology that uses message queues to cache real estate data to address the temporary data storage needs during network outages. However, this technology only implements simple stacked data storage and does not design an incremental timestamp merging algorithm. It cannot solve the problem of zero event loss during network outages, nor can it effectively handle the core requirements of data deduplication and causal ordering. This leads to residual conflicts in data synchronization after network recovery, affecting data integrity and consistency.

[0005] Regarding robot event script updates, the robot event script technology disclosed in CN107728785A uses a static loading method to implement robot control logic. Script updates require manual intervention, which is not only inefficient but may also cause exhibition hall operation interruptions. Furthermore, this technology lacks a hot-swappable mechanism for gray-scale rollback, has no zero-downtime update capability, and has not established a mathematical standard for version compatibility. System failures due to version incompatibility are prone to occur during script updates, and it is impossible to quickly roll back to a stable version after a failure occurs.

[0006] Furthermore, existing technologies related to robot linkage control in exhibition halls suffer from a common flaw: the lack of causal sequence verification in log synchronization. This leads to inconsistencies between the log data received from the cloud and the actual execution order of actions on the local devices, resulting in distorted cloud statistics and impacting the accuracy of operational analysis and decision-making. In summary, existing technologies have significant shortcomings in areas such as dynamic adaptation to multiple protocols, offline cached data processing, script update flexibility, and log synchronization consistency, making it difficult to meet the efficiency, reliability, and flexibility requirements of IoT-enabled smart exhibition halls for robot linkage control. Summary of the Invention

[0007] The purpose of this invention is to provide a robot exhibition hall linkage control method, device, equipment, and storage medium, aiming to solve the problems that existing technologies cannot meet the requirements of efficiency, reliability, and flexibility of robot linkage control for IoT smart exhibition halls.

[0008] In a first aspect, embodiments of the present invention provide a robot showroom linkage control method, comprising: Receive and parse the task instructions sent by the robot, and obtain the requirements of the task instructions for real-time performance, bandwidth and power consumption based on the parsed task instructions; Based on the requirements, the adaptation vectors of each protocol are measured. The overall adaptation of each candidate protocol is calculated by combining the adaptation vectors of each protocol with a preset weight vector. The protocol with the highest overall adaptation is selected as the transmission protocol. Use the transmission protocol to send control commands corresponding to the task commands to the devices in the exhibition hall; When a network connection interruption with the cloud server is detected, the control command is cached as a network outage event in the local database; When network connectivity is detected to be restored, the cached network outage events will be conflict-resolved and merged. When an encrypted update script is received, the update script is verified and its compatibility is determined. After verification and compatibility assessment are passed, the update script is loaded to replace the currently running script.

[0009] Secondly, embodiments of the present invention provide a robot exhibition hall linkage control device, comprising: The parsing unit is used to receive and parse the task instructions sent by the robot, and obtain the requirements of the task instructions for real-time performance, bandwidth and power consumption based on the parsed task instructions. The calculation unit is used to measure the adaptation vector of each protocol based on the requirements, calculate the comprehensive adaptation of each candidate protocol by the adaptation vector of each protocol and the preset weight vector, and select the protocol with the highest comprehensive adaptation as the transmission protocol. The sending unit is used to send control commands corresponding to the task commands to the devices in the exhibition hall using the transmission protocol; A caching unit is used to cache the control command as a network disconnection event in a local database when a network connection interruption with the cloud server is detected. The merging unit is used to resolve and merge the cached network outage events when the network connection is detected to be restored. The verification unit is used to verify and determine the compatibility of the received encrypted update script. The loading unit is used to load the update script to replace the currently running script after the verification and compatibility determination are passed.

[0010] Thirdly, embodiments of the present invention provide a computer device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the robot showroom linkage control method described in the first aspect.

[0011] Fourthly, embodiments of the present invention also provide a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, which, when executed by a processor, implements the robot showroom linkage control method described in the first aspect.

[0012] This invention discloses a robot exhibition hall linkage control method, device, equipment, and storage medium. The method includes: receiving and parsing task instructions sent by a robot, and obtaining the requirements of the task instructions for real-time performance, bandwidth, and power consumption based on the parsed task instructions; measuring the adaptation vector of each protocol based on the requirements, calculating the comprehensive adaptation degree of each candidate protocol by using the adaptation vector of each protocol and a preset weight vector, and selecting the protocol with the highest comprehensive adaptation degree as the transmission protocol; sending control instructions corresponding to the task instructions to devices in the exhibition hall using the transmission protocol; when a network connection interruption with the cloud server is detected, caching the control instructions as a network outage event in a local database; when a network connection is detected to be restored, resolving and merging the cached network outage events; when an encrypted update script is received, verifying and determining the compatibility of the update script; and after the verification and compatibility determination are passed, loading the update script to replace the currently running script. This invention achieves dynamic protocol optimization by constructing a formulaic routing model based on three-dimensional weights of real-time performance, bandwidth, and power consumption; it ensures zero loss and causal order of network outage events by utilizing conflict resolution and merging; and it supports seamless hot updates and automatic rollback of scripts by introducing compatibility judgment. This significantly reduces end-to-end transmission latency, achieves complete event synchronization, and enables zero-downtime script updates that are imperceptible to viewers, effectively improving system reliability, real-time performance, and operational efficiency. This invention also provides a robot exhibition hall linkage control device, a computer-readable storage medium, and a computer device, all possessing the aforementioned beneficial effects, which will not be elaborated upon further here. Attached Figure Description

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

[0014] Figure 1 A flowchart illustrating the linkage control method for a robot exhibition hall; Figure 2 This is a schematic diagram of the first sub-process of the robot exhibition hall linkage control method. Figure 3 This is a schematic diagram of the second sub-process of the robot exhibition hall linkage control method; Figure 4 This is a schematic diagram of the third sub-process of the robot exhibition hall linkage control method; Figure 5 This is a schematic block diagram of the linkage control device for the robot exhibition hall. Detailed Implementation

[0015] 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, not all, of the embodiments of the present invention. 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.

[0016] It should be understood that, when used in this specification and the appended claims, the terms “comprising” and “including” indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more of its features, integrals, steps, operations, elements, components and / or collections thereof.

[0017] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0018] It should also be further understood that the term "and / or" as used in this specification and the appended claims refers to any combination of one or more of the relevant listed items and all possible combinations, and includes such combinations.

[0019] Please see Figures 1-4 This embodiment provides a robot showroom linkage control method, including: S101: Receive and parse the task instructions sent by the robot, and obtain the requirements of the task instructions for real-time performance, bandwidth and power consumption based on the parsed task instructions; Specifically, when the robot needs to approach the interactive display and trigger its demonstration, it sends a structured task instruction to the Unified Control Terminal (UCC) via the MQTT protocol (a lightweight publish / subscribe messaging protocol). Upon receiving the instruction, the UCC first parses it, identifying key elements such as the task type (device linkage), the target device (interactive display), and the required action (playing specified multimedia content). Based on the parsed task type and parameters, the UCC calls a pre-defined task requirement mapping table. This mapping table defines the core communication quality requirements for different task categories. For device linkage tasks, especially display triggers requiring immediate feedback, the system maps a high real-time requirement, a medium bandwidth requirement (due to the potential need to transmit start commands or a few parameters), and a low power consumption expectation (to extend the robot and display device's battery life). Thus, the UCC completes the extraction of quantifiable three-dimensional requirements for real-time performance, bandwidth, and power consumption from the raw instruction, providing clear input for subsequent dynamic protocol routing decisions.

[0020] S102: Based on the requirements, measure the adaptation vector of each protocol, calculate the comprehensive adaptation of each candidate protocol by using the adaptation vector of each protocol and the preset weight vector, and select the protocol with the highest comprehensive adaptation as the transmission protocol. In this embodiment, the UCC has a built-in dynamic protocol routing table. Based on the robot's requirements for real-time performance, bandwidth, and power consumption, and combined with the preset protocol routing table, a weighted algorithm is used to calculate the suitability of each candidate protocol, thereby selecting the most suitable transmission protocol for different instructions.

[0021] Specifically, the candidate protocol set is set as follows: To meet the robot's command requirements, a three-dimensional adaptation vector is constructed: in, Protocol The adaptability in the real-time dimension ranges from [0, 1], with a higher value indicating stronger real-time performance. Protocol In terms of bandwidth adaptability, the value range is also [0, 1], and a higher value means more sufficient bandwidth; This represents the agreement. The adaptability in the power consumption dimension ranges from [0, 1], with higher values ​​indicating lower power consumption. Based on the robot's instruction requirements, the weight vectors for each dimension are set as follows: satisfy So, the agreement Overall adaptability relative to current robot instruction requirements The calculation formula is: The protocol with the highest overall adaptability was selected as the transmission protocol for this robot command, namely: In one specific embodiment, a robot provides explanations and demonstrations within the exhibition hall following a preset route. The system utilizes dynamic protocol routing to automatically switch between Wi-Fi and Bluetooth protocols based on the current network conditions and device distribution within the exhibition hall, ensuring stable and smooth command transmission between the robot and the display devices.

[0022] Assume the robot's current task is to approach an interactive display stand that supports Bluetooth connectivity and trigger a display action. The system determines which protocol to use based on real-time calculated protocol compatibility. The formula for calculating protocol compatibility is defined as follows: in, These represent the weights for real-time performance, bandwidth, and power consumption, respectively. These represent the adaptability of protocol i in terms of real-time performance, bandwidth, and power consumption, respectively, with values ​​ranging from [0, 1].

[0023] Measurements showed that the real-time adaptability of the Wi-Fi protocol in the current scenario was [data missing]. Bandwidth adaptability Power consumption adaptability The real-time adaptability of the Bluetooth protocol in the current scenario. Bandwidth adaptability Power consumption adaptability .

[0024] The calculation shows that: because The system automatically switches to Bluetooth protocol, sending control commands quickly and stably to make the booth perform corresponding actions to complement the explanation content.

[0025] In some embodiments, it also includes: Analyze the task queue from the robot to obtain the next scheduled task, which includes the task type and target location; Based on the robot's current position, real-time moving speed, and target position, predict the time when the robot will arrive at the target position; Query the pre-stored digital map of the exhibition hall, which includes a protocol signal coverage heatmap, to obtain expected network quality data along the path from the current location to the target location; Based on the task type and expected network quality data, calculate the predicted fit of each candidate protocol at different future time points along the path. Based on the calculated predicted adaptability at each time point, a forward-looking protocol switching sequence and corresponding switching schedule for the coverage path are generated. During the process of the robot performing tasks using the current protocol, the communication protocol is proactively switched to a predetermined protocol in the forward-looking protocol switching sequence at the predicted switching time point according to the switching schedule. After the protocol switch and task execution are completed, the actual task execution indicators and network performance data are collected, and the data is used to update the protocol signal coverage heat map in the exhibition hall digital map.

[0026] This embodiment obtains task types and target locations by parsing the robot's task queue, predicts arrival time based on current location, real-time movement speed, and target location, queries a digital map of the exhibition hall containing protocol signal coverage heatmaps to obtain path network quality data, calculates protocol prediction adaptability at each time point by combining task type, generates a forward-looking protocol switching sequence and switching schedule for the coverage path, proactively switches protocols at predicted time points according to the schedule, and finally collects actual execution data to update the digital map. Its advantages lie in achieving deep coupling between tasks and the network environment, planning protocol switching timing in advance through predictive analysis to avoid communication interruptions caused by immediate reactions, and dynamically optimizing the digital map based on actual execution data, enabling the predictive model to continuously adapt to environmental changes and ensuring the accuracy and continuity of protocol switching.

[0027] Specifically, during the guided tour of the exhibition hall by the robot, the Unified Control Terminal (UCC) continuously monitors and maintains a dynamic task queue. For example, the current queue sequentially stores task instructions such as proceeding to explain sculpture #3, proceeding to the central interactive screen to play a video, and returning to the charging station to wait. When the robot is about to finish explaining painting #2, the UCC begins processing the next instruction in the queue. It parses the specific content of the next pre-defined task from the head of the queue: the task type is identified as proceeding to a specific exhibit location and triggering an explanation, and the target location is extracted from the instruction parameters as precise coordinates in the exhibition hall map coordinate system, corresponding to exhibition area B-12 where sculpture #3 is located. The UCC structurally encapsulates the parsed information, generating a task object containing standard fields, with the task type and target location as core attributes, providing clear input for subsequent predictive path planning and protocol selection.

[0028] Next, the robot uses its onboard UWB indoor positioning system or visual SLAM system to obtain its real-time coordinates on the digital map of the exhibition hall, which serves as its current location. Simultaneously, the target location, provided in the task analysis phase, is the coordinates of the center point of booth 3. Based on these two coordinates, the path planning algorithm, combined with the static layout model of the exhibition hall (such as wall and display case positions) and dynamic obstacle information, calculates an optimal collision-free path and determines its total length, i.e., the spatial distance. Meanwhile, the robot's motion control system continuously provides its real-time speed data, which integrates feedback from the wheel encoders and acceleration information based on the inertial measurement unit. The prediction model not only uses the current instantaneous speed but also references the robot's typical acceleration curve on such a flat exhibition hall floor and the planned cruising speed to be reached midway along the path. Finally, the system divides the calculated total path length by the smoothed and model-corrected predicted average speed to determine the precise time the robot is expected to arrive at the target booth location. This predicted time will be output as a key time reference for subsequent protocol switching decisions.

[0029] The path planning algorithm, based on the coordinates of these two points, combined with the static layout model of the exhibition hall (such as the positions of walls and display cases) and dynamic obstacle information, calculates an optimal collision-free path and determines the total length of the path, including: The robot's current position coordinates are obtained through the robot's positioning system, and the target position coordinates are parsed from the task instructions, thus obtaining the current position coordinates and target position coordinates as the first output; Load the pre-stored digital map of the exhibition hall to obtain a static layout model including the positions of walls and display cases, and collect dynamic obstacle information in real time through a sensor network to obtain the static layout model and dynamic obstacle information as the second output; Based on the current position coordinates and target position coordinates in the first output, and the static layout model and dynamic obstacle information in the second output, a path search algorithm is used to calculate an optimal collision-free travel path from the current position to the target position. The path satisfies the robot's kinematic constraints and avoids all obstacles, thus obtaining the optimal collision-free travel path as the third output. Based on the optimal collision-free path in the third output, the total length of the path is calculated by discretizing the path point sequence and accumulating the Euclidean distances between adjacent points, thus obtaining the spatial distance as the final output.

[0030] Specifically, when the exhibition hall guide robot initiates the next task execution process, it obtains its real-time position coordinates through its integrated positioning system. This system combines UWB positioning and visual positioning technologies to ensure coordinate accuracy. Simultaneously, the system parses the position coordinates corresponding to the target service area from the task instructions to be executed, integrating the two sets of coordinate data to form the current position coordinates and target position coordinates as the first output. The system then retrieves the locally stored digital map of the exhibition hall, extracting a static layout model from the map that includes the positions of all walls, display cases, fixed pillars, and safety boundaries. At the same time, it connects to the multi-source sensor network deployed in the exhibition hall. This network uses infrared sensors and panoramic cameras to collect real-time dynamic obstacle information such as the area of ​​densely populated areas and the real-time position and direction of movement of other mobile devices. The static layout model and dynamic obstacle information are then integrated to form the second output. Based on the current and target position coordinates from the first output, and the static layout model and dynamic obstacle information from the second output, the system initiates a preset A* path search algorithm. The algorithm optimizes for the shortest path length while incorporating the robot's kinematic constraints, limiting its turning radius and maximum speed. During the calculation, it avoids static obstacles such as walls and display cases, as well as dynamic obstacles such as pedestrians and other mobile devices in real time. Finally, it generates an optimal collision-free path from the current position to the target position as the third output. The system processes this optimal collision-free path by discretizing it into an ordered sequence of path points. It iterates through each pair of adjacent path points in the sequence, calculating the straight-line distance between each pair using the Euclidean distance formula. Then, it sums the distances of all adjacent path points to obtain the total length of the optimal collision-free path, thus using the spatial distance as the final output.

[0031] After obtaining the optimal collision-free path from the robot's current position to the target position, the system immediately accesses a pre-stored digital map database of the exhibition hall. This digital map not only contains the geometric structure of the physical space but also overlays multiple layers of protocol signal coverage heatmaps. Each heatmap corresponds to a communication protocol, such as Wi-Fi 2.4GHz, Wi-Fi 5GHz, Bluetooth, and Zigbee, and stores historically measured network quality indicators such as signal strength, average latency, and packet loss rate at each grid point in the form of gridded data. The system precisely aligns the coordinate sequence of the calculated optimal collision-free path with the coordinate system of the digital map. Next, the system traverses every coordinate point on the path sequence. For each point, it locates its corresponding grid in the digital map and extracts the signal strength value, historical latency data, and stability score stored within that grid from the heatmap layer corresponding to each protocol. Through this process, the system collects a set of multi-dimensional expected network quality data for each point on the path. Finally, the system integrates the data collected from these points along the path sequence into a structured dataset. This dataset describes the expected network conditions of the areas traversed by the robot's trajectory throughout its journey from the starting point to the end point for each candidate communication protocol, providing crucial environmental input for subsequent protocol prediction and fit calculations.

[0032] After obtaining the optimal travel path with a structured description and the expected network quality dataset for each point along it, the system enters the predictive protocol fit calculation stage. First, based on the task type of the next scheduled task being executed, the system calls pre-defined mapping rules to determine the weight vectors for the task's requirements in three dimensions: real-time performance, bandwidth, and power consumption. For example, for a presentation task requiring real-time interaction with the exhibition booth, the weights might be (0.5, 0.3, 0.2). Simultaneously, for each candidate communication protocol, the system maps its expected network quality data for each point on the path to three-dimensional fit vector components at that point using a predefined transformation function; for example, the Wi-Fi signal strength and historical latency data for a point are converted into Wi-Fi protocol fit values ​​in the real-time and bandwidth dimensions for that point. Next, the system combines the robot's predicted movement speed with the path point sequence to associate each path point with a predicted future time point. For each future time point, the system substitutes the corresponding protocol fit vectors and the current task's weight vector into the comprehensive fit calculation formula to calculate the predicted fit score for each protocol at that future time. By traversing all locations along the path that are associated with time points, the system ultimately generates a data structure that clearly displays the predicted fit score of each candidate protocol at each future moment on the entire timeline from the start to the end of the task. This provides a precise quantitative basis for formulating a forward-looking optimal protocol switching plan.

[0033] After calculating the predicted fit at each future time point along the path, the system initiates the generation of a forward-looking protocol switching plan. The algorithm iterates through the predicted fit data for each point on the timeline, marking the theoretically optimal protocol with the highest score at each moment. Next, a switching hysteresis logic is applied to optimize the decision: a time point is only confirmed as a valid protocol switching decision point if the fit advantage of the new protocol consistently exceeds a preset threshold (e.g., 0.1) of the old protocol and remains there for a minimum duration (e.g., 2 seconds). The system connects these decision points in chronological order to form a clear protocol switching sequence, such as [Wi-Fi, Switching Point A, Bluetooth]. Simultaneously, the algorithm binds each switching point to the precise time point at which the robot is expected to reach the corresponding path location, generating a specific switching schedule that clearly specifies when (e.g., T+12.3 seconds) the instruction will switch to which protocol (e.g., Bluetooth).

[0034] As the robot begins moving along the planned path and performing its tasks, the Unified Control Terminal (UCC) rigorously monitors the handover schedule. When the system clock reaches the predetermined handover time, the UCC proactively issues a handover command to the robot's communication module. At this point, regardless of the current connection quality, the system will interrupt the existing protocol connection as planned and initiate a new connection establishment process according to the predetermined target protocol in the sequence. This predictive proactive handover ensures that the protocol transition occurs before network conditions deteriorate due to the robot's physical movement, thus avoiding passive, potentially disruptive, emergency handovers triggered by signal degradation and achieving a smooth transition.

[0035] After the robot completes the entire task, including all protocol switching actions, the system initiates a data collection and learning process. UCC collects actual metrics for this task execution, including the actual usage time of each protocol, service latency before and after the switch, command success rate, and real-time signal strength and packet loss rate reported by the device at each location. This real-world network performance data and task execution metrics are aggregated and uploaded to the cloud. The cloud server uses this new measured data to incrementally update the protocol signal coverage heatmaps for corresponding areas and paths in the exhibition hall's digital map, such as correcting the Wi-Fi signal strength value at a grid point or updating the average latency record for the Bluetooth channel. Through this process, the system's predictive model receives the latest real-world feedback, making the heatmap data more accurate when predicting and planning for other robots or tasks in the future, achieving closed-loop continuous self-optimization.

[0036] S103: Use the transmission protocol to send control commands corresponding to the task commands to the equipment in the exhibition hall; After selecting the transmission protocol, the system immediately generates a sequence of device-level control commands based on the parsed task instructions. This sequence includes key information such as device identifier, command type, parameter values, and timestamps. For example, for navigation-related task instructions, the system maps parameters such as target coordinates and movement speed to robot chassis control commands; for interactive tasks, it generates a sequence of touchscreen response commands. Subsequently, the system calls the communication interface of the selected transmission protocol to encapsulate the control command data packets according to the protocol specifications, including adding checksums, sequence numbers, and priority markers to ensure that the data format conforms to the protocol requirements. After encapsulation, the system establishes a communication connection through a preset network channel and sends the data packets to the designated target device in the exhibition hall in a streaming manner. Simultaneously, the system monitors the transmission status in real time. If a transmission anomaly is detected, a retransmission mechanism is automatically triggered until the device confirms receipt, thereby achieving precise execution of task instructions to device control.

[0037] In this embodiment, after sending the control command corresponding to the task command to the equipment in the exhibition hall using the transmission protocol, the process includes: Obtain the actual completion rate and expected completion rate of the task after the control command is completed; The success rate is calculated based on the ratio of the actual completion rate to the expected completion rate of the task. The weight vector is updated based on the success rate using the following formula: in, This represents the updated weight vector; This represents the weight vector before the update; This represents the weight adjustment coefficient, with a value range of (0, 1). Indicates the degree of success.

[0038] Specifically, to more accurately reflect the robot's preference for different protocols in its instructions, the weight vector w can be dynamically adjusted based on historical task execution data. The task execution success rate is defined as η, and its calculation formula is: The weight vector is updated based on η, and the update formula is as follows: Where β is the weight adjustment coefficient, ranging from (0, 1), used to control the magnitude of weight adjustment. The updated weight vector needs to be normalized according to the following formula to ensure that the sum of the weights is 1: in, This represents the normalized weight vector.

[0039] S104: When a network connection interruption with the cloud server is detected, the control command is cached as a network disconnection event in the local database; In this embodiment, caching control commands as network outage events in the local database includes: Generate a unique identifier, timestamp, event type, event payload data, event processing status, and semantic version number for each control command; Cache the unique identifier, timestamp, event type, event payload data, event processing status, and semantic version number to the local database.

[0040] This caching mechanism generates a unique identifier, timestamp, event type, event payload data, event processing status, and semantic version number for each control command, ensuring the integrity and traceability of event information. The unique identifier ensures the uniqueness of each event within the system, providing a precise basis for subsequent deduplication; the timestamp accurately records the event's occurrence time, supporting chronological sorting and guaranteeing causal consistency; the event type clearly distinguishes command categories, such as navigation or interactive commands, facilitating targeted system processing; the event payload data completely preserves the command content, preventing information loss; the event processing status is initialized to pending, enabling the system to monitor the processing progress of cached events in real time; and the semantic version number is used for conflict resolution and version consistency verification. These elements work together to effectively prevent event stacking even when the system is offline, achieving zero event loss, deduplication, and causal order guarantee. This provides a complete data foundation for the subsequent execution of the Δ-window optimistic locking merging strategy, solving the problems of cached data redundancy and disordered ordering in existing technologies.

[0041] Specifically, in the event of network instability or outage, UCC can detect the connection status with the cloud server in real time. Once an outage is confirmed, it immediately activates the outage caching mechanism, recording control events to the local SQLite database. To ensure the consistency and integrity of the locally cached data, the following data storage structure is adopted: Where id is the unique identifier for the event, and timestamp is the timestamp of the event occurrence. The event type is indicated by the event payload, the event status is indicated by the event processing status (such as pending, uploaded, etc.), and the version is the event semantic version number (written into the payload when generated by the script, used for optimistic locking conflict resolution).

[0042] S105: When network connection is detected to be restored, the cached network outage events will be conflict-resolved and merged; In this embodiment, resolving and merging cached network outage events includes: Retrieve network outage events with a pending synchronization status from the local database; Retrieve cloud events within the corresponding time window from the cloud server; Define conflict windows; Calculate the difference between the timestamp of the network outage event and the timestamp of the cloud event to obtain the timestamp difference; When the timestamp difference is less than or equal to the conflict window, it is determined whether the version number of the network outage event is greater than the version number of the cloud event. If the version number of the network outage event is greater than the version number of the cloud event, the network outage event is retained and the cloud event is discarded. If the version number of the network outage event is less than or equal to the version number of the cloud event, the cloud event is retained and the network outage event is discarded. The final retained cloud events and network outage events are sorted in ascending order by timestamp and uploaded to the cloud server in sequence.

[0043] This conflict resolution and merging mechanism effectively solves the problems of data redundancy and causal order distortion in network outage event processing by accurately calculating timestamp differences and comparing semantic version numbers. The system first acquires the network outage events to be synchronized and the corresponding cloud events within a time window. A conflict window of 2 seconds is defined to limit the event processing range, ensuring that conflict detection is only performed on events with similar times. After calculating the timestamp difference, when the difference is less than or equal to the window value, the system retains the latest event and discards outdated events based on the semantic version number, achieving event deduplication and version consistency. Finally, the retained events are uploaded in ascending order of timestamp, ensuring that the event processing order conforms to the actual occurrence logic. This avoids the redundancy and disordered order caused by simply stacking cached data in existing technologies, while guaranteeing zero data loss and complete causal order for network outage events, providing a highly reliable data synchronization foundation for the system.

[0044] In some embodiments, a data synchronization process is triggered after network recovery. To efficiently synchronize data and avoid data conflicts, an incremental synchronization algorithm based on timestamps and event IDs is employed, and a Δ-window optimistic locking merging strategy is embedded. Define the conflict window Δ = 2s (NTP maximum permissible error); For any network outage event Cloud events ,like Then the conflict is resolved; among them, Indicates the timestamp of the network outage event; Represents the timestamp of an event in the cloud; The event ID representing the network outage event; The event ID represents the event in the cloud.

[0045] Conflict resolution employs a version number-based strategy: version number wins. One event is marked as discard; In this embodiment, before sorting the final retained cloud events and network outage events in ascending order of timestamps, the following is included: If an irreversible deviation in the device state is detected, a soft reset command is sent to the device to roll back to the most recent state snapshot.

[0046] For example, if an irreversible deviation occurs (such as when the device is manually intervened), soft compensation is triggered: a soft-reset command is immediately issued to roll back the device to the most recent snapshot (snapshot period 5 minutes). The compensation command is sent first after synchronization is completed to ensure eventual consistency.

[0047] This embodiment detects irreversible deviations in device status in real time. If a deviation is detected, a soft reset command is immediately issued, causing the device to roll back to the most recent state snapshot. This completely eliminates the risk of inconsistencies in status before event sorting. This mechanism effectively prevents the accumulation of abnormal device statuses due to network outages or fluctuations, ensuring that the device remains in a reliable baseline state throughout event processing. It avoids causal sequence distortion and cloud statistical errors caused by status deviations in existing technologies. Furthermore, the soft reset operation is automatically triggered within the snapshot period (5 minutes) without manual intervention, significantly shortening system recovery time. This provides a clean and consistent data foundation for subsequent events to be sorted in ascending order of timestamps, ensuring the accuracy and reliability of the entire data synchronization process.

[0048] In some embodiments, the system initiates a data synchronization process after a network outage is recovered. The synchronization time window is defined as the timestamp T of the last successful synchronization. last up to the current time T current ,Right now The system first queries the local SQLite database for all events whose timestamps fall within this window and whose status is pending, forming a local event set E. local Simultaneously, a request is sent to the cloud server to retrieve the set of cloud events E within the same time window. cloud Next, the system applies the Δ-window optimistic locking merging algorithm to process the two sets. The core conflict probability of this algorithm is determined by the model. Description, where λ is the event arrival rate. The total number of events within the window is Δ, where Δ is the preset conflict time window (e.g., 2 seconds).

[0049] Next, query the local database to find the desired result. Furthermore, the status is a set of events that are pending and awaiting processing. ; Request a query from the cloud server to satisfy event set .

[0050] Next, all retained events are sorted in ascending order of timestamp and uploaded sequentially to the cloud server, while the local event status is updated to "uploaded". During this process, if any device is detected to have an irreversible state deviation due to manual intervention during the network outage, the system will immediately issue a soft reset command to that device, rolling its state back to the most recently saved snapshot. Finally, after all synchronization tasks are completed, the system will... last Update to the current T current This establishes a new reference point for the next synchronization.

[0051] In some embodiments, it also includes: Monitor control events generated by robots and exhibition hall equipment within a preset time period to obtain the real-time event arrival rate λ, and obtain historical conflict frequency data from historical records; Based on real-time event arrival rate λ and historical conflict frequency data, a dynamic conflict window value Δ is generated through a predefined dynamic window calculation model. When performing incremental synchronization operations between network outage events and cloud events, a dynamic conflict window value Δ is used as the time window threshold for conflict determination to perform conflict resolution and merging based on timestamp differences and version numbers. Based on the actual conflict resolution results during this synchronization operation, the historical conflict frequency data is updated for use in calculating the dynamic conflict window value in subsequent cycles.

[0052] This embodiment continuously monitors the system to generate a real-time event arrival rate λ and simultaneously acquires historical conflict frequencies, providing a realistic and quantitative basis for window adjustment and freeing the system from the limitations of relying on fixed empirical values. Secondly, based on these two types of data, a dynamic window value Δ is generated through a predefined model, achieving intelligent adaptation of the conflict judgment threshold. Automatically narrowing the window during high event density periods effectively filters irrelevant event pairs caused by minor timestamp fluctuations, significantly reducing the computational overhead of conflict comparison; appropriately widening the window during low event density periods ensures that all potential conflicts are included in the detection range, avoiding the risk of missed detection due to an overly tight window. Furthermore, this dynamic value is directly applied to the conflict resolution stage of incremental synchronization, optimizing the accuracy and efficiency of each synchronization operation based on the current system state. Finally, historical conflict frequency data is updated based on the actual results of this synchronization, forming a closed-loop feedback learning mechanism. This allows the dynamic window calculation model to continuously evolve, constantly approaching the actual operating characteristics of the system, thereby achieving continuous improvement in the accuracy and efficiency of conflict resolution over long-term operation.

[0053] Specifically, within a complete synchronization cycle, such as every minute, the system statistically analyzes all control commands received and processed by the unified control terminal (UCC). These commands include navigation and explanation instructions sent by the narration robot, as well as status information or execution reports from various display devices. The system accumulates the number of all newly generated events within this cycle and divides this number by the cycle length to calculate the real-time event arrival rate λ for the current cycle. Simultaneously, the system accesses its maintained historical synchronization record database, which records detailed logs of data synchronization performed after each network recovery. The system extracts key indicators from these logs, primarily calculating the ratio of the number of event pairs actually judged as conflicting during the Δ-window conflict resolution process to the total number of event pairs participating in the comparison over the most recent several synchronization cycles. This ratio serves as historical conflict frequency data. The real-time calculated λ and the retrieved historical conflict frequency data are output together as the core input parameters for subsequent dynamic adjustment of the conflict window size.

[0054] Next, the predefined dynamic window calculation model sets a fixed base window value, configures weight coefficients α=0.3 and β=0.2, and limits the effective range of the dynamic conflict window value Δ to between 1 second and 3 seconds. The model calculation formula is Δ=base window value × (1-α×λ normalized value + β×historical conflict frequency normalized value). For the acquired real-time event arrival rate λ, the system normalizes it according to the extreme range of historical event arrival rates, transforming it into a value within the interval [0,1]. For the extracted historical conflict frequency data, the system also performs normalization transformation according to the value range of 0 to 100%, obtaining the corresponding normalized result. Subsequently, the system substitutes the base window value, the normalized real-time event arrival rate λ, the historical conflict frequency data, and the preset weight coefficients into the model formula to calculate the preliminary window value. Finally, the system verifies whether the preliminary window value is within the preset effective range. If it is within the range, it is directly determined as the dynamic conflict window value Δ used in this case; if it is outside the range, the boundary value of the effective interval is taken as the final dynamic conflict window value Δ.

[0055] Then, during incremental synchronization of events between the network outage and cloud, the system uses a dynamic conflict window value Δ as a time window threshold to determine conflicts in the synchronization events. The system extracts the timestamp of each event to be synchronized and calculates the difference between it and the timestamp of the most recently successfully synchronized event. When this difference is less than or equal to the dynamic conflict window value Δ, the system further compares the event version numbers, retaining the event with the higher version number as a valid update, and performing data merging or discarding operations on the event with the lower version number. When the difference is greater than Δ, the event is considered an independent event and directly applied to the target system without conflict handling. This process, through dual verification of timestamp difference and version number, ensures the accuracy and consistency of event synchronization in network outage scenarios, avoiding misjudgments or omissions caused by a fixed window.

[0056] After all synchronization operations and conflict resolution are completed, the system automatically compiles the core data for this synchronization, including the total number of network outage events and cloud events involved in conflict determination, as well as the actual number of conflict events that were determined by the dynamic conflict window value Δ and resolved. Based on the statistical results, the conflict frequency for this synchronization is calculated, which is the ratio of the actual number of conflict events to the total number of events involved in determination. Considering the timeliness of historical data, the system removes historical conflict frequency data that exceeds the preset retention period, retaining only recent valid data. The conflict frequency calculated in this instance is then integrated into the remaining valid historical data, and the historical conflict frequency statistics are updated using a weighted average algorithm. The updated historical conflict frequency data is stored in the corresponding module of the local database, serving as the core reference for calculating the dynamic conflict window value Δ within the subsequent preset time period, ensuring the continuity and adaptability of dynamic window adjustments.

[0057] In one specific embodiment, the scenario is as follows: at 10:15:30, the robot instructs the large screen to play a 4K video, but the network suddenly drops.

[0058] 1. Statistics on network outage duration and events: Actual measurement =32s; Average event interval =2.1s; Substitute into the formula: 15 events were cached.

[0059] 2. For Δ-window conflict calculation: Window Δ = 2.0s; Event arrival rate λ = 0.35s -1 ; Number of events within the window =15; At least one conflict probability; Version optimistic locking test results; Local events =1024, timestamp=10:15:31.200, version=3; Cloud events =1101,timestamp=10:15:31.800,version=2; → Proceed to conflict resolution.

[0060] Since version(3) > version(2), local event 1024 is retained, and cloud event 1101 is discarded. 3. Soft compensation trigger threshold: Snapshot period: 5 minutes; The most recent snapshot was taken at 10:12:00. Current time is 10:15:32, 212 seconds have passed (less than 300 seconds). No soft compensation was triggered (no record of manual intervention).

[0061] 4. Data consistency verification after synchronization: 15 events were uploaded; 0 duplicate records were found in the cloud (the conflict has been resolved by the version lock). 0 packets lost; Log integrity is 100%.

[0062] S106: When an encrypted update script is received, the update script is verified and compatibility is determined. In this embodiment, the verification and compatibility determination of the update script include: Obtain the available resources of the system and the application programming interface corresponding to the update script; Determine whether the application programming interface has changed and whether the resource requirements of the update script exceed the available resources of the system; If the application programming interface has not changed and the resource requirements of the update script do not exceed the available resources of the system, it is determined that the update script passes the verification and compatibility determination; If the application programming interface has changed or the resource requirements of the update script exceed the available resources of the system, it is determined that the update script fails the verification and compatibility determination.

[0063] This verification and compatibility determination mechanism realizes the accurate mathematical determination of script compatibility by automatically obtaining the available resources of the system and the API information of the update script, effectively solving the problems in the prior art that script updates rely on manual intervention and are prone to cause system downtime. Before loading the script, the system synchronously verifies the API change status and resource requirements. If the API has not changed and the resource requirements do not exceed the available system range, it is determined to pass and dynamic loading is allowed; otherwise, loading is automatically rejected, avoiding system crashes or functional abnormalities caused by script incompatibility. This dual-verification mechanism ensures the zero-downtime feature of script updates, enables hot plugging without on-site manual operation, and prevents device performance degradation caused by resource overload, significantly improving the stability and maintainability of the robot exhibition hall linkage control system, and providing a reliable guarantee for the gray release and continuous iteration of scripts.

[0064] In some embodiments, the robot can push the encrypted modified script to the UCC through the MQTT protocol. After receiving the script, the UCC first performs syntax and format verification on the script content, and the scripts that pass the verification are temporarily stored in the update queue. Subsequently, the UCC dynamically loads the modified script into memory. After the Node-RED engine (the Node-RED engine is a flow-based programming tool for building event-driven applications) recognizes the modified script, it executes the device linkage control task according to the logic defined in the script to achieve seamless update and hot plugging of the script. To improve the flexibility and intelligence level of script updates, the script automatic update solution is further expanded: Specifically, maintain a script version library in the cloud to record different versions of each script and their release information. Define the script version number as Here, `major` represents the major version number, `minor` represents the minor version number, and `patch` represents the revision version number. When a new script version is pushed to UCC, UCC compares it with the cloud script repository based on the script name and version number to determine if it is the latest version, avoiding duplicate updates and version confusion. Simultaneously, a compatibility check is added between the new script and the existing system environment. The conditions for passing the compatibility check are defined as follows: Where A = (API_changes = ∅) indicates that the API has not changed, and R = (resource_requirements ≤ available_resources) indicates that the resource requirements are met.

[0065] S107: After the verification and compatibility determination are passed, the update script is loaded to replace the currently running script.

[0066] In this embodiment, loading the update script includes: Following the canary release strategy, the update script was gradually pushed to and loaded onto the devices in the exhibition hall.

[0067] By gradually pushing out the loading and updating scripts using a canary release strategy, we can avoid the possibility of equipment failures throughout the exhibition hall due to potential script issues during a full update, thus keeping the risk to a small extent and reducing the impact of the failure.

[0068] Specifically, for important exhibition hall display tasks or complex script updates, the script canary release function is supported. The canary release strategy is defined as follows: Where `initial_ratio` is the initial release ratio, `growth_rate` is the release ratio growth rate, `t` is the release time, and `max_ratio` is the maximum release ratio. By gradually expanding the push scope of new scripts, the potential risks that large-scale script updates may bring are effectively reduced.

[0069] In some embodiments, the OTF-SU script hot-plugging process begins with the cloud pushing an encrypted script package to the unified control terminal (UCC). The UCC first performs signature verification, syntax checking, and compatibility assessment on the script package. If the signature verification fails or the script is determined to be incompatible with the current system, the process will trigger an alarm and terminate the update. If the script is determined to be compatible, the UCC will write the script to the shadow buffer and gradually expand the scope of script push and loading to devices in the exhibition hall according to the canary release strategy. During the script push and loading process, the UCC continuously monitors the script's running status for anomalies. Once the traffic freeze node is reached, the active buffer and shadow buffer will be switched within 50 milliseconds. If the script runs abnormally a total of 3 times after the switch, the UCC will automatically roll back to the old version of the script. If the script runs normally, the UCC will upload the update logs and core-dump file, thus completing the entire OTF-SU script hot-plugging process.

[0070] In one specific embodiment, the exhibition hall plans to add an interactive element that requires more complex interaction between the robot and the display equipment. Staff will pre-write and encrypt the new script in the cloud before pushing it to the UCC.

[0071] After UCC completes a series of hot-swap operations such as script verification and dynamic loading, the robot can work in coordination with the display device according to the logic of the new script when it performs the relevant task next time.

[0072] During the script canary release process, the scope of new scripts is gradually expanded according to the preset canary release strategy. The formula for calculating the canary release push ratio is defined as follows: in, λ represents the initial push ratio, λ represents the push rate parameter, and t represents the time after publication.

[0073] Assumption (Initially pushing to 10% of devices), λ=0.1 (push rate parameter), after t=10 time units, the push ratio is: This means that approximately 63.2% of devices have been updated to the new script, effectively reducing the potential risks that large-scale script updates may bring and ensuring a smooth transition during the update process.

[0074] In some embodiments, it also includes: The received update script is subjected to a compatibility check between the application programming interface and resource requirements. When the check passes, a first pass signal is generated. By analyzing the content of the updated script through the first signal, we can analyze its call and data dependency relationships with other currently running scripts in the system and generate a script dependency graph. Based on the dependency graph between scripts, identify all other scripts that directly or indirectly depend on the updated script and generate a list of affected dependent scripts; The update script is loaded into a resource-constrained secure sandbox environment and run. The scripts in the affected dependency script list call operations to the update script are simulated in the secure sandbox environment. At the same time, the behavioral indicators of the update script during the running process are monitored to obtain the sandbox running monitoring results. Based on the sandbox operation monitoring results, determine whether the update script behavior is abnormal; If no anomalies are found, the updated script and its dependency graph will be officially deployed to the production environment to replace the old script, in accordance with the canary release strategy. If an anomaly is detected, the update process will be terminated and an alarm message will be generated.

[0075] This embodiment analyzes and generates a dependency graph between scripts, expanding the evaluation dimension from a single script to the entire script ecosystem. It can accurately identify the chain reactions that updates may trigger, thereby preventing cascading failures caused by a single script update that result in the failure of multiple related functions, and achieving system-level update impact assessment.

[0076] Specifically, when the cloud server pushes an encrypted script package for updating the robot's interaction process to the unified control terminal (UCC), the UCC initiates its hot-swap script update process. First, the UCC decrypts and digitally verifies the received script package to ensure its authenticity and lack of tampering. After successful verification, the UCC performs rigorous syntax and format parsing on the script itself, checking its compliance with the Node-RED sub-stream specification. Subsequently, the system enters the core compatibility assessment phase. This assessment involves two parallel checks: First, it checks for changes to the application programming interfaces (APIs). The system compares all external interfaces declared in the new script (such as the HTTP interface for controlling the large screen and the CAN instruction set for driving the robot's underlying layer) with the list of currently registered and stable APIs in the system to confirm whether any interfaces have been removed, renamed, or have undergone incompatible parameter structure changes. Second, it assesses resource requirements. The system parses the maximum memory usage, CPU computing power requirements, and possible persistent storage space declared in the script or estimated through static analysis, and compares these with the UCC's current available resource capacity. Only when both of the above checks pass—that is, the API change set is empty and the resource requirements do not exceed the available resources—will the system ultimately determine that the update script has passed the compatibility test. At this point, UCC internally generates a clear first pass signal, which will trigger the subsequent dependency analysis and sandbox testing process.

[0077] Specifically, by analyzing the content of the updated script through the first signal, the call and data dependencies between the script and other currently running scripts in the system are analyzed to generate an inter-script dependency graph, including: The system receives the target script to be updated and the first pass signal generated after the target script's compatibility with resource requirements through the application programming interface (API). Then, based on the first pass signal, it extracts the API call list, data input / output nodes, function call logic, and resource usage type data of the target script. Next, it retrieves similar runtime characteristic data of all currently running existing scripts in the system, including API call records, data interaction objects, externally provided function services, and resource dependency information for each existing script. Then, it correlates and matches the runtime characteristic data of the target script with the runtime characteristic data of all existing scripts, analyzing the direct call relationship, indirect call chain, data transmission direction, and resource sharing dependency type between the target script and each existing script. Finally, based on the analyzed call and data dependency relationships, it sets the script as a graph node... The system employs a graph construction rule that uses dependencies as connecting edges and dependency strength as edge weights. Following this rule, the target script and all existing scripts are mapped to graph nodes. Identified direct dependencies, indirect dependencies, data dependencies, and resource dependencies are mapped to different types of connecting edges. The dependency triggering conditions and interaction frequencies for each edge are labeled, generating a script dependency graph covering both the target script and all existing scripts. Next, based on this script dependency graph, all existing script nodes are traversed to identify directly dependent scripts with direct connecting edges to the target script, as well as indirectly dependent scripts linked through multiple layers of connecting edges. This information is then integrated to form a list of dependent scripts affected by updates to the target script. Finally, the script dependency graph and the list of affected dependent scripts are synchronously stored in the system data center as the core basis for subsequent script sandbox testing and coordinated updates.

[0078] Next, starting from the graph nodes corresponding to the update scripts, the system uses a graph traversal algorithm to identify all directly connected nodes, generating a set of directly dependent scripts. Then, for each script node in the set, the system further traverses all its connecting edges to identify indirect script nodes associated through multi-level dependency paths, forming a set of indirect dependent scripts. The system merges the set of directly dependent scripts and the set of indirect dependent scripts, filters out duplicate script entries, and integrates them to generate a complete dependency list containing all scripts affected by the update scripts. This list serves as the core input for subsequent script sandbox testing and impact assessment of linked updates.

[0079] After generating the list of affected dependent scripts, the system initiates the sandbox testing process. First, the system creates a strictly resource-constrained, independent secure sandbox environment within UCC, with preset quota limits set for CPU, memory, network, and file system access. Next, the target script to be updated is loaded into this sandbox, but its main logic is not directly activated. Based on the dependent script list, the system simulates typical calls to the target script from each dependent script in the list, such as sending simulated MQTT messages or HTTP requests through virtual interfaces within the sandbox to trigger the corresponding processing functions of the target script. During the execution of the target script responding to these simulated calls, the sandbox monitor continuously monitors and records its behavioral metrics, including CPU utilization curves, memory allocation and reclamation, the presence of blocking system calls, the initiator and frequency of network requests, and whether there are attempts to access restricted resources without authorization. Simultaneously, the system injects abnormal input or simulates network latency to test the script's robustness. All monitoring data is collected in real time and stored in a structured format to form a detailed sandbox operation monitoring results report. This report not only includes raw performance data, but also makes preliminary markings of abnormal behaviors according to preset security policies, providing an objective basis for the final decision on whether to allow the operation.

[0080] After obtaining a detailed sandbox operation monitoring report, the system enters the final deployment decision-making phase. The decision engine first automatically analyzes the report based on a preset set of anomaly detection rules. These rules include, but are not limited to: whether CPU utilization consistently exceeds a safety threshold, whether memory usage shows an unrecoverable leakage trend, whether prohibited system calls occur, whether network requests point to unauthorized addresses, and whether the script throws unhandled exceptions under simulated stress testing. The system compares the monitoring data with the rule set item by item and performs a comprehensive score. If all checks pass and the score indicates no anomalies, the system determines that the update script is safe and reliable, and then triggers the formal deployment process. At this point, the system retrieves the previously generated script dependency graph and the list of affected scripts, and combines it with a preset canary release strategy, such as first selecting a small number of devices in non-critical exhibition areas, packaging the update script and its related dependency context information into a transactional update unit, synchronously deploying it to the target device group, and replacing the old script with an atomic operation.

[0081] Conversely, if the rule engine identifies one or more anomalies in the monitoring results, such as detecting memory leaks or unauthorized access attempts, the system immediately determines that the update poses a risk. The decision-making process then transitions to the security handling branch, terminating the entire update process and generating a structured alert. This alert details the type of abnormal behavior, the triggering rule, relevant monitoring data snapshots, and a list of affected dependency scripts, and is sent to the administrator through a predefined operations channel. Simultaneously, the system automatically cleans up the sandbox environment and all temporary caches to ensure that problematic scripts are completely isolated and do not impact the running production environment.

[0082] In some embodiments, it also includes: Receive sandbox operation monitoring results generated after the script runs in the secure sandbox environment; Retrieve the pre-stored historical fault database, which contains a mapping relationship between abnormal modes and handling strategies; Based on the sandbox operation monitoring results and the abnormal patterns in the historical fault database, the current abnormality is classified and its abnormality level and type are determined. When the anomaly level is determined to be a minor anomaly, the parameter adaptive adjustment logic is triggered, and the self-healing parameter adjustment instruction is calculated and generated based on the sandbox operation monitoring results. When the anomaly level is determined to be moderate, the set of affected dependent scripts directly associated with the current abnormal script is identified based on the pre-generated script dependency graph. Based on the identified set of affected dependency scripts, a partial rollback operation is performed, rolling back only the set of affected dependency scripts to the previous stable version; When the anomaly level is determined to be a severe anomaly, the overall update process is terminated and an alarm message is generated. After completing parameter adaptive adjustment, partial rollback operation, or generating alarm information, the type, level, handling measures, and final result of this anomaly will be updated to the historical fault database as a new historical fault record.

[0083] This embodiment significantly improves the robustness of script updates and resource utilization efficiency by constructing a hierarchical anomaly handling system. Its core advantage lies in the anomaly classification mechanism based on sandbox operation monitoring results and a historical fault database, achieving refined anomaly handling: minor anomalies automatically trigger adaptive parameter adjustments to avoid update interruptions; moderate anomalies only roll back affected dependent scripts while preserving other normal update results; and only severe anomalies terminate the process and trigger an alarm, effectively avoiding system downtime and resource waste caused by traditional single rollback strategies. Simultaneously, the application of dependency graphs ensures that self-healing operations do not disrupt the integrity of the script chain, maintaining overall system stability. After each anomaly handling, the type, level, measures, and results are updated to the historical fault database, forming a data-driven closed-loop optimization mechanism. This allows the system to continuously learn and dynamically adjust handling strategies, improving the accuracy and response speed of future anomaly detection.

[0084] Specifically, after completing the simulated call test of the update script and its dependent scripts in the secure sandbox environment, the sandbox monitor summarizes and performs preliminary processing on all raw monitoring data collected throughout the entire runtime cycle. This data includes CPU utilization recorded in time series, detailed snapshots of memory allocation and deallocation, time-series and target address logs of network requests, file system read / write operation records, and the type and parameters of all system calls. Based on a preset format template, the monitor integrates this multi-source, heterogeneous time-series data into a structured sandbox runtime monitoring results report. This report not only includes raw metrics but also includes preliminary analysis annotations based on predefined rules, such as marking memory leak trends and highlighting abnormally high-frequency system calls. Subsequently, the sandbox environment's management interface sends this complete monitoring results report as a data packet through an internal inter-process communication mechanism to the external update decision-making and anomaly handling engine, thus completing the reception and transmission of monitoring results and providing a complete data foundation for subsequent anomaly classification and handling decisions.

[0085] Once the update decision engine receives the structured sandbox operation monitoring results report, it immediately triggers a query process to the historical fault database. The decision engine first parses the report, extracting key anomaly characteristics from the current operation, such as memory leaks and specific API call timeouts, and combining this with the type tags of the script to be updated, such as core protocol switching scripts. Subsequently, the system initiates a connection request to a dedicated historical fault database, indexed by time series and script type, storing all anomalies and their handling records from previous script updates, runs, and sandbox tests. The query request uses the script type and anomaly characteristic keywords as input conditions. The database engine searches based on these conditions and returns a set of matching historical fault records. Each record contains a detailed description of the pattern of similar anomalies that occurred in the past (such as the slope of the memory curve growth, error codes), the handling strategy taken at that time (such as adjusting memory allocation parameters, rolling back the version number), and the final effect evaluation. The system sorts the returned historical records by relevance, selecting the records with the highest matching degree and their mapped handling strategies as a reference for subsequent anomaly classification and handling decisions. This process understands the current monitoring phenomenon within the context of historical experience.

[0086] Next, based on the system call anomaly count, memory leak rate, and CPU utilization fluctuation values ​​from the sandbox operation monitoring results, current anomaly characteristic data is extracted. Simultaneously, the mapping relationship between anomaly patterns and handling strategies stored in the historical fault database is retrieved. This mapping relationship includes threshold definitions for minor anomalies (system call anomalies ≤ 10 times / minute and memory leak rate ≤ 0.5MB / second), moderate anomalies (system call anomalies > 10 times / minute or memory leak rate > 0.5MB / second), and severe anomalies (system call anomalies > 20 times / minute or memory leak rate > 1MB / second or data interaction error rate > 5%). The system then assigns the current anomaly characteristics... The data is compared item by item with historical patterns. When the number of abnormal system calls is ≤10 times / minute and the memory leak rate is ≤0.5MB / second, the anomaly level is determined to be minor. When the number of abnormal system calls is >10 times / minute but ≤20 times / minute and the memory leak rate is >0.5MB / second but ≤1MB / second, the anomaly level is determined to be moderate. When the number of abnormal system calls is >20 times / minute, the memory leak rate is >1MB / second, or the data interaction error rate is >5%, the anomaly level is determined to be severe. Finally, a structured result containing the anomaly level and type is generated, which serves as the direct basis for triggering adaptive adjustments, partial rollbacks, or process termination in the future.

[0087] When the system determines that the current sandbox operation is at a minor anomaly level, it performs in-depth analysis of the sandbox operation monitoring results to extract specific dynamic parameters related to the anomaly, such as the period and amplitude of memory fluctuations and the peak CPU usage of specific function modules. Then, based on this data and combined with the resource usage history model of this type of script, the adjustment logic calculates a set of optimized operating parameters. For example, it calculates and decides to increase the soft memory limit of the script's container by 5%, reduce the number of active threads in its internal non-critical task thread pool by one to reduce CPU contention, or fine-tune its internal garbage collection trigger threshold. Subsequently, the system encapsulates these calculation results into a set of specific, executable configuration instructions, such as a set of JSON instructions for dynamically updating container configurations or a specific control API call sequence sent to the script runtime. These generated instructions constitute the self-healing parameter adjustment instructions, designed to smoothly correct resource usage deviations without interrupting service, allowing the script's running state to return to a stable range.

[0088] After determining the anomaly level to be moderate, the system automatically retrieves a pre-generated script dependency graph from the system data center. This graph uses nodes to represent scripts and edges to represent dependency types and strengths. Based on the graph nodes corresponding to the currently anomalous script, the system executes a depth-first traversal algorithm to identify all directly connected dependent script nodes, generating a set of affected dependent scripts. This set contains unique script identifiers, dependency triggering conditions, and interaction frequency data. Then, based on the unique script identifiers in the set, the system retrieves the previous stable version of each script from the version control system. Subsequently, the system only performs version rollback operations on the scripts in the affected dependent script set, switching their runtime environment to the previous stable version, while maintaining the continued validity of the running status of other unaffected scripts, ensuring the overall functional integrity of the system and the continuity of the update process.

[0089] Upon determining that the anomaly level is severe, the current overall update process is immediately terminated, and all script deployments, switching, and dependent application operations are stopped. An alarm message is generated, containing the anomaly type (e.g., data interaction error rate > 5%), level (severe), handling measures (process termination), and final result (update failure). This message includes the timestamp of the anomaly occurrence, the specific error code, and the system's suggested handling steps. The alarm message is pushed to the system monitoring center in real time through the internal alarm channel and an event log is generated. The system then records the anomaly type, level, handling measures, and final result (e.g., update failure status) as a new record, appending a timestamp, anomaly characteristic values ​​(system call anomaly count > 20 times / minute, memory leak rate > 1MB / second), and handling feedback details, and updates it to the historical fault database to ensure that the historical fault database continuously accumulates the latest anomaly patterns to optimize subsequent anomaly classification models.

[0090] Please see Figure 5This embodiment provides a robot showroom linkage control device 200, including: The parsing unit 201 is used to receive and parse the task instructions sent by the robot, and obtain the requirements of the task instructions for real-time performance, bandwidth and power consumption based on the parsed task instructions. The calculation unit 202 is used to measure the adaptation vector of each protocol based on the requirements, calculate the comprehensive adaptation of each candidate protocol by the adaptation vector of each protocol and the preset weight vector, and select the protocol with the highest comprehensive adaptation as the transmission protocol. Sending unit 203 is used to send control commands corresponding to the task commands to the equipment in the exhibition hall using the transmission protocol; The cache unit 204 is used to cache the control command as a network disconnection event to the local database when a network connection interruption with the cloud server is detected. The merging unit 205 is used to resolve and merge the cached network outage events when the network connection is detected to be restored. The verification unit 206 is used to verify and determine the compatibility of the encrypted update script when it is received. The loading unit 207 is used to load the update script to replace the currently running script after the verification and compatibility determination are passed.

[0091] Furthermore, the cache unit 204 includes: A generation subunit is used to generate a unique identifier, timestamp, event type, event payload data, event processing status, and semantic version number for each control instruction; The data caching subunit is used to cache the unique identifier, timestamp, event type, event payload data, event processing status, and semantic version number to the local database.

[0092] Furthermore, the merging unit 205 includes: The network outage event acquisition subunit is used to acquire network outage events with a status of pending synchronization from the local database; The cloud event acquisition subunit is used to acquire cloud events within the corresponding time window from the cloud server. The window definition sub-unit is used to define conflicting windows; The difference calculation subunit is used to calculate the difference between the timestamp of the network outage event and the timestamp of the cloud event to obtain the timestamp difference. The version number determination subunit is used to determine whether the version number of the network outage event is greater than the version number of the cloud event when the timestamp difference is less than or equal to the conflict window. The network outage event retention subunit is used to retain the network outage event and discard the cloud event if the version number of the network outage event is greater than the version number of the cloud event. The cloud event retention subunit is used to retain the cloud event and discard the network outage event if the version number of the network outage event is less than or equal to the version number of the cloud event. The upload subunit is used to sort the finally retained cloud events and network outage events in ascending order of timestamps and upload them sequentially to the cloud server.

[0093] Furthermore, the upload subunit includes: The rollback subunit is used to send a soft reset command to the device if an irreversible deviation in the device state is detected, so that the device rolls back to the most recent state snapshot.

[0094] Furthermore, the verification unit 206 includes: The available resource acquisition subunit is used to acquire the available resources of the system and the application programming interface corresponding to the update script; The change judgment subunit is used to determine whether the application programming interface has changed and whether the resource requirements of the update script exceed the available resources of the system. The determination subunit is used to determine if the application programming interface has not changed and the resource requirements of the update script do not exceed the available resources of the system, and if so, the update script passes the verification and compatibility determination. The failure determination subunit is used to determine that the update script fails the verification and compatibility determination if the application programming interface changes or the resource requirements of the update script exceed the available resources of the system.

[0095] Furthermore, the loading unit 207 includes: The push subunit is used to gradually push and load the update script to the devices in the exhibition hall according to the canary release strategy.

[0096] Furthermore, the transmitting unit 203 includes: The completion rate acquisition subunit is used to acquire the actual completion rate and the expected completion rate of the task after the control command is completed; The ratio calculation subunit is used to calculate the success rate based on the ratio of the actual completion rate of the task to the expected completion rate of the task. The updated subunit updates the weight vector according to the success rate using the following formula: in, This represents the updated weight vector; This represents the weight vector before the update; This represents the weight adjustment coefficient, with a value range of (0, 1). Indicates the degree of success.

[0097] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the above-described apparatus and unit can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0098] The present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed, can implement the methods provided in the above embodiments. The storage medium may include various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0099] The present invention also provides a computer device, which may include a memory and a processor. The memory stores a computer program, and when the processor calls the computer program in the memory, it can implement the methods provided in the above embodiments. Of course, the computer device may also include various network interfaces, power supplies, and other components.

[0100] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section. It should be noted that those skilled in the art can make various improvements and modifications to this invention without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this invention.

[0101] It should also be noted that, in this specification, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusivity.

[0102] The term "comprises" implies that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprises a..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

Claims

1. A robot exhibition hall linkage control method, characterized in that, include: Receive and parse the task instructions sent by the robot, and obtain the requirements of the task instructions for real-time performance, bandwidth and power consumption based on the parsed task instructions; Based on the requirements, the adaptation vectors of each protocol are measured. The overall adaptation of each candidate protocol is calculated by combining the adaptation vectors of each protocol with a preset weight vector. The protocol with the highest overall adaptation is selected as the transmission protocol. Use the transmission protocol to send control commands corresponding to the task commands to the devices in the exhibition hall; When a network connection interruption with the cloud server is detected, the control command is cached as a network outage event in the local database; When network connectivity is detected to be restored, the cached network outage events will be conflict-resolved and merged. When an encrypted update script is received, the update script is verified and its compatibility is determined. After verification and compatibility assessment are passed, the update script is loaded to replace the currently running script.

2. The robot showroom linkage control method according to claim 1, characterized in that, The step of caching the control command as a network disconnection event in the local database includes: For each control instruction, generate a unique identifier, timestamp, event type, event payload data, event processing status, and semantic version number; The unique identifier, timestamp, event type, event payload data, event processing status, and semantic version number are cached in the local database.

3. The robot showroom linkage control method according to claim 1, characterized in that, The process of resolving and merging the cached network outage events includes: Obtain network outage events with a status of pending synchronization from the local database; Retrieve cloud events within the corresponding time window from the cloud server; Define conflict windows; Calculate the difference between the timestamp of the network outage event and the timestamp of the cloud event to obtain the timestamp difference; When the timestamp difference is less than or equal to the conflict window, it is determined whether the version number of the network outage event is greater than the version number of the cloud event. If the version number of the network outage event is greater than the version number of the cloud event, then the network outage event is retained and the cloud event is discarded; If the version number of the network outage event is less than or equal to the version number of the cloud event, then the cloud event is retained and the network outage event is discarded. The cloud events and network outage events that are ultimately retained are sorted in ascending order by timestamp and uploaded to the cloud server in sequence.

4. The robot showroom linkage control method according to claim 3, characterized in that, The step of sorting the cloud events and network outage events that are ultimately retained in ascending order of timestamps includes: If an irreversible deviation in the device state is detected, a soft reset command is issued to the device to roll back to the most recent state snapshot.

5. The robot exhibition hall linkage control method according to claim 1, characterized in that, The verification and compatibility determination of the update script includes: Obtain the available resources of the system and the application programming interface corresponding to the update script; Determine whether the application programming interface has changed, and whether the resource requirements of the update script exceed the available resources of the system; If the application programming interface has not changed and the resource requirements of the update script do not exceed the available resources of the system, then the update script is determined to have passed the verification and compatibility determination. If the application programming interface changes, or the resource requirements of the update script exceed the available resources of the system, the update script is determined to have failed the verification and compatibility assessment.

6. The robot showroom linkage control method according to claim 1, characterized in that, The loading of the update script includes: Following the canary release strategy, the update script is gradually pushed to and loaded onto the devices in the exhibition hall.

7. The robot exhibition hall linkage control method according to claim 1, characterized in that, After sending the control command corresponding to the task command to the equipment in the exhibition hall using the transmission protocol, the process includes: Obtain the actual completion rate and expected completion rate of the task after the control command is executed; The success rate is calculated based on the ratio of the actual completion rate of the task to the expected completion rate of the task. The weight vector is updated according to the success rate using the following formula: in, This represents the updated weight vector; This represents the weight vector before the update; This represents the weight adjustment coefficient, with a value range of (0, 1). Indicates the degree of success.

8. A robot exhibition hall linkage control device, characterized in that, include: The parsing unit is used to receive and parse the task instructions sent by the robot, and obtain the requirements of the task instructions for real-time performance, bandwidth and power consumption based on the parsed task instructions. The calculation unit is used to measure the adaptation vector of each protocol based on the requirements, calculate the comprehensive adaptation of each candidate protocol by the adaptation vector of each protocol and the preset weight vector, and select the protocol with the highest comprehensive adaptation as the transmission protocol. The sending unit is used to send control commands corresponding to the task commands to the devices in the exhibition hall using the transmission protocol; A caching unit is used to cache the control command as a network disconnection event in a local database when a network connection interruption with the cloud server is detected. The merging unit is used to resolve and merge the cached network outage events when the network connection is detected to be restored. The verification unit is used to verify and determine the compatibility of the received encrypted update script. The loading unit is used to load the update script to replace the currently running script after the verification and compatibility determination are passed.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the robot showroom linkage control method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, causes the processor to perform the robot showroom linkage control method as described in any one of claims 1 to 7.

Images