KONGSBERG Delivers Advanced Vessel Traffic Services Solution for Great Belt VTS in Denmark

The Analysis

KONGSBERG delivered a new Vessel Traffic Services solution for Great Belt VTS in Denmark, announced on 25 June, and the release gives me four things I can actually hold. The contract was awarded by DALO, the Danish defence acquisition and logistics organisation. The software is Foresight, KONGSBERG's own family of maritime domain awareness systems, adapted for this site. It is integrated with the radar and CCTV that were already there, with KONGSBERG carrying full responsibility for the integration and the interfaces. And it comes with a long-term Managed Services agreement for continuity, reliability and lifecycle support. Everything else in the announcement is adjectives, and I want to be plain about how thin the factual payload is: no transit time, no throughput, no availability figure, no before and after.

So let me model it before somebody models it for me. Think of a strait as a queue with one server and a hard geometric limit. Ships arrive, they are sequenced and cleared, they transit, they leave. The service rate is set by the channel, the bridge span and the traffic separation scheme, and no software adds a lane. What a VTS can do is shorten the waiting part of that queue and make the waiting predictable. It cannot add capacity. That distinction is the entire ball game, because capacity is what people imagine they are buying when they read a story like this one.

Note also what the system actually offers, because the release is unusually careful about it. It provides information services to vessels passing the Great Belt Bridge. Information, not command. That is not a shortcoming of this delivery, it is what a vessel traffic service is, and it tells you exactly what you are allowed to expect: better, earlier, more authoritative information about a fixed-capacity chokepoint. If your Baltic boxes have ever sat at a discharge port waiting for a ship that stayed "two days out" for four days, the value here is not that the strait got faster. It is that somebody upstream finds out sooner.

Start with the only number we were given, which is none. The project manager is quoted saying the system is fully operational and performing as expected in normal operations. I believe him and I also want to point at what that sentence does and does not cover. It covers the median day. Every queue I care about fails on the tenth day, not the median one. A system that behaves as expected in normal operations has told me nothing at all about the afternoon the wind turns, a casualty blocks the separation scheme, or three arrivals bunch into the same two hours. So before anything else, decide which regime you are buying for, because the release only speaks about one of them.

Here is the model, with every assumption mine rather than theirs. Assume the strait carries thirty vessel transits a day, and assume the median ship spends six hours inside the traffic area. Little's law says the number in the system equals arrival rate multiplied by time in system, so the expected number in system is thirty times six twenty-fourths, which is seven and a half vessels. That is a small number, and small numbers at a chokepoint are deceptive, because a small system has no slack in it. Now assume something halves the service rate for twelve hours. Arrivals continue at thirty a day, so fifteen vessels show up in that half-day while the strait clears seven and a half. Seven and a half vessels of backlog accumulate.

The drain is the part people get wrong. Once the restriction lifts, the backlog does not vanish; it clears only at the excess of service over arrivals. If service returns to thirty a day and arrivals stay at thirty a day, the excess is zero and the queue never drains at all, it just sits there until the arrival pattern thins out on its own. If the strait can surge to thirty-six a day, the excess is six a day and seven and a half vessels take about one and a quarter days to clear. That is the signature of a fixed-capacity chokepoint: a twelve-hour event leaves a one to two day tail behind it, and the tail lands on whoever was at the back of the queue. Software does not change that arithmetic. What software changes is how early you know.

Which brings me to the bottleneck, because there is one and it is not in the strait. Ask where the time actually goes on a delayed Baltic arrival and you will almost always find the same shape: the ship is late by a day and a half, the discharge berth is ready, the truck plan was built three days ago, and nobody re-planned because nobody knew. The physical bottleneck is the channel. The operational bottleneck is the latency between a change in the real world and a changed decision in your planning system. That latency is measured in hours, it is yours, and it is the only thing on this list that a better information service can actually move.

Now translate it into the four accounts, because that is where a delivery like this either earns something or does not. For cost, a VTS does not touch your freight bill, your energy line or your handling charges; the money is in the buffer you can release if arrival error falls. For lead time, it touches only the waiting term, so its whole value is variance reduction and none of it is speed. For inventory, this is where the real number sits, and only if the information reaches the sheet where you size cover. For anything regulatory, nothing here changes your obligations; a vessel traffic service is not a customs system and the release claims nothing about documentation. Three of those four are conditional on the data arriving somewhere useful.

Here is the prize, quantified, with every assumption stated so you can argue with it rather than with me. Assume fifty sailings a year into your Baltic discharge port, and sixty of your boxes on each, so three thousand boxes a year and about 8.2 a day. Assume you size cover against arrival variability using your ninetieth percentile absolute arrival error at three days out, and assume that number is sixty hours today. At 8.2 boxes a day, sixty hours is two and a half days, which is 20.5 boxes. Assume 40,000 of goods value in a box. That is 820,000 of working capital held against arrival error, and at an assumed 8 per cent cost of capital it costs about 65,600 a year to carry.

Now assume better strait transit information takes that ninetieth percentile error at three days out from sixty hours to thirty-six. That is my assumption; there is no figure in the release, and it is the number you must measure rather than believe. Cover falls to one and a half days, 12.3 boxes, 492,000 held, about 39,400 a year to carry. The release is 328,000 of working capital and roughly 26,200 a year. That is the whole business case, and it lives or dies on one question: does the information actually reach the sheet where you size the buffer, or does it stop at a screen in somebody's operations room. Most deployments I have looked at die on exactly that question, having passed every technical review.

Then the availability arithmetic, because a feed you depend on is a service and services have uptime. Assume the managed services arrangement holds the information service at 99.5 per cent availability. Over a year of 8,760 hours that is 43.8 hours of outage. Assume each of your fifty sailings has a twelve-hour window during which strait information actually matters to your plan. The chance that a given window intersects an outage is roughly twelve over 8,760 times 43.8, which is about 6 per cent, so expect about three of your fifty sailings a year to be planning blind at exactly the moment you needed the feed. Three sailings carrying sixty boxes each is not a rounding error. It is the argument for a fallback, and it is an argument you can make in numbers rather than in feelings.

One more thing sits inside that lifecycle promise, and it is the one nobody puts in the contract. A system under lifecycle support changes under you. Versions move, interfaces move, and the configuration you baselined in July is not the configuration running in March. That is not a defect, it is what support means, but it has a direct consequence for the baseline you just spent twelve weeks building: it has a shelf life. Pin the version you validated, require written notice before any change to an interface you consume, and re-run the baseline after every change rather than assuming continuity. If your contract does not name a notice period in days, then the number of days is whatever the supplier decides on the morning it happens, and your measurement programme has no defence against that.

And be clear about what an information service is not. If the authority publishes a restriction or an advisory and your box is late anyway, you have no claim against anybody for that. There is no service level here running in your direction, and the release makes no offer of one. What you have is a better public signal, and the party you hold to a commitment remains the carrier you contracted with. That is worth saying out loud in the room, because I have watched teams slowly transfer their expectations from the contract that governs them to the feed that informs them, and then spend a quarter arguing with the wrong party about a delay neither of them caused.

There is also one lever here that people forget, because it is the only one you actually own. You cannot widen the channel, but you can influence when your ship arrives at it. Queues are worse than their average suggests when arrivals bunch, and a ship that joins a bunch pays for the ships in front of it as well as for itself. Ask your carrier whether the proforma can be moved by a few hours so your arrivals do not land in the same band as everyone else's. Assume, and this is my assumption not theirs, that being at the back of a bunch costs six hours, and assume a fifth of your fifty sailings a year currently land in bunched windows. That is ten sailings and sixty hours a year of avoidable variance, bought for the price of a schedule conversation rather than a project. It is small, and it is the only item on this list that costs nothing and needs no vendor.

Integration is where this sort of delivery either works or does not, and the release is unusually specific about it, so I will borrow the wording. The solution is integrated with existing radar and CCTV infrastructure, with KONGSBERG holding full responsibility for the integration and the interfaces. That single sentence is worth more than every adjective in the announcement put together. Every system project I have reviewed that failed, failed at an interface, and nearly all of them failed there because two parties each believed the other owned it. One party, named, owning the interfaces is the transferable lesson here, and it applies directly to you: when you connect an external feed into your planning system, write down one name against the interface, and write down what happens at two in the morning when it breaks.

The managed services part deserves the same treatment, which is to say read it as a contract rather than as a property of the software. Software does not have reliability. A service with an availability target, a response time and a named owner has reliability. Note too that the release says support is provided remotely rather than on site, which makes the response time more important, not less, because nobody is walking down a corridor to a rack. So when you buy anything in this class, ask the same three questions. What availability is committed in writing, measured per month. What is the committed response time on a severity one fault, in hours, and does it apply out of hours. Who owns the version you are running and the roadmap for it. If any of those three comes back as an adjective, you have bought a mood.

Keep the human in the loop, and keep them named. A vessel traffic service publishes information and a master decides. The design goals the release names are high availability, redundancy and secure communications, which are the goals of a system whose output somebody has to act on under time pressure. That means the alert chain matters more than the model behind it. Pick whichever decision you want the feed to change: re-sequencing a discharge berth, releasing a truck, moving a cut-off. Name the person who acts on that signal and carries the miss when nothing happens. If the answer is nobody in particular, the feed becomes a screen people glance at, and in my experience that transition takes about six weeks from go-live.

Baseline first, and I have never once seen this waste anybody's time. Take twelve weeks of your own logs for the one lane you care about. For each sailing, record the estimated arrival you were handed at seven days out, at three days out and at one day out, then record the actual arrival. Score absolute error in hours. That is your baseline, and every claim anybody makes to you afterwards gets measured against it. No supplier figure may appear in that sheet, and every gap gets marked unknown rather than filled in, because a filled-in gap will quietly become a fact by the time it reaches a business case.

Then shadow mode. Run the new feed alongside the old method for eight weeks, output visible, no automated action taken, scored daily against the handwritten baseline. Pre-register the primary metric in writing before week one, and pre-register the stopping rule on the same page. Mine would read as follows. Primary metric: ninetieth percentile absolute arrival error at three days out, in hours, on your own sailings. Stop rule: if that figure is not at least twenty per cent below baseline for four consecutive weeks, or if monthly feed availability falls below 99 per cent, revert to the old method within twenty-four hours and write down what was learned. No extension on the basis of a roadmap, a new release or a promise about next quarter's data.

Do not let accuracy become the goal. Accuracy is a proxy. The goal is inventory turns and service level, and a feed can be more accurate on average and worse exactly where it counts, because it is the tail of the error distribution that triggers the expedite, the premium freight and the phone call. Score the ninetieth percentile of absolute error rather than the mean, and put that number on the same page as the cover you hold, so the two are argued about together instead of separately.

Set the thresholds now, while nothing is at stake. P90 absolute arrival error at three days out, in hours, with a target of thirty-six hours within two quarters from your own measured baseline. Feed availability at or above 99.5 per cent, measured monthly by your own ingestion logs rather than by the provider's status page. Notification latency, meaning the time from an authority publishing a traffic restriction to it appearing in your planning system, at thirty minutes during working hours and one hundred and twenty out of hours. Completeness of strait transit entry and exit timestamps on at least 90 per cent of your sailings within one quarter. And an override rate: if your operators override more than 40 per cent of automated flags for two consecutive weeks, stop and investigate before you scale anything.

The traps, and they are mostly the same ones I see every quarter. Buying the dashboard before the baseline, which means you will never be able to prove the dashboard did anything. Treating an authority's information service as a commitment to you, when it is published to vessels and the release offers you no service level at all. Reading "performing as expected in normal operations" as a claim about the bad day, which it is not. Confusing the source system's availability with the availability of the data to you: their redundancy is not your pipeline, and your pipeline is the thing that actually fails. And letting one season teach the model, because a strait in February is not a strait in July, and a baseline that does not span a season change has not measured anything yet.

Two more things I would refuse to do. I would not build a business case on a press release with no numbers in it, and this one has none. And I would not tell you which supplier to buy; the class of system matters, the name on it does not, and your own twelve-week baseline will tell you more than any reference site ever will. I will also not tell you the strait got faster. It did not. The channel is the same width it was last week, the bridge is the same bridge, and no amount of maritime domain awareness adds a lane to either of them.

What changed is narrower than the headline and more useful than the headline. A busy chokepoint is now better observed by the authority that runs it, and observation is worth money to you only if somebody downstream changes a decision because of it. That is the whole mechanism, and it is a boring one: better input, lower error, less cover. Quantify it first, then optimise it, and if you cannot quantify it, do not optimise it. The queue in front of the strait has not moved. The size of the bet you place on where that queue ends can move, and that is the only thing here with a number attached.

↑ Back to the key points

— By Ravi Chandran