Beibu Gulf Port launches waterway AI model, extending lock agents to 20 Xijiang ship locks

The Analysis

Every time a port group announces a model, the first thing I do is not read the release twice. I draw the queue. Arrivals on the left, a service station in the middle, departures on the right, and the waiting line in front of the station, which is the only part nobody photographs. What came out of Beibu Gulf Port Group on 24 August gives me a queue with an unusual shape. The ship-lock scheduling agent was piloted at the four locks of the Changzhou hub on the Xijiang and then extended to twenty locks across thirteen cascades. The port-group agent runs at Qinzhou and has been pushed out to five terminals under the group. Five organisations, led by the Tianjin Research Institute for Water Transport Engineering, spent more than a year building it together. Thirteen service stations in series, and one of them sets the pace for all the others.

The sentence I want to pull apart is the one that will end up in every board deck: berth planning and lock slot assignment went from several hours to a few minutes. That is not a statement about a ship. It is a statement about a person holding a spreadsheet, and about how long that person needs before an answer exists. Those are two different clocks. The vessel cares about the second one, and it only gets to care about it after the first one stops ticking. Mix them up and you will build a budget around a saving you never see.

I have watched this film in container terminals, in rail classification yards and in cross-dock operations. The installations that survived had one thing in common: a named human being, written into the procedure, who owned the result when the machine was wrong. The ones that died quietly had beautiful throughput curves and no answer to the question of what happens on the day it misfires. So before anybody turns this into a slide, model it. Where is the bottleneck, which decision does it actually replace, and which number tells us to stop.

Start with the picture. A barge leaves an upstream terminal, arrives at a lock, waits, enters a chamber, rises or falls, leaves, and then does it again. Every lock is a service station, and every reach between two locks is a buffer that holds a few dozen vessels at most before it backs up into the previous one. Stack thirteen of those stations in a line and you have the river as the model sees it: thirteen cascades, twenty chambers, and one constraint that decides the throughput of the whole chain. In queueing language that constraint is the station with the highest ratio of arrivals to service rate, and the honest answer is that almost nobody instruments it. The agent started at four locks and was then extended across the rest, which is exactly the part I want to slow down on.

Locks are batch servers, and that one detail changes how you model everything downstream of it. A lock does not serve vessels one at a time. It fills a chamber and then it cycles. So waiting time is not a smooth curve in utilisation, it arrives in steps. A vessel that misses a cycle waits a full cycle plus the fill time of the next one. If your chamber cycle is 45 minutes and you show up two minutes late, your penalty is not two minutes, it is something closer to 47. That is why the shape of the distribution matters more than the average, and why any benefit claim that only quotes an average should be read as an unfinished sentence.

Now the headline, and the two clocks. Clock one is decision latency: the gap between the moment the planner has the information and the moment a plan exists. Clock two is process latency: how long a vessel actually sits. The release is a claim about clock one. Vessels live in clock two. Clock one only reaches clock two through one specific mechanism, and that mechanism is re-planning frequency. A plan that took three hours was, in practice, a plan you made once a shift and then patched by telephone. A plan that takes five minutes is a plan you can rebuild every time a vessel reports a delay, every time the water level moves, every time a chamber goes down for maintenance. The saving is not the two hours and fifty-five minutes you freed up. The saving is the number of times a day you can now re-optimise, and that number used to be one or two and could now be ten.

If you want a number to argue with, here is mine, with every assumption on the table. Assume several hours means 180 minutes and a few minutes means 5, so 175 minutes released per planning event. Assume each cascade plans twice a day, once for upstream traffic and once for downstream, across thirteen cascades: that is 26 events a day, or 4,550 minutes, or roughly 75.8 planner hours released per day. Assume a fully loaded planner hour costs 120 yuan. That is about 9,100 yuan a day, and across 330 operating days something near 3.0 million yuan a year. Now be honest with it: those are released hours, not removed headcount. Budget for the half you can genuinely convert into fewer shifts or into work nobody is doing today, and call it 1.5 million.

That number is small, and it should be small, because it is the wrong number. The money on a river sits in vessel time, not planner time. Second calculation. Assume a barge waits an average of six hours at one cascade, and split that wait into two pieces: 1.5 hours waiting for the plan, and 4.5 hours waiting for a chamber and for the cycle itself. Cutting planning time cannot touch the 4.5. Assume the faster plan converts 60 percent of the 1.5 into time genuinely saved, which is 0.9 hours per cascade per vessel.

Assume a vessel on this corridor passes six cascades on a typical trip, giving 5.4 hours per vessel. Assume 300 barges a day presenting for locks, and assume the fully loaded cost of a barge day, vessel plus crew plus fuel plus the capital tied up in the cargo, is 4,000 yuan, which is about 167 yuan an hour. That is roughly 900 yuan per vessel, 270,000 yuan a day, and about 89 million yuan a year.

Read that figure the way I read it, as a ceiling rather than a forecast. It only appears if waiting time genuinely falls, and faster planning does not automatically shorten waiting. It shortens waiting if and only if the extra re-plans are aimed at the thing that actually wastes chamber time. So the defensible version is perhaps 30 percent of the ceiling, around 27 million yuan a year, and even that you have to prove. The point of the arithmetic is the ratio: vessel time here is roughly thirty times planner time. If your pilot measures planner hours, you are watching the wrong queue.

Here is the part that decides whether any of this reaches your inventory. Assume transit through one cascade has a mean of six hours and a standard deviation of 2.1 hours, which is 35 percent of the mean, driven by water level, visibility, maintenance windows and the mix of vessel types in the queue. Assume the thirteen cascades behave independently, which is optimistic but useful. End-to-end variance then scales with the square root of thirteen, about 3.6. So the mean end-to-end transit is 78 hours and the standard deviation is roughly 7.6 hours. Commit to a customer or plan replenishment on the mean and you will be short about one trip in two. Commit on the 95th percentile instead, which is 78 plus 1.65 times 7.6, call it 90.5 hours. The distance between 78 and 90.5 is 12.5 hours of buffer you did not know you were missing.

Put a quantity on it. Assume a warehouse behind Qinzhou draws 1,000 tonnes a day off this corridor. Twelve and a half hours of unplanned variance is 12.5 divided by 24 times 1,000, about 521 tonnes. That is the size of the hole that opens when a planning system improves the mean and leaves the tail alone. And that is precisely what a scheduling agent does: it is good at the mean, it is not automatically good at the tail. The tail on this corridor is a chamber out of service, a fog closure, an unseasonal water level, a vessel that reports late and then arrives early. So whatever the agent delivers, re-baseline your safety stock on variance and on the 95th percentile, and do not release the old buffer until the new percentile has held for a full quarter.

Be precise about which decision the thing replaces, because this is where headcount expectations quietly go wrong. The agent replaces the generation of a schedule. It does not replace the arbitration of exceptions. After it goes in, the planner stops drawing the plan and starts judging the plan, and the skills are not the same. If you promised a reduction in people on the basis of a reduction in drawing time, you will be disappointed, and worse, you will have removed the only person who could catch a bad plan. Keep the headcount through the pilot, redeploy it from producing to reviewing, and measure the review: time from anomaly flagged to anomaly arbitrated, with a target under 15 minutes. If the review queue is where the delay now sits, you have moved the bottleneck rather than removed it, which is still progress as long as you say so out loud.

Keep the two agents apart in your accounting. Berth allocation at Qinzhou and lock scheduling on the Xijiang are separate problems with separate objective functions and separate constraints. One optimises a quay line against vessel drafts, cargo handling rates and yard capacity. The other optimises chambers against water, vessel dimensions and cascade sequencing. A result in one is not evidence for the other. If someone presents a combined benefit number, ask for the decomposition, and if the decomposition does not exist, treat the combined number as a placeholder. This is not pedantry. Pilots that report one blended figure are usually hiding the fact that only half of it is real.

On the evidence base: four locks at Changzhou, then twenty locks across thirteen cascades. Four out of twenty is 20 percent coverage for the validation, and the other sixteen sit on different water, different chamber dimensions, different vessel mixes and different upstream and downstream connections. I am not saying the extension will fail. I am saying that pilot and extension are two different claims and deserve two different acceptance tests. Ask for a per-cascade acceptance with its own baseline and its own read date, and refuse the word rollout as a substitute for evidence. A single go-live date across twenty chambers is a project plan, not a validation.

Five organisations, led by the Tianjin Research Institute for Water Transport Engineering, spent more than a year on this. Read that as information about the cost of replication, not as a marketing point. When a research institute, a university and a carrier-side operator have to build something together for over a year, the hard part was data, interfaces and agreement on definitions, not the model. If you are budgeting for something comparable in your own operation, put integration and joint debugging on its own line, because that is where the calendar goes, and because a licence fee with nothing behind it has never shipped anything. Include the communications layer in that budget too: a scheduling agent that depends on upstream reporting is only as available as the link that carries the report, so hold the link to 99.5 percent availability and log every dropout as an incident rather than as a note.

One trap that kills these systems quietly. The agent learned from historical human schedules, and human schedules contain good practice and they also contain habit: always giving way to a particular operator, padding a favourite vessel, avoiding a chamber that somebody once had trouble with. Train on that and go live and you have automated the folklore at machine speed. Run it in shadow mode first. The model proposes, the duty planner decides, and every disagreement is logged with a reason code. Four weeks of that tells you more than any accuracy figure in a release. If the disagreement rate sits above 25 percent, either the model is not ready or your planners know something the model does not, and both are worth discovering before a vessel is involved in the discovery.

Separate your constraints from your objectives, because mixing them is the classic modelling accident. Some conditions on a river are hard constraints, not things to trade off: vessels carrying certain cargoes cannot share a chamber with others, oversize vessels have their own windows, maintenance closures are fixed. Those go into the model as constraints that cannot be violated. Throughput, waiting time and chamber utilisation are objectives that can be traded. If a system lets a soft objective quietly override a hard constraint in order to look better on the objective, you will not find out from a dashboard. You will find out from an incident. So ask for the constraint set in writing, and ask what happens when the constraint set makes the problem infeasible, because that is the moment the system tells you who it really serves.

Underneath all of it sits a boring prerequisite. If you do not know when a vessel will actually arrive at the approach, the agent is solving an optimisation problem on the wrong input, and solving it very fast. Arrival forecast error is the invisible ceiling on this entire class of system. Measure it before you commit to anything: median absolute error between the time a vessel reports and the time it actually reaches the approach. If that number is above 45 minutes, spend your first quarter on the forecast instead of on the scheduler. I know that is the less exciting project. It is also the one that pays, and it is a prerequisite rather than an alternative, so you will probably end up doing both.

Then the question I ask before any metric: when this is wrong, who covers it. Not what is the contingency plan, because that sentence commits nobody. Who signs the schedule. If the agent proposes a slot and the barge misses its water window, who pays the waiting time. If a bad slot contributes to a demurrage claim or something worse, whose budget absorbs it, and is there a cap. Get it into the operating procedure with a name and a number before the first live plan is issued. Also set the degradation rule: if the agent is unavailable, or disagrees with the planner beyond a threshold, the cascade reverts to manual planning within 30 minutes and stays there until somebody with authority puts it back. A system whose output nobody owns will be trusted exactly as far as it is convenient, which means it will be trusted in calm water and switched off in the conditions where it was supposed to earn its keep.

Instrumentation, with thresholds, because a tool without a threshold is a hobby. Planner adoption rate, meaning the share of agent-produced schedules executed without edit: target 75 percent, investigate below 60, stop below 50 for two consecutive weeks. Re-plans per cascade per day: target four or more, since if you are still re-planning twice a day you have bought speed you are not spending. Median and 95th percentile of arrival-to-lock waiting time, read weekly against the control cascades, with the 95th percentile not allowed to run more than 8 percent worse. Lock chamber utilisation, measured as effective chamber volume per available chamber-hour, looking for at least five percentage points. Time from anomaly flagged to human in control, at 15 minutes, anything longer triggering automatic reversion for that cascade. Arrival forecast error, median under 45 minutes. Event timestamp completeness across arrival, queue, chamber and departure events at 98 percent, below which the data cannot support attribution and you are arguing from memory.

Design the comparison as though you actually want an answer. Hold out two cascades that match the pilot on vessel mix, water-level band, cargo type and arrival distribution, keep them on manual planning for twelve weeks, and do not read the result until each leg has accumulated at least 1,500 lock transit records. Alternating days or random weeks will not do, because the river is seasonal and you would be comparing August with October and calling it an effect. If you cannot hold out a cascade, hold out a shift pattern inside one and accept that you now have a weaker experiment, then widen your intervals accordingly and refuse to publish a point estimate as though it were a result.

Set the stop-loss while nobody is defending a decision yet. Three triggers: the 95th percentile waiting time running more than 8 percent worse than control for three consecutive weeks; adoption below 60 percent for two consecutive weeks; or one incident attributable to a wrong schedule, whether that is a demurrage claim, a barge held overnight on a bad slot, or a close call that a planner caught by hand. Any one of those pauses expansion, and two of them revert the cascade to manual planning until a written cause analysis exists. Expansion itself waits for week twelve and releases only when three conditions hold together: 95th percentile no worse than 8 percent above control, adoption above 75 percent, and zero attributable incidents.

What can you get without a model at all, in case the timeline does not survive contact with your budget. Two things, both dull, both effective. Staggered arrival windows, where you allocate reserved chamber slots to high-priority cargo and charge for them, which is a policy change rather than a system change and can be done with a notice to shipping agents. And a reporting discipline: mandatory reporting at a fixed point upstream, timestamped, with a real consequence for silence. In my experience those two together recover a meaningful share of the variance the agent is being asked to absorb, and they cost a procedure document and part of one clerk. Do them even if you do adopt the agent, because the agent needs their output, and because they are what you fall back on when the system is down.

Is this worth doing. Probably, and for a reason that is not the one in the headline. The minutes matter less than the ability to re-plan, and the ability to re-plan matters less than the variance you take out of the corridor. Measure the right queue, hold out a control, name the person who signs, and keep a stop-loss you are actually willing to use, and this is the kind of project that pays for itself quietly over a year. Measure planner hours, extend on the strength of the word extension, and let the output float with nobody owning it, and you will have bought a faster way to produce a plan nobody trusts. Same model, same river, two outcomes, and the difference is entirely in how you chose to measure it.

↑ Back to the key points

— By Ravi Chandran