SECOM Terminal & S‑100 Route Exchange: Building the Foundation

In this article, Andy Murray of Raymarine Commercial unpacks frequent misconceptions about S‑100 and explains what they really mean from a cartographic and implementation standpoint.

If you’ve been in any S-100 meetings in the past year, SECOM has come up roughly once a slide. It tends to get talked about as a future-state catch-all for everything S-100 will eventually deliver to the bridge. That framing isn’t wrong, but it’s getting in the way. In 2026 the SECOM Terminal has one practical job the industry is genuinely close to operationalising: route exchange. 

Everything else is going to take trials. Worth saying out loud, because the gap between “the standard supports it” and “you can rely on it on a paying voyage” is where the next two years of work actually sit. 

The plain English version is below. If your business depends on getting this right, the source documents are the current drafts of IEC 61174 Edition 5 and IEC 63173-2. Read them. 

First pass: route exchange 

S-421 is the data product for routes. Ship to shore, ship to ship, shore to ship. A route described in a standardised, machine-readable form, signed and exchanged between systems that don’t need to know anything about each other beyond how to speak SECOM. 

This is the use case the SECOM Terminal was effectively designed around first, and it’s the one closest to being usable in earnest. Pilot stations sending a recommended route to an inbound vessel. VTS sharing a routing instruction. A shore-based fleet operations centre coordinating a route change with a master. A pilot boarding with their planned passage already loaded on the bridge before they step off the launch. 

The pieces exist. IEC TC80 Working Group 17 is closing out the last of the S-421 issues. Sea trials have given us real evidence of what works and what still needs sharpening. 

Don’t disturb WEND for the heavy data yet 

Here’s where the conversation needs to get more disciplined. The SECOM Terminal is, by design, agnostic about what it carries. So in principle, once you’ve got the Terminal and an S-100 approved ECDIS, you can pipe S-102 high-resolution bathymetry, S-104 water levels, S-111 surface currents and the rest down the same secure pipe. 

In practice the heavy data products (charts, bathymetry, the things vessels carry gigabytes of) are distributed today under the WEND principles for very good reasons. WEND has taken decades to harmonise. The producer responsibilities are clear. The commercial models work. The operational reliability is proven. We should not be tinkering with that while we’re still establishing if the SECOM Terminal model works at all. 

The right sequence is: ship route exchange in earnest as the foundation. Use it to prove the SECOM model holds up on real bridges. Then, on top of type approved S-100 ECDIS, run structured trials of harmonised distribution for the heavier data products. Learn what changes and what doesn’t. Learn what new producer obligations the model creates. Feed that evidence back into WEND when there’s enough of it to justify changing anything. 

If we keep trying to solve the edge of every problem before we start, then we never build a foundation. The whole point of starting with route exchange is that it’s a self-contained capability with a well understood operational role. It doesn’t disrupt anything we already rely on. 

“Last mile” is simpler than people make it sound 

The other piece of jargon that tends to confuse this conversation is “last mile”. I’ve seen it treated as if it means a satellite link, or a separate piece of hardware, or some new layer of comms infrastructure that has to be procured. 

It doesn’t have to be any of those things. One way to do it, in its simplest form, is an IP connection at the IEC 61162-460 gateway, which is the secure maritime ethernet gateway already present on type approved bridges. The SECOM Terminal then is a software application sitting on that gateway. Other implementations are possible, but this is the cleanest version, and it’s a good one to anchor the conversation on. 

The IP connection itself is agnostic about how it gets to shore. It can ride over whatever comms the vessel already has. It might be ship-provided VSAT or LTE. It might be a manufacturer-provided link. It might be a mix that fails over between them. The Terminal doesn’t care, because IP doesn’t care. 

Once you draw it that way, a lot of the supposed complexity falls out. The gateway is already the boundary between the ship’s bridge network and the outside world. It already enforces the cyber resilience requirements of 61162-460. The Terminal is one more service running on it, alongside whatever else is there. The “last mile” is just the IP path from that Terminal to its shore counterpart, over whatever comms link is up. 

This matters commercially. The shipboard footprint for adopting route exchange is a software addition to equipment that’s already on the ship. Not a new box. Not a new cable run. Not a new training programme for the crew on hardware they’ve never seen. 

What you actually need on the ship 

For route exchange specifically: an S-100 approved ECDIS. IEC 61174 Edition 5 defines what that means and how it will be tested. An IEC 61162-460 gateway, which the bridge probably already has. A SECOM Terminal as a software application running on that gateway. An installed certificate chain that the rest of the maritime ecosystem trusts. A connectivity path with enough reliability for the exchange to be useful in the moments it matters, riding over whichever comms link is available. 

That’s the foundation. Once it’s in service and proven, the trials for the heavier S-100 data products can run on top of the same approved equipment, without disturbing the WEND distribution channels that are working today. 

Keep it incremental, or it won’t happen 

This whole thing has to be incremental. Get route exchange running on real ships. Build the trials for additional data products on top of that, over the coming years. Expand as the operational evidence justifies it. 

The alternative is we spend the next ten years trying to regulate something we haven’t yet operated. That’s how good ideas die in committee. We’ve seen it happen before, and there’s no reason to do it again with this one. 

The question that has to anchor the work is the one we sometimes lose sight of in standards rooms: what is the benefit to the mariner, and what is the benefit to the vessel owner or operator? If we can’t answer that for a given step, we shouldn’t be taking that step yet. If we can, the case writes itself. 

Read the drafts 

If you want to influence what this looks like, the window is the current draft cycle of IEC 61174 Ed5 and IEC 63173-2. Comments still get in. The text still moves. Once the standards publish, you’re working around them instead of shaping them. 

The SECOM Terminal will end up being the part of the bridge nobody talks about, because it’s working. We get there by being honest about what’s ready, what needs trialling, and what benefit any of it delivers to the people on the bridge and to the people paying for the ship. And by reading the drafts that decide all of it.