Shared lock distribution system and method

By using a decentralized shared lock allocation system, the scheduling conflict problem between multiple AGVS systems was resolved, and the orderly scheduling of AGV vehicles was achieved, ensuring the continuity and efficiency of factory production.

CN121636136APending Publication Date: 2026-03-10BMW BRILLIANCE AUTOMOTIVE
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-09-04
Publication Date
2026-03-10

AI Technical Summary

Technical Problem

When multiple AGVS systems are deployed in a factory, there is a problem of AGV scheduling conflicts, which leads to a decrease in production efficiency and production interruption.

Method used

A decentralized shared lock allocation system is adopted. Through a decentralized network composed of master shared lock nodes and slave shared lock nodes, shared lock application requests are reviewed and allocated, ensuring that only the system holding shared lock resources can control the handling robots in the shared area.

Benefits of technology

This effectively avoids conflicts between resource scheduling systems, ensures the normal and orderly operation of factory production, and improves production efficiency.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121636136A_ABST
    Figure CN121636136A_ABST
Patent Text Reader

Abstract

The embodiment of the invention provides a shared lock distribution system and method, the shared lock distribution system comprises a plurality of shared lock nodes, and each shared lock node corresponds to a resource scheduling system; the plurality of shared lock nodes are composed of a master shared lock node and at least two slave shared lock nodes, and a target slave shared lock node in the at least two slave shared lock nodes receives a shared lock application request submitted by a target resource scheduling system corresponding to the target slave shared lock node for a scheduling control task; sending the request to a master shared lock node; the master shared lock node forwards the request to the slave shared lock node through a decentralized network, and receives feedback auditing information; determining shared lock distribution information according to the auditing information; and the target slave shared lock node sends the shared lock resource to a target resource scheduling system under the condition that the shared lock distribution information meets a distribution condition, so that the target resource scheduling system controls a transfer robot in a sharing area to execute a scheduling control task based on the shared lock resource.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The embodiments in this specification relate to the field of resource scheduling technology, and in particular to a shared lock allocation system and method. Background Technology

[0002] With the development of the internet and computer technology, the construction of digital factories has become a trend. By employing AGVS (Automated Guided Vehicle System) to schedule and control AGVs (Automated Guided Vehicles), tasks can be automatically executed, significantly improving production efficiency and saving labor costs. However, in large factory areas, the number of AGVs to be scheduled will be large. If a single AGVS system simultaneously schedules a large number of AGVs, its scheduling performance will be unable to meet business needs. Furthermore, if the AGVS system fails, it will affect the entire factory's production. Therefore, to avoid this problem, existing technologies deploy multiple AGVS systems in the factory, each responsible for the scheduling and control of AGVs within a specific area, ensuring that any system failure does not affect production schedules. However, when multiple AGVS systems operate within the same factory, AGVs controlled by different systems may need to work in shared areas, inevitably causing scheduling conflicts between AGVS systems. Therefore, an effective solution to address these issues is urgently needed. Summary of the Invention

[0003] In view of this, embodiments of this specification provide a shared lock allocation system. One or more embodiments of this specification also relate to a shared lock allocation method, a computing device, a computer-readable storage medium, and a computer program product, to address the technical deficiencies existing in the prior art.

[0004] According to a first aspect of the embodiments of this specification, a shared lock allocation system is provided, comprising multiple shared lock nodes, each shared lock node corresponding to a resource scheduling system, and the multiple shared lock nodes forming a decentralized network; wherein the multiple shared lock nodes consist of a master shared lock node and at least two slave shared lock nodes, including:

[0005] The target shared lock node among the at least two target shared lock nodes is used to receive a shared lock application request submitted by the target resource scheduling system corresponding to the target shared lock node for a scheduling control task; and to send the shared lock application request to the master shared lock node;

[0006] The master shared lock node is used to forward the shared lock application request to each slave shared lock node through the decentralized network, and receive the review information fed back by each slave shared lock node in response to the shared lock application request; determine the shared lock allocation information based on the review information, and send it to the target slave shared lock node;

[0007] The target from the shared lock node is used to send the shared lock resources to the target resource scheduling system when the shared lock allocation information meets the allocation conditions. The target resource scheduling system then controls the transport robots within the shared area to perform the scheduling control task based on the shared lock resources.

[0008] Optionally, each of the plurality of shared lock nodes is configured with a consensus module. The consensus module is used to select a master shared lock node from the plurality of shared lock nodes through a preset election algorithm, and to designate the remaining shared lock nodes other than the master shared lock node as slave shared lock nodes. The shared lock nodes communicate with each other through a peer-to-peer protocol.

[0009] Optionally, any one of the at least two associated shared lock nodes is configured to, upon receiving the shared lock application request forwarded by the master shared lock node, invoke the preset review rules of the shared lock module to review the shared lock application request, obtain review information, and feed back the review information to the master shared lock node.

[0010] Optionally, the master shared lock node is further configured to receive review information from each slave shared lock node in response to the shared lock application request, process the review information according to preset decision rules, determine the shared lock review allocation ratio based on the processing result, and send the shared lock review allocation ratio as shared lock allocation information to the target slave shared lock node.

[0011] Optionally, the target shared lock node is further configured to compare the shared lock review allocation ratio with a preset ratio threshold; if the shared lock review allocation ratio is greater than the preset ratio threshold, determine that the shared lock review allocation ratio meets the allocation conditions, and apply for shared lock resources in the corresponding shared area; and send the shared lock resources to the target resource scheduling system.

[0012] Optionally, the target shared lock node is further configured to determine that the shared lock review and allocation ratio does not meet the allocation conditions if the shared lock review and allocation ratio is less than or equal to the preset ratio threshold; create application planning information for the shared lock application request, and send the application planning information to the target resource scheduling system; wherein, the application planning information is used by the target resource scheduling system to adjust the submission time of the shared lock application request.

[0013] Optionally, any one of the multiple shared lock nodes and the associated resource scheduling system corresponding to the associated shared lock node are deployed on the same physical machine server, and the associated resource scheduling system corresponding to any one of the shared lock nodes corresponds to different system providers.

[0014] According to a second aspect of the embodiments of this specification, a shared lock allocation method is provided, applied to a target slave shared lock node, comprising:

[0015] Receive the shared lock request submitted by the target resource scheduling system corresponding to the target from the shared lock node for the scheduling control task;

[0016] The shared lock request is sent to the main shared lock node, and the shared lock allocation information is received from the main shared lock node in response to the shared lock request.

[0017] When the shared lock allocation information meets the allocation conditions, the shared lock resource is sent to the target resource scheduling system, so that the target resource scheduling system can control the transport robot in the shared area to perform the scheduling control task based on the shared lock resource.

[0018] According to a third aspect of the embodiments of this specification, another shared lock allocation method is provided, applied to a primary shared lock node, comprising:

[0019] Receive at least two shared lock request requests submitted by the target shared lock node from the shared lock node;

[0020] The shared lock request is forwarded to each of the at least two slave shared lock nodes via a decentralized network;

[0021] Receive the review information fed back by each shared lock node in response to the shared lock application request, and determine the shared lock allocation information based on the review information;

[0022] The shared lock allocation information is sent to the target slave shared lock node, so that the target slave shared lock node can allocate shared lock resources corresponding to the shared area according to the shared lock allocation information.

[0023] According to a fourth aspect of the embodiments of this specification, a computing device is provided, comprising:

[0024] Memory and processor;

[0025] The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions, which, when executed by the processor, implement the steps of the shared lock allocation method described above.

[0026] According to a fifth aspect of the embodiments of this specification, a computer-readable storage medium is provided that stores computer-executable instructions that, when executed by a processor, implement the steps of the shared lock allocation method described above.

[0027] According to a sixth aspect of the embodiments of this specification, a computer program product is provided, including a computer program or instructions that, when executed by a processor, implement the steps of the shared lock allocation method described above.

[0028] The shared lock allocation system provided in this embodiment includes multiple shared lock nodes, each corresponding to a resource scheduling system, and the multiple shared lock nodes form a decentralized network. Each shared lock node consists of a master shared lock node and at least two slave shared lock nodes. To prevent conflicts between multiple resource scheduling systems from affecting the execution of scheduling control tasks when the resource scheduling system controls the transport robot within a shared area, after the target slave shared lock node receives a shared lock application request submitted by the target resource scheduling system corresponding to the target slave shared lock node for the scheduling control task, it sends the shared lock application request to the master shared lock node. The master shared lock node then forwards the shared lock application request to each slave shared lock node through the decentralized network, enabling any slave node in the network to review the application request from the target slave shared lock node. At this time, it can receive review information from each slave shared lock node regarding the shared lock application request; the review information determines the validity of the shared lock application. The system checks whether the request is approved. Based on the approved information, it determines the shared lock allocation information and sends it to the target shared lock node. If the target shared lock node determines that the shared lock allocation information meets the allocation conditions, it indicates that the resource scheduling system can control the transport robots within the shared area. To avoid scheduling conflicts, the shared lock resource can be sent to the target resource scheduling system, enabling the target resource scheduling system to control the transport robots within the shared area based on the shared lock resource. This achieves decentralized allocation of shared lock resources, and only the system holding the shared lock resource can control the transport robots within the shared area. This effectively avoids conflicts caused by simultaneous scheduling by the resource scheduling system, ensuring the normal and orderly progress of factory production. Attached Figure Description

[0029] Figure 1 This is a schematic diagram of a shared lock allocation system provided in one embodiment of this specification;

[0030] Figure 2 This is a schematic diagram of a shared lock allocation system provided in one embodiment of this specification;

[0031] Figure 3 This is a flowchart illustrating a shared lock allocation method provided in one embodiment of this specification;

[0032] Figure 4 This is a flowchart of another shared lock allocation method provided in one embodiment of this specification;

[0033] Figure 5 This is a structural block diagram of a computing device provided in one embodiment of this specification. Detailed Implementation

[0034] Many specific details are set forth in the following description to provide a full understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this specification. Therefore, this specification is not limited to the specific implementations disclosed below.

[0035] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of this specification. The singular forms “a,” “described,” and “the” as used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0036] It should be understood that although the terms first, second, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first may also be referred to as second without departing from the scope of one or more embodiments of this specification, and similarly, second may also be referred to as first. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

[0037] Furthermore, it should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in one or more embodiments of this specification are all information and data authorized by the user or fully authorized by all parties. Moreover, the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0038] First, the terms and concepts used in one or more embodiments of this specification will be explained.

[0039] AGVS (Automated Guided Vehicle System) is an automated logistics solution integrating multiple advanced technologies. This system uses battery-powered, driverless transport vehicles to automate the handling, loading, unloading, and transportation of goods, significantly improving the efficiency and flexibility of material handling.

[0040] AGV (Automated Guided Vehicle) is an intelligent transportation tool widely used in modern industry.

[0041] P2P network: short for Peer-to-Peer, is an internet system without a centralized server, where information is exchanged entirely by a group of users.

[0042] Raft election algorithm: It is a consensus algorithm used in distributed systems to select leaders, and is designed to solve the consistency problem in distributed environments.

[0043] This specification provides a shared lock allocation system, and also relates to a shared lock allocation method, a computing device, a computer-readable storage medium, and a computer program product, which are described in detail in the following embodiments.

[0044] In practical applications, the centralized shared lock service management and allocation of lock resources to different AGVS systems presents security risks. Since factories often have multiple AGVS systems from different vendors, these vendors cannot establish mutual trust. If one AGVS system performs an abnormal operation or makes an abnormal request to the centralized shared lock service, it could cause other vendors' AGVS systems to malfunction. Furthermore, deliberate tampering with the centralized shared lock service data, such as adjusting priorities, can also affect the normal operation of other AGVS systems. Therefore, an effective solution is urgently needed to address these issues.

[0045] See Figure 1 The schematic diagram shows the shared lock allocation system provided in this embodiment, which includes multiple shared lock nodes, each corresponding to a resource scheduling system, and the multiple shared lock nodes form a decentralized network. The multiple shared lock nodes consist of a master shared lock node and at least two slave shared lock nodes. To avoid conflicts between multiple resource scheduling systems and affect the execution of scheduling control tasks when the resource scheduling system controls the transport robot in the shared area, after the target slave shared lock node receives a shared lock application request submitted by the target resource scheduling system corresponding to the target slave shared lock node for the scheduling control task, it sends the shared lock application request to the master shared lock node. The master shared lock node then forwards the shared lock application request to each slave shared lock node through the decentralized network, so that any slave node in the network can review the application request of the target slave shared lock node. At this time, it can receive review information from each slave shared lock node regarding the shared lock application request; the review information determines the validity of the shared lock application. The system checks whether the request is approved. Based on the approved information, it determines the shared lock allocation information and sends it to the target shared lock node. If the target shared lock node determines that the shared lock allocation information meets the allocation conditions, it indicates that the resource scheduling system can control the transport robots within the shared area. To avoid scheduling conflicts, the shared lock resource can be sent to the target resource scheduling system, enabling the target resource scheduling system to control the transport robots within the shared area based on the shared lock resource. This achieves decentralized allocation of shared lock resources, and only the system holding the shared lock resource can control the transport robots within the shared area. This effectively avoids conflicts caused by simultaneous scheduling by the resource scheduling system, ensuring the normal and orderly progress of factory production.

[0046] See Figure 2 , Figure 2 A schematic diagram of a shared lock allocation system according to an embodiment of this specification is shown. The shared lock allocation system 200 includes multiple shared lock nodes, each shared lock node corresponding to a resource scheduling system, and the multiple shared lock nodes form a decentralized network; wherein the multiple shared lock nodes consist of a master shared lock node 210 and at least two slave shared lock nodes 220, including:

[0047] The target slave shared lock node 220 among the at least two slave shared lock nodes is used to receive a shared lock application request submitted by the target resource scheduling system corresponding to the target slave shared lock node for a scheduling control task; and to send the shared lock application request to the master shared lock node;

[0048] The master shared lock node 210 is used to forward the shared lock application request to each slave shared lock node through the decentralized network, and receive the review information fed back by each slave shared lock node in response to the shared lock application request; determine the shared lock allocation information based on the review information, and send it to the target slave shared lock node;

[0049] The target from the shared lock node 220 is used to send the shared lock resources to the target resource scheduling system when the shared lock allocation information meets the allocation conditions. The target resource scheduling system then controls the transport robots in the shared area to perform the scheduling control task based on the shared lock resources.

[0050] The shared lock allocation system provided in this embodiment is applied to a scenario where different AGVS systems within a factory schedule and control AGVs within a shared area. These different AGVS systems are developed and provided by different manufacturers. The shared area refers to the area covered by the control areas of each AGVS system when scheduling their respective AGVs. When AGVs within this area are controlled by different AGVS systems, there may be conflicts between multiple systems. Therefore, to ensure orderly scheduling and control, when an AGVS system controls AGVs within the shared area, it needs to request shared lock resources. This ensures that only the AGVS system holding the shared lock resources can schedule and control AGVs within the shared area, without being affected by other AGVS systems.

[0051] Specifically, a shared lock node refers to a node in the shared lock allocation system that corresponds to different resource scheduling systems. Each resource scheduling system corresponds to one shared lock node, and both the resource scheduling system and the shared lock node are deployed on the same physical server. Correspondingly, the resource scheduling system is the AGVS system, and the resource scheduling systems corresponding to different shared lock nodes are developed and provided by different vendors. Correspondingly, the master shared lock node refers to the shared lock node among multiple shared lock nodes that is responsible for information statistics and request forwarding; correspondingly, the slave shared lock node refers to the shared lock node among multiple shared lock nodes that is responsible for interacting with the resource scheduling system.

[0052] Furthermore, the scheduling and control task specifically refers to the task of the target resource scheduling system in scheduling and controlling the handling robots within the shared area, such as controlling the handling robot to move item 1 from shelf A to drop-off point B within the shared area. Correspondingly, the shared lock application request specifically refers to the shared lock resource application request submitted by the target resource scheduling system when applying to control the handling robots within the shared area. Correspondingly, the review information specifically refers to the results of the review of the shared lock application requests submitted by each slave shared lock node to the target resource scheduling system, used to determine whether to allocate shared lock resources to the target resource scheduling system. Correspondingly, the shared lock allocation information is the allocation information obtained by the master shared lock node after statistically processing the review information submitted by each slave shared lock node. Correspondingly, the allocation conditions specifically refer to the conditions for verifying whether to allocate shared lock resources to the target resource scheduling system. Correspondingly, the handling robot refers to an AGV (Automated Guided Vehicle) or other robots with control requirements, such as shelf robots, cargo robot, picking robot, etc.

[0053] Based on this, in order to avoid conflicts between multiple resource scheduling systems when the resource scheduling system controls the handling robots in the shared area, thus affecting the execution of scheduling and control tasks, a shared lock node can be allocated to each resource scheduling system to form a shared lock allocation system. Each shared lock node corresponds to one resource scheduling system, and multiple shared lock nodes form a decentralized network. Among them, multiple shared lock nodes consist of one master shared lock node and at least two slave shared lock nodes.

[0054] After receiving a shared lock application request submitted by the target resource scheduling system for a scheduling control task from at least two target shared lock nodes, the target shared lock node sends the shared lock application request to the master shared lock node. The master shared lock node then forwards the shared lock application request to each slave shared lock node via a decentralized network, enabling any slave node in the network to review the application request from the target shared lock node. At this time, the master shared lock node receives review information from each slave shared lock node regarding the shared lock application request. Based on the review information, it can determine whether the shared lock application request is approved, and then determine the shared lock allocation information based on the review information and send it to the target slave shared lock node.

[0055] Furthermore, once the shared lock node determines that the shared lock allocation information meets the allocation conditions, it indicates that the resource scheduling system can control the handling robots within the shared area. To avoid scheduling conflicts, the shared lock resources can be sent to the target resource scheduling system, enabling the target resource scheduling system to control the handling robots within the shared area to perform scheduling control tasks based on the shared lock resources. This achieves decentralized allocation of shared lock resources, and only the system holding the shared lock resources can control the handling robots within the shared area, effectively avoiding conflicts caused by simultaneous scheduling by the resource scheduling system, thus ensuring the normal and orderly progress of factory production.

[0056] In practical implementation, the shared lock allocation system can adopt a decentralized architecture, constructing shared lock services through P2P network interactions between shared lock nodes, thus achieving secure and reliable shared lock management. It should be noted that a shared lock node in the shared lock allocation system can be understood as the smallest working unit of the shared lock service, and its main functions include communicating with other shared lock nodes, participating in consensus leader election, executing shared lock management logic, and interacting with the resource scheduling system.

[0057] Each shared lock node mainly comprises a P2P communication module, a consensus module, a shared lock module, and a driver module. The P2P communication module enables information synchronization and forwarding between shared lock nodes through the P2P communication protocol. The consensus module determines the master and slave shared lock nodes using a consensus algorithm. The shared lock module executes the corresponding logical processing and is responsible for reviewing shared lock request applications. The driver module facilitates interaction between the shared lock node and its corresponding resource scheduling system.

[0058] For example, a car manufacturing plant deploys four AGVS systems. AGVS-1 controls AGVs in area A, AGVS-2 in area B, AGVS-3 in area C, and AGVS-4 in area D. During task execution, these four systems may control AGVs in a shared area E. To avoid conflicts when the four systems control AGVs in shared area D, a shared lock resource allocation method can be used for scheduling. Specifically, AGVS-1 corresponds to shared lock node G1, AGVS-2 to G2, AGVS-3 to G3, and AGVS-4 to G4. G4 is the master shared lock node, and G1, G2, and G3 are slave shared lock nodes.

[0059] Furthermore, after the AGVS-1 system's corresponding shared lock node G1 receives a shared lock application request from the AGVS-1 system for the engine parts handling task (the engine parts are placed on shelves in shared area E), shared lock node G1 can forward the shared lock application request to the master shared lock node G4. The master shared lock node G4 then sends the shared lock application request to the slave shared lock nodes G2 and G3. The slave shared lock nodes G2 and G3 review the shared lock application request submitted by the slave shared lock node G1 and determine that both slave shared lock nodes G2 and G3 agree to the AGVS-1 system's scheduling and control of the AGVs in shared area E. At this time, the master shared lock node G4 can feed back the review result to the slave shared lock node G1. Then, the slave shared lock node G1 sends shared lock resources to the AGVS-1 system to ensure that other AGVS systems can no longer use the shared lock resources. This allows the AGVS-1 system to schedule the AGVs in shared area E based on the shared lock resources to move the engine parts on the shelves to the designated location to support vehicle assembly processing.

[0060] In summary, by allocating shared lock resources in a decentralized manner, and ensuring that only the system holding the shared lock resources can control the handling robots within the shared area, conflicts caused by simultaneous scheduling by the resource scheduling system can be effectively avoided, thus ensuring that the factory's production progress can proceed normally and orderly.

[0061] In one optional embodiment of this specification, each of the plurality of shared lock nodes is configured with a consensus module. The consensus module is used to select a master shared lock node from the plurality of shared lock nodes through a preset election algorithm, and to designate the remaining shared lock nodes other than the master shared lock node as slave shared lock nodes. The shared lock nodes communicate with each other through a peer-to-peer protocol.

[0062] Specifically, the election algorithm refers to the Raft election algorithm; correspondingly, the peer-to-peer protocol refers to the P2P protocol. Based on this, to achieve decentralization, a consensus module can be configured on each shared lock node. This allows the shared lock nodes to elect a master shared lock node through the consensus module, enabling them to communicate via the peer-to-peer protocol (P2P protocol).

[0063] In other words, each of the multiple shared lock nodes can be configured with a consensus module. Each shared lock node can select a master shared lock node from among the multiple shared lock nodes through a preset election algorithm in the consensus module, and designate the remaining shared lock nodes other than the master shared lock node as slave shared lock nodes. Furthermore, the shared lock nodes communicate with each other through a peer-to-peer protocol, so that during the shared lock allocation phase, the master shared lock node receives shared lock application requests submitted by external systems and forwards them to different slave shared lock nodes for review. The slave shared lock nodes then call the shared lock module to execute the corresponding logic processing to complete the review of the shared lock application request.

[0064] In summary, by configuring a consensus module on each shared lock node, the shared lock node can select a master shared lock node. This allows the master shared lock node to handle request forwarding and information statistics during the shared lock allocation phase, thereby achieving decentralization.

[0065] In one optional embodiment of this specification, any one of the at least two associated shared lock nodes is used to, upon receiving the shared lock application request forwarded by the master shared lock node, invoke the preset review rules of the shared lock module to review the shared lock application request, obtain review information, and feed back the review information to the master shared lock node.

[0066] Specifically, the associated shared lock node refers to the slave shared lock node that receives a shared lock application request forwarded by the master shared lock node. Correspondingly, the shared lock module refers to the module that reviews shared lock application requests using review rules. These review rules can be understood as the rules for approving a resource scheduling system's request for shared lock resources. These rules can be set according to actual needs. For example, if the resource scheduling system corresponding to the slave shared lock node needs to control the transport robot in the shared area at the current moment, it means that the resource scheduling system also needs to apply for shared lock resources. In this case, the rule can be to determine whether its corresponding resource scheduling system also needs to apply for shared lock resources within the set time; if yes, it can provide feedback indicating that the review was not approved; if no, it can provide feedback indicating that the review was approved. The master shared lock node can determine whether to allocate shared lock resources to the target resource scheduling system by statistically analyzing the approved and disapproved review information.

[0067] Based on this, after the primary shared lock resource forwards the shared lock application request to each secondary shared lock node, the secondary shared lock node can call the pre-set review rules of the shared lock module to review the shared lock application request, obtain review information based on the review results, and feed it back to the primary shared lock node. The primary shared lock node then performs statistics and sends shared lock allocation information to the target secondary shared lock node to determine whether to allocate shared lock resources to the target resource scheduling system corresponding to the target secondary shared lock node.

[0068] Continuing with the previous example, the shared lock nodes G1 to G4, corresponding to the AGVS-1 to AGVS-4 systems respectively, will be configured with consensus modules. Each shared lock node's consensus module uses the Raft election algorithm to determine that shared lock node G4 is the master shared lock node, and shared lock nodes G1, G2, and G3 are slave shared lock nodes. When the master shared lock node G4 forwards the shared lock request submitted by the AGVS-1 system corresponding to shared lock node G1 to the slave shared lock nodes G2 and G3, the slave shared lock nodes G2 and G3 can execute the corresponding logical processing through their deployed shared lock modules. If the execution result indicates that both slave shared lock nodes G2 and G3 have returned true, then it is determined that both slave shared lock nodes G2 and G3 agree that the AGVS-1 system should schedule and control the AGVs within the shared area E.

[0069] In summary, by configuring a shared lock module on the shared lock node, shared lock application requests can be reviewed according to preset review rules. This allows all shared lock nodes to discuss and determine whether to allocate shared lock resources, thus ensuring fairness.

[0070] In one optional embodiment of this specification, the master shared lock node is further configured to receive review information from each slave shared lock node in response to the shared lock application request, process the review information according to a preset decision rule, determine the shared lock review allocation ratio based on the processing result, and send the shared lock review allocation ratio as shared lock allocation information to the target slave shared lock node.

[0071] Specifically, the decision-making rules refer to the rules for statistically analyzing review information to determine the shared lock review allocation ratio. The shared lock review allocation ratio specifically refers to the distribution of approval and disapproval percentages obtained after statistically analyzing the review information fed back from each shared lock node.

[0072] Based on this, after each slave shared lock node feeds back the review information to the master shared lock node, the master shared lock node can process the review information according to the preset decision rules, and thus determine the shared lock review allocation ratio based on the processing result; by using the shared lock review allocation ratio as shared lock allocation information and sending it to the target slave shared lock node, the target slave shared lock node can complete the shared lock resource allocation processing operation.

[0073] In summary, by using the shared lock audit allocation ratio as shared lock allocation information, the goal of determining the shared lock allocation process from the shared lock node can be achieved more quickly and conveniently, thereby improving processing efficiency.

[0074] In one optional embodiment of this specification, the target shared lock node is further configured to compare the shared lock review allocation ratio with a preset ratio threshold; if the shared lock review allocation ratio is greater than the preset ratio threshold, determine that the shared lock review allocation ratio meets the allocation conditions, and apply for shared lock resources in the corresponding shared area; and send the shared lock resources to the target resource scheduling system.

[0075] If the proportion of shared lock review and allocation is less than or equal to the preset proportion threshold, it is determined that the proportion of shared lock review and allocation does not meet the allocation conditions; application planning information is created for the shared lock application request, and the application planning information is sent to the target resource scheduling system; wherein, the application planning information is used by the target resource scheduling system to adjust the submission time of the shared lock application request.

[0076] Specifically, the preset percentage threshold refers to a threshold used to compare the percentage of shared locks reviewed and allocated, which can be 50% or 45%, etc., and this embodiment does not impose any limitations on it. Correspondingly, the application planning information refers to the information fed back by the target resource scheduling system. This information is used by the target resource scheduling system to adjust the submission time of the shared lock application request, so that after adjusting the submission time, there is a higher probability that the shared lock resource will be allocated to perform the scheduling and allocation task.

[0077] Based on this, after receiving the shared lock approval and allocation ratio from the main shared lock node, the target can compare the shared lock approval and allocation ratio with a preset ratio threshold. If the shared lock approval and allocation ratio is greater than the preset ratio threshold, it is determined that the shared lock approval and allocation ratio meets the allocation conditions. This further indicates that the target resource scheduling system can control the transport robots in the shared area, and therefore can apply for shared lock resources for the corresponding shared area. The shared lock resources are then sent to the target resource scheduling system for the target resource scheduling system to control the transport robots in the shared area to perform scheduling and control tasks based on the shared lock resources.

[0078] If the proportion of shared locks approved for allocation is less than or equal to a preset threshold, it is determined that the proportion of shared locks approved for allocation does not meet the allocation conditions. This further indicates that the target resource scheduling system cannot control the transport robots in the shared area at this time. In order not to affect the execution of the task, application planning information can be created for the shared lock application request and sent to the target resource scheduling system. The target resource scheduling system can then adjust the submission time of the shared lock application request based on the application planning information, so as to submit the shared lock application request at a suitable time after adjustment, thereby successfully applying for shared lock resources and completing the control of the transport robots in the shared area.

[0079] In summary, by comparing the proportion of shared lock allocation with a threshold and selecting different strategies for subsequent processing based on the comparison results, it is easier for the target resource scheduling system to apply for shared lock resources.

[0080] In one optional embodiment of this specification, any one of the plurality of shared lock nodes and the associated resource scheduling system corresponding to the associated shared lock node are deployed on the same physical machine server, and the associated resource scheduling system corresponding to any one of the associated shared lock nodes corresponds to different system providers.

[0081] In other words, any associated shared lock node and its corresponding resource scheduling system are deployed on the same physical server, and different resource scheduling systems are provided and maintained by different system providers.

[0082] Continuing with the previous example, when the primary shared lock node G4 forwards the shared lock application request submitted by the AGVS-1 system corresponding to shared lock node G1 to the secondary shared lock nodes G2 and G3, the secondary shared lock nodes G2 and G3, as well as the primary shared lock node G4, can all execute corresponding logical processing through the deployed shared lock module. Based on the execution result, secondary shared lock node G2 returns true, secondary shared lock node G3 returns false, and primary shared lock node G4 returns true. Subsequently, after statistical analysis, it is determined that the agreement rate is 67%, exceeding the set threshold of 50%. Therefore, the primary shared lock node G4 will send the agreement result to the secondary shared lock node G1. Afterward, the secondary shared lock node G1 can send shared lock resources to the AGVS-1 system to ensure that other AGVS systems can no longer use the shared lock resources. This allows the AGVS-1 system to schedule AGVs within the shared area E to move engine parts from the shelf to a designated location based on the shared lock resources, supporting vehicle assembly processing.

[0083] In summary, by allocating shared lock resources in a decentralized manner, and ensuring that only the system holding the shared lock resources can control the handling robots within the shared area, conflicts caused by simultaneous scheduling by the resource scheduling system can be effectively avoided, thus ensuring that the factory's production progress can proceed normally and orderly.

[0084] Corresponding to the above system embodiments, this specification also provides embodiments of shared lock allocation methods. Figure 3 A flowchart illustrating a shared lock allocation method according to one embodiment of this specification is shown. Figure 3 As shown, this method is applied to a target from a shared lock node, including:

[0085] Step S302: Receive the shared lock application request submitted by the target resource scheduling system corresponding to the target shared lock node for the scheduling control task;

[0086] Step S304: Send the shared lock application request to the main shared lock node, and receive the shared lock allocation information fed back by the main shared lock node in response to the shared lock application request;

[0087] Step S306: If the shared lock allocation information meets the allocation conditions, the shared lock resource is sent to the target resource scheduling system, so that the target resource scheduling system can control the transport robot in the shared area to perform the scheduling control task based on the shared lock resource.

[0088] In one optional embodiment, the target shared lock node belongs to a shared lock allocation system, which includes multiple shared lock nodes, each of which corresponds to a resource scheduling system, and the multiple shared lock nodes form a decentralized network; wherein, the multiple shared lock nodes consist of one master shared lock node and at least two slave shared lock nodes.

[0089] In one optional embodiment, each of the plurality of shared lock nodes is configured with a consensus module. The consensus module is used to select a master shared lock node from the plurality of shared lock nodes through a preset election algorithm, and to designate the remaining shared lock nodes other than the master shared lock node as slave shared lock nodes. The shared lock nodes communicate with each other through a peer-to-peer protocol.

[0090] In an optional embodiment, any one of the at least two associated shared lock nodes is configured to, upon receiving the shared lock application request forwarded by the master shared lock node, invoke the audit rules preset by the shared lock module to audit the shared lock application request, obtain audit information, and feed back the audit information to the master shared lock node.

[0091] In an optional embodiment, the master shared lock node is further configured to receive review information from each slave shared lock node in response to the shared lock application request, process the review information according to a preset decision rule, determine the shared lock review allocation ratio based on the processing result, and send the shared lock review allocation ratio as shared lock allocation information to the target slave shared lock node.

[0092] In an optional embodiment, the target shared lock node is further configured to compare the shared lock review allocation ratio with a preset ratio threshold; if the shared lock review allocation ratio is greater than the preset ratio threshold, determine that the shared lock review allocation ratio meets the allocation conditions, and apply for shared lock resources in the corresponding shared area; and send the shared lock resources to the target resource scheduling system.

[0093] In an optional embodiment, the target shared lock node is further configured to determine that the shared lock review and allocation ratio does not meet the allocation conditions if the shared lock review and allocation ratio is less than or equal to the preset ratio threshold; create application planning information for the shared lock application request, and send the application planning information to the target resource scheduling system; wherein, the application planning information is used by the target resource scheduling system to adjust the submission time of the shared lock application request.

[0094] In one optional embodiment, any one of the plurality of shared lock nodes and the associated resource scheduling system corresponding to the associated shared lock node are deployed on the same physical machine server, and the associated resource scheduling system corresponding to any one of the associated shared lock nodes corresponds to different system providers.

[0095] The above is an illustrative scheme of a shared lock allocation method according to this embodiment. It should be noted that the technical solution of this shared lock allocation method and the technical solution of the shared lock allocation system described above belong to the same concept. For details not described in detail in the technical solution of the shared lock allocation method, please refer to the description of the technical solution of the shared lock allocation system described above.

[0096] Corresponding to the above system embodiments, this specification also provides another embodiment of a shared lock allocation method. Figure 4 A flowchart illustrating another shared lock allocation method provided in one embodiment of this specification is shown. Figure 4 As shown, this method is applied to the primary shared lock node and includes:

[0097] Step S402: Receive at least two shared lock request requests submitted by the target shared lock nodes from the shared lock nodes;

[0098] Step S404: Forward the shared lock request to each of the at least two slave shared lock nodes through a decentralized network;

[0099] Step S406: Receive the review information from each shared lock node in response to the shared lock application request, and determine the shared lock allocation information based on the review information;

[0100] Step S408: The shared lock allocation information is sent to the target slave shared lock node, so that the target slave shared lock node can allocate shared lock resources corresponding to the shared area according to the shared lock allocation information.

[0101] In one optional embodiment, the master shared lock node belongs to a shared lock allocation system, which includes multiple shared lock nodes, each of which corresponds to a resource scheduling system, and the multiple shared lock nodes form a decentralized network; wherein, the multiple shared lock nodes consist of one master shared lock node and at least two slave shared lock nodes.

[0102] In one optional embodiment, each of the plurality of shared lock nodes is configured with a consensus module. The consensus module is used to select a master shared lock node from the plurality of shared lock nodes through a preset election algorithm, and to designate the remaining shared lock nodes other than the master shared lock node as slave shared lock nodes. The shared lock nodes communicate with each other through a peer-to-peer protocol.

[0103] In an optional embodiment, any one of the at least two associated shared lock nodes is configured to, upon receiving the shared lock application request forwarded by the master shared lock node, invoke the audit rules preset by the shared lock module to audit the shared lock application request, obtain audit information, and feed back the audit information to the master shared lock node.

[0104] In an optional embodiment, the master shared lock node is further configured to receive review information from each slave shared lock node in response to the shared lock application request, process the review information according to a preset decision rule, determine the shared lock review allocation ratio based on the processing result, and send the shared lock review allocation ratio as shared lock allocation information to the target slave shared lock node.

[0105] In an optional embodiment, the target shared lock node is further configured to compare the shared lock review allocation ratio with a preset ratio threshold; if the shared lock review allocation ratio is greater than the preset ratio threshold, determine that the shared lock review allocation ratio meets the allocation conditions, and apply for shared lock resources in the corresponding shared area; and send the shared lock resources to the target resource scheduling system.

[0106] In an optional embodiment, the target shared lock node is further configured to determine that the shared lock review and allocation ratio does not meet the allocation conditions if the shared lock review and allocation ratio is less than or equal to the preset ratio threshold; create application planning information for the shared lock application request, and send the application planning information to the target resource scheduling system; wherein, the application planning information is used by the target resource scheduling system to adjust the submission time of the shared lock application request.

[0107] In one optional embodiment, any one of the plurality of shared lock nodes and the associated resource scheduling system corresponding to the associated shared lock node are deployed on the same physical machine server, and the associated resource scheduling system corresponding to any one of the associated shared lock nodes corresponds to different system providers.

[0108] The above is an illustrative scheme of another shared lock allocation method in this embodiment. It should be noted that the technical solution of this shared lock allocation method belongs to the same concept as the technical solution of the shared lock allocation system described above. For details not described in detail in the technical solution of the shared lock allocation method, please refer to the description of the technical solution of the shared lock allocation system described above.

[0109] Figure 5 A structural block diagram of a computing device 500 according to one embodiment of this specification is shown. The components of the computing device 500 include, but are not limited to, a memory 510 and a processor 520. The processor 520 is connected to the memory 510 via a bus 530, and a database 550 is used to store data.

[0110] The computing device 500 also includes an access device 540, which enables the computing device 500 to communicate via one or more networks 560. Examples of these networks include Public Switched Telephone Network (PSTN), Local Area Network (LAN), Wide Area Network (WAN), Personal Area Network (PAN), or combinations of communication networks such as the Internet. The access device 540 may include one or more of any type of wired or wireless network interface (e.g., a network interface controller (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) wireless interface, a Wi-MAX (Worldwide Interoperability for Microwave Access) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, or a Near Field Communication (NFC) interface.

[0111] In one embodiment of this specification, the above-described components of the computing device 500 and Figure 5 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 5 The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this specification. Those skilled in the art can add or replace other components as needed.

[0112] Computing device 500 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or personal computers (PCs). Computing device 500 can also be a mobile or stationary server.

[0113] The processor 520 is configured to execute the following computer-executable instructions, which, when executed by the processor, implement the steps of the shared lock allocation method described above.

[0114] The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device and the technical solution of the shared lock allocation method described above belong to the same concept. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the shared lock allocation method described above.

[0115] An embodiment of this specification also provides a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the steps of the shared lock allocation method described above.

[0116] The above is an illustrative scheme of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium belongs to the same concept as the technical solution of the shared lock allocation method described above. For details not described in detail in the technical solution of the storage medium, please refer to the description of the technical solution of the shared lock allocation method described above.

[0117] An embodiment of this specification also provides a computer program product, including a computer program or instructions that, when executed by a processor, implement the steps of the shared lock allocation method described above.

[0118] The above is an illustrative scheme of a computer program product according to this embodiment. It should be noted that the technical solution of this computer program product and the technical solution of the shared lock allocation method described above belong to the same concept. For details not described in detail in the technical solution of the computer program product, please refer to the description of the technical solution of the shared lock allocation method described above.

[0119] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0120] The computer instructions include computer program code, which may be in the form of source code, object code, executable file, or certain intermediate forms. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording media, USB flash drive, portable hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium may be appropriately added or removed according to the requirements of patent practice. For example, in some regions, according to patent practice, computer-readable media may not include electrical carrier signals and telecommunication signals.

[0121] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments in this specification are not limited to the described order of actions, because according to the embodiments in this specification, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in this specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the embodiments in this specification.

[0122] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0123] The preferred embodiments disclosed above are merely illustrative of this specification. Optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the embodiments described in this specification. These embodiments are selected and specifically described in this specification to better explain the principles and practical applications of the embodiments, thereby enabling those skilled in the art to better understand and utilize this specification.

Claims

1. A shared lock allocation system, characterized by, The shared lock allocation system comprises a plurality of shared lock nodes, each shared lock node corresponding to a resource scheduling system, and the plurality of shared lock nodes forming a decentralized network; wherein the plurality of shared lock nodes are composed of one master shared lock node and at least two slave shared lock nodes, comprising: The target slave shared lock node in the at least two slave shared lock nodes is configured to receive a shared lock application request submitted by a target resource scheduling system corresponding to the target slave shared lock node for a scheduling control task; and send the shared lock application request to the master shared lock node. The master shared lock node is configured to forward the shared lock application request to each slave shared lock node through the decentralized network, receive audit information fed back by each slave shared lock node for the shared lock application request, determine shared lock allocation information according to the audit information, and send the shared lock allocation information to the target slave shared lock node. The target slave shared lock node is configured to send shared lock resources to the target resource scheduling system under the condition that the shared lock allocation information meets an allocation condition, so that the target resource scheduling system controls a transfer robot in a shared area to perform the scheduling control task based on the shared lock resources.

2. The shared lock allocation system of claim 1, wherein, Each shared lock node in the plurality of shared lock nodes is configured with a consensus module, the consensus module is configured to select a master shared lock node in the plurality of shared lock nodes through a preset election algorithm, and the remaining shared lock nodes in the plurality of shared lock nodes except the master shared lock node are used as slave shared lock nodes; wherein each shared lock node communicates with each other through a peer-to-peer protocol.

3. The shared lock allocation system of claim 1, wherein, Any associated slave shared lock node in the at least two slave shared lock nodes is configured to, in a case of receiving the shared lock application request forwarded by the master shared lock node, call a preset audit rule of a shared lock module to audit the shared lock application request, obtain audit information, and feed back the audit information to the master shared lock node.

4. The shared lock allocation system of claim 1, wherein, The master shared lock node is further configured to receive the audit information fed back by each slave shared lock node for the shared lock application request, process the audit information according to a preset decision rule, determine a shared lock audit allocation proportion according to a processing result, use the shared lock audit allocation proportion as shared lock allocation information, and send the shared lock allocation information to the target slave shared lock node.

5. The shared lock allocation system of claim 4, wherein, The target slave shared lock node is further configured to compare the shared lock audit allocation proportion with a preset proportion threshold; in a case that the shared lock audit allocation proportion is greater than the preset proportion threshold, determine that the shared lock audit allocation proportion meets an allocation condition, and apply for shared lock resources of a corresponding shared area; and send the shared lock resources to the target resource scheduling system.

6. The shared lock allocation system of claim 5, wherein, The target slave shared lock node is further configured to determine that the shared lock audit allocation ratio does not meet the allocation condition if the shared lock audit allocation ratio is less than or equal to the preset ratio threshold; create application planning information for the shared lock application request, and send the application planning information to the target resource scheduling system; and wherein the application planning information is used by the target resource scheduling system to adjust the submission time of the shared lock application request.

7. The shared lock allocation system of any of claims 1-6, wherein, Any one of the plurality of shared lock nodes is associated with a shared lock node, and the associated resource scheduling system corresponding to the associated shared lock node is deployed on the same physical server, and the associated resource scheduling system corresponding to any one of the associated shared lock nodes corresponds to different system providers.

8. A method of shared lock allocation, characterized by, The application is applied to a target slave shared lock node, and includes: Receiving a shared lock application request submitted by a target resource scheduling system corresponding to the target slave shared lock node for a scheduling control task; Sending the shared lock application request to a master shared lock node, and receiving shared lock allocation information fed back by the master shared lock node for the shared lock application request; If the shared lock allocation information meets the allocation condition, sending a shared lock resource to the target resource scheduling system, so that the target resource scheduling system controls a transfer robot in a shared area to perform the scheduling control task based on the shared lock resource.

9. A method of shared lock allocation, characterized by, The application is applied to a master shared lock node, and includes: Receiving a shared lock application request submitted by a target slave shared lock node among at least two slave shared lock nodes; Forwarding the shared lock application request to each slave shared lock node among the at least two slave shared lock nodes through a decentralized network; Receiving audit information fed back by each slave shared lock node for the shared lock application request, and determining shared lock allocation information according to the audit information; Sending the shared lock allocation information to the target slave shared lock node, so that the target slave shared lock node allocates a shared lock resource corresponding to a shared area according to the shared lock allocation information.

10. A computing device, comprising: It includes: A memory and a processor; The memory is used to store computer executable instructions, and the processor is used to execute the computer executable instructions, which realize the steps of the method of claim 8 or 9 when the computer executable instructions are executed by the processor.

11. A computer readable storage medium, characterized in that, It stores computer executable instructions, which realize the steps of the method of claim 8 or 9 when the computer executable instructions are executed by the processor.

12. A computer program product, characterised in that, It includes a computer program or instructions, which realize the steps of the method of claim 8 or 9 when the computer program or instructions are executed by the processor.