Cooperative operation real-time data exchange system and method suitable for cooperative hoisting scene of multiple portal cranes

Abstract

The invention provides a collaborative operation real-time data exchange system and method suitable for a collaborative hoisting scene of multiple portal cranes, and relates to the field of portal crane control. The system comprises a gantry crane control unit, a shared memory module, a central scheduling control module, a safety monitoring module and a system database. According to the method, a shared memory with partitions and a communication link are established through initialization, instructions are issued through central scheduling when tasks are executed, state synchronization and autonomous fine adjustment of all the gantry cranes are achieved based on the shared memory, the data transmission amount is reduced by combining event driving and differential synchronization, and the safety monitoring module monitors in real time and triggers the fault-tolerant process. According to the scheme, the real-time performance, the safety and the expansibility of collaborative operation are improved, and the method is suitable for multi-machine collaborative hoisting in scenes such as large ports and wharfs.

Description

Technical Field

[0001] This invention relates to the field of gantry crane control, and more particularly to a real-time data exchange system and method for collaborative operations in scenarios involving multiple gantry cranes working together. Background Technology

[0002] Gantry cranes are commonly found in ports, docks, shipyards, and large industrial areas, used for loading, unloading, transferring, and hoisting various heavy goods or large structural components. Their base typically employs a portal-like or supported rigid structure, mounted on a fixed base or rail. Gantry cranes are equipped with a slewing mechanism at the top, allowing for a large operating area. Gantry cranes are widely used in port container handling, offshore wind power equipment installation, large-module shipbuilding assembly, and port bulk cargo handling.

[0003] In practical applications, when a single gantry crane is unable to lift excessively long, large, or heavy objects independently, multiple gantry cranes are often required to work in concert to complete the lifting of such cargo. For example, in shipbuilding assembly, multiple gantry cranes are needed to lift a huge hull section together; in port terminals, two or more gantry cranes are needed to coordinate the lifting of excessively large equipment or structural components. These scenarios all require the gantry cranes to operate synchronously and in unison to maintain load balance and operational safety.

[0004] Most existing multi-machine collaborative hoisting systems employ traditional master-slave control or PLC-based network scanning methods, with relatively simple synchronization strategies. Chinese invention patent CN117963737A describes a synchronous control method where two bridge cranes use a "master-slave" mode via a wireless network, incorporating signal difference feedback to ensure synchronization accuracy. While this approach ensures safety by detecting differences between the master and slave controllers and promptly stopping the crane, it is limited to a fixed master-slave architecture and lacks flexibility when expanding to multi-device collaboration. Some systems lack a unified data sharing platform, with each crane controller operating independently and relying on periodic communication to maintain consistency, making it difficult to respond promptly to rapid changes.

[0005] Furthermore, existing multi-machine collaborative control systems often focus on functionality while neglecting fault tolerance and safety. Many systems employ a single central control or master node scheduling mechanism; if this node fails, the entire operation will be interrupted, lacking fault isolation and redundancy mechanisms. Summary of the Invention

[0006] Purpose of the invention: To propose a real-time data exchange system and method for collaborative lifting scenarios involving multiple gantry cranes, in order to solve the aforementioned problems existing in the prior art.

[0007] A first aspect of the present invention provides a real-time data exchange system for collaborative operations applicable to scenarios involving the coordinated lifting of multiple gantry cranes, comprising:

[0008] Multiple gantry crane control units, one for each gantry crane, are used to control the machine to perform lifting actions, write their real-time status to a shared memory module, and read instructions and status information from other units in the shared memory module to achieve distributed autonomous fine-tuning;

[0009] The shared memory module, as the core of data exchange, is divided into a status area, an instruction area, an event area, and a security area. Each area has controlled read and write permissions, supporting efficient real-time data exchange between units. Its synchronization latency is reduced by orders of magnitude compared to traditional industrial Ethernet, providing a guarantee for precise collaborative control. An atomic read and write mechanism is used to ensure data consistency.

[0010] The central dispatch and control module is used to receive collaborative hoisting tasks, plan collaborative strategies, issue instructions to each gantry crane control unit through the shared memory module, and monitor the global status to achieve centralized dispatch.

[0011] The safety monitoring module is used to monitor the system's operating status in real time, detect anomalies, set alarm flags in the safety area of ​​the shared memory module, and trigger safety fault tolerance processes, including emergency braking, coordinated load reduction, and fault isolation and redundancy switching.

[0012] The system database stores configuration files, task data, and runtime logs, allowing various modules to read configurations and write logs.

[0013] In a further embodiment of the first aspect, the shared memory module is implemented using a physical shared storage device or through high-speed network simulation. In terms of hardware, a high-speed backplane bus or fiber optic ring network with DMA and bus arbitration functions is selected to ensure bus fairness and low latency when multiple nodes access each other in parallel.

[0014] The shared memory module adopts a differential data synchronization strategy. Each gantry crane control unit writes the new value into the status area of ​​the shared memory only when the difference between the new and old values ​​of its own key variables exceeds a preset dead zone threshold.

[0015] In a further embodiment of the first aspect, the atomic read / write mechanism includes double-buffered update, hardware-supported bus lock and mutex lock and priority inheritance protocol. Double-buffered update is used to avoid read / write conflicts of multi-byte data structures, bus lock ensures that the execution of atomic instructions is not interrupted, and priority inheritance protocol is used to avoid priority inversion.

[0016] In a further embodiment of the first aspect, the safety monitoring module includes a safety sensor input acquisition unit, a heartbeat monitoring unit, and an emergency triggering unit. The safety sensor input acquisition unit is used to acquire data from a torque sensor, an inclination sensor, and an anemometer. The heartbeat monitoring unit is used to check the heartbeat count of each unit. The emergency triggering unit is used to write an emergency flag and trigger hardware braking.

[0017] In a further embodiment of the first aspect, the central dispatch control module may be concurrently served by an independent industrial computer or the control unit of a gantry crane. In the event of failure of the central module, each gantry crane control unit can maintain a safe state in accordance with the last instruction or contingency plan.

[0018] In a further embodiment of the first aspect, the collaborative real-time data exchange system also includes a redundant communication channel. When the main channel fails, the safety monitoring module drives all units to switch to the backup channel for communication, with the switching time in milliseconds.

[0019] A second aspect of the present invention proposes a real-time data exchange method for collaborative operations in scenarios involving multiple gantry cranes working together. This method is based on the real-time data exchange system for collaborative operations disclosed in the first aspect. The steps of this method are as follows:

[0020] S1. Each gantry crane control unit, central dispatch control module, and safety monitoring module performs a power-on self-test, loads configuration files from the system database, initializes shared memory and divides it into status area, instruction area, event area, and safety area, establishes a communication link and completes clock synchronization, and enters standby state.

[0021] S2. The central dispatch and control module receives the collaborative hoisting task, plans the collaborative strategy, and sends it to each gantry crane control unit through the shared memory instruction area. After reading the instruction, each gantry crane control unit executes the preparatory action and writes the real-time status into the shared memory status area. After the central dispatch and control module confirms that all units are ready, it issues a global collaborative instruction. Each gantry crane control unit reads the instruction and executes the collaborative action. At the same time, it performs distributed autonomous fine-tuning based on the global real-time status in the shared memory to keep the actions synchronized.

[0022] S3, the safety monitoring module monitors key data in shared memory in real time. If an anomaly is detected, an alarm flag is set in the safety zone and a safety fault tolerance process is triggered, including emergency braking, coordinated load reduction, fault isolation and redundancy switching.

[0023] S4. When the hoisting task is completed, each gantry crane control unit publishes a "task completed" event in the shared memory event area. After confirmation by the central dispatch control module, the data is summarized and a report is generated, and the system is reset to standby state.

[0024] In a further embodiment of the second aspect, in step S1, the initialization of shared memory includes setting access permissions for each module to different areas, the establishment of communication links includes testing of primary and backup links, and clock synchronization is achieved using a precise time protocol.

[0025] In step S2, the collaborative strategy includes load distribution, motion trajectory, and synchronous control parameters for each machine; distributed autonomous fine-tuning refers to the autonomous adjustment of the control quantity of the actuator to eliminate the deviation when a gantry crane control unit detects that the deviation between its own motion state and the collaborative target or the state of other units exceeds a preset threshold.

[0026] In step S3, emergency braking includes the safety module cutting off the power output of all gantry cranes through hardware circuitry, and each gantry crane control unit assisting in braking and entering a safe mode after hearing the "emergency stop" sign; coordinated load reduction refers to each gantry crane control unit lowering the load to the ground at a safe speed according to instructions or local strategies in the event of a temporary communication interruption; the fault isolation and redundancy switching includes isolating the faulty unit from the coordinated task, the central dispatch control module replanning the tasks of the remaining units, and if there is a backup device, the backup gantry crane taking over part of the load.

[0027] In a further embodiment of the second aspect, the events include safety events, dispatch instruction events, and normal status events, which are processed in order of priority. The safety events are initiated by the safety monitoring module or the gantry crane control unit, the dispatch instruction events are initiated by the central dispatch control module, and the normal status events are initiated by the gantry crane control unit.

[0028] During the execution of the task, the central dispatch and control module monitors the global synchronization status at a frequency lower than the preset target, while each gantry crane control unit updates its own status at a frequency higher than the preset target and achieves local autonomous coordination, forming a control mode that combines centralized dispatch and distributed autonomy.

[0029] In a further embodiment of the second aspect, when an event occurs, the gantry crane control unit or safety monitoring module that detects the event writes the event information into the event area of ​​shared memory; the central dispatch control module and other gantry crane control units capture the event and respond through a publish / subscribe mechanism; the status data synchronization adopts a differential update strategy, propagating the changed portion only when the data change exceeds a preset dead zone threshold.

[0030] Compared with the prior art, the present invention has significant technical advantages in the following aspects:

[0031] (1) Innovating the data exchange method, in the synchronization of critical state data, an event-driven differential synchronization mechanism replaces the traditional high-frequency periodic polling mode, greatly reducing data transmission redundancy and latency, retaining only the necessary low-frequency heartbeat for link monitoring; by introducing high-speed shared memory as the "data center" for all collaborative units, and combining it with the event-driven differential synchronization mechanism, a high-efficiency and high-speed data exchange channel is constructed. This design aims to achieve stable data synchronization at the millisecond level, solving the problems of data latency, jitter, and redundancy from the source, and laying a solid data foundation for precise collaborative control.

[0032] (2) Reconstructing the collaborative control architecture to enhance system flexibility and intelligence: The purpose of this invention is to break through the rigid framework of "master-slave control" and establish a hybrid control mode that combines centralized scheduling with distributed autonomy. In this mode, the central scheduling module is responsible for global task planning and macro-strategy distribution, while each gantry crane unit uses the shared global real-time status to perform high-speed local autonomous coordination and error correction. This architecture organically integrates the global perspective of centralized control with the rapid response and robustness of distributed control, aiming to systematically solve the problems of poor flexibility, weak scalability, and single point of failure in traditional modes.

[0033] (3) Constructing a highly reliable defense-in-depth security system to ensure reliability throughout the entire operation process: The purpose of this invention is to elevate security design to a core position. By setting up an independent security monitoring module with the highest arbitration authority, and constructing physically redundant communication links and a rapid fault switching mechanism, a multi-layered, proactive defense-in-depth system is established. This design ensures that in the event of any single point of failure or communication anomaly, the system can instantly enter a preset security protection state (such as coordinated load reduction or emergency shutdown), thereby establishing a reliable collaborative operating environment. Attached Figure Description

[0034] Figure 1 This is a complete flowchart of the collaborative hoisting task from start to finish in the embodiment.

[0035] Figure 2 This is a schematic diagram of a hybrid control architecture that combines distributed and centralized control in the embodiment.

[0036] Figure 3 This is a schematic diagram of the fault-tolerant control process in the embodiment. Detailed Implementation

[0037] In the following description, numerous specific details are set forth in order to provide a more thorough understanding of the invention. However, it will be apparent to those skilled in the art that the invention can be practiced without one or more of these details. In other instances, certain technical features well-known in the art have not been described in order to avoid obscuring the invention.

[0038] Currently, the industry mainly uses the following solutions to achieve coordinated control of multiple gantry cranes:

[0039] Network communication based on TCP / IP or general industrial Ethernet: Many existing systems connect various gantry crane controllers via Ethernet, exchanging data using protocols such as TCP / IP, UDP, or OPC. This approach is relatively easy to implement and offers high equipment versatility. However, since ordinary Ethernet is not designed for real-time control, its communication latency and jitter are difficult to predict, especially under high network load, which can affect synchronization accuracy. Furthermore, network communication typically sends complete data packets at fixed intervals, repeatedly sending large amounts of the same data even with minor state changes, resulting in low efficiency. Although industrial Ethernet protocols (such as ProfinetIRT, EtherCAT, etc.) enhance real-time performance, they still suffer from complex configuration and strong dependence on network topology and cabling. For example, when gantry cranes are widely distributed, long-distance network cables or fiber optic cables need to be laid, and switches / routers need to be configured, increasing deployment costs and potential points of failure.

[0040] Centralized Control / Master-Slave Control: Another common approach is to use a centralized controller or master-slave control architecture. For example, a master PLC / computer sends commands to synchronously control multiple gantry cranes, or an operator uses a single remote control to simultaneously control multiple gantry cranes. Synchronous control technology from companies like Columbus McKinnon allows one operator to simultaneously control multiple gantry cranes through a single remote control device, achieving synchronized operation. This centralized control is effective in simple situations, ensuring consistent command delivery. However, its disadvantages include: high single-point-of-failure risk—if the master controller fails, all gantry cranes cannot coordinate; poor scalability—each additional gantry crane requires a hardware and software upgrade for the master controller; and communication delay—the master controller needs to poll or broadcast to each device, leading to a significant increase in load as the number of devices increases. Furthermore, control systems for different gantry cranes often come from different manufacturers, requiring a unified interface for centralized control, resulting in high modification costs.

[0041] Control networks based on fieldbus / industrial bus: In industrial settings, solutions using fieldbuses such as CAN bus and Profibus connect multiple gantry crane controllers. These buses typically support a certain degree of real-time communication and multiple masters. However, they have limited bandwidth (e.g., CAN is usually within 1Mbps) and limited connection distance, making them suitable for simple coordination of two or three devices. For example, in the IncosaSolutions case, two gantry cranes connect their respective controllers via a CAN bus to synchronize their operations. However, as the number of gantry cranes increases or the amount of control data grows, bus arbitration and bandwidth become bottlenecks, making it difficult to ensure that all devices receive data in a timely manner. Furthermore, bus-based architectures, similar to centralized control, also suffer from the problem of a single node failure affecting the entire system.

[0042] I. Overall System Workflow

[0043] The collaborative real-time data exchange system proposed in this invention, applicable to collaborative lifting scenarios involving multiple gantry cranes, adopts a distributed shared memory architecture and an event-driven control mechanism. The overall system consists of multiple gantry crane control units, a shared memory module, a central dispatch control module, a safety monitoring module, and a system database. The structure and logical relationships of each component are as follows: Figure 1 As shown below. The technical solution will be described in detail below:

[0044] Starting from the A. Initialization phase, after completing all preparations, the system enters the B. Standby and Task Loop. Upon receiving a new task, the system enters the C. Collaborative Execution phase, which is an internal loop encompassing preparation, execution, exception handling, and phase completion checks. If the task successfully completes all phases, it enters the D. Termination phase for data processing and reset, then returns to the standby state. If an exception occurs during execution, it will immediately jump to the safety and fault-tolerant process for handling.

[0045] System startup and initialization phase (corresponding flowchart A)

[0046] The goal of this phase is to ensure that all collaborative units and modules are in a correct, synchronized, and ready state.

[0047] Power-on self-test: All gantry crane control units (CCUs), central dispatching modules, and safety monitoring modules are powered on in sequence to perform hardware self-tests (processor, memory, and interface tests) and software initialization.

[0048] Configuration loading: Each module reads and loads its own configuration file from the system database, which includes device physical parameters, shared memory address mapping relationships, security thresholds, communication parameters, etc.

[0049] Shared memory initialization: The shared memory module establishes a memory space according to the configuration and strictly divides it into a status area, instruction area, event area, security area, etc., according to functional requirements. At the same time, it sets the access permissions of each module to different areas.

[0050] Communication link establishment: Each CCU connects to the shared memory through a preset high-speed interface. The system will automatically perform communication tests to confirm that both the primary and backup links are in normal working order, ensuring high availability of the data path.

[0051] System Synchronization and Standby: Each module confirms its online status with a heartbeat mechanism (updating a counter value in shared memory at a fixed low frequency). Subsequently, the system completes clock synchronization of all nodes through the Precise Time Protocol (PTP). At this point, all modules are ready, and the system enters the "standby" state.

[0052] Task execution phase (corresponding to flowcharts B and C)

[0053] This is the stage that demonstrates the core collaborative mechanism of the invention, describing how multiple gantry cranes work as a whole to perform complex tasks.

[0054] Task Reception and Planning: The operator inputs the collaborative lifting task through the Human-Machine Interface (HMI). Task parameters include, but are not limited to, the identifiers of the gantry cranes participating in the collaboration, the attributes of the object to be lifted, and the initial and target position coordinates. The central dispatch module receives the task, performs a feasibility analysis, and intelligently plans a detailed collaborative strategy, including load distribution for each crane, motion trajectory, and synchronization control parameters.

[0055] Task Distribution and Preparation: The scheduling module issues initial preparation instructions (such as moving to the target workstation) to the designated CCUs via the instruction area of ​​shared memory. After reading the instructions, each CCU independently controls its own movement and continuously writes its real-time position, height, and other information to the status area of ​​shared memory. The scheduling module then continuously monitors the status area, waiting for all participating CCUs to reach their designated positions.

[0056] Collaborative task execution:

[0057] Once the scheduling module confirms that all CCUs are ready, it will issue a global coordination instruction in the instruction area. This instruction contains the type of coordination action and key control parameters (such as target speed, target position, etc.).

[0058] Almost simultaneously, all participating CCUs read the instruction and began to control the actuators to perform coordinated actions.

[0059] The key to collaboration lies in the fact that during the execution of collaborative actions, each CCU not only relies on its own sensors for closed-loop control, but also reads the real-time status of other collaborative CCUs from the shared memory state area at a high frequency.

[0060] Distributed autonomous fine-tuning: If a CCU detects a deviation in its motion state from the state of the cooperating target or other units that exceeds a preset synchronization error threshold through its control algorithm, the CCU's control logic will autonomously and independently adjust the control input of its actuators (such as adjusting motor speed) to actively eliminate the deviation and dynamically maintain precise synchronization with other units. This autonomous coordination based on shared real-time state is one of the core innovations of this invention that distinguishes it from traditional master-slave control.

[0061] During this period, the central scheduling module will monitor the global synchronization status at a low frequency, perform macro-level interventions, or issue instructions for the next stage after the current stage of tasks is completed.

[0062] Real-time monitoring and dynamic adjustment: Throughout the entire task execution process, the safety monitoring module independently monitors all critical data in the shared memory. Upon detecting an anomaly, it immediately sets an alarm flag in the safety zone, triggering corresponding safety and fault-tolerant procedures to ensure operational safety.

[0063] Task completion and reset phase (corresponding flowchart D)

[0064] Task confirmation: When the hoisted object is safely placed and each CCU detects that the load status meets the task completion conditions, it will publish a "task completed" event in the shared memory event area.

[0065] Data aggregation and reporting: After the scheduling module captures the "task completion" events of all relevant CCUs, it confirms the end of the entire job. The system automatically aggregates the process data of this task from the database and logs, and generates a task report for analysis and archiving.

[0066] System reset: Each gantry crane returns to the standby position, temporary task data in shared memory is cleared, and the system is restored to a clean "standby" state, ready to receive the next task.

[0067] II. System Overall Architecture

[0068] This system adopts a hybrid control architecture that combines distributed and centralized control. (See...) Figure 2 Each gantry crane is equipped with an independent control unit, and these control units communicate with each other through a shared memory module, while a central scheduling module coordinates tasks. This forms a star-shaped collaborative control network, where each node can operate autonomously while sharing the global status.

[0069] Crane Control Unit (CCU): Each gantry crane has one CCU, which contains an embedded PLC, sensor and actuator interfaces, and an edge computing unit. The CCU is responsible for the low-level control of the crane itself (such as motor drive, brake control, and spreader operation) and data interaction with shared memory. Each CCU allocates a dedicated shared memory area to publish its own status (such as hook height, load weight, and travel speed) and read instructions issued by other CCUs and the scheduling module. The CCU also runs local safety logic (such as overload protection) to automatically respond in emergencies. Simultaneously, the CCU connects to the shared memory module through high-speed interfaces (such as PCIe reflective memory cards and fiber optic Ethernet ports) to exchange data with other units.

[0070] Shared memory module: This is the core data exchange medium of this invention. It can be a physical shared storage device (e.g., a multi-port shared memory board or a distributed memory array), or it can simulate the function of shared memory through a high-speed network (e.g., using reflective memory technology or a memory data bus to achieve memory mirroring synchronization). The shared memory is divided into several regions, each assigned to a specific purpose or unit (see "Memory Partitioning Mechanism" below). All control units accessing the shared memory have controlled read and write permissions to each region, thereby enabling data exchange with low latency. In this architecture, each gantry crane control unit appears to run on a multi-core computer, communicating with each other through shared memory. To ensure real-time performance, the shared memory module prioritizes memory-level communication, minimizing the overhead of the TCP / IP protocol stack. In terms of hardware implementation, a high-speed backplane bus or fiber optic ring network with DMA and bus arbitration functions can be selected to ensure bus fairness and low latency when multiple nodes access the system in parallel.

[0071] Central Dispatch and Control Module: The central dispatch module (also known as the scheduler) is logically located at the top level of the system. It is responsible for receiving hoisting operation task instructions, planning the coordinated action strategy of multiple gantry cranes, and issuing instructions to each CCU through shared memory. The dispatch module can be a standalone industrial computer or a CCU of one of the gantry cranes. During system operation, the dispatch module continuously monitors the status data of each CCU in the shared memory, calculates based on a predetermined collaborative algorithm or AI decision model, and generates the next target actions for each machine (such as speed, position setting, etc.). These control instructions are then written into the command area of ​​the shared memory and read and executed by the corresponding CCU. The central dispatch module is also responsible for handling global events (such as synchronous hoisting start / stop signals, stage transitions, etc.) and coordinating the sequence of staged operations. It is important to emphasize that although a central dispatch module exists, this system is not simply a centralized control system—each CCU still has autonomous control capabilities. The central dispatch module acts more like a coordinator, setting reference targets for each machine and supervising coordination. When communication fails or the central module fails, each CCU can maintain a safe state according to the last instruction or contingency plan, possessing a certain degree of fault tolerance and independence.

[0072] Safety Monitoring Module: The safety module permeates all levels of the system. Its main function is to monitor the system's operational status in real time, detect potential hazards, and trigger protective measures. It includes acquiring inputs from safety sensors (such as torque sensors, tilt sensors, and anemometers) and monitoring the status of each CCU (e.g., whether a gantry crane has stopped responding). The safety module can be implemented as an independent hardware circuit or a combined hardware and software unit, linked to shared memory. When an anomaly is detected (e.g., overload, height difference between two cranes exceeding a threshold, loss of communication heartbeat), the safety module immediately writes an emergency event flag to a dedicated safety area in shared memory. All CCUs listen for this safety flag, and upon detection, immediately enter a safe mode (e.g., immediately stop movement or reduce the load at a safe speed). Simultaneously, the safety module can also directly send hard-wired emergency stop signals to the actuators of each gantry crane (bypassing the software layer) to ensure absolute safety. The safety module also manages the health status of redundant systems, such as monitoring the primary / backup communication link and automatically switching communication to the backup link when the primary link is disconnected, achieving rapid fault tolerance.

[0073] System Database and Logs: The system database stores configuration parameters, task schedules, and historical data logs. Configuration files define the parameters (rated lifting capacity, range of motion, control interface type, etc.) and shared memory allocation (memory address offset, etc.) for each gantry crane, and are loaded during system initialization. Task schedules can be read and executed by the scheduling module. During operation, key data (such as timestamped status snapshots, event records, and alarm information) are written to the log database for future analysis and optimization. The database module connects to shared memory in read-only mode or periodically copies data from shared memory to minimize interference with real-time control. Additionally, the database provides a human-machine interface, allowing maintenance personnel to view system operating status, adjust configurations, or replay historical records via a host computer for system debugging and training.

[0074] III. Event-driven and differential synchronization mechanisms

[0075] The data exchange in this system follows an event-driven principle, rather than a simple periodic broadcast. This means that the generation and propagation of data are triggered by state changes or task events.

[0076] Event Definitions: The system defines a series of collaborative operation events, such as "Start Synchronous Lifting," "Reach Target Height," "Pause and Wait," "Resume Operation," "Emergency Stop," and "Fault Occurrence / Recovery." In addition, certain state changes of each gantry crane are also considered events, such as "Height Change Exceeds Threshold," "Load Change Exceeds Threshold," and "Motion Completes a Stage." These events are represented in shared memory as flags or message queues, and each event contains an event type and associated parameters (such as the occurrence unit, timestamp, and relevant numerical values).

[0077] Event Triggering and Propagation: When an event occurs in the system, the relevant units immediately write the event information to shared memory. For example, when gantry crane A reaches a predetermined height, its CCU will write the "A_reached Height" event to memory. Shared memory uses a publish / subscribe mechanism; the central scheduling module and other CCUs subscribe to the event regions of interest, thus enabling them to capture the event immediately. In contrast, traditional polling methods may require waiting until the next cycle to detect a change in state, while event-driven mechanisms make the response nearly instantaneous.

[0078] Event Handling: The scheduling module makes corresponding decisions based on captured events: if all gantry cranes issue a "height reached" event, the next "synchronous translation" command is triggered; if the safety module issues an "overload" event, the scheduling module immediately issues an "emergency stop" command, etc. Each CCU can also respond to events directly locally, improving reliability. For example, when an "emergency stop" event flag is detected, power is immediately cut off without waiting for a central command. The event handling process needs to consider event priority: safety events have the highest priority, followed by scheduling command events, and then normal state events. When multiple events occur simultaneously, the system processes them sequentially according to priority to ensure that critical events are not delayed.

[0079] Differential Data Synchronization: For state data synchronization, this invention employs a differential update strategy, meaning updates are propagated only when data changes, and only the changed parts are propagated. Each CCU maintains a copy of the key variables from the previous cycle. The new value is written to the corresponding area of ​​shared memory only when the new value of the variable in the current cycle differs from the old value and exceeds a preset dead-zone threshold. If the change is minor (within the noise range), updates can be temporarily suspended to reduce invalid data transmission. On the other hand, the central scheduling module also uses a differential approach when issuing instructions—only updating the changed control parameters. For example, during synchronous lifting, the lifting speed instructions for all gantry cranes may be the same and remain constant. In this case, the scheduling module does not need to repeatedly write the same instruction every cycle; instead, it only needs to issue a "set uniform speed" instruction once at the beginning, and issue a new instruction only when a change is needed. Differential synchronization can significantly reduce data exchange volume, which is particularly effective when the shared memory bus is slow or there are many nodes, ensuring system real-time performance.

[0080] Heartbeat and Monitoring: While emphasizing event-driven operation, this system still uses low-frequency heartbeat messages to monitor communication and operational status. Each CCU and central module writes an incrementing counter or timestamp to the shared memory heartbeat area at a low frequency to indicate "I'm still alive." The security module uses this to monitor whether each unit is online: if a CCU's heartbeat times out and is not updated, the unit is considered faulty or communication is interrupted, and a fault event is immediately triggered so that the system can take measures (such as suspending related collaborative operations). The heartbeat mechanism ensures that even in a static, stable phase with fewer events, the system can detect node anomalies.

[0081] IV. Shared Memory Partitioning and Atomic Read / Write

[0082] Memory space partitioning: Shared memory is divided into multiple regions according to function (this can be done technically through address offsets or through a memory table structure):

[0083] Status area (each gantry crane's own sub-area): Used to store the current key status data of each gantry crane, such as position and attitude (hook height, span position), movement speed, acceleration, load weight, and working mode (manual / automatic). Each CCU has write permissions to its own status area and read permissions to other status areas. Through the status area, each gantry crane publishes its own status to the entire system in real time.

[0084] Command Area: This area is where the central dispatch module writes various control commands or target values. The command area can be further subdivided into multiple sub-segments. For example, each gantry crane has its own sub-segment to store direct commands for that crane (such as target height and speed curves), and a global command segment to store coordinated commands that require execution by all equipment (such as the "start lifting simultaneously" signal). Each CCU has read-only access to its own command sub-segment (written by the dispatch module), while the global command segment is read-only by all CCUs. Through the command area, the central dispatch module can broadcast control commands to any single crane or the entire system.

[0085] Event Area: Used for publishing and recording system events. A circular buffer or queue structure can be used to record event messages. When an event occurs, the event code, source, parameters, and other information are written. All units have write permissions (to publish their own events) and read permissions (to read events from others) to the event area. To prevent conflicts, a separate event queue can be set up for each type of event source, or a mutex lock can be used to control writing (see below). The event area can also contain a flag mapping for currently active events, used for quickly checking whether an event has occurred (e.g., the emergency stop flag is controlled by the security module).

[0086] Safety Zone: This zone is specifically designed for transmitting safety monitoring information, including settings for various safety parameters (such as maximum permissible deviation), as well as emergency braking signals and alarm codes issued by the safety module. The safety zone is typically written to by the safety module and read by other modules. Within the safety zone, critical emergency flags should be designed for unidirectional triggering (e.g., once set, they can only be reset by the safety module or manually) to prevent accidental alteration by other units.

[0087] Synchronization Lock Area: An auxiliary area used to implement concurrent access control, containing mutexes or semaphore variables. Since multiple units may simultaneously access certain sensitive areas of shared memory (especially event queues or global instructions), synchronization mechanisms are needed to avoid conflicts. The synchronization lock area can set several mutexes for different resources, such as event queue locks and global instruction locks. When a unit needs to write to the corresponding area, it must first acquire the lock, and then release it after completion. For real-time considerations, non-blocking methods, such as atomic test-and-set operations, can be used to implement locks. These lock variables themselves are stored in shared memory and atomic reads and writes are guaranteed using hardware bus locks or consistency protocols. An atomic read-write operation means that the read-modify-write operation is completed at the bus level in one step, and other processors do not see the intermediate state, thus ensuring data consistency.

[0088] Atomic operations ensure consistency: In a multi-machine concurrent environment, it is essential to avoid situations where individual units read partially updated data. This system ensures the atomicity and consistency of critical data reads and writes through the following measures:

[0089] Double-buffered updates: For complex multi-byte data structures (such as a state vector consisting of a set of positions and orientations), double-buffering is employed. The CCU first writes the new state to be published into its own state area's pre-buffer, and then atomically switches the pointer or flag to the new buffer, allowing other units to instantly see the complete new data. This avoids data tearing caused by writing and reading simultaneously.

[0090] Hardware-supported bus locking: When using shared memory across multiple boards, the bus controller provides bus locking and arbitration functions. When a processor is executing a specific atomic instruction (such as testing and setting a lock variable), it locks the bus to ensure that its read, modify, and write operations are not interrupted.

[0091] This system fully utilizes the characteristics of such hardware to achieve atomic updates of things like lock variables and counters. For example, when an event queue needs to be written, the CCU executes a bus-locked XADD instruction to modify the write pointer. Other processors cannot access this pointer variable until the bus lock is released, thus ensuring the correct update of the queue index.

[0092] Mutex Locks and Priority Inversion Handling: At the software level, mutex locks and semaphores are defined for serializing access to shared resources (as described above with event queue locks). To avoid priority inversion caused by high-priority tasks waiting for low-priority tasks, the system employs a priority inheritance protocol: when a low-priority CCU holds the lock and a high-priority central scheduling module requests the lock, the execution priority of the low-priority CCU is temporarily increased until it releases the lock. Since this system operates in a real-time environment, this mechanism ensures that high-priority scheduled tasks are not indefinitely delayed due to lock waiting.

[0093] Data verification and redundant storage: To further improve consistency and reliability, important data in shared memory employs redundant verification and backup storage. For example, each status data block is appended with a CRC checksum or version number, allowing the reader to verify data integrity. For critical control instructions, the scheduling module may write two copies to different memory addresses (primary and secondary). Each CCU cross-checks the two copies of the instruction for consistency; if they are inconsistent, execution is rejected and a fault is reported. The shared memory module itself can also maintain data mirroring at the underlying level, for example, using dual-port RAM or a multi-copy mechanism, to provide hardware-level fault tolerance for single points of failure.

[0094] V. Dispatch and Control Process

[0095] The scheduling and control flow of this system can be described using a state machine or flowchart. The stages from task start to task end are as follows (see the suggested scheduling flowchart):

[0096] Task Initialization: Operators issue collaborative hoisting task commands via the human-machine interface, specifying the participating gantry cranes and the target operation (e.g., jointly lifting a component and moving it to a designated location). The central dispatch module receives the task and reads the corresponding task configuration (including the division of labor and operating parameters of each gantry crane) from the database. The dispatch module writes the "task start" global command and initial preparation commands (e.g., "all gantry cranes raise their hooks to the standby height") into the shared memory instruction area.

[0097] Preparation Phase: After receiving the preparation command, each CCU begins its preparation actions, such as raising the hook to the specified initial height and adjusting its posture. During this period, each CCU continuously writes its own status to the status area. The scheduling module monitors the status of all CCUs. When it detects that all gantry cranes have reached the standby state (via status area data or a "ready" event triggered by a CCU), it writes a "preparation complete" event to the event area or updates a synchronization flag. Subsequently, the scheduling module issues the next phase of coordinated action commands.

[0098] Synchronous Lifting Phase: The scheduling module broadcasts a "Synchronous Lifting Start" command in the command area, including a unified lifting speed or the individual speed curves of each crane. All CCUs receive this command almost simultaneously and execute the lifting action. During this process, each CCU updates its own height and load information to the status area at a certain frequency (e.g., 50Hz), achieving mutually visible parallel closed-loop control: the controller of each gantry crane not only controls its speed based on its own sensor closed-loop control but can also refer to the height data of other gantry cranes to ensure relative synchronization. If it finds that its speed is slightly faster, resulting in a height lead, it can autonomously slow down slightly to wait; conversely, if it lags behind, it can slightly increase its speed, thus achieving fine synchronization without central intervention (this is the advantage of distributed collaborative control achieved by using shared memory to obtain the real-time status of other machines). At the same time, the scheduling module also checks the status of each machine at a lower frequency (e.g., 10Hz) and corrects macroscopic deviations (e.g., if a machine is consistently lagging too far behind, a command is issued for fine-tuning). This phase continues until it is detected that all gantry cranes have reached the target height or the lifting condition has been met. Then, each CCU issues a "Target Height Reached" event.

[0099] Attitude / Position Adjustment Phase: In many lifting operations, after the component is lifted into position, multiple cranes need to coordinate translation or fine-tune its attitude. For example, two gantry cranes may need to simultaneously move the component horizontally a certain distance, or one crane may need to be slightly higher and the other slightly lower to adjust the tilt angle before placing them together. Based on task requirements, the scheduling module, after capturing the "lifting complete" event, calculates the next action plan and issues corresponding instructions (e.g., "synchronously move 5 meters eastward" or "gantry crane A maintains its height, B lowers 0.5 meters for angle adjustment"). Each CCU executes its own instructions while simultaneously monitoring each other's status through shared memory to ensure coordinated actions. This phase may cycle through multiple sub-phases until the component is moved to the target position and its attitude meets the requirements.

[0100] Collaborative lowering and lowering phase: After the component is moved and aligned with the installation position, the scheduling module issues a "synchronized lowering and lowering" command, instructing each gantry crane to lower the load smoothly at a uniform speed or sequence. During this process, status synchronization monitoring continues to prevent tilting caused by one side lowering too quickly. Finally, once the load has landed or installation is complete, each CCU detects that the load weight has returned to zero, triggering a "lowering and lowering complete" event.

[0101] Final Phase: The scheduling module confirms task completion and writes a "task completed" flag to shared memory. Upon receiving this flag, each CCU exits collaborative mode and resumes its independent control state. The scheduling module aggregates all data from the database logs, generates a task report, and saves it. The system then enters an idle or standby state, awaiting the next task.

[0102] If an abnormal event occurs at any stage of the above process (such as a malfunction of a gantry crane, overload, or communication interruption), the process will enter a safety handling sub-process (see the next section), which may suspend the current task or renegotiate the action. The entire scheduling process relies heavily on the transparent, high-speed data exchange provided by shared memory, combining centralized coordination with decentralized autonomy to successfully complete complex multi-machine collaborative operations.

[0103] VI. Safety and Fault Tolerance Control Process

[0104] This invention prioritizes safety and incorporates a comprehensive fault-tolerant control process to handle exceptional situations. (See attached document.) Figure 3 .

[0105] Anomaly Detection: The safety monitoring module checks for the following possible anomalies in real time: overload (actual load at a lifting point exceeds the rated load), imbalance (excessive load difference between different gantry cranes or height difference exceeding limits), equipment failure (CCU heartbeat loss, motor drive alarm), communication failure (shared memory write timeout or data verification error), etc. Once any abnormal condition is met, the corresponding anomaly flag is immediately written to the safety area, and an "anomaly occurred" event can be generated in the event area for the system to record.

[0106] Emergency Braking: In the event of a serious safety threat (such as load imbalance posing a risk of tipping over, or the detection of a critical sensor failure), the safety module triggers the emergency braking procedure. It writes an "emergency stop" flag into the safety zone and cuts off the power output to all relevant gantry cranes via hardware circuitry, immediately halting their movement. Simultaneously, it issues an audible and visual alarm to notify on-site personnel. Since each CCU also detects the emergency stop flag, its software control assists in braking and enters a safe mode. Emergency stops are typically non-coordinated; each piece of equipment independently protects itself and its load.

[0107] Coordinated load reduction: Some anomalies (such as temporary communication interruptions) may not pose an immediate danger, but require the current lifting operation to be terminated as soon as possible to ensure safety. In such cases, the safety module or scheduling module initiates a coordinated load reduction process: issuing a global command to all gantry cranes to lower the load to the ground at a safe speed. If communication is still normal, each CCU coordinates the lowering and lowering according to the command; if the central communication is unreliable, each CCU also has a local strategy—such as automatically and slowly lowering the load if no new command is received within a timeout period (timeout protection logic). Coordinated load reduction ensures that risks are minimized in the event of control anomalies.

[0108] Fault Isolation and Redundancy Switching: When a unit fault is detected (e.g., the controller of gantry crane B crashes), the system isolates that unit from the collaborative task. The scheduling module ignores B's data and may replan whether the remaining gantry cranes can complete the handover task (if not, the task is stopped). Simultaneously, if a backup device is available, the backup gantry crane may take over part of the load. On the communication channel, this system deploys a redundant ring network or dual-channel shared memory: when the primary channel fails, the safety module drives all units to switch to the backup channel for communication; the switching time is in the millisecond range, with minimal impact on collaborative control. After redundancy switching is completed, the system clears the fault flag (if the faulty device has been removed or restored) and continues the task or prepares to terminate.

[0109] Recovery and Resynchronization: Some anomalies can be resolved, such as recovering from a momentary communication failure or completing the replacement of a non-critical sensor. In these cases, the system needs to ensure that all devices resynchronize their states after recovery. The process is as follows: pause the phased task, freeze the current state as a reference, and then, after the fault is resolved, each device resets / calibrates its state data. The scheduling module compares the states of each device to ensure there is no relative displacement or load change, then clears the pause flag and resumes the task. This "resynchronization" action is particularly important after a communication failure, ensuring that inconsistent states do not cause malfunctions when communication is restored.

[0110] Through the aforementioned safety and fault-tolerant processes, this system can cope with various abnormal situations, achieving rapid fault detection, safe shutdown / unloading, and redundancy switching, greatly improving the safety and reliability of multi-machine collaborative hoisting. Crucially, in emergency situations, the system prioritizes safety above all else, sacrificing task progress to ensure the safety of personnel and equipment; while in non-emergency faults, the system utilizes redundancy and adjustments to minimize or quickly restore collaborative operations. This flexible fault-tolerant design makes this invention more practical in engineering applications.

[0111] To fully evaluate the innovativeness of this invention, it is necessary to analyze other technical solutions that may achieve similar objectives and compare their shortcomings and limitations:

[0112] Industrial Ethernet + Centralized Control Scheme: An alternative approach is to use high-end industrial Ethernet (such as EtherCAT, ProfinetIRT) to build a centralized control system, in which the central PLC periodically obtains the status of each gantry crane through real-time Ethernet and issues control commands. Its advantage is that it utilizes mature bus technology and the system implementation is relatively simple. However, its limitations are: (1) Even with real-time Ethernet, the communication cycle is often in the millisecond range (typically 2-5ms). When there are multiple devices and a large amount of I / O data, the cycle needs to be extended to ensure bus stability, and real-time performance is limited; (2) The centralized architecture has poor scalability. Adding gantry cranes will significantly occupy bus bandwidth, and PLC performance will become a bottleneck; (3) The single point of failure problem still exists - the failure of the central PLC or bus master station will paralyze the entire system, and redundant configuration is costly; (4) The system is highly dependent on the network, the wiring is complex and the distance is limited (hundreds of meters, requiring the addition of switching equipment). In contrast, the shared memory architecture of this invention uses event-driven instead of fixed-cycle, avoids invalid bandwidth occupation, and reduces the central pressure through distributed control, making it superior in terms of overall reliability and real-time performance.

[0113] Wireless Mesh Network Collaboration Solution: Another alternative is to use an industrial wireless network to connect multiple gantry cranes, making them form a wireless mesh network in a shared state, and then each of them synchronizes its actions according to a consensus algorithm. The advantage is that the deployment is flexible, especially suitable for scenarios where gantry cranes are far apart or move frequently, without the need to lay cables. There are also wireless synchronous remote control systems for multiple cranes on the market. However, the main shortcomings of the wireless solution are: (1) the wireless channel has low reliability and is easily affected by interference and obstruction, packet loss and delay are unavoidable, and the risk is high in critical hoisting; (2) the bandwidth is limited, and it is difficult for general industrial wireless to carry large amounts of high-speed exchange, and the synchronization accuracy and real-time performance of multiple machines are difficult to match that of wired; (3) network security issues, the signal may be intercepted or interfered with, and additional encryption and anti-interference measures are required. In general, wireless mesh is suitable for auxiliary and non-critical occasions, and there are still technical obstacles to achieving the stringent collaboration requirements of this invention. Although this invention can also combine wireless as an alternative channel, the core still relies on high-speed wired shared memory, and the overall performance is more stable.

[0114] Multi-sensor autonomous synchronization scheme: This approach assumes that each gantry crane does not communicate directly, but achieves synchronization by sharing external identifiers or environmental cues. For example, sensors installed on the load (such as laser rangefinders and gyroscopes) provide relative position and attitude information of multiple gantry cranes. Each gantry crane reads these sensor data and adjusts its movements to maintain consistency; or a vision measurement system is used to capture the attitude of the load, allowing each gantry crane to synchronize based on visual feedback. The advantage of this scheme is low coupling: there is no need for wired communication between gantry cranes, as long as they can all observe the state of the load. Its disadvantages are also obvious: (1) it is highly dependent on external sensors, and slight changes in the environment (smoke, rain, fog, poor lighting) may cause large measurement errors or failure; (2) the control response is indirect and delayed, because the information flow from the load to the sensor and then to the controller is longer than direct communication; (3) the accuracy is limited. When high-precision synchronization of the movement of multiple devices is required, the vision / laser scheme is difficult to achieve the synchronization accuracy of electrical hard connection. Overall, this autonomous synchronization is more suitable for simple collaboration or as a safety aid (collision avoidance) and is not suitable for the main synchronization control task.

[0115] Hard-wired master-slave configuration: Another traditional approach involves hard-wired control signals from one gantry crane to the other when two gantry cranes are operating in tandem, achieving simple master-slave control (e.g., simultaneously sending the speed command from the master crane to the slave crane). This method effectively treats the two machines as a single unit, offering advantages such as simplicity and good synchronization (due to physically identical signals). However, it lacks flexibility: it only allows for a fixed pairing of two cranes with similar performance; it cannot be extended to three or more cranes operating in tandem; and errors in master crane control can still affect the entire system. Furthermore, hard-wired connections bypass the slave crane's own protection logic, posing safety risks (e.g., the master crane continues lifting while the slave crane may already be overloaded). Therefore, this approach has limited application, currently used more for temporary coordination of two small cranes lifting light loads, and is unsuitable for complex scenarios. This invention, however, implements flexible master-slave or multi-master relationships through software logic, allowing for the designation of any number of cranes for coordination as needed, without bypassing the individual cranes' own protection mechanisms, resulting in higher security.

[0116] In summary, although various alternative solutions exist to achieve multi-machine collaborative control, they all have shortcomings to varying degrees under the comprehensive requirements of real-time synchronization, flexible expansion, and security fault tolerance. Industrial Ethernet centralized control is inferior to this invention in terms of real-time performance and fault tolerance; wireless mesh is limited by reliability; autonomous solutions relying on external sensors suffer from accuracy lag; and hard-wired master-slave connections lack universality and intelligent scheduling capabilities. Therefore, the shared memory real-time data exchange system proposed in this invention outperforms the aforementioned alternative solutions in overall technical performance, exhibiting greater applicability and innovation.

[0117] Therefore, this invention employs a shared memory solution, which offers comprehensive advantages in terms of real-time performance, accuracy, and cost, making it more suitable for the collaborative operation needs of multiple gantry cranes. Furthermore, this invention, through modular design and advanced data fusion algorithms, further enhances the system's intelligence and adaptability, ensuring efficient operation and safety under complex working conditions.

[0118] The modules in this system interact through shared memory and signal interfaces, but function or message interfaces also exist in the software implementation:

[0119] The gantry crane control unit (CCU) software provides a drive interface (for communicating with the underlying motor drive), a sensor interface (for reading encoder, torque, etc.), a MemoryAPI interface (a function library for reading and writing shared memory), and a SafetyAPI interface (for monitoring emergency stop inputs, etc.). For example, MemoryAPI.write(stateOffset, dataStruct) writes the state data structure to the corresponding offset in shared memory; SafetyAPI.checkEmergencyStop() queries the status of the local emergency stop button.

[0120] The central scheduling module provides the TaskAPI for receiving task instructions (e.g., TaskAPI.startTask(taskConfig) to start a task), the PlanAPI for planning routes and speeds (which can interface with third-party hoisting route planning software), the MemBroadcast interface for writing commands to the instruction area to broadcast commands, and the EventHandler callback mechanism for handling event area messages. For example, when the "CraneA_Ready" event occurs in the event area, the registered onCraneReady("A") function will be called.

[0121] The safety monitoring module primarily interacts through hardware I / O and the Memory API. It has a SensorMonitor thread that reads safety-related sensors, a HeartbeatMonitor thread that checks heartbeat counts, and an EmergencyTrigger routine that writes emergency flags and triggers hardware via the Memory API. Interfaces such as MemoryAPI.setBit(safetyOffset, EMERGENCY_STOP_BIT) are used to set the emergency stop flag in the safety zone; HardwareIO.cutOffPower(craneId) directly cuts off the power circuit to a specific gantry crane.

[0122] The system database / log module provides the LogWriter interface for other modules to call. For example, when the scheduling module issues a command, it can call LogWriter.recordEvent("CMD",craneId,commandDetails) to record a command log; when the security module detects an overload, it records an alarm event using LogWriter.recordEvent("ALERT",craneId,"Overload"). The database also provides a QueryAPI for operations and maintenance personnel to query historical data, or to display the current status through a UI interface (the UI thread periodically reads the status from the MemoryAPI and updates the interface).

[0123] Testing and verification: This invention has undergone thorough testing in laboratory and simulated field environments:

[0124] In a laboratory environment, the prototype control of this system was deployed using two small gantry crane models (1:10 scale, maximum load 100kg). Synchronous lifting, synchronous movement, and synchronous lowering were tested. Results showed that when lifting a 50kg beam to a height of 2m, the height difference between the two cranes remained within 2cm, essentially achieving synchronization. When one crane intentionally slowed down to simulate lag, the other crane detected and waited, achieving resynchronization. When a 10% sudden load disturbance was applied, the two cranes adjusted to a new equilibrium in less than 0.2 seconds by sharing data. Communication latency tests showed that the average time to transmit 8 bytes of status data via the reflective memory bus was less than 50 microseconds, significantly better than the millisecond-level latency of TCP / IP under the same conditions.

[0125] In a simulation environment, a virtual model of three gantry cranes collaboratively lifting a bridge section was built (using MATLAB / Simulink and Unity3D). During the simulation, the system coordinated the three gantry cranes to lift and move a 20-ton, 30-meter-long bridge steel truss for installation. Results showed that good synchronization and balance were maintained regardless of whether lifting was done simultaneously or with one end lifted as an auxiliary. In one simulation scenario, a two-second communication interruption was intentionally introduced for one gantry crane. The system detected this and automatically directed the other two cranes to slowly lower their loads, preventing instability. After communication was restored, the operation successfully resumed through a resynchronization process. This verified the system's stability and fault tolerance in more complex multi-crane (three-crane) scenarios.

[0126] The safety function tests included: overload protection test (gradually increasing the load until it exceeded the threshold, observing whether the system would promptly alarm and stop lifting), emergency stop response test (manually pressing the emergency stop switch, measuring the time required for all gantry cranes to come to a complete stop; the average result was <100ms), and heartbeat loss test (disconnecting one controller from the network, observing how quickly the system detected and acted; the result was <250ms for fault isolation to be triggered). All test results indicate that the system's safety monitoring mechanism is functioning normally and has met design expectations.

[0127] Code Functional Structure Overview: The software framework of this invention can be represented by a simplified architecture diagram, which consists of the following main parts:

[0128] The lowest layer, DriverLayer, encapsulates various hardware interfaces, such as motor drivers, I / O boards, and reflective memory card drivers. This layer provides a unified API to the upper layers, such as MotorControl.setSpeed(craneId, value), and internally controls specific motors via CAN bus or PWM signals.

[0129] Operating System and Middleware Layer: Each control unit runs a real-time operating system (such as VxWorks, RTX, FreeRTOS, or real-time Linux), providing task scheduling and synchronization mechanisms. This system may use real-time middleware (such as ACE, DDS, or a custom shared memory library) to manage cross-node communication. For example, using DDS (Data Distribution Service) configured in shared memory transfer mode simplifies data publish-subscribe programming.

[0130] Collaborative Control Core Layer: This is the core software layer of this invention, including SharedMemoryManager (managing shared memory read / write and mutual exclusion locking), SyncController (implementing event-driven and differential synchronization logic), Scheduler (implementing the central scheduling module), LocalController (local control logic for each CCU), and SafetyManager (safety monitoring and processing logic). These core modules collaborate through message queues or direct function calls. For example, the Scheduler calls SharedMemoryManager to obtain all status data and calculate the schedule; the LocalController is driven by SyncController and adjusts local motion control according to shared memory instructions, etc.

[0131] Application and Interface Layer: This layer includes auxiliary modules such as UserInterface (displays status and receives manual commands), Logger (records logs), and Configuration (loads configuration at startup). This layer makes the system easy to interact with and maintain, but it does not participate in the real-time control loop and typically runs on a low-priority thread.

[0132] The code structure employs a modular design, with modules isolated from each other and communicating through explicit interfaces, facilitating future maintenance and upgrades. For example, if the communication medium needs to be replaced, only the SharedMemoryManager module needs to be modified to adapt to the new driver, without affecting other control logic. The source code adheres to MISRAC / C++ and other safe programming standards, and watchdog protection is added to critical paths to ensure reliable operation.

[0133] While the above supplementary materials are not within the scope of patent protection, they are helpful for understanding and implementing this invention. The configuration examples and interface descriptions demonstrate the flexibility and compatibility of this system; test data proves the effectiveness of this solution; and the code structure demonstrates the feasibility of its implementation. It is believed that these detailed technical disclosures will provide sufficient support for the implementation and review of this invention.

[0134] Through the detailed technical disclosure above, this invention fully demonstrates an innovative solution for achieving efficient data scheduling and precise angle calculation in the collaborative operation of multiple gantry cranes, possessing significant practical value and promotional significance. Combined with the efficient data scheduling mechanism, multi-sensor data fusion, and stringent safety measures proposed in this paper, this invention not only solves key problems in existing technologies but also lays a solid foundation for future intelligent and networked gantry crane systems.

[0135] In summary, the multi-machine collaborative real-time data exchange system of the present invention demonstrates significant technical advantages in the following aspects:

[0136] Significantly improved real-time performance: Through a shared memory architecture and event-driven differential synchronization, this system reduces data transmission latency between multiple gantry cranes to milliseconds or even sub-milliseconds, far superior to traditional network communication solutions. Changes in the status of each gantry crane can be instantly communicated to its counterparts, achieving synchronized actions. This highly real-time communication lays the foundation for precise collaborative control. In scenarios requiring precise synchronization, such as the lifting of large components, this invention ensures minimal synchronization errors, improving operational quality and safety.

[0137] Enhanced reliability and safety: This system employs redundant communication and fault-tolerant design, coupled with comprehensive safety monitoring strategies, greatly enhancing its resilience against failures. When one communication path fails, the backup path seamlessly takes over; in the event of a single device failure, the system quickly isolates the faulty device and directs the remaining devices to maintain or reduce their load, preventing accidents. In contrast, a failure of a traditional centralized control center can paralyze the entire system. This invention's safety module monitors key parameters in real time, enabling proactive intervention at the first sign of danger, preventing accidents before they occur. Since continuous monitoring and timely adjustments during collaborative hoisting are crucial for safety, this invention elevates safety to a new level through real-time monitoring and rapid response.

[0138] Improved Collaborative Efficiency: By combining central dispatch for global optimization with local autonomous responses from individual units, this system enables multiple gantry cranes to work smoothly like a team, reducing unnecessary waiting and repeated adjustments. For example, during the synchronous lifting phase, because each crane shares its status and coordinates automatically, the load can often be lifted into position in one go, eliminating the need for multiple trial lifts and leveling as required by manual coordination. This significantly improves operational efficiency. It is estimated that in the installation of certain large components, using this system can reduce the coordination time between two gantry cranes by more than 20% (compared to traditional manual signal coordination methods), saving valuable construction time.

[0139] It boasts significant comprehensive benefits: This solution demonstrates a higher return on investment from a full lifecycle perspective. Firstly, through its modular design, the system supports upgrades to existing equipment by adding interface cards and software, avoiding the high initial investment associated with complete replacement and resolving incompatibility issues between different manufacturers' equipment. Secondly, by significantly improving collaborative work efficiency, shortening project timelines, and effectively reducing the risk of safety incidents due to synchronization errors, it significantly reduces long-term operating, labor, insurance, and maintenance costs.

[0140] Flexible system expansion and deployment: The modular architecture makes this system applicable to multi-machine collaboration of different scales and types. Whether it's two gantry cranes working together to move containers in a port, or three crawler cranes working together to lift bridge sections in bridge construction, this invention can be put into use simply by adding or removing control units and adjusting memory partition configurations as needed. For industries such as wind power and shipbuilding, the system supports hybrid wired or wireless networking, adapting to actual on-site environments (for example, in wind power construction, one gantry crane is on land and another is on a barge, sharing memory data via a wireless link). This flexibility and scalability are difficult to achieve with traditional fixed-architecture systems, meaning this invention has broad industry applicability and promotional value.

[0141] The intelligent potential brought by real-time data sharing: Since the status of all devices is aggregated in shared memory, it is easy to further integrate with AI decision-making or intelligent monitoring systems to achieve a higher level of optimization. For example, machine learning algorithms can be run on the central scheduling module to optimize movement trajectories or predict dangerous trends using real-time big data; data can also be shared with a digital twin system to simulate the current hoisting process in real time and provide auxiliary suggestions. These are inherent data and architectural advantages of this system, making it not only a solution for current collaborative control but also laying the foundation for future intelligent gantry crane group control.

[0142] In summary, this invention surpasses existing technologies in terms of real-time performance, reliability, efficiency, cost, and flexibility, representing a significant advancement in multi-machine collaborative hoisting within the engineering machinery field. Particularly in the context of increasingly stringent safety and real-time requirements, this invention provides a practical, cost-effective, and efficient solution with high engineering application value and market competitiveness.

[0143] The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments have been described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification. Although the present invention has been shown and described with reference to specific preferred embodiments, it should not be construed as limiting the invention itself. Various changes in form and detail may be made without departing from the spirit and scope of the invention as defined in the appended claims.

Claims

1. A real-time data exchange system for collaborative operations of multiple gantry cranes in a coordinated lifting scenario, characterized in that, include: Multiple gantry crane control units, one for each gantry crane, are used to control the machine to perform lifting actions, write their real-time status to a shared memory module, and read instructions and status information from other units in the shared memory module to achieve distributed autonomous fine-tuning; The shared memory module, as the core of data exchange, is divided into a status area, an instruction area, an event area, and a security area. Each area has controlled read and write permissions, supports real-time data exchange between units, and uses an atomic read and write mechanism to ensure data consistency. The central dispatch and control module is used to receive collaborative hoisting tasks, plan collaborative strategies, issue instructions to each gantry crane control unit through the shared memory module, and monitor the global status to achieve centralized dispatch. The safety monitoring module is used to monitor the system's operating status in real time, detect anomalies, set alarm flags in the safety area of ​​the shared memory module, and trigger safety fault tolerance processes, including emergency braking, coordinated load reduction, and fault isolation and redundancy switching. The system database stores configuration files, task data, and runtime logs, allowing various modules to read configurations and write logs.

2. The collaborative real-time data exchange system according to claim 1, characterized in that, The shared memory module is implemented using a physical shared storage device or through high-speed network simulation. In terms of hardware, a high-speed backplane bus or fiber optic ring network with DMA and bus arbitration functions is selected to ensure bus fairness and low latency when multiple nodes access the memory in parallel. The shared memory module adopts a differential data synchronization strategy. Each gantry crane control unit writes the new value into the status area of ​​the shared memory only when the difference between the new and old values ​​of its own key variables exceeds a preset dead zone threshold.

3. The collaborative real-time data exchange system according to claim 1, characterized in that, The atomic read / write mechanism includes double-buffered updates, hardware-supported bus locks and mutexes, and a priority inheritance protocol. Double-buffered updates are used to avoid read / write conflicts in multi-byte data structures, bus locks ensure that the execution of atomic instructions is not interrupted, and the priority inheritance protocol is used to avoid priority inversion.

4. The collaborative real-time data exchange system according to claim 1, characterized in that, The safety monitoring module includes a safety sensor input acquisition unit, a heartbeat monitoring unit, and an emergency triggering unit. The safety sensor input acquisition unit is used to acquire data from torque sensors, tilt sensors, and anemometers. The heartbeat monitoring unit is used to check the heartbeat count of each unit. The emergency triggering unit is used to write emergency flags and trigger hardware braking.

5. The collaborative real-time data exchange system according to claim 1, characterized in that, The central dispatch and control module can be served by an independent industrial computer or the control unit of a gantry crane. In the event of failure of the central module, each gantry crane control unit can maintain a safe state according to the last instruction or contingency plan.

6. The collaborative real-time data exchange system according to claim 1, characterized in that, It also includes redundant communication channels. When the main channel fails, the safety monitoring module drives all units to switch to the backup channel for communication, with the switching time in milliseconds.

7. A method for real-time data exchange in collaborative lifting scenarios involving multiple gantry cranes, implemented based on the real-time data exchange system for collaborative operations as described in any one of claims 1 to 6, characterized in that, include: S1. Each gantry crane control unit, central dispatch control module, and safety monitoring module performs a power-on self-test, loads configuration files from the system database, initializes shared memory and divides it into status area, instruction area, event area, and safety area, establishes a communication link and completes clock synchronization, and enters standby state. S2. The central dispatch and control module receives the collaborative hoisting task, plans the collaborative strategy, and sends it to each gantry crane control unit through the shared memory instruction area. After reading the instruction, each gantry crane control unit executes the preparatory action and writes the real-time status into the shared memory status area. After the central dispatch and control module confirms that all units are ready, it issues a global collaborative instruction. Each gantry crane control unit reads the instruction and executes the collaborative action. At the same time, it performs distributed autonomous fine-tuning based on the global real-time status in the shared memory to keep the actions synchronized. S3, the safety monitoring module monitors key data in shared memory in real time. If an anomaly is detected, an alarm flag is set in the safety zone and a safety fault tolerance process is triggered, including emergency braking, coordinated load reduction, fault isolation and redundancy switching. S4. When the hoisting task is completed, each gantry crane control unit publishes a "task completed" event in the shared memory event area. After confirmation by the central dispatch control module, the data is summarized and a report is generated, and the system is reset to standby state.

8. The method for real-time data exchange in collaborative operations according to claim 7, characterized in that, In step S1, the initialization of shared memory includes setting the access permissions of each module to different areas, the establishment of communication links includes testing of primary and backup links, and clock synchronization is achieved using a precise time protocol. In step S2, the collaborative strategy includes load distribution, motion trajectory, and synchronous control parameters for each machine; distributed autonomous fine-tuning refers to the autonomous adjustment of the control quantity of the actuator to eliminate the deviation when a gantry crane control unit detects that the deviation between its own motion state and the collaborative target or the state of other units exceeds a preset threshold. In step S3, emergency braking includes the safety module cutting off the power output of all gantry cranes through hardware circuitry, and each gantry crane control unit assisting in braking and entering a safe mode after hearing the "emergency stop" sign; coordinated load reduction refers to each gantry crane control unit lowering the load to the ground at a safe speed according to instructions or local strategies in the event of a temporary communication interruption; the fault isolation and redundancy switching includes isolating the faulty unit from the coordinated task, the central dispatch control module replanning the tasks of the remaining units, and if there is a backup device, the backup gantry crane taking over part of the load.

9. The collaborative real-time data exchange method according to claim 7, characterized in that, The events include safety events, dispatch instruction events, and normal status events, which are processed in order of priority. Safety events are initiated by the safety monitoring module or the gantry crane control unit, dispatch instruction events are initiated by the central dispatch control module, and normal status events are initiated by the gantry crane control unit. During the execution of the task, the central dispatch and control module monitors the global synchronization status at a frequency lower than the preset target, while each gantry crane control unit updates its own status at a frequency higher than the preset target and achieves local autonomous coordination, forming a control mode that combines centralized dispatch and distributed autonomy.

10. The collaborative real-time data exchange method according to claim 7, characterized in that, When an event occurs, the gantry crane control unit or safety monitoring module that detects the event writes the event information into the event area of ​​shared memory; the central dispatch control module and other gantry crane control units capture the event and respond through a publish / subscribe mechanism; the status data synchronization adopts a differential update strategy, propagating the changed part only when the data change exceeds the preset dead zone threshold.

Images