ISO 19848 Shipboard Data Standard: What It Defines and Doesn't
The ISO 19848 shipboard data standard defines how sensors on a ship's machinery and equipment are named, how their measurements are structured, and how those data are described. It is written for people implementing software that captures and processes sensor data. It standardizes the sensor layer, not the maintenance, warranty or cost records around it.
What Does ISO 19848 Define?
According to the Vista summary of ISO 19848, the document applies to the structure of the ship and to shipboard machinery and equipment. It is a data standard: it fixes data concepts and data structures that a shipboard data server must use. Mind4Ship describes it, in its own explainer on ISO 19848, as a shared vocabulary for vessel data. The standard covers three things:
- Sensor measurement data, called time series data, in two forms: tabular data or event data.
- Sensor metadata, called the Data Channel Property, which describes each channel.
- A systematic way to name sensors, called the Data Channel ID.
How Does ISO 19848 Identify a Sensor?
The standard defines methods for building a local ID, which is a unique reference to a sensor on board one vessel. It also defines a universal ID that incorporates the IMO number, which makes the reference globally unique. Vista notes that the universal ID is a URI and could be a URL that represents that particular sensor signal.
The structure is flexible by design. Different naming entities can define their own naming rules, each with associated code books. The initial version introduced two: one from the Japan Ship Machinery and Equipment Association and one from DNV. DNV's rule is based on the Vessel Information Structures model.
That flexibility has a consequence. Following ISO 19848 does not by itself mean two vendors use the same names. Two systems can both conform and still choose different naming rules, so comparing them may still need a mapping between code books.
How Do ISO 19847 and ISO 19848 Fit Together?
ISO 19847 covers the shipboard data server. ISO 19848 supplies the data concepts and structures that the server must use. Mind4Ship describes the pairing as the basis for consistent analytics across a fleet. In plain terms, one standard describes the container and the other describes what goes in it.
What ISO 19848 Does Not Cover
A fleet's hard questions rarely stop at a sensor reading. Someone asks whether the component that ran hot was under warranty, which procedure the technician followed, or what an asset costs per operating hour. The standard is scoped to sensor naming and sensor data, so those answers live elsewhere. The table shows where the boundary sits.
| Question a fleet asks | Sensor data standard | Unified schema layer |
|---|---|---|
| What is this sensor called, and what does it measure? | Yes: Data Channel ID and Data Channel Property | Carries the identifier forward |
| How is a measurement series structured? | Yes: tabular or event data | Treats it as one data type among several |
| Which maintenance work followed this reading? | Not covered | Links readings to maintenance logs |
| Is the component under warranty, and with which vendor? | Not covered | Links to warranty and vendor terms |
| Where is the procedure or the undocumented fix? | Not covered | Makes procedures and technician knowledge searchable |
| What is the true cost per operating hour? | Not covered | Combines telemetry with financial and procurement records |
This is where our work sits. We build a unified, machine-readable data model that normalizes OEM telemetry, maintenance logs, procedures and manuals, financials, warranty and vendor terms, personnel records, procurement data and institutional knowledge into one schema. We are starting with maritime. A standard for sensor naming is useful input to that kind of model, but it is one layer of it. Our posts on a unified data schema for industrial AI and on the unified operational data model for fleets cover the wider picture.
How a Sensor Standard and a Unified Schema Work Together
A sensor identifier that is stable and globally unique is exactly what a schema wants to attach other records to. If a channel has a persistent ID, a maintenance entry, a warranty term or a procedure can point to it and stay connected when a dashboard or a model changes. A fleet that already records ISO 19848 channel identifiers has a head start on that linking. A fleet that does not can still normalize its telemetry, but it has to assign the identifiers itself.
The same logic explains why the standard cannot make data AI-ready alone. Naming is one property of machine-readable data, which also needs typed relationships and a queryable structure. We explain that distinction in AI-ready versus machine-readable data, and the equipment hierarchy the identifiers hang from is covered in our guide to equipment taxonomy for maintenance data.
A Practical Check Before You Rely on the Standard
The standard itself is not free reading. Vista advises implementers to buy it from a national standards organisation or distributor, such as Standard Norge in Norway or DIN in Germany. The catalogue entry for ISO 19848 is a starting point for finding the edition you need.
FAQ
Is ISO 19848 the Same as ISO 19847?
No. ISO 19847 concerns the shipboard data server. ISO 19848 defines the data concepts and structures that server must use, including sensor naming, sensor metadata and the form of measurement data.
Does ISO 19848 make data from different OEMs identical?
Not automatically. The standard allows different naming rules with their own code books, so conforming systems can still differ. It gives a common structure and makes mapping far more tractable, but a comparison across manufacturers can still require translation.
Do I need to buy the standard to use it?
Implementers of a shipboard data server, or of selected ISO 19848 structures, should buy it from their national standards body or a distributor. Summaries from Vista and Mind4Ship are useful for orientation but are not the standard.
Does a standard replace a unified schema?
No. A sensor standard names and structures sensor data. A unified schema also holds maintenance logs, warranty terms, procedures and financial records, and relates them to each other. If you want to see how we would build that model from your existing systems, request a demo. Then test it with one sensor: can its identifier lead you to the work orders, the warranty terms and the procedure that apply to it?
Related resources
- One Schema for Telemetry, Procedures, Financials and Institutional Knowledge: A Unified Data Schema for Industrial AI
- Why Fleet Data Needs One Schema, Not One More Dashboard
- AI-Ready vs Machine-Readable Data: What It Means for Fleet Operators
- Equipment Taxonomy for Maintenance Data: A Practical Guide
- How Do You Track Warranty Claims Across Vendors? What a Unified Data Model Needs to Include
- Operational Data Stores vs. Unified Schemas: What Industrial Fleets Actually Need
- Root Cause Analysis for Vessel Maintenance: Why It Depends on Unified Data
SailPlan builds the machine-readable data model that makes every AI tool in your stack actually work. Request a demo to see it in action.