Aviro360 Folds Yard Gate, Inventory and Security Into One Login: 15-Second Gates, 98% Accuracy

The Analysis

A yard is a queue wearing a fence. Trucks arrive, a gate serves them, and the server is not the gate arm but the transaction behind it: does the system already know this container, this plate, this appointment, this chassis, this booking. If it does, the arm goes up. If it does not, a person goes looking, and while that person looks everyone behind them waits. The slot map, the cameras, the exception dashboard, they are all instrumentation bolted onto that one queue.

On 20 October Aviro360, incubated inside ConGlobal, a North American yard operator, released an upgraded Yard Visibility System. The pitch is consolidation: one login to watch gate activity, container positions, security events and operational exceptions across a single site or across a few hundred of them. Four numbers come with it. Gate processing in 15 seconds. More than 95 per cent of qualified gate transactions generated automatically. Inventory accuracy above 98 per cent. And 250,000 operational events handled a day. There is also a fifth claim that does not look like a number but behaves like one: the system layers on top of existing yard, transport, warehouse, ERP and terminal operating systems rather than replacing them.

These are good numbers, and every one of them is an average. That is where this piece lives. A queue does not feel averages; it feels variance and tails. What follows prices the four numbers in the units a yard runs on: minutes of waiting, hostler hours burned on rehandles, and the arrival rate at which the curve goes vertical.

Start with what is actually being claimed, because four numbers released together tend to be read as one number. Fifteen seconds is the service time of a gate transaction, and specifically of a clean one: the container is known, the plate reads, the appointment matches, the chassis is in the pool, the booking is in the system. At fifteen seconds a single gate lane can theoretically serve 3,600 divided by 15, which is 240 trucks an hour. Nobody runs a lane at 240 trucks an hour, and the distance between that theoretical figure and the real one is the entire subject of this article.

Ninety-five per cent of qualified gate transactions are generated automatically. Read that twice, because the load-bearing word is qualified. The denominator is not all transactions. The useful reading is the inverse: five per cent still need a person, and they do not spread evenly across the day. They cluster in the hours you can least afford it: shift change, vessel cut-off, the last hour before a rail departure, the afternoon a customer moves a delivery window.

Ninety-eight per cent inventory accuracy is a statement about boxes, not about moves. It says that of every hundred containers standing in the yard, ninety-eight are where the system thinks they are. It says nothing about the two that are not, and the two that are not are the only ones that generate work.

Two hundred and fifty thousand operational events a day is a network number. Across twenty-four hours that is about 10,400 an hour, roughly 174 a minute, just under three a second. Spread across a hundred sites it is 2,500 events per site per day, a busy yard but not an extraordinary one. Across ten sites it is 25,000 per site, a very different animal. The headline does not say which case you are looking at, and the two imply completely different plants. Ask for the site count behind the aggregate before using the figure.

The architecture claim is the fifth number nobody counts. Layering on top of existing yard, transport, warehouse, ERP and terminal operating systems instead of replacing them has an obvious benefit, no rip-and-replace and no big-bang cutover, and a subtler cost: five systems each hold their own version of where a container is, and when they disagree something has to decide. A single login does not resolve a conflict; it makes the conflict visible in one place instead of five. Whether that is a feature or a problem depends on whether a reconciliation rule was written down before go-live, and projects of this shape fail on that rule more often than on the software.

Why now, and why in this shape? Because the yard has been the least instrumented node in the container journey for two decades. The transport management system knows the order, the warehouse system knows the pallet, the terminal system knows the vessel and the stow. Between them sits a fenced piece of asphalt where a box spends between six hours and six weeks, and for most of that time no system knows anything useful about it. That gap was tolerable when yards were cheap overflow parking. It stopped being tolerable when chassis pools tightened, when appointment windows started being enforced, and when detention and demurrage began to be computed off event timestamps rather than off a driver's signature.

The second upstream push is that the yard is where the exceptions live. A vessel delay is a schedule event. A box that is in the yard but not where the yard thinks it is, is a search. A broken seal is a claim. An unauthorised gate exit is a theft. None are scheduling problems and none are volume problems, which is why they resisted the scheduling and volume tools built for the rest of the chain. The incubation detail is the tell: a system grown inside a yard operator rather than bought by one models the exception paths first, because operators live inside the exceptions. That is the most plausible reading of why gate and inventory are released alongside security events, and it is the part a buyer should interrogate hardest, because a demo cannot show it.

Who gets what, and how much. The consolidation claim, one to hundreds of sites in one pane, is where compounding happens, for a specific reason. In a multi-site network the same container appears in more than one yard over its life: terminal-adjacent, then rail-served, then a warehouse yard, and every transfer has historically been arranged by telephone. A single pane turns each transfer from a phone call into a query, and the saving is not in the query. It is that the query can be made by someone not standing next to the box.

The single-site case is smaller. One yard with two gate lanes and 4,000 slots does not need network visibility. It needs its queue to behave. For that operator the only question is whether these numbers move the two metrics that cost money, driver turn time and rehandles. Everything else in the release is instrumentation on a process that was already fine.

There is also a sized group for whom none of this pays, and utilisation is the gate on every argument here. Below about 0.5 utilisation, meaning two lanes, an effective service time near 32 seconds, and fewer than roughly 56 trucks an hour per lane, your queue is short and nothing you do to the server changes that materially. You would be buying a dashboard for a queue that was never your problem. Put the money into appointment flattening and chassis availability instead.

Timing propagates in a fixed order, and knowing it stops you declaring victory in week one. Per-transaction service time shows up the same day, because every transaction measures it. Inventory accuracy takes one to two weeks, because it cannot be measured until you have run a physical cycle count and established the real denominator. Rehandle reduction takes four to eight weeks: at 600 outbound moves a day and a 2 per cent position error you get roughly twelve digs a day, so a week gives about sixty digs, enough to see a 20 per cent change and nowhere near enough to see a 5 per cent one. Cutting the exception tail is a quarter-scale job, because exception types are long-tailed and fixing the top five categories leaves the residual standing. Detention, demurrage and turn-time disputes move on contract cycles, one to two quarters out. Underneath it all sits the integration calendar to the five systems, and that calendar sets your go-live date.

So put one yard on the table and keep the assumptions visible. Assume two gate lanes and 4,000 container slots. Assume 600 outbound gate moves a day and 250 working days a year. Assume a clean gate transaction takes 15 seconds, the released figure. Assume a transaction needing a human takes six minutes, or 360 seconds; that is an assumption, not a released number, and it is the first figure you should replace with your own gate log. Assume the automatic rate is 95 per cent. Assume a search for a mispositioned box takes eight minutes of hostler time, and that reaching it requires moving an average of two and a half other containers at four minutes each. Every number below follows from those assumptions plus the released figures. Change one and the arithmetic moves, which is the point of writing them down.

Here is the part the release does not say, and it is the reason this piece exists. All four numbers are per-transaction statistics. Not one is a queue statistic, and a queue does not run on averages. Take the 15 seconds and the 95 per cent together and compute the effective mean service time: 0.95 times 15 plus 0.05 times 360 is 14.25 plus 18, which is 32.25 seconds. The advertised service time has more than doubled and nothing about the advertisement changed. Five per cent of transactions at six minutes each contribute more to the mean than ninety-five per cent at fifteen seconds each.

Now the variance, because the mean is only half of it. The second moment is 0.95 times 15 squared plus 0.05 times 360 squared, which is 213.75 plus 6,480, or 6,693.75. Subtract the square of the mean, 1,040.06, and the variance is 5,653.69. Divide by the squared mean and the squared coefficient of variation of service is 5.44. For a perfectly deterministic server that is zero. For this one it is five and a half, which in queueing terms is a loudly variable server: most trucks clear in a quarter of a minute, a few take six minutes, and the mixture is poison.

Feed that into the standard approximation for waiting in a general queue. Waiting is roughly half the sum of the arrival and service variation coefficients, times utilisation divided by one minus utilisation, times the effective service time. Assume Poisson arrivals, so arrival variation is 1. At 60 trucks an hour per lane, capacity is 3,600 over 32.25, or 111.6, so utilisation is 0.54 and the ratio is 1.17. Half of one plus 5.44 is 3.22. Multiply: 3.22 times 1.17 times 32.25 is about 121 seconds. Two minutes of waiting on a fifteen-second gate.

Run the same lane with every transaction clean and you get a different world. Service time 15 seconds, service variation essentially zero, utilisation 60 over 240 or 0.25, the ratio 0.33, half of one plus zero is 0.5, and waiting is 0.5 times 0.33 times 15, about 2.5 seconds. Same trucks, same lanes, same released service time. The whole difference between two and a half seconds and two minutes is the five per cent.

Then the curve goes vertical. At 90 arrivals an hour per lane utilisation reaches 0.81, the ratio becomes 4.16, and waiting is about 432 seconds, seven minutes. At 100 an hour utilisation is 0.90, the ratio 8.60, and waiting about 892 seconds, close to fifteen minutes. At 110 an hour utilisation is 0.99 and the model returns waiting measured in hours, which in practice means the queue stops draining. The tripwire sits at utilisation 0.85, roughly 95 trucks an hour per lane at this service time. Above that line no amount of clean-transaction speed saves you.

The same mispricing shows up on the accuracy number. Ninety-eight per cent inventory accuracy sounds like a rounding error, and per box it is. Per move it is not. Four thousand slots at two per cent is eighty containers whose recorded position is wrong. Six hundred outbound moves a day at a two per cent hit rate is twelve boxes a day somebody has to go looking for. Twelve searches at eight minutes is 96 minutes. Twelve digs at two and a half unplanned moves each is thirty extra moves, at four minutes each 120 minutes. Together 216 minutes a day, about 3.6 hostler-hours burned on the two per cent. Across 250 working days that is roughly 900 hostler-hours a year. Multiply by your own hourly cost, because I am not going to invent one.

Move accuracy one point, to 99 per cent. Eighty mispositioned boxes become forty, twelve digs become six, 3.6 hostler-hours become 1.8, and 900 hours a year become 450. One percentage point of inventory accuracy is worth about 450 hostler-hours a year in this yard. Compare that with the lever everybody negotiates, the second at the gate. Holding the tail at six minutes and moving the clean transaction from 15 seconds to 12 seconds takes the effective mean from 32.25 to 29.4 seconds, under nine per cent. The marginal point of accuracy and the marginal second are not the same size, and the release prices the second.

Put that into buying language and it changes what you ask for. Move the automatic rate from 95 per cent to 97 per cent while the clean transaction stays at 15 seconds, and effective mean service time drops from 32.25 seconds to 0.97 times 15 plus 0.03 times 360, which is 25.35 seconds. That is a 21 per cent improvement with no change at all to the headline number. Auto rate is the highest-leverage figure in the release and it is printed in the least prominent position, as a percentage nobody thinks to negotiate. That gap between what is measured and what matters is the one thing to take out of a vendor meeting, and it has not been reported anywhere.

None of this is an argument for buying it. It is an argument for knowing which number to negotiate if you do, and for noticing that the four numbers are not four measures of the same property. Two describe a mean, one describes a tail, and one describes an aggregate whose denominator was never published.

Now the part where this could all be wrong. The obvious objection is that the queue is not the bottleneck at all. If your constraint is dock doors, chassis availability, or the number of hostlers on shift, a faster gate does nothing except relocate the queue to the next station, and you will have paid for visibility into a queue that was never the constraint. Check this first: stand in the yard for a day and note where trucks accumulate. At the gate, the server is the problem. Inside, it is not, and the arithmetic above is irrelevant to you.

A second counterfactual concerns arrivals rather than service. Flattening appointments is the standard answer to gate congestion and it does work, but on this arithmetic it works less than you would hope, because service variation dominates. Take the same lane at 90 arrivals an hour and drive arrival variation from 1 down to 0.3 by enforcing appointment windows tightly. Half of 0.3 plus 5.44 is 2.87 against 3.22, roughly an eleven per cent reduction in waiting, from about 432 seconds to about 385. Useful, not decisive. Kill the tail instead. Cut the six-minute exception to three minutes and service variation falls from 5.44 to about 2.39, effective service time drops to 23.25 seconds, lane capacity rises to 155 an hour, utilisation falls to 0.58, and waiting at the same 90 arrivals comes down to roughly 55 seconds. A seven-fold improvement from a lever that costs nothing but catalogue work.

Ömer Kaya would start from the node rather than from the server, and he would be right to: the question he would ask is what happens to the road outside the gate once the queue stops draining, because at some arrival rate the queue stops being a yard problem and becomes a municipal one, and drayage appointments two nodes downstream start defaulting in a chain. The two views meet at exactly one number, which is the arrival rate at which queue length exceeds the standing room inside the fence. That is the same tripwire computed above, and it is why this is a quantity problem before it is a technology problem.

There is a harder objection, and it is the one I would raise myself. What is the 98 per cent measured against? Measured against the system's own record of where it last saw the box, it is self-referential and means approximately nothing. Accuracy claims only mean something against a physical count, and the denominator has to be stated: 98 per cent of 4,000 slots, counted how often, by whom, with what tolerance for a slot one bay off. Without that the number cannot be audited, and an unauditable number cannot be a contract term.

The third boundary condition is architectural. Layering is only possible if the systems underneath expose something to layer onto. A yard running on paper, or on a yard management system with no integration surface, cannot be layered, and the does-not-replace claim quietly becomes a migration project with a different price and calendar. Ask which of your five systems has an interface before accepting the architecture argument.

So what does an operator do with all this? Instrument before you buy. Pull eight weeks of gate logs and compute two things: lane utilisation by hour, and the 95th-percentile service time against the median. If the 95th percentile is more than four times the median, your problem is the tail and every average in the brochure is aimed at the wrong target. Name the system of record for container position before integration starts, because the five systems will each claim to know where the box is and only one should win. Set the tripwire and wire it to something: when a lane prints above 95 trucks an hour for three consecutive days, open a third lane or push appointments out, rather than discovering the problem when the queue reaches the road.

Build the accuracy baseline with a weekly cycle count over a fifth of the yard for four weeks. And log digs against outbound moves as a standing metric, holding rehandles below 1.5 per hundred gate-outs; at 4,000 slots and 98 per cent you start from roughly twelve digs a day, so the arithmetic tells you what one point is worth before you spend anything.

The release is worth reading for one reason that has nothing to do with the four numbers. It signals that yard visibility is consolidating into a single pane across networks rather than staying a per-site tool, which changes what buyers compare and what they can demand. What it does not tell you, and what no coverage of it has told you, is that a fifteen-second gate with a five per cent exception tail is a thirty-two-second gate, that a thirty-two-second gate at 95 trucks an hour is a fifteen-minute wait, and that the two per cent of boxes the system cannot find costs more hostler time than three seconds at the gate saves. That is the arithmetic, and you can run it on your own logs this week without buying anything at all.

↑ Back to the key points

— By Ravi Chandran