StrategyTechnology

Stop waiting for the standard. It is not coming, and you do not need it.

Every maritime digitalisation panel ends with the same call for common data standards. It sounds responsible, offends nobody, and can never be proven wrong, because the standard is always somewhere in the future. We argue it is not coming: no regulator mandates a data interface, no buyer group has the pull to force one, and the incentives to share are weak. Even a standard agreed tomorrow would reach the fleet at the pace of newbuilding, over two decades. Meanwhile CII, EU ETS and FuelEU Maritime charge shipowners today, on data most of them do not fully trust. Standardisation is a software problem, not a committee problem: contextualise your own fleet’s data once, and standards become an output format, not a prerequisite.

Stop waiting for the standard. It is not coming, and you do not need it.

Stop waiting for the standard. It is not coming, and you do not need it.

Every maritime digitalisation panel ends the same way. Someone on stage says, "What this industry really needs is common data standards." The room nods. The moderator thanks the panel. Nothing changes, and the next panel says exactly the same thing.

It's a comfortable line. It sounds responsible, it offends nobody, and it can never be proven wrong, because the standard is always somewhere in the future. That is precisely why we should stop saying it. "We need standards first" has become the industry's most respectable way of not acting.

Why the standard is not coming

Three structural facts stand in the way, and none of them will change in the next decade.

Fragmentation at every step. A single vessel carries equipment from dozens of manufacturers, integrated by a yard with its own conventions, classed by one of a dozen societies, flagged in one jurisdiction, owned in another, managed in a third and chartered by a fourth party with its own reporting demands. Onboard, the data speaks Modbus, serial, proprietary OEM protocols and analogue signals, and a good share of it exists only in PDF reports. Other asset-oriented industries, like aviation and automotive, did get common data standards, but nobody volunteered. In the US, regulators made OBD-II diagnostics compulsory for new cars. In aviation, the airlines themselves, through ARINC, a company they jointly owned, wrote the interface specifications that equipment suppliers had to meet. Shipping has neither: no regulator mandating a data interface, and no group of buyers with that kind of pull on suppliers.

The incentives to share are weak, and rationally so. Equipment manufacturers earn service revenue from knowing more about their machines than the owner does. Open data is, from their point of view, giving that away. Owners in turn treat operational data as competitive and share it reluctantly. And nobody pays for a standard. There's no revenue in writing one and no penalty for ignoring one.

There is no regulatory mechanism for data semantics. The IMO works in decades and regulates outcomes, not the data model underneath them. It requires that you report fuel consumption; it has no view on how your flow meter names its tags. Class societies compete with each other, and no single one can mandate a data model across the world fleet. Nobody is building the lever that would make a data standard compulsory, and without that lever, voluntary alignment across thousands of independent actors is a hope, not a plan.

The standards themselves do exist. ISO 19848 defines data channels and introduces DNV VIS and JSMEA as naming rules, and a few infrastructure providers, ourselves included, use them as canonical models. What none of them reach is the OEM interface on the ship. The standard describes what the data should look like after somebody has done the mapping. It doesn't do the mapping.

The legacy fleet makes the argument moot anyway

Suppose we are wrong. Suppose the industry agrees on a complete, elegant data standard tomorrow and every equipment manufacturer adopts it.

It would apply to newbuilds. Ships live 20 to 30 years, and the world fleet is getting older, not younger. Most of the vessels operating in 2040 have already been built, with the interfaces they have today. A standard adopted now reaches the fleet at the pace of newbuilding, one ship at a time, over two decades.

And even the standardised newbuild drifts. Sister vessels are less identical than the name suggests, and even genuinely identical ones start diverging the day they hit the water, because upgrades happen vessel by vessel, not fleet by fleet. Whatever solution the industry lands on will have to handle heterogeneous, non-standard installations for the next 15 to 20 years regardless, which means a standards-first strategy is solving the wrong problem.

The real cost of waiting

"We are waiting for standards" is decision deferral with a respectable name, and the bill is no longer theoretical. CII, EU ETS and FuelEU Maritime charge shipowners today, based on data most of them do not fully trust. Every year spent waiting is a year of poorer decisions on fuel, maintenance and compliance, and a year of operational knowledge leaving with retiring crews. The people who are comfortable waiting are, in our experience, rarely the people accountable for the vessel's performance.

Standardisation is a software problem, not a committee problem

The industry doesn't need to agree on one data model for everyone to use. Each owner needs the data from their own fleet contextualised correctly once, and a layer that can deliver it to any consumer in whatever format each consumer needs.

That layer sits between the ship and the owner's cloud. It captures whatever the vessel speaks, whether Modbus, serial, an OEM API or a file from an existing collector. It maps each signal to a canonical model and contextualises it, so that a tag isn't just a number but a specific measurement on a specific engine, in a known unit, with a known quality. And it lands the result in the owner's own environment, under the owner's control.

Once the contextualisation is right, standards stop being a prerequisite and become an output format. This isn't a thought experiment; it's how owners already behave when given the choice. One of the largest independent shipowners in the world runs more than 350 vessels with a variety of data collectors, from the yard, from their own installations and from acquired fleets, and gets one coherent dataset out of all of them because the mapping happens above the collectors, not in them. Owners we work with routinely ask for delivery of data in their own in-house naming standard, in JSMEA and in DNV VIS at the same time. Those naming rules describe the same ship at different levels of detail, so converting from one to another often loses something. None of these owners are waiting for the industry to pick one. They want - and need - all of them, and only a mapping layer makes that possible.

The mapping is never finished, though. OEMs update interfaces, sensors get replaced, a collector vendor changes its API, and a fleet's worth of tags has to be remapped. Meanwhile, people have built reports and dashboards on top of those names. Rename one, even to fix a mistake, and their numbers quietly break. Every change has to be weighed against who depends on it, and somebody has to own those decisions for years. That is governance, not a translation table. It's also where you learn that most of the data a vessel produces will never be looked at, and that the small share people do rely on has to be right: a measurement means nothing until you know what it measures, where, and under which conditions, and that knowledge comes from understanding ships, not from the data itself.

Standardisation is an operated function, not a one-off project. That's a reason to start now, not later: the work exists whether or not a committee ever agrees, and the owners who have started are the ones who already know how to absorb it.

The industry-wide standard, if it ever comes, will come out of layers like this, bottom-up, as a description of what the working systems already do. That is how standards emerged in every other industry. Standards are downstream of practice, not upstream of it.

What this means if you own or manage ships

Stop treating the standards committee as a substitute for starting.

Start capturing now, across the fleet you have, not the fleet you might order. The legacy vessel with the mixed OEM setup is the normal case, not the exception, and it's exactly where the value sits. If you already have collectors on board, keep them; the layer above them is what has been missing.

Insist on vendor neutrality and owner-controlled data. The data lands in your cloud, in your model, and you can export it and leave. The layer can be neutral even where the industry isn't standard. Judge any provider on that test.

Adopt existing vocabularies internally where they fit. DNV VIS or JSMEA are reasonable canonical models for your own fleet. Just don't wait for your suppliers to adopt them before you do.

Two objections, and a disclosure

"If everyone builds their own layer, we end up with proprietary silos." This statement is true, if the layer is closed. That's why the test above matters. What you are looking for is a layer that allows data accessible and open, in any standard, irrespective of where you want to use your data. A silo you own, control and can leave isn't a silo.

"You are just moving the lock-in from the OEM to the platform." Partly fair, and worth taking seriously. The difference is who owns the data and the model, and whether you can walk away. Ask that question of every vendor, including us.

And yes, we are a company that builds this layer, so read this with that in mind. But the argument doesn't rest on who makes it. It rests on the structure of the industry, and that structure isn't changing in time for anyone to wait it out.

Standards are what an industry writes down after it has already solved the problem.

Solve the problem.

Sondre Midtbust Stang

Sondre Midtbust Stang

Maritime Data Engineer

Sondre shapes Raa Labs' maritime data architecture, setting the standards that give vessel data structure and context at fleet scale.

Meet the Raa Labs team →
← Back to all posts
Strategy

Why maritime AI projects fail - and how to fix it

While maritime executives rush to embrace AI, a critical challenge remains overlooked: the quality of data feeding these systems. Without reliable, accurate, and consistent data, AI initiatives are doomed to fail. Before jumping on the AI bandwagon, maritime organizations must focus on building their data foundation. Learn more about the success factors for your AI project.

Read →
Whitepaper

Reliable vessel data at fleet scale

This white paper tells the story of how Eastern Pacific Shipping, one of the world's largest ship owners, moved from data-rich to data-ready across a fleet of more than 350 vessels. Working with Raa Labs, EPS built a unified vessel data foundation that standardises fleet data, monitors its health continuously, and delivers it through structured APIs and a conversational MCP to interact with the data through LLMs and AI chatbots. Readers come away with a clear example of how treating vessel data as governed infrastructure, not fragmented telemetry, can unlock performance, sustainability, and AI at fleet scale.

Read the whitepaper →
Technology

Why contextualization is critical

Vessel comparison is impossible without - if you want to use your operational vessel data in a meaningful way, you need to ensure proper contextualization of your data tags

Read →
Newsletter
Stay in the loop
Occasional insights on vessel data and maritime intelligence.
By submitting, you accept to be added to our newsletter distribution list.