Cluster management system based on single intelligent vehicle body

Abstract

The embodiment of the invention provides a cluster management system based on single intelligent vehicle bodies. The system comprises a cluster coordination service module which is used for electing a main node and a standby main node among a plurality of intelligent terminal devices in a cluster according to an election algorithm; the node role distribution module is connected with the cluster coordination service module and is used for respectively distributing the main node, the standby main node and the preset number of execution nodes to the plurality of intelligent terminal devices according to the election result; the state monitoring module is connected with the cluster coordination service module and is used for monitoring the running state information of the main node in real time and triggering the standby main node to be upgraded to the main node when the main node is detected to be abnormal; and the role switching module is connected with the state monitoring module and the node role distribution module, and is used for electing a new standby main node from the plurality of intelligent terminal devices according to the abnormal state of the main node, and updating the distribution state of the execution node. Through the system, stable operation of the cluster system is realized.

Description

Technical Field

[0001] This application relates to the field of information technology, and in particular to a cluster management system based on a single intelligent vehicle body. Background Technology

[0002] With the rapid development of the robotics industry, Automated Guided Vehicles (AGVs), forklift AGVs, and intelligent devices with autonomous mobility have been widely used in industrial production, warehousing and logistics, and last-mile delivery in cities. These intelligent terminals typically possess a certain degree of autonomous decision-making capability, such as autonomous path planning, dynamic obstacle avoidance, and task execution control. However, in multi-device collaborative operation scenarios, unified organization and coordination are still needed in areas such as task allocation, path conflict resolution, resource sharing, and state consistency maintenance to form a system with overall operational capabilities.

[0003] In existing technologies, a common solution is to deploy a separate central server (such as an industrial server) to uniformly schedule and manage all smart terminal devices. The central server is responsible for core functions such as task allocation, path planning, resource allocation, and conflict resolution.

[0004] However, existing solutions suffer from high costs, strong dependence, and the risk of system paralysis due to central node failure. Summary of the Invention

[0005] This application provides a cluster management system based on a single intelligent vehicle body to solve the problems of high cost, strong dependence, and system paralysis caused by failure of the central node in the prior art.

[0006] In a first aspect, embodiments of this application provide a cluster management system based on a single intelligent vehicle body, including:

[0007] The cluster coordination service module is used to elect a master node and a backup master node among multiple smart terminal devices in the cluster according to an election algorithm.

[0008] The node role allocation module is connected to the cluster coordination service module and is used to allocate the master node, the backup master node and a preset number of execution nodes to the multiple smart terminal devices according to the election results.

[0009] The status monitoring module is connected to the cluster coordination service module and is used to monitor the running status information of the master node in real time, and trigger the backup master node to be promoted to the master node when the master node is detected to be abnormal.

[0010] The role switching module, connected to the status monitoring module and the node role allocation module, is used to elect a new backup master node from among the multiple smart terminal devices based on the abnormal state of the master node, and update the allocation status of the execution node.

[0011] In one possible implementation, the election algorithm is to perform a weighted score on the multiple smart terminal devices based on their relative location, performance, availability, and workload, and then determine the master node and the backup master node based on the weighted score.

[0012] In one possible implementation, when the master node and the standby master node in the cluster cannot be identified by the execution node at the same time, the cluster coordination service module is further configured to control the execution node to perform a full recovery and verification of job status data based on the redundant job data distributed in each execution node after confirming that both the master node and the standby master node have failed, and to trigger the election of a new master node and a new standby master node when the job status recovery is successful.

[0013] In one possible implementation, the role switching module is further configured to control the node role allocation module to update the original master node to an execution node after the master node switching and backup master node re-election are completed.

[0014] In one possible implementation, the cluster coordination service module further includes a data synchronization module;

[0015] The data synchronization module is used to synchronize the minimum amount of data required to maintain cluster collaboration in the master node to the backup master node.

[0016] In one possible implementation, the role switching module is further configured to, when a new smart terminal device joins the cluster, assign it as an execution node according to the current node role status in the cluster, and trigger the cluster coordination service module to update the cluster member information.

[0017] In one possible implementation, the cluster management system based on a single intelligent vehicle body further includes a task management module, which is communicatively connected to the master node.

[0018] The task management module is used to receive cluster task instructions and distribute tasks to execution nodes.

[0019] In one possible implementation, the task management module is further configured to coordinate resource usage among multiple smart terminal devices through shared resource status, wherein the shared resource status includes at least one of path, charging pile, and storage location. In another possible implementation, the smart terminal device is a mobile robot or automated guided vehicle (AGV) with autonomous navigation and task execution capabilities.

[0020] In one possible implementation, a cluster management system based on a single intelligent vehicle body is deployed on each intelligent terminal device to enable the creation, maintenance, and management of the cluster without relying on an independent central server.

[0021] This application provides a cluster management system based on a single intelligent vehicle body. Through the collaborative operation of a cluster coordination service module, a node role allocation module, a status monitoring module, and a role switching module, a highly reliable distributed control system is constructed. First, the cluster coordination service module uses an election algorithm to comprehensively evaluate the operational status information of multiple intelligent terminal devices participating in the cluster, thereby electing a unique master node and a unique backup master node to ensure that the cluster has a clear coordination core at any given time. After the election, the node role allocation module maps and assigns the master node, backup master node, and a preset number of execution nodes to the corresponding intelligent terminal devices according to the election results. This allows each node to assume differentiated but collaborative functional roles within the cluster, thus constructing a stable cluster collaboration structure. Simultaneously, the status monitoring module continuously collects and analyzes the operational status information of the master node, including communication status, computing status, or task processing status, to achieve real-time monitoring of the master node's health status. When an abnormality or failure of the master node is detected, the module will respond accordingly. When the fault occurs, the takeover procedure of the standby master node is immediately activated, achieving a seamless and smooth switch of "management rights" and effectively avoiding system paralysis caused by a single point of failure. On this basis, the role switching module controls the standby master node to automatically upgrade to the new master node based on the abnormal indication signal output by the status monitoring module, and re-initiates an election among the remaining smart terminal devices to determine the new standby master node. At the same time, the role allocation status of the execution nodes is updated, so that the cluster can complete role reconstruction without manual intervention, maintaining the continuity and consistency of task scheduling and resource coordination capabilities. Through the coordinated cooperation between the above modules, dynamic election, automatic switching and adaptive management of cluster node roles are realized, significantly improving the stability, reliability and overall operating efficiency of the cluster system in the event of a master node failure. Attached Figure Description

[0022] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0023] Figure 1 A system architecture diagram of a cluster management system based on a single intelligent vehicle body provided in this application embodiment;

[0024] Figure 2 A schematic diagram of the node states provided in the embodiments of this application. Figure 1 ;

[0025] Figure 3 A schematic diagram of the node states provided in the embodiments of this application. Figure 2 .

[0026] The accompanying drawings have illustrated specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to specific embodiments. Detailed Implementation

[0027] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0028] With the rapid development of the robotics industry, Automated Guided Vehicles (AGVs), forklift AGVs, and intelligent devices with autonomous mobility are widely deployed and applied in industrial manufacturing, warehousing and logistics, park delivery, and urban last-mile delivery. These intelligent terminals typically integrate sensors, controllers, and computing units, possessing a certain degree of autonomous decision-making capabilities. They can perform operations such as autonomous path planning, dynamic obstacle avoidance, motion control, and task execution based on environmental information.

[0029] As applications expand, multiple intelligent terminal devices often coexist on-site, operating in parallel within the same environment. This involves complex issues such as channel sharing, competition for operational resources, and task execution order. Therefore, the autonomous capabilities of a single device are insufficient to meet the requirements of overall operational efficiency and safety. In multi-device collaborative operation scenarios, a unified organization and coordination mechanism is still needed to manage task allocation, path conflict resolution, resource sharing, and device status consistency, thereby forming a collaborative system with overall operational capabilities and controllability.

[0030] In existing technologies, a centralized scheduling and management solution is typically adopted to address the need for collaborative operation of multiple intelligent terminals. This involves deploying a separate central server (such as an industrial server or control host) to uniformly schedule and manage all intelligent terminal devices within the work area. This central server usually maintains communication connections with each terminal device and centrally undertakes core functions such as task allocation, path planning, traffic control, resource allocation, and conflict detection and resolution.

[0031] In this technical solution, intelligent terminal devices primarily function as execution units, and their operational behavior largely depends on control commands issued by the central server. The central server needs to continuously acquire status information from each terminal device and make unified decisions based on a global perspective to coordinate the operational behavior of multiple devices in the same working environment, thereby avoiding path conflicts and resource contention issues.

[0032] However, the aforementioned centralized scheduling and management scheme has significant technical drawbacks in practical applications. First, the central server typically requires high-performance industrial-grade hardware, leading to high costs in hardware procurement, deployment, and subsequent maintenance, hindering large-scale promotion and flexible deployment. Second, the centralized scheduling scheme is highly dependent on the central node; the coordination of all intelligent terminal devices relies on the central server. If the central server fails, restarts abnormally, or requires maintenance or upgrades, the entire scheduling system will malfunction, forcing all terminal devices to interrupt their operations, posing a significant single point of failure risk. Furthermore, as the number of terminal devices increases, the computational and communication load on the central server continues to rise, limiting system scalability and real-time performance, making it difficult to meet the stability and reliability requirements of high-concurrency, multi-device collaborative operation scenarios.

[0033] To address the shortcomings of existing technologies that rely on centralized scheduling or fixed central nodes for unified management, which are prone to single points of failure, insufficient system reliability, and high maintenance costs, the inventors proposed a cluster management system based on a single intelligent vehicle body, based on the principles of distributed collaborative control and dynamic role evolution. This system operates a cluster coordination service on each intelligent terminal device, dynamically determines the master node and backup master node within the cluster using an election mechanism, and assigns the remaining nodes as execution nodes, thus logically forming a cluster structure with a clear coordination core that does not rely on a fixed center. In practical implementation, the system continuously monitors the operating status of the master node. When an anomaly is detected, the backup master node is automatically promoted to the new master node, and a new backup master node is re-elected from the remaining nodes. Simultaneously, the role assignments of the execution nodes are updated to ensure the integrity and consistency of the cluster's collaborative relationships. Through this technical solution, the autonomous election and smooth switching of cluster node roles are achieved. While avoiding the impact of single points of failure on the overall system operation, this significantly improves the stability, continuity, and adaptability of the cluster system, effectively meeting the high reliability and high availability requirements of multi-intelligent terminal collaborative operation scenarios.

[0034] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0035] Figure 1 A system architecture diagram of a cluster management system based on a single intelligent vehicle body provided in this application embodiment; as shown below. Figure 1 As shown, the system includes: a cluster coordination service module 10, a node role allocation module 20, a status monitoring module 30, a role switching module 40, and a task management module 50. Each module runs in the local computing unit of the smart terminal device and works collaboratively through communication, thereby enabling the creation, maintenance, and management of clusters of multiple smart terminal devices without relying on an independent central server. By distributing cluster management capabilities across each smart terminal device, any device can assume both an execution role and, when needed, a cluster coordination role. This eliminates the single point of failure risk associated with centralized control at the system architecture level, improving the overall system reliability and scalability.

[0036] Specifically, during cluster initialization or when reorganization is required, the cluster coordination service module 10 elects a master node and a backup master node among multiple smart terminal devices in the cluster according to an election algorithm. Specifically, after joining the cluster, each smart terminal device reports its own operational capability parameters to the cluster coordination service module 10. A unified election rule is used to comprehensively evaluate each device, thereby determining the most suitable master node and backup master node to undertake the cluster coordination task. In this way, the master node and backup master node are not bound to fixed devices but are dynamically determined based on real-time status, thus avoiding the impact on the overall cluster operation due to insufficient performance or failure of a fixed central node, and improving the flexibility and stability of the cluster organization.

[0037] In one possible implementation, the election algorithm employs a weighted scoring method based on relative device location, device performance, device availability, and device workload. Specifically, in the cluster management system based on individual intelligent vehicle bodies, the cluster coordination service module 10 dynamically integrates the real-time remaining battery power of each intelligent unit with its specific location coordinates on the factory operation map. Device performance is only a secondary reference and no static priority is preset. Specifically, nodes with sufficient battery power (e.g., above 80%) are prioritized to ensure that the elected leader has stable endurance to perform continuous management and coordination tasks. Simultaneously, the real-time location coordinates of nodes are given priority; nodes located in the central area of ​​the factory or near high-incidence areas of current tasks are given higher weight due to their better communication latency and faster task response speed, while nodes at the edge, in charging areas, or on congested paths are downweighted. Device performance parameters (such as load and speed) are used as auxiliary evaluation criteria when the above core factors are similar. This weighting strategy fundamentally abandons fixed priority configuration and achieves optimal election based on real-time operation status and physical environment, ensuring that the cluster leadership is always held by the intelligent vehicle most suitable for coordination under the current time and space conditions, thereby significantly improving the overall operation efficiency and system adaptability of the cluster.

[0038] After node election is completed, the node role allocation module 20 connects to the cluster coordination service module 10 and, based on the election results, assigns the master node, standby master node, and a preset number of execution nodes to multiple smart terminal devices. The node role allocation module 20 maintains a node role mapping table, enabling each smart terminal device to clearly define its role within the cluster, thus completing the initial construction of the cluster's logical structure. This clear division of roles allows the master node to focus on coordination and management, execution nodes to focus on task execution, and standby master nodes to focus on state synchronization and fault tolerance preparation. This achieves a cluster operation mode with clearly defined responsibilities and high collaborative efficiency, eliminates dependence on a fixed central node, and enhances the system's self-organizing capability and initialization flexibility.

[0039] After the cluster enters a stable operating state, to ensure management continuity, the cluster coordination service module 10 also includes a data synchronization module 101. This module is responsible for continuously and in real-time synchronizing the minimum amount of data necessary for maintaining cluster collaboration from the master node to the standby master node, such as task status information, node role information, and shared resource status information. This unidirectional, event-driven, or periodic data push replaces the "heartbeat" detection mechanism between nodes commonly found in traditional distributed systems. By synchronizing only critical data, communication overhead is reduced, and it is ensured that the standby master node can immediately take over cluster management tasks when upgraded to the master node, thereby achieving rapid recovery and high availability assurance in terms of technology. The task management module 50 also begins to work, responsible for receiving cluster task instructions from external systems (such as warehouse management systems). At the same time, the task management module 50 is also used to coordinate resource usage among multiple smart terminal devices through shared resource status, which includes at least one of paths (such as paths in single smart terminal business scenario data), charging piles, and storage locations. By uniformly maintaining the state of shared resources, multiple execution nodes are prevented from competing for the same resource simultaneously. Even under a decentralized architecture, unified and orderly task scheduling and resource allocation are still achieved, ensuring operational efficiency.

[0040] To ensure high availability of the cluster, the status monitoring module 30 runs continuously. Connected to the cluster coordination service module 10, it monitors the master node's operational status in real time through heartbeat mechanisms and health checks. This information includes the device's online status, self-check health status, and communication latency with other nodes. If a master node anomaly is detected, such as lost heartbeat or response timeout, the module immediately triggers a failover process, promoting the standby master node to the new master node and taking over cluster management responsibilities. Simultaneously, the role switching module 40 is activated. Connected to the status monitoring module 30 and the node role allocation module 20, it elects a new standby master node from multiple smart terminal devices based on the master node's abnormal status and updates the allocation status of execution nodes. It first coordinates with the cluster coordination service module 10 to re-initiate an election among the remaining execution nodes to generate a new standby master node to fill the vacancy.

[0041] It should be noted that when both the primary and backup primary nodes in the cluster become unrecognizable by the execution nodes, the cluster coordination service module 10 controls all execution nodes to jointly confirm that both the primary and backup primary nodes have failed. After confirming the failure, the cluster coordination service module 10 coordinates each execution node to perform a full recovery and verification of the job status data based on the redundant job data distributed and stored on each execution node. Specifically, the redundant job data includes real-time recorded material status in the factory warehouse, such as the type of goods, shelf location, and inventory status (e.g., pending inbound or pending outbound). This data is distributed and stored on each execution node in a sharded manner, achieving data backup and redundancy similar to disk RAID. If the job status data recovery fails, the cluster coordination service module 10 suspends the election process to avoid meaningless cluster reorganization; if the recovery is successful, it triggers the election of a new primary and backup primary node. Thus, this distributed data redundancy ensures the persistence and recoverability of critical job data. In the extreme scenario of dual primary node failure, it prioritizes the integrity of business data, providing a reliable foundation for cluster recovery, improving data security and system resilience under severe failures, and avoiding job interruptions due to data loss.

[0042] It should also be noted that, to ensure the rigor and consistency of the cluster failover process and to avoid misjudgments and role conflicts caused by momentary network anomalies, this system introduces a majority confirmation principle in the role upgrade mechanism. Specifically, when the status monitoring module 30 detects a potential failure of the primary node, it does not immediately trigger the upgrade of the standby primary node. Instead, the cluster coordination service module 10 coordinates all execution nodes to jointly confirm the abnormal state of the primary node. Only after more than half of the execution nodes confirm that the primary node has indeed failed will the cluster coordination service module 10 allow the standby primary node to be officially upgraded to the new primary node. For example, in a 7-node cluster consisting of 1 primary node, 1 standby primary node, and 5 execution nodes, at least 3 execution nodes need to confirm the primary node's failure before the standby primary node can perform the failover. By verifying the fault state through distributed consensus, the local judgment of a single monitoring module is elevated to a joint decision by a majority of nodes in the cluster. This approach effectively distinguishes between temporary network jitter and permanent failures: if only a brief link problem occurs between the standby master node and the master node, but most execution nodes can still detect the master node, then a failover will not be triggered. The technical effect is to completely eliminate dual-master situations caused by misjudgments from single-point monitoring or local network partitions, ensuring the uniqueness of cluster leadership and the reliability of failover decisions, thereby guaranteeing cluster stability and data consistency in complex network environments.

[0043] Subsequently, the role switching module 40 instructs the node role allocation module 20 to update the role allocation status of the entire cluster. If the original master node subsequently recovers and re-requests to join the cluster, the nodes in the new cluster will explicitly reject its leadership request based on this identifier. After receiving the rejection, the original master node confirms that it has been replaced and thus degrades to an execution node through the role switching module 40, rejoining the cluster to participate in the job. The original standby master node is handled in a similar manner to avoid cluster oscillation caused by unstable node states. This achieves automatic fault detection and role state machine switching based on state awareness; and full automation from node failure occurrence, master-slave switchover to architecture recovery, greatly improving the system's robustness and continuous service capability.

[0044] In one possible implementation, the role switching module 40 is also used to assign a new smart terminal device as an execution node based on the current node role status in the cluster when the new smart terminal device joins the cluster, and to trigger the cluster coordination service module to update the cluster member information. Specifically, when a new smart terminal device needs to join the cluster, the role switching module 40 intervenes: it first evaluates the current role composition of the cluster, and under normal circumstances (i.e., there are already valid master nodes and backup master nodes), it initializes the new node as an execution node and triggers the cluster coordination service module 10 to update the cluster member list, so that it can quickly integrate into the cluster and start receiving tasks. All modules of the entire system are deployed locally on each smart terminal device, and all collaborative functions are completed through peer-to-peer communication between devices, completely eliminating the dependence on an independent central server, enabling the cluster to scale elastically, simplifying system operation and maintenance, and ultimately building a low-cost, highly reliable, adaptive, and easily scalable distributed smart device cluster management system.

[0045] In a specific application scenario, multiple devices form a cluster in a warehouse or manufacturing site. The cluster coordination service module 10 elects a master node and a backup master node. The master node uniformly issues handling tasks through the task management module 50 and coordinates paths and charging pile resources. When the master node shuts down due to insufficient power, the backup master node automatically becomes the master node, ensuring the cluster continues to operate stably. This demonstrates the significant effectiveness of the cluster management system in terms of reliability, continuity, and intelligent collaboration in practical applications.

[0046] It's important to note that in the system design, multiple independent clusters can run in parallel within a single operational domain. Key business data between clusters within the domain (such as global resource maps, inventory status, route reservations, and traffic control signals) are synchronized peer-to-peer through the master nodes of each cluster, acting as gateways. This forms a distributed yet logically unified control plane, allowing each cluster to schedule autonomously while ensuring consistency of the operational status across the entire domain. When cross-domain collaboration is involved, master nodes in different domains discover each other through periodic broadcast declarations, establishing inter-domain communication links. Subsequently, they synchronize cross-domain business data as needed through efficient service call interfaces (such as RPC or message queues), for example, sharing long-distance route planning conditions, coordinating cross-domain vehicle meeting and avoidance rules, or transmitting contextual information for cross-domain logistics orders. This multi-level data synchronization architecture ensures both the high performance and autonomy of individual clusters while achieving collaborative operation and global state unification across multiple clusters and domains, effectively supporting the scalable operation of large-scale, distributed intelligent vehicle systems.

[0047] It should also be noted that the cluster management system based on individual intelligent vehicle bodies in this application manages individual intelligent vehicle bodies (intelligent terminal devices), which are highly autonomous mobile execution units. Specifically, these intelligent terminal devices can be mobile robots or automated guided vehicles (AGVs) with autonomous navigation and task execution capabilities. These devices typically have built-in environmental perception, path planning, and decision control units, enabling them to independently complete positioning, movement, and basic operations in complex dynamic environments. This constitutes the physical and logical basis for their participation in and support of the decentralized cluster management. It is precisely based on this autonomy that multiple such devices can form an autonomous cluster through the software module set provided by this system, based on peer-to-peer communication, without relying on direct motion control from an external central scheduling system.

[0048] During system operation, the specific form and capabilities of intelligent terminal devices directly affect the implementation and interaction of their module functions. For example, during cluster initialization election, the performance of an automated guided vehicle (AGV) can be reflected in the response speed of its drive motor, navigation accuracy, or battery capacity; device availability is related to whether it is currently in a fault state, charging, or undergoing maintenance; and task load refers to the number of shelves it is currently carrying or the complexity of its assigned routes. These real-time status parameters derived from the autonomous capabilities of the devices become the core basis for the election algorithm's weighted scoring, ensuring that the elected master node and backup master node objectively possess the comprehensive qualities to lead the stable operation of the cluster.

[0049] Furthermore, the autonomous task execution capabilities of these intelligent terminal devices enable efficient division of labor within the task management module. For a mobile robot, a task instruction issued by the master node might be the coordinates of a target point and a grasping operation command; for an automated guided vehicle, it might be a warehouse location number. Upon receiving the instruction, the execution node can independently plan the optimal path to the target and safely avoid obstacles using its own autonomous navigation capabilities, without requiring micro-path planning from the master node. Simultaneously, their need for state awareness and coordination of shared resources (such as narrow passages, charging stations, and loading / unloading platforms) stems from the inevitable spatial and resource exclusion issues that arise during their autonomous movement. This makes the coordination function based on the state of shared resources within the task management module crucial for ensuring efficient and safe parallel operation of the cluster.

[0050] In summary, defining intelligent terminal devices as mobile robots or automated guided vehicles (AGVs) with autonomous navigation and task execution capabilities is not a generalized example, but rather a crucial prerequisite for the establishment of this system's technical solution and the realization of its beneficial effects. It defines the underlying entities managed by the system and permeates all core processes such as election, task allocation, resource coordination, and fault recovery, ensuring that the decentralized cluster management method can be implemented in real-world scenarios such as industrial logistics and warehousing, solving practical problems related to multi-device collaboration.

[0051] This application provides a cluster management system based on a single intelligent vehicle body. Through the collaborative operation of a cluster coordination service module, a node role allocation module, a status monitoring module, and a role switching module, a highly reliable distributed control system is constructed. First, the cluster coordination service module uses an election algorithm to comprehensively evaluate the operational status information of multiple intelligent terminal devices participating in the cluster, thereby electing a unique master node and a unique backup master node to ensure that the cluster has a clear coordination core at any given time. After the election, the node role allocation module maps and assigns the master node, backup master node, and a preset number of execution nodes to the corresponding intelligent terminal devices according to the election results. This allows each node to assume differentiated but collaborative functional roles within the cluster, thus constructing a stable cluster collaboration structure. Simultaneously, the status monitoring module continuously collects and analyzes the operational status information of the master node, including communication status, computing status, or task processing status, to achieve real-time monitoring of the master node's health status. When an abnormality or failure of the master node is detected, the module will respond accordingly. When the fault occurs, the takeover procedure of the standby master node is immediately activated, achieving a seamless and smooth switch of "management rights" and effectively avoiding system paralysis caused by a single point of failure. On this basis, the role switching module controls the standby master node to automatically upgrade to the new master node based on the abnormal indication signal output by the status monitoring module, and re-initiates an election among the remaining smart terminal devices to determine the new standby master node. At the same time, the role allocation status of the execution nodes is updated, so that the cluster can complete role reconstruction without manual intervention, maintaining the continuity and consistency of task scheduling and resource coordination capabilities. Through the coordinated cooperation between the above modules, dynamic election, automatic switching and adaptive management of cluster node roles are realized, significantly improving the stability, reliability and overall operating efficiency of the cluster system in the event of a master node failure.

[0052] It should be noted that when merging two existing clusters, the cluster merge process employs an orderly and lossless collaborative merge mechanism: First, the master node of the merged cluster, after ensuring that all nodes in its cluster have completed their currently executing tasks, proactively freezes all unstarted or ongoing task queues and synchronizes complete cluster business data (including task context, resource map status, inventory information, and node runtime metadata) to the master node of the target merged cluster. After synchronization, the original cluster's standby master node and execution nodes are marked as "migration status" and join the target cluster as new execution nodes, simultaneously receiving and storing the new cluster's distributed redundant data shards, achieving data-level fusion. Subsequently, the original master node releases its held cluster identifier and name resources and broadcasts a "cluster dissolution will" message to inform all other cluster master nodes in the domain to update the global topology and unlock related resources, ensuring that no residual invalid cluster information remains in the system. Finally, all nodes in the original cluster officially join the target cluster as independent nodes, participate in a new round of weight election, and integrate into the new job scheduling system. This achieves a seamless cluster merge without business interruption or data loss, realizing dynamic integration and elastic scaling of system resources.

[0053] It should also be noted that this application employs a controlled and collaborative decomposition mechanism during the cluster decomposition process: First, a group of execution nodes in the original cluster proactively initiates a decomposition request and submits a decomposition proposal to the original master node, containing a list of target nodes and the expected scope of tasks in the new cluster. Upon receiving the proposal, the original master node verifies whether the decomposition will affect the execution of current critical tasks and confirms that the remaining cluster size still meets the minimum availability constraint. After confirmation and agreement, these nodes enter the decomposition-pending state. Subsequently, the decomposition-pending node group immediately elects a new master node internally using a weighted election algorithm based on power consumption, location, and performance. The newly elected master node proactively establishes a connection with the original cluster master node, synchronizing all necessary job context data, including the queue of unfinished tasks, resource map status, inventory information, and path planning constraints, ensuring task continuity and avoiding resource conflicts. After data synchronization is complete, the new cluster immediately initiates a distributed data redundancy backup mechanism, storing critical status information in shards on each node, forming an autonomous recovery capability. Immediately afterwards, the new cluster announced its establishment through the domain broadcast channel. The master nodes of all other clusters in the domain received this topology update and updated the global resource view and the status of the storage area accordingly. This maintained the consistency of data in the entire work area and avoided task conflicts and redundant resource allocation in the context of multiple clusters running in parallel. Thus, a new cluster that has achieved smooth division at both the business and data levels was officially put into operation.

[0054] Figure 2 A schematic diagram of the node states provided in the embodiments of this application. Figure 1 ; Figure 3A schematic diagram of the node states provided in the embodiments of this application. Figure 2 ;in, Figure 3 To ensure the cluster system enters a stable operating state after the initial election, device 1 is elected as the master node, while devices 2 through 7 are other intelligent terminal devices within the same cluster. At this point, master node device 1 assumes the responsibility of unified coordination and management of the cluster. It maintains continuous communication with each execution node through the state flow (shown by the solid black line), collecting operational status information from each device and issuing cluster status update commands. Simultaneously, master node device 1 distributes job task commands generated or received by the task management module to the corresponding execution nodes through the task distribution flow (shown by the long black dashed line), controlling each intelligent terminal device to execute specific tasks according to predetermined strategies. Furthermore, master node device 1 also synchronizes the minimum amount of data required to maintain cluster collaborative operation to the backup master node, device 4, through the synchronization data flow (shown by the short black dashed line), enabling the backup master node to grasp the core operational information of the cluster in real time. The parallel existence of these multiple data flows allows the cluster to efficiently complete task scheduling in a stable state while providing a data foundation for potential master node switching, demonstrating the system's coordination and reliability during normal operation.

[0055] Figure 2 When the original master node device 1 leaves the cluster due to failure, offline status, or maintenance, the cluster management system detects the master node anomaly through the status monitoring module and triggers the role switching mechanism. At this time, device 4, originally the backup master node, automatically becomes the new master node and begins to assume the unified coordination and management responsibilities of the cluster. The upgraded master node device 4 re-establishes status communication relationships with devices 2, 3, 5, 6, and 7 through the status flow shown by the black solid line, and continues to distribute job tasks to each execution node through the task distribution flow shown by the black long dashed line, ensuring the continuity of cluster task scheduling. Simultaneously, device 4 performs critical data synchronization with the newly elected backup master node through the synchronization data flow shown by the black short dashed line to restore the master-slave structure. After the original master node device 1 comes back online, it no longer assumes the responsibilities of a master node, but is adjusted to an execution node or a backup master node according to the control of the role switching module, thus rejoining the cluster to participate in operations. Through the above process, the cluster can still maintain stable operation even when the master node is offline, avoiding the paralysis of the entire system due to the failure of a single node, which fully demonstrates the technical effect of this application in terms of fault tolerance, self-recovery capability and high availability.

[0056] pass Figure 3 and ​As can be seen from the different operating states shown, the cluster management system based on a single intelligent vehicle body of this application can form a clear master-slave structure and task collaboration relationship after the first election, and automatically complete role switching and data flow reconstruction in the case of master node abnormality, thereby maintaining the continuous and stable operation of the cluster without manual intervention. It is particularly suitable for complex application scenarios where multiple intelligent terminal devices work together.

[0057] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A cluster management system based on a single intelligent vehicle body, characterized in that, include: The cluster coordination service module is used to elect a master node and a standby master node among multiple smart terminal devices in the cluster according to an election algorithm. The node role allocation module is connected to the cluster coordination service module and is used to allocate the master node, the backup master node and a preset number of execution nodes to the multiple smart terminal devices according to the election results. The status monitoring module is connected to the cluster coordination service module and is used to monitor the running status information of the master node in real time, and trigger the backup master node to be promoted to the master node when the master node is detected to be abnormal. The role switching module, connected to the status monitoring module and the node role allocation module, is used to elect a new backup master node from among the multiple smart terminal devices based on the abnormal state of the master node, and update the allocation status of the execution node.

2. The system according to claim 1, characterized in that, The election algorithm assigns a weighted score to the multiple smart terminal devices based on their relative location, performance, availability, and workload, and determines the master node and the backup master node based on the weighted score.

3. The system according to claim 1, characterized in that, When the primary node and the standby primary node in the cluster cannot be identified by the execution node at the same time, the cluster coordination service module is also used to control the execution node to perform a full recovery and verification of the job status data based on the redundant job data distributed in each execution node after confirming that the primary node and the standby primary node have both failed, and to trigger the election of a new primary node and a new standby primary node when the job status is successfully recovered.

4. The system according to claim 1, characterized in that, The role switching module is also used to control the node role allocation module to update the original master node to the execution node after the master node switching and backup master node re-election are completed.

5. The system according to claim 1, characterized in that, The cluster coordination service module also includes a data synchronization module; The data synchronization module is used to synchronize the minimum amount of data required to maintain cluster collaboration in the master node to the backup master node.

6. The system according to claim 1, characterized in that, The role switching module is also used to assign a new smart terminal device to the cluster as an execution node according to the current node role status in the cluster when the new smart terminal device joins the cluster, and to trigger the cluster coordination service module to update the cluster member information.

7. The system according to claim 1, characterized in that, The cluster management system based on a single intelligent vehicle body also includes a task management module, which is communicatively connected to the master node. The task management module is used to receive cluster task instructions and distribute tasks to execution nodes.

8. The system according to claim 7, characterized in that, The task management module is also used to coordinate resource usage among multiple smart terminal devices through shared resource status, which includes at least one of path, charging pile, and storage location.

9. The system according to claim 1, characterized in that, The intelligent terminal device is a mobile robot or automated guided vehicle with autonomous navigation and task execution capabilities.

10. The system according to claims 1-9, characterized in that, The cluster management system based on a single intelligent vehicle body is deployed on each of the aforementioned intelligent terminal devices, and is used to realize the creation, maintenance and management of the cluster without relying on an independent central server.

Images