A bridge crane container ship gantry crane dynamic joint scheduling device and method based on hybrid space-time network prediction

Abstract

The application discloses a bridge crane container ship gantry crane dynamic joint scheduling device and method based on mixed space-time network prediction, which comprises a data access unit, a tensor calculation unit, a joint solving unit, a shadow checking unit and a learning updating unit, characterized in that: the data access unit writes basic data into a unified memory structure; the tensor calculation unit establishes a ship cabin grid tensor, a stack area berth tensor and a road section tensor and splices them into a demand tensor; the joint solving unit takes the demand tensor as input and then outputs a distribution scheme; the shadow checking unit runs the distribution scheme according to multiple groups of time intervals, and writes abnormal records into the learning updating unit; and the learning updating unit compares the shadow queue with an actual execution deviation, updates a convolution kernel weight, regenerates a weight file and completes self-evolution.

Description

Technical Field

[0001] This invention relates to the field of dynamic joint scheduling technology for bridge cranes, container trucks, and gantry cranes, specifically a dynamic joint scheduling device and method for bridge cranes, container trucks, and gantry cranes based on hybrid spatiotemporal network prediction. Background Technology

[0002] While container terminals already boast a high level of automation for individual machines, current technologies still rely on a scheduling model based on "human experience and single-equipment optimization." This results in a lack of real-time global coordination among quay cranes, trucks, and gantry cranes, leaving quay cranes idle. Manual instruction sequencing cannot dynamically respond to random disturbances such as ship stability, container turnover in the stacking area, and peak traffic for external trucks, leading to longer berthing times for ships compared to advanced international terminals. Furthermore, one-time fixed sequencing algorithms lack a self-evolution mechanism and cannot adaptively adjust to changes in operational processes, such as layer-by-layer loading, loading on-demand, or barge-on-demand loading. In abnormal operating conditions, such as equipment offline, road closures, or occupied container spaces, there is a lack of online backtracking paths, necessitating full manual takeover and interrupting the automated process.

[0003] The existing technology uses the following steps to solve the above-mentioned technical problems: Step 1, the operation sequence of the gantry cranes is manually determined. The central control operator determines the loading and unloading sequence of the compartments based on the ship's plans and experience. Once fixed, it is not dynamically adjusted. Step 2, static task balancing - the fixed sequence of tasks is evenly distributed to each gantry crane according to the quantity, ensuring that "there is a task at all times". Step 3, sequential equipment matching - first, tasks are assigned to the gantry cranes, then the nearest available truck is found for the task, and finally the yard foreman verbally arranges the gantry cranes. There is no global timeline. Step 4, manual takeover in case of abnormalities - in case of equipment failure or container position conflict, the manual mode is switched immediately. The original algorithm has no backtracking path.

[0004] This scheme only considers the balance of the number of tasks, does not introduce time prediction, cannot minimize the idle time of the cranes, and cannot adapt to process switching and random disturbances online. Summary of the Invention

[0005] The technical problem to be solved by the present invention is to provide a dynamic joint scheduling device and method for bridge cranes, container trucks and gantry cranes based on hybrid spatiotemporal network prediction. Based on second-level perception, it completes global joint decision-making in second-level cycle, continuously compresses the idle time of bridge cranes, realizes zero-wait continuous operation, and has the ability to self-heal and adapt to processes.

[0006] This invention is achieved through the following technical solution: A dynamic joint scheduling device for bridge cranes, container trucks, and gantry cranes based on hybrid spatiotemporal network prediction, comprising a data access unit, a tensor calculation unit, a joint solution unit, a shadow verification unit, and a learning and updating unit. The data access unit writes basic data into a unified memory structure. The tensor calculation unit establishes ship compartment tensors, stacking area bay position tensors, and road segment tensors. The tensor calculation unit extracts tensors and concatenates them into a demand tensor. The joint solution unit takes the demand tensor as input and outputs an allocation scheme. The shadow verification unit runs the allocation scheme on a rolling basis according to multiple time intervals and writes abnormal records into the learning and updating unit. The learning and updating unit compares the shadow queue with the actual execution deviation, updates the convolution kernel weights, regenerates the weight file, and completes self-evolution.

[0007] A further technical solution is that the algorithm for the tensor computation unit to extract tensors includes a first algorithm, which extracts the spatiotemporal features of the tensor and outputs a prediction vector, which is then concatenated to form the required tensor. The first algorithm includes a causal convolutional network and a Transformer self-attention mechanism.

[0008] A further technical solution involves using a causal convolutional network as the first algorithm to extract spatiotemporal features through sliding convolution on tensors.

[0009] A further technical solution involves using positional encoding and multi-head attention to extract spatiotemporal features when the first algorithm is a Transformer self-attention mechanism.

[0010] In a further technical solution, the data access unit, tensor calculation unit, joint solution unit, shadow verification unit, and learning update unit share the CPU, memory, and network with the container terminal production operating system, and they communicate with each other via memory tensors without an external bus.

[0011] Further technical solutions require basic data including ship hull location maps, container distribution maps, and electronic fence adjacency lists.

[0012] In a further technical solution, the joint solving unit takes the demand tensor as input, establishes a four-term weighted sum objective function, and uses a second algorithm to iterate and then solve for the output allocation scheme.

[0013] A further technical solution is that the second algorithm includes an adaptive metaheuristic algorithm, ILP, and branch and bound algorithms. When using ILP and branch and bound algorithms, if a timeout occurs, it automatically reverts to the adaptive metaheuristic algorithm.

[0014] Further technical solutions and allocation schemes include activating an ordered task list, a truck and task matching table, and a gantry crane operation sequence.

[0015] In a further technical solution, the shadow verification unit includes a detection module. The detection module pulls the latest equipment status tensor. If it finds that the equipment is offline, the road is blocked, or the container space is occupied, it immediately triggers an abnormal rollback. Then, the crane task balancing strategy is selected, recalculated, and distributed. The above process is then executed in a rolling manner, and the abnormal record is written into the learning update unit.

[0016] A further technical solution involves a shadow queue running by the shadow verification unit, which includes a memory table and an appended blockchain log. When using the appended blockchain log, if the verification fails, the pointer is moved forward to prevent data from being tampered with.

[0017] A further technical solution is that the learning and updating unit starts self-evolution during idle time, such as 00:30 every day. The learning and updating unit pulls the shadow queue of the previous 24 hours and the actual execution deviation, updates the convolution kernel weights with mini-batch gradient descent; generates a new weight file and hot-loads it to the online engine; and then completes self-evolution, which takes effect directly during the morning peak the next day.

[0018] A dynamic joint scheduling device and method for bridge cranes, container trucks, and gantry cranes based on hybrid spatiotemporal network prediction includes:

[0019] Step 1: Input real-time data into tables, establish ship compartment tensors, storage area bay position tensors, and road segment tensors, and align their timestamps to milliseconds to form the same moment;

[0020] Step 2: Hybrid spatiotemporal network prediction. A causal convolutional network is used to slide over the three tensors from Step 1 to extract spatiotemporal features. Three prediction vectors are output: cabin vector, container retrieval vector, and road segment vector. The three vectors are concatenated into a demand tensor, which serves as the sole input for subsequent solutions.

[0021] Step 3, Sub-steps and Technical Implementation: 3.1 Crane Capacity Calculation: Read the demand tensor bay vector and calculate the maximum number of tasks that can be activated for each crane in this round; 3.2 Container Candidate Screening: Remove suspended containers, isolated containers, and containers with unloaded outer sections from the bay space tensor to generate a candidate container list; 3.3 Determining the Number of Activated Cranes: Take the minimum value between the capacity in 3.1 and the number of candidates in 3.2 to obtain the total number of activated tasks in this round; 3.4 Joint Solution: Using the demand tensor as input, establish a four-term weighted sum objective function and solve for the following outputs: an ordered list of activated tasks, a truck-task matching table, and the gantry crane operation sequence.

[0022] Step 4, Shadow Queue Verification and Abnormal Rollback: First, the joint solution is completed at t0. When t0+t1s, the result is written to the shadow queue. When t0+t2, the result detection module pulls the latest equipment status tensor. When t0+t3, if equipment is found to be offline, road is blocked, or container space is occupied, abnormal rollback is immediately triggered. When t0+t4, the alternative crane task balancing strategy is recalculated and distributed. When t0+t5, the next round of rolling begins.

[0023] Step 5: Daily self-evolution. At T1 each day, the system automatically pulls the shadow queue of the previous 24 hours and the deviation from the actual execution. At T2, the convolution kernel weights are updated using mini-batch gradient descent. At T3, a new weight file is generated. At T4, it is hot-loaded to the online engine. At T5, self-evolution is completed, and it takes effect directly at T6.

[0024] In a further technical solution, in step one, the ship compartment tensor is a two-dimensional table, where rows represent compartment numbers, columns represent layer numbers, and cell values ​​represent container number, weight, dimensions, and port of destination; the storage area bay position tensor is a three-dimensional table, where rows represent bay positions, columns represent column numbers, depth represents layer numbers, and cell values ​​represent container number, status, and number of times containers have been turned over; the road segment tensor is a one-dimensional table, where the index represents the electronic fence ID, and the value represents the current average vehicle speed, length, and direction.

[0025] In a further technical solution, in step two, the following parameters are defined: Cabin vector: element = cabin ID, value = activation probability (0-1); Container retrieval vector: element = bay coordinate, value = container retrieval cost (seconds); Road segment vector: element = fence ID, value = estimated passage time (seconds).

[0026] In a further technical solution, in step three, the idle time of the gantry crane is equal to the sum of the arrival intervals of adjacent tasks; the waiting time of the truck is equal to the sum of the differences between the arrival time and the start time of the task; the number of stacking areas without gantry cranes is equal to the count of active tasks falling into the stacking area without RTG; the stacking area balance is equal to the standard deviation / mean of the task count; an adaptive metaheuristic algorithm is used to solve the problem with an upper limit of 500 iterations and a time limit of 2 seconds.

[0027] In a further technical solution, in step four, t1=50ms, t2=100ms, t3=200ms, t4=500ms, and t5=2s.

[0028] In a further technical solution, in step five, T1 is 00:30 daily, T2 is 00:35 daily, T3 is 00:45 daily, T4 is 00:50 daily, T5 is 01:00 daily, and T6 is the morning peak of the next day.

[0029] A further technical solution involves step five, using mini-batch gradient descent with a learning rate of 0.001 and a batch size of 256.

[0030] The beneficial effects of this invention are as follows: First, because this invention embeds time prediction into the "demand tensor" and completes the four-step joint solution within 2 seconds, the gantry crane no longer relies on static order waiting for containers, the measured idle rate is reduced from 12% to 4%, and the ship berthing time is correspondingly shortened by 10%, directly achieving the invention's purpose. Second, shadow queues and abnormal rollback reduce the risk of "unexecutability" to automatic switching within 500 milliseconds, and the production process is no longer forced to be manually taken over due to occasional disturbances, meeting the invention's purpose. Third, daily online learning continuously fine-tunes weights, and process mode switching does not require manual code modification. The single-ship operation efficiency remains above 27.5 TEUs / hour in all three modes: layer-by-layer, on-the-fly loading, and barge on-the-fly loading, continuously verifying the invention's purpose. Fourth, this invention uses a combination of real-time data, short-term prediction, and closed-loop verification to transform the originally discrete, static, and easily interrupted terminal scheduling into a continuous, dynamic, and evolvable automated process, achieving a global efficiency improvement without adding any new hardware.

[0031] Second, the hybrid spatiotemporal network prediction mechanism transforms the ship location map, container distribution map, and electronic fence adjacency list into a "demand tensor". The causal convolutional network outputs a prediction vector of "activatable compartment - container retrieval sequence - route travel time" for the next 10 minutes at once, which serves as the sole input for subsequent joint solutions, replacing the static manual sequence.

[0032] The third and fourth steps are strictly serial and globally joint solutions: crane capacity → container candidates → number of activations → joint solution. The input for each step is only the output tensor of the previous step, and there is no cross-layer call to external interfaces. The objective function is weighted and minimizes "cable crane idle + truck waiting + number of RTG-less stacking areas + stacking area imbalance", and the solution is completed within 2 seconds.

[0033] III. Shadow Queue - Result Detection - Anomaly Rollback Closed Loop: The solution result is first written to the memory shadow queue, and the executability is verified using the latest field status tensor. If the verification fails, the system automatically rolls back to the alternative "bridge crane task balancing strategy" and reissues it within 500ms to ensure continuous and uninterrupted production.

[0034] Fourth, daily online self-evolution: using the shadow queue of the previous 24 hours and the actual deviation at midnight every day, the prediction model weights are updated by small-batch gradient descent, and hot-loaded before the peak the next morning, to achieve zero-code, zero-downtime adaptive switching of processes (by layer / as-installed / as-installed on barges).

[0035] V. Tensor-Table Driven Hardware Device: Composed of five units: “Data Access, Tensor Calculation, Joint Solving, Shadow Verification, and Learning Update”, it shares CPU / memory / network with n-TOS (Container Terminal Production Operating System), without adding any new hardware, ensuring “ready to use upon delivery and upgrades without disrupting production”. Attached Figure Description

[0036] For ease of explanation, the present invention will be described in detail below with reference to specific embodiments and accompanying drawings.

[0037] Figure 1 This is an overall process overview diagram of the present invention;

[0038] Figure 2 This is a flowchart for the joint solution process. Detailed Implementation

[0039] like Figures 1-2 As shown, the present invention will be described in detail. For ease of description, the directions mentioned below are defined as follows: the directions of up, down, left, right, front, and back mentioned below are the same as... Figure 1 The projection relationships are consistent in all directions (up, down, left, right, front, back). This invention provides a dynamic joint scheduling device and method for bridge cranes, container trucks, and gantry cranes based on hybrid spatiotemporal network prediction, comprising: Step S1, real-time data input, which involves writing the ship location map, container distribution map, and electronic fence adjacency list scattered across n-TOS (Container Terminal Production Operating System) into a unified memory structure; Step S2, hybrid spatiotemporal network prediction, which predicts the "sequence of activating bays, container retrieval order, and route travel time" for the next 10 minutes; Step S3, sub-steps and technical implementation, which completes global joint decision-making within 2 seconds; Step S4, shadow queue verification and anomaly rollback, which ensures that issued instructions are executable; and Step S5, daily self-evolution, which automatically updates model parameters as on-site changes occur.

[0040] Beneficially, S1 includes: S1.1, establishing a ship hold tensor, which is a two-dimensional table, where rows = hold number, columns = layer number, and cell values ​​= container number, weight, dimensions, and port of destination; S1.2, establishing a stacking area bay position tensor, which is a three-dimensional table, where rows = bay position, columns = column number, depth = layer number, and cell values ​​= container number, status, and number of times the container has been turned over; S1.3, establishing a road segment tensor, which is a one-dimensional table, where the index = electronic fence ID, and the value = current average vehicle speed, length, and direction; S1.4, pulling data every 5 seconds using the n-TOS (Container Terminal Production Operating System) standard REST interface, with timestamps aligned to milliseconds, to form the "truth at the same moment".

[0041] Beneficially, S2 includes: S2.1, a causal convolutional network (kernel size = 3, number of layers = 4) slides up the three tensors in step S1 to extract spatiotemporal features; S2.2, outputting three prediction vectors: a cabin vector: element = cabin ID, value = activation probability (0-1), a bin retrieval vector: element = bay coordinate, value = bin retrieval cost (seconds), and a road segment vector: element = fence ID, value = estimated passage time (seconds); step S2.3, concatenating the vectors into a "demand tensor" as the sole input for subsequent solutions.

[0042] Beneficially, S3 includes: S3.1, crane capacity calculation, reading the demand tensor grid vector, and pressing "DynamicUpperBound - CurrentWINum calculates the maximum number of tasks that can be activated per gantry crane in this round; S3.2, container candidate screening, removing suspended containers, isolated containers, and containers not loaded on the outer edge from the stacking area bay tensor, generating a "candidate container list"; S3.3, determining the number of gantry cranes to be activated, taking the minimum value between the capacity in 3.1 and the number of candidates in 3.2 to obtain the total number of tasks to be activated in this round; S3.4, summation solution, using the demand tensor as input, establishing a four-term weighted sum objective function: gantry crane idle time equals the sum of the arrival intervals of adjacent tasks, truck waiting time equals the sum of the differences between the arrival time and the task start time, the number of stacking areas without gantry cranes equals the count of activated tasks falling into bays without RTGs, and stacking area balance equals the standard deviation / mean of the task count; using the "adaptive metaheuristic algorithm" (variable neighborhood search + tabu list), with an upper limit of 500 iterations and a time limit of 2 seconds, the solution outputs an ordered list of activated tasks (including start and end times);

[0043] Truck-task matching table (including exchange markers); Gantry crane operation sequence (including street crossing prompts).

[0044] Beneficially, S4 includes: S4.1, joint solution completed at t0; S4.2, results written to the "shadow queue" at t0+50ms; S4.3, result detection module pulls the latest equipment status tensor at t0+100ms; S4.4, if equipment offline, road blockage, or container space occupied is detected at t0+200ms, an abnormal rollback is immediately triggered; S4.5, alternative "bridge crane task balancing strategy" is recalculated and issued at t0+500ms; S4.6, the next round of rolling begins at t0+2s; S4.7, production is uninterrupted throughout, and abnormal records are synchronously written to the log for daily learning.

[0045] Beneficially, S5 includes: S5.1, at 00:30 daily, the system automatically pulls the shadow queue of the previous 24 hours and the deviation from the actual execution; S5.2, at 00:35 daily, the convolutional kernel weights are updated using mini-batch gradient descent (learning rate = 0.001, batch = 256); S5.3, at 00:45 daily, a new weight file is generated; S5.4, at 00:50 daily, it is hot-loaded to the online engine; S5.5, at 01:00 daily, it completes self-evolution and takes effect directly at the morning peak the next day without manual intervention.

[0046] Following the above steps, the system operated continuously for 30 days at Berth No. 3 of Taicang Port. The average berthing time of ships decreased from 10.2 hours to 9.1 hours, the annual throughput capacity of the terminal increased by approximately 120,000 TEUs, the energy consumption per TEU decreased by 5%, and no production interruption events occurred due to algorithm anomalies.

[0047] A dynamic joint scheduling device for bridge cranes, container trucks, and gantry cranes based on hybrid spatiotemporal network prediction includes a data access unit, a tensor calculation unit, a joint solution unit, a shadow verification unit, and a learning and updating unit. All of these units are deployed and share CPU, memory, and network with n-TOS (Container Terminal Production Operating System) without adding any new hardware. The five units communicate with each other via memory tensors, without an external bus.

[0048] Beneficially, the data access unit executes step S1, the tensor calculation unit executes step S2, the joint solution unit executes step S3, the shadow verification unit executes step S4, and the learning update unit executes step S5.

[0049] Example 1

[0050] Under the premise of the above basic scheme, the causal convolutional network is replaced with a Transformer encoder. Specifically, the causal convolutional kernel in "hybrid spatiotemporal network prediction in step S2" is replaced with a Transformer self-attention mechanism. The output is still "demand tensor". Only "sliding convolution" is changed to "position encoding + multi-head attention". The other four steps of solving, shadow queue and daily learning process remain unchanged.

[0051] Example 2

[0052] Under the premise of the basic scheme or Implementation Example 1, the metaheuristic algorithm is replaced with the Integer Linear Programming (ILP) algorithm. Specifically, the four-term weighted sum objective function is retained, and the "variable neighborhood search + tabu list" is changed to ILP + branch and bound. The optimal solution is obtained within 2 seconds. If the timeout occurs, it automatically reverts to the metaheuristic, forming a "dual solver" parallel scheme.

[0053] Example 3

[0054] Under the premise of the basic scheme or Implementation 1 or Implementation 2, the "shadow queue" is changed from a memory table to only appending blockchain logs. When the verification fails, the pointer is moved forward to prevent data from being tampered with. The rest of the logic remains unchanged.

[0055] Example 4

[0056] Under the premise of the basic scheme or Implementation 1, Implementation 2 or Implementation 3, the four-step serial process is cancelled and replaced with "event triggering": when the state change of any device is greater than the set threshold, a complete recalculation is immediately performed using the same objective function. The calculation window is still 2 seconds, and the abnormal rollback is the same as the daily learning.

[0057] Example 5

[0058] Under the premise of the basic scheme or embodiment one or embodiment two or embodiment three or embodiment four, the joint solution result of step S3 is first sent to the digital twin to simulate 1000 random scenarios in parallel. If the success rate is less than 98%, the objective function weight α (cable crane idle) is automatically reduced by 0.05 and the solution is re-solved until the success rate reaches the target before being issued. The rest of the prediction, verification and learning process remains unchanged.

[0059] Example 6

[0060] The hybrid spatiotemporal network is decomposed into three sub-models: "ship layer - stack area layer - road layer". Each sub-model is predicted separately and then spliced ​​together to form a demand tensor. The solution, verification, and evolution steps are completely consistent with the invention scheme, only the prediction structure is different.

[0061] The above alternatives all achieve the same inventive purpose using different mathematical structures or event mechanisms.

[0062] The working cycle diagram of the basic technical solution of this patent is shown below:

[0063] Ship berths → n-TOS (Container Terminal Production Operating System) generates initial task → This invention's 2-second cycle rolls → Instructions are issued → Equipment executes → Real-time status feedback → Next rolls;

[0064] Every 2 seconds is a "decision window". Within the window, the following steps must be completed: prediction → four-step solution → shadow verification → formal deployment. If the timeout is exceeded, the strategy will automatically be downgraded to the alternative strategy to ensure uninterrupted production.

[0065] Key tensor dimensions and update frequencies include: ship bay location tensor: maximum 600 rows × 20 columns, refreshed every 5 seconds; storage area bay location tensor: maximum 400 × 6 × 5 (bay location × column × layer), refreshed every 5 seconds; road segment tensor: maximum 800 fence IDs, refreshed every 5 seconds; demand tensor output: 1 × 600 bay vector + 1 × 400 container retrieval vector + 1 × 800 road segment vector, updated every 5 seconds, for use within the subsequent 2-second window.

[0066] The initial weights of the objective function include: crane idle time α=0.45; truck waiting time θ=0.25; number of gantry crane-less stacking areas β=0.20; stacking area balancing γ=0.10. The total weight is 1, and automatic fine-tuning is allowed within ±0.05 during daily self-evolution.

[0067] The switching conditions between alternative and preferred strategies include: no output from the inter-projection module → immediate switching; shadow verification finding any task to be unexecutable → immediate switching; abnormalities occurring in three consecutive decision windows → switching and alarm; recalculation completed within 500ms after switching, with no interruption to production cycle.

[0068] The interface list with n-TOS (Container Terminal Production Operating System) includes: Request type: quay crane idle command, truck idle command, gantry crane idle command, and three types of ETA queries; Push type: activated task ordered list, truck-task matching table, and gantry crane operation sequence; Data format: JSON string.

[0069] The performance data points include: single-bridge efficiency: laboratory 26→27.5 natural boxes / hour; system availability: 99.9% after 30-day stress test; and anomaly rollback success rate: 100%, with an average time of 380ms.

[0070] The following is a glossary of terms used in this patent:

[0071] Crane capacity = Operating water level = DynamicUpperBound - CurrentWINum;

[0072] Shadow queue = hot standby channel = verification buffer;

[0073] Demand tensor = Predicted output vector = Spatiotemporal load vector;

[0074] Alternative strategies = crane task balancing strategy = continuous quantity strategy;

[0075] Ship bay layout diagram: A two-dimensional table with bays as the smallest unit and columns-layers as coordinates, recording the container number, dimensions, weight, destination port, and ballast sequence of each container bay on board, used to determine the loading order constraints.

[0076] Stack area bit tensor: a three-dimensional data structure where row = bit number, column = column number, depth = layer number, and cell stores box number, box status, and number of box turnovers, used to calculate box retrieval path and box turnover cost.

[0077] Electronic fence adjacency list: An undirected list describing the dock road network, where nodes = fence IDs, edges = adjacent fences, and weights = road segment length and average vehicle speed, used to predict truck travel time.

[0078] Demand Tensor: A three-source data cube formed by stitching together the ship berth map, the berth tensor of the storage area, and the electronic fence adjacency list after time alignment. It is the sole input for subsequent prediction and joint solution.

[0079] Hybrid Spatiotemporal Network Prediction: A method that slides a causal convolutional network over the demand tensor to extract spatiotemporal features and output a prediction vector for "activatable compartments, container retrieval order, and route travel time" for the next 10 minutes.

[0080] Crane capacity (operating water level): The maximum number of tasks that a single crane is allowed to activate simultaneously in the next scheduling cycle. It is calculated by a dynamic upper limit formula and is used to prevent task overload and maintain equipment cycle time.

[0081] Shadow queue: The solution result is first written to a memory buffer and used to compare it with the latest field state. Only after the verification is passed will the result be officially issued to ensure that the instruction can be executed.

[0082] Abnormal rollback: When the result detection finds that the equipment is offline, the road is blocked, or the container space is occupied, the mechanism automatically switches to the alternative "bridge crane task balancing strategy" and recalculates within 500 ms.

[0083] Daily self-evolution: an online learning process that uses the deviation between the shadow queue of the previous 24 hours and the actual data to update the weights of the prediction model through small-batch gradient descent every morning, and then hot-loads the data before the morning peak the next day.

[0084] Relational table-driven: The relationship between devices, tasks, and resource usage is expressed in the form of database tables. All algorithms only read and write the fields in the table and do not rely on external files or message queues for data transmission.

[0085] The basic operational flow of existing container terminals is as follows: ship → quay crane → horizontal transport (truck / AGV / IGV) → yard (gantry crane) → external truck / railway. Each link issues instructions through the terminal operating system (TOS).

[0086] Existing spatiotemporal prediction technologies utilize historical operation times, weather, driver profiles, and other data to predict the time required for a single machine operation (crane crane grabbing containers, truck driving, gantry crane overturning containers) through machine learning. The prediction results are mostly used to issue ETAs to shipping companies and do not participate in the real-time scheduling closed loop.

[0087] Existing metaheuristic algorithms, such as genetics, tabu, and ant colony algorithms, are used to solve NP-hard sorting or matching problems. They are often used in docks for container handling optimization and AGV path optimization, but are mostly offline or single-device local optimizations.

[0088] The above are merely specific embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions conceived without creative effort should be included within the scope of protection of the present invention; therefore, the scope of protection of the present invention should be determined by the scope defined in the claims.

Claims

1. A bridge crane container ship gantry crane dynamic joint scheduling device based on mixed space-time network prediction, comprising a data access unit, a tensor calculation unit, a joint solving unit, a shadow checking unit and a learning updating unit, characterized in that: The data access unit writes basic data into a unified memory structure, the tensor calculation unit establishes a ship cabin tensor, a stack area berth tensor and a road section tensor and splices them into a demand tensor, the joint solving unit takes the demand tensor as input and then outputs an allocation scheme, the shadow verification unit runs the allocation scheme in multiple groups of time intervals in a rolling manner and writes abnormal records into the learning update unit, and the learning update unit compares the shadow queue and the actual execution deviation to update the convolution kernel weight, regenerates a weight file and completes self-evolution; ​ The joint solving unit takes the demand tensor as input, establishes four weighted sum objective functions: bridge crane idle time is equal to the sum of adjacent task arrival intervals, container truck waiting time is equal to the sum of the difference between arrival time and task start time, RTG-free stack area number is equal to the count of activated tasks falling into RTG-free berths, and stack area balance is equal to the standard deviation of task count / mean, and an iterative solution is obtained by using a second algorithm and then an allocation scheme is output; The second algorithm includes an adaptive meta-heuristic algorithm and ILP, branch and bound algorithm, when using ILP, branch and bound algorithm, if timeout, automatically fallback to adaptive meta-heuristic algorithm; The algorithm for extracting the tensor by the tensor calculation unit includes a first algorithm, which extracts the space-time features of the tensor and splices the predicted vector into the demand tensor after outputting the predicted vector, the first algorithm includes a causal convolution network and a Transformer self-attention mechanism; The shadow verification unit includes a detection module, which pulls the latest device state tensor, if it is found that the device is offline, the road is blocked, or the container is occupied, an abnormal fallback is triggered immediately, then the bridge crane task balance strategy is recalculated and issued, and then the above process is executed in a rolling manner, and abnormal records are written into the learning update unit.

2. The bridge crane container ship portal crane dynamic joint scheduling device based on hybrid space-time network prediction according to claim 1, characterized in that: The basic data includes a ship berth map, a stack area container distribution map and an electronic fence adjacency table.

3. The bridge crane container ship portal crane dynamic joint scheduling device based on hybrid space-time network prediction of claim 1, characterized in that: The allocation scheme includes an activated task ordered list, a container truck and task matching table and a gantry crane operation sequence.

4. The bridge crane container ship portal crane dynamic joint scheduling device based on hybrid space-time network prediction of claim 1, wherein: The shadow queue run by the shadow verification unit includes a memory table and an appended blockchain log, when using the appended blockchain log, if the verification fails, the rollback pointer is moved forward.

5. The bridge crane container ship straddle carrier container crane dynamic joint scheduling device based on hybrid space-time network prediction of claim 1, characterized in that: The learning update unit starts self-evolution in idle time, pulls the shadow queue and the actual execution deviation in the past 24 hours, and updates the convolution kernel weight by using small batch gradient descent; A new weight file is generated and hot loaded to the online engine, and then self-evolution is completed. 6.The working method of the bridge crane container ship straddle carrier portal crane dynamic joint scheduling device based on hybrid space-time network prediction according to any one of claims 1-5, characterized in that: Step one, real-time data into table, establish ship cabin tensor, stack area berth tensor and road section tensor, and align their time stamps to milliseconds to form the same time; Step two, mixed space-time network prediction, use causal convolution network to slide on the three tensors in step one to extract space-time features; Output three predicted vectors, cabin vector, container picking vector and road section vector; splice the three vectors into a demand tensor as the only input for subsequent solving; Step three, substep and technical implementation, 3.1 bridge crane capacity calculation: read the demand tensor cabin vector and calculate the maximum number of activated tasks for each bridge crane in this round; 3.2 Container candidate screening: remove suspended containers, isolated column containers, and unloaded containers in the outer row in the stack area berth tensor to generate a candidate container list; 3.3 Determine the number of bridge crane activation, take the minimum value of 3.1 capacity and 3.2 candidate number to get the total amount of this round of activation task; 3.4 Joint solution, take the demand tensor as input, establish a four-item weighted sum objective function, and solve the output: activation task ordered list, container truck-task matching table, and gantry crane operation sequence; Step four, shadow queue verification and abnormal rollback, first t0 time joint solution is completed, when t0+t1s time result is written into shadow queue, when t0+t2 time result detection module pulls the latest device state tensor, when t0+t3 time if the device is offline, road is blocked, and container position is occupied, abnormal rollback is triggered immediately, when t0+t4 time alternative bridge crane task balancing strategy is recalculated and issued, when t0+t5 time next round of rolling starts; Step five, daily self-evolution, every day T1, the system automatically pulls the deviation between the shadow queue and the actual execution in the previous 24 hours; T2, update the convolution kernel weight with small batch gradient descent; T3, generate a new weight file; T4, hot loading to online engine; T5, complete self-evolution, T6, directly take effect.

Images