Vessel Data Integration Platform

A vessel data integration platform collects data from a ship's many systems, gives it one consistent structure, and keeps it available on board and ashore. The crew, the technical team and every connected application then work from the same numbers.

Most fleets do not lack data. They lack agreement about it. The noon report, the flow meter total, the tank soundings and the performance platform's estimate are four versions of yesterday's fuel consumption, and they rarely match. An integration platform exists to replace those versions with one agreed version.

That sounds like an IT project, but the decisions that determine success are operational:

• Which types of data need to flow in which direction
• Which side's version wins when ship and shore disagree
• What every signal is called, in which unit, and at what time
• Who owns the data and who may use it

This guide covers those decisions for shipowners, ship managers, and the technical and IT teams who work with them. It focuses on the data foundation itself. For what shore teams do with that data, such as condition tracking and alerts, see our guide to remote vessel monitoring systems.

What Is a Vessel Data Integration Platform?

A vessel data integration platform is the layer between the systems that produce ship data and the applications that use it. It collects data from onboard and shore sources, gives it a common structure and naming, stores it, keeps ship and shore copies in sync, and makes it available to people and applications through defined interfaces.

Three Things the Term Can Mean

The phrase is used for three different kinds of integration:

The first is usually a feature of chartering and commercial management software. This guide covers the second and third, because together they decide whether ship and shore actually see the same data.

Gateway, Data Lake or Platform?

Several product categories cover part of this layer, and the gaps between them are where integration problems start:

• An IoT gateway collects and forwards onboard data but usually leaves naming, storage and access to whatever sits on the shore side.
• A shore data lake handles analysis but does nothing for the crew, for naming at the source, or for syncing records back to the ship.
• Monitoring and fleet management applications often include their own collection layer. What matters is whether that layer is open to other applications or private to the product.

That last point decides long-term cost. If each application brings a private data layer, every new application becomes a new integration project on every ship. See API Integration in Ship Management for how open platforms connect third-party applications.

Why Ship and Shore End Up With Different Data

Few fleets choose fragmented data. It builds up because systems are bought one at a time, and each supplier has good reasons to bring its own data collection:

• Equipment makers install their own gateways to support diagnostics and service contracts on their equipment.
• Application vendors install their own data boxes because they cannot rely on data from another supplier's system.
• Business software such as maintenance and purchasing systems runs its own ship-shore replication, separate from any sensor data.

Each decision makes sense on its own. Together they produce parallel data paths, each with its own tags, timestamps and access rules. With N data sources and M applications, point-to-point integration can need up to N × M connections. A shared platform needs N + M.

The fix is therefore partly technical and partly a purchasing policy. A platform provides the shared layer. Contracts and specifications make new suppliers deliver data to it instead of building another path beside it. The roadmap below covers the contract side.

Six Types of Vessel Data and How Each Should Move

The most common design mistake is to treat all ship data the same way. Different types move in different directions and at different volumes, and each needs its own synchronization method.

Mixing up the methods causes predictable failures. Treat maintenance records like a sensor stream and edits made ashore never reach the ship. Treat sensor data like records and the satellite link fills with data nobody needed at full resolution.

Decide Which System Owns Each Data Path

Few products handle all six types equally well. Sensor data platforms are built for high-volume, one-way streams. Maintenance and purchasing systems usually have their own two-way replication for records. Forcing one product to do both often produces a weak version of each.

A common and workable split looks like this:

• The integration platform owns sensor data, events and the data channel definitions.
• Business systems keep their own record replication.
• The two are joined by shared identifiers, such as linking each data channel to a maintenance component code, rather than by copying data between them.

The point is to make this split an explicit decision. Otherwise it happens by accident. The overlap between types can then be used on purpose. For example, much of a noon report already exists as sensor data, so the platform can pre-fill it and the crew only checks and confirms. See automated voyage reporting.

Architecture: What Runs On Board and What Runs Ashore

Onboard-First vs Cloud Relay

There are two basic designs for the onboard side:

• Cloud relay: a gateway collects data and forwards it. Data is organized and stored ashore. The crew sees it only through a connection to shore, if at all.
• Onboard-first: an onboard data server collects, names, stores and serves the data on the ship, and synchronizes with shore. The ship holds its own complete copy.

If the goal is the same data on ship and shore, only the onboard-first design actually delivers it:

• The ship keeps working during outages. Onboard applications and crew displays do not depend on the satellite link.
• High-resolution data stays available. The ship can keep, for example, one-second data for several weeks, while shore receives summaries and requests detail when needed.
• The crew becomes a user, not just a data source. Engineers use the same trends and applications as the office, which changes how the system is received on board.
• Onboard applications have one source. Crew-facing tools read from the server instead of building their own connections to equipment.

The shore side then holds fleet-wide history, joins ship data with shore data, and serves shore applications through APIs. Whether it runs in the cloud or on your own servers is a separate decision. See Cloud vs On-Premise Ship Management Systems.

Splitting the Work Between Ship and Shore

Most tasks have an obvious home. Three are worth deciding deliberately:

• Data-quality checks belong on board, before summarizing. Once a frozen or out-of-range value has been averaged into a one-minute summary, it is much harder to spot ashore.
• Summaries should be calculated on board. That keeps the satellite traffic down and makes sure the ship and shore summaries are calculated the same way.
• Models are trained ashore but can run on board. A model trained on fleet history can be deployed to the onboard server so its results do not depend on the link, and so the crew sees the same results as the office.

Designing for Disconnection

The link will fail, sometimes for hours and sometimes for days. A platform built for ships treats disconnection as normal operation, not as an error:

• Onboard applications work without shore. Nothing the crew depends on should need a live connection.
• Queued data keeps its original timestamps and order. When the link returns, data is backfilled as it was recorded, not stamped with the time it arrived.
• Resending never creates duplicates. After a partial transfer, the same data will be sent again. The shore side must recognize it and not count it twice.
• Shore screens show how fresh the data is. A "last received" time on every ship view prevents anyone from mistaking hours-old values for current ones.
• Shore analysis handles late data. Daily totals and averages must be recalculated when backfilled data arrives, or reports will quietly differ from the underlying data.

Keeping Ship and Shore in Sync

One-Way Data: The Same Data at Different Resolutions

For sensor data, "the same data" should mean the same values and the same signal identities, not the same sampling rate. The ship keeps full resolution. Shore keeps summaries plus the ability to retrieve raw data for any period.

This only works if summaries are defined consistently. A one-minute value might be an average, the last value, or a minimum and maximum, and each gives a different picture of a fast-changing signal. The platform should record how every summary was calculated, so an analyst ashore and an engineer on board comparing numbers know they are comparing like with like.

Two-Way Data: Who Wins When Ship and Shore Disagree?

Records edited on both sides will eventually conflict. A typical case: during an outage, the chief engineer closes a maintenance job on board while the superintendent reschedules the same job ashore. When the link returns, there are two versions of one record.

"Last write wins," the default in many replication setups, silently discards one of the edits. The more robust approach combines two rules:

• Field-level ownership: each field has one owning side. The ship owns execution data such as completion date, running hours and work done. Shore owns planning data such as due dates, priorities and budgets. Both edits in the example survive because they touch different fields.
• A conflict queue for the cases no rule can settle, so a person decides instead of the software.

Master data follows the same logic. The equipment register and spare parts catalog are usually maintained ashore and pushed to the ship, and changes proposed on board go back as requests rather than direct edits.

Ask any vendor to show exactly what happens in the maintenance example above. The answer tells you more about the platform than most feature lists.

Time: The Integration Problem Nobody Plans For

Because clocks change as the ship crosses time zones, a noon-to-noon reporting day can be shorter or longer than 24 hours. Reports are usually written in ship's time. Sensor data may be stamped in UTC, or in the local clock of whichever onboard system recorded it, and that clock may drift or be reset by hand.

The consequences are easy to miss:

• A daily consumption figure from the noon report and a 24-hour total from flow meters cover different periods, so they never match, even when both are correct.
• Events recorded by two systems with unsynchronized clocks can appear in the wrong order, which misleads any investigation of a trip or failure.

The rules that prevent this are simple, but they have to be set before data is connected:

• Store every timestamp in UTC.
• Store the ship's time offset as a separate attribute so reports can still be shown in ship's time.
• Synchronize onboard clocks to a reliable time source such as GNSS time, and record which source each system uses.
• Compare reports and sensor totals over the same UTC period.

Standards and Data Models: Making Data Mean the Same Thing Everywhere

ISO 19847 (shipboard data servers) and ISO 19848 (standard data for shipboard machinery and equipment) are the reference model for ship data. Our remote vessel monitoring guide explains why they matter to buyers. This section looks at how ISO 19848 works, because that determines what "compliant" actually delivers.

How ISO 19848 Identifies a Data Channel

ISO 19848 gives each data channel, typically one sensor reading, a structured identifier called a Local ID. Instead of a free-text tag written differently by each supplier, a Local ID is built from defined parts:

• The naming rule used to build the ID
• The item: which equipment or component the value belongs to
• Metadata tags that describe the value, such as the quantity measured (for example, temperature), the content (for example, exhaust gas) and the position (for example, outlet)

As a simplified illustration of the structure (not a valid ID):

[naming rule] / [main engine > cylinder 3] / [quantity: temperature] [content: exhaust gas] [position: outlet]

The first edition of the standard introduced two naming rules. One comes from the Japan Ship Machinery and Equipment Association (JSMEA), which publishes a codebook and standard IDs for commonly used data channels. The other comes from DNV and is based on its Vessel Information Structure (VIS), a functional model of the whole vessel. The two differ in scope and detail. This has a practical consequence for buyers: ISO 19848 compliance does not by itself guarantee that two systems use identical names. Ask which naming rule and codebook version a platform uses, and how it maps between rules if your fleet uses both.

A Universal ID adds the naming entity and the ship's IMO number to the Local ID. Every data channel then becomes unique worldwide, so data from different ships, managers or companies can be combined without collisions.

ISO 19848 also separates two things that are often mixed up:

• The data channel list: metadata describing each channel, such as what it measures, its unit and its range
• The time-series data itself, packaged either as tabular data (values at regular intervals) or as event data (values recorded when something happens)

The data channel list is an asset in its own right, and it changes over a ship's life. Keep it under version control, with every added sensor, replaced transmitter and renamed channel recorded.

Interfaces: Why Breadth Means Independence

Onboard data reaches the platform through a mix of interfaces: IEC 61162 serial and Ethernet outputs from navigation equipment, Modbus from alarm systems and controllers, OPC UA (IEC 62541) on newer equipment, and file exports on older systems. The remote monitoring guide covers the practical obstacles with each.

Two points matter specifically for integration. First, OPC UA can carry a structured description of each value, not just the value itself. As more equipment supports it, mapping becomes easier. Second, the range of interfaces a platform accepts decides your independence from equipment makers. A platform that reads from whatever is installed lets you choose equipment on its merits. A platform that works best with its own hardware quietly narrows your future options.

Metadata That Keeps Data Trustworthy Over Time

Values stay reliable only while their context is recorded. The metadata that most often goes missing is:

• Calibration dates and sensor replacements. A new transmitter often causes a step change in a trend that looks exactly like a change in the machine.
• The link to the maintenance system. When data channels are linked to maintenance component codes, sensor trends and maintenance history appear on one timeline, and you can see an overhaul and the change in behavior together. This link is the practical foundation of condition-based maintenance. See marine condition monitoring.

Data Ownership, Access and Sharing

Owners, managers, charterers, equipment makers, shipyards, classification societies and platform vendors all have a legitimate interest in ship data, and contracts often say little about any of them. The charter party context deserves particular care: speed and consumption data can support or weaken performance claims, so decide in advance who may see which data, and when.

Settle these questions in writing before connecting the first signal:

• Who owns the raw data, and who owns what is derived from it, such as models, benchmarks and reports?
• May the vendor use your data, anonymized or not, to develop its own products?
• In what formats can you export all data and metadata, and on what terms when the contract ends?
• Which third parties may access which data, for how long, and who approves it?
• For ships under third-party management, what does the owner need to approve before data is shared?
• What happens to the data when a ship is sold or changes manager? Universal IDs based on the IMO number make a clean transfer technically possible. Whether it happens is a contract question.

Parts of the industry have set up shared frameworks for ship data. In these arrangements, common rules let data owners keep control while equipment makers and shipyards can obtain rights to use data with the owner's consent. Some separate a "cooperative" area, with shared rules for collecting and distributing data, from a "competitive" area where companies build their own services. Whether or not you join such a framework, it is a useful model for your own contracts.

Inside the platform, grant access by role, ship and data group, and log it. A maker's service engineer needs one engine's data for a defined period, not the fleet's full history. For the trade-offs between open and proprietary platforms, see Open vs. Closed Data Platforms.

Security for an Integrated Data Platform

Integration concentrates access. A single platform that reads from many onboard systems and connects to shore is exactly what an attacker would target, so it has to be designed into the ship's security architecture rather than added afterwards.

For ships contracted for construction on or after July 1, 2024, IACS Unified Requirement E26 sets the frame:

• Computer-based systems are grouped into security zones. Each zone is either isolated or connected to other zones and networks only through means that control the data passing between them.
• Systems within scope must not expose IP addresses to untrusted networks.
• Communication over untrusted networks must use secure connections with authentication and encryption.
• Only authorized mobile and portable devices may be connected.

UR E27 covers the security of the individual onboard systems and equipment.

For an integration platform, this translates into specific design choices:

• The onboard data server sits in its own security zone, with read-only connections to control systems.
• Data flows one way where it only needs to go ashore. Hardware that physically allows traffic in one direction (a data diode) removes a whole class of risk.
• Equipment makers get remote access through approved, logged, time-limited sessions, not permanent connections. This matters more on an integrated platform, because one maker's access route could otherwise reach other systems.
• Each party has separate credentials, so access can be reviewed and withdrawn per party.

For existing ships outside the scope of E26 and E27, the same principles are a sound benchmark.

How to Evaluate a Vessel Data Integration Platform: A Checklist

Use these questions in vendor meetings. Where possible, ask the vendor to demonstrate the answer with data from a ship like yours.

For a general vendor framework, see Ship Management Software Vendor Evaluation. For a side-by-side look at two vessel data platforms, see ClassNK CMAXS vs MaSSA-One: Vessel Data Platform Comparison. For more options, see our fleet management software comparison.

Implementation Roadmap

1. Take an inventory. For each ship type, list data sources, existing connections to shore, the applications that use them, and every place where the same figure is entered by hand more than once. The duplicates show where integration pays off first.
2. Decide the data rules before connecting anything. Choose the naming rule and required metadata, the UTC rule for timestamps, which system owns each data path, and which side owns each field of two-way records. These decisions are cheap at the start and expensive to change later.
3. Pilot on representative ships. Include at least one older ship. Measure data availability, the reduction in manual entry, and how closely report figures now match sensor data. See How to Test a Ship Management System Before Fleet-Wide Commitment and Retrofit vs Newbuild.
4. Write data requirements into purchasing. In newbuild specifications and equipment orders, require suppliers to provide a complete signal list using your chosen naming rule, to give data access through a standard interface, and to allow your platform and approved third parties to read the data. This stops new silos from forming while you remove the old ones.
5. Move existing connections onto the platform one application at a time. Replace point-to-point links gradually rather than switching everything at once.
6. Put governance in place. Name a data owner, set change control for the data channel list, and review data quality regularly. Integration decays without an owner.

The most common mistakes are connecting first and deciding naming later, letting each application define its own tags, and treating the crew as data providers rather than users. See 7 Ship Management System Implementation Mistakes to Avoid, How Much Does a Ship Management System Cost? and Ship Management System Installation Timeline.

FAQ

Do we need to replace existing onboard systems?

Usually not. An integration platform reads from existing alarm and monitoring systems, controllers and navigation equipment. Added sensors are needed only where a required signal does not exist.

Should every ship in the fleet use the same platform vendor?

It simplifies operation, but it is not strictly necessary. What must be common is the data model: naming rule, metadata and time rules. With a common model, data from different platforms can be combined ashore. Without one, even a single-vendor fleet can end up with inconsistent data.

Our sister ships have different signal lists. Is that normal?

Yes. Ships of the same design often differ in equipment makers, software versions and yard practice. Reusable mappings reduce the work, but each ship still needs its signal list checked rather than copied.

If two platforms both comply with ISO 19848, can they exchange data automatically?

Not always. They may use different naming rules or codebook versions. Compliance gives a shared structure, but names may still need mapping.

How much satellite bandwidth does integration need?

It depends mainly on how sensor data is summarized before it is sent. Most platforms keep full resolution on board and send summaries ashore. Documents and bulk transfers can be scheduled for port calls or low-traffic periods.

Who should own the platform inside our company?

Ownership is best shared between the technical department and IT, with one named data owner responsible for the data channel list, data quality and access rights. Platforms without an owner drift back into inconsistent data.

Can a ship's data history follow the ship when it is sold or changes manager?

Technically yes, if data uses universal IDs based on the IMO number and can be exported with its metadata. Whether it actually does is a contract question, so agree on it in advance.

Summary

A vessel data integration platform gives ship and shore one agreed version of the data instead of many competing ones. The technology matters, but the decisions that make it work are about the data itself:

• Keep a complete copy on board.
• Move each type of data in the way that suits it, and decide which system owns each path.
• Settle in advance who wins when records conflict.
• Store time in UTC.
• Name every signal to a standard and keep its metadata current.
• Settle ownership and access in contracts, and make new suppliers deliver data to the platform rather than around it.

Get these foundations right, and every later application, from monitoring to reporting to analytics, can build on data that everyone trusts.

Ready to compare solutions? See our fleet management software comparison.