Fleet Schema vs. Common Data Model: Key Differences
A common data model is a governed, shared specification that gives many systems one agreed set of names, formats, structures and relationships. It lets them exchange data without each pair needing its own translator. A fleet schema is that same idea applied to a mixed-OEM vessel. It adds the equipment hierarchy, maintenance and work-order records, warranty/vendor/procurement links and personnel data that a generic model does not define. This lets an ops manager compare two vessels from different OEMs on one footing.
What is a common data model and what problem does it solve?
A common data model gives participating teams and systems a governed specification for selected business data. It defines shared names, formats, structures, and relationships without requiring every source to use the same schema or database. As ThoughtSpot explains, it creates an agreed representation across a defined group of participants.
The core problem is the combinatorial explosion of point-to-point integrations. With n systems, direct mappings grow as O(n²). A shared model reduces them to O(n). As Alation notes, instead of requiring point-to-point mappings between every system, CDMs allow each system to map to a single, shared model. This simplification accelerates development and lowers maintenance overhead as enterprise ecosystems grow.
The Microsoft Common Data Model provides a shared data language for business and analytical applications. It includes standardized, extensible data schemas with entities, attributes, semantic metadata, and relationships. These schemas represent commonly used concepts to simplify the creation, aggregation, and analysis of data.
How do equipment OEMs publish telemetry?
Each OEM names its signals, chooses its units and assigns its own identifiers for the same physical quantity. A coolant temperature might be "CT_TEMP" in °C on one engine and "Coolant_Temp_F" in °F on another, under different channel IDs. This is not a data-quality problem; it is a naming-and-units problem that must be mapped before comparison is possible.
ISO 19848 defines LocalID as a unique and standard identification of each sensor or data channel onboard a given ship. DNV's naming rule defines how such a LocalID can be generated using Reference libraries and associated codebooks. However, OEM platforms still ship their own conventions. The standard provides a stable identifier for the sensor, but it does not force the OEM to name its signal or choose its unit in a way that matches another manufacturer.
This fragmentation means that two vessels with different OEM engines cannot be compared directly from their raw telemetry feeds. The signal names, units and identifiers differ between manufacturers. A fleet schema must map each manufacturer's signals to shared fields before any cross-asset analysis is possible.
Which industry standards exist for vessel data exchange?
ISO 19848 covers sensor identification via LocalID. DNV's VIS-based naming standard builds on the Vessel Information Structures model maintained since 2005. OPC UA serves as a field-level transport protocol. ISO 19847 handles data exchange between shipboard systems. These are the main maritime-specific standards for identification and transport.
Broader patterns show the same canonical-model idea applied in other domains. Microsoft's Common Data Model standardizes business entities. CMIS provides a common data model for typed files and folders in content management. OMOP created a common data model for claims and electronic health records. None of these define the full fleet schema a maritime operator needs. They cover identification and transport, not the maintenance, warranty and procurement relationships that make operational comparison possible.
A fleet schema uses these standards as inputs but goes beyond them. It must link sensor data to maintenance events, warranty terms and procurement records. The standards give you a stable ID for a sensor; the schema gives you the context around that sensor.
How should maintenance records and hierarchies be structured?
The hierarchy runs vessel → system (e.g. main engine, auxiliary generator) → component (e.g. cylinder liner, fuel injector). Each level carries a unique identifier. Maintenance events and work orders link to the component they apply to, not just to the vessel or system. This lets a query pull every work order for a specific component across all vessels, regardless of OEM.
Structuring records at the component level is critical for cross-asset comparison. If a work order only references the vessel, you cannot isolate the performance of a specific part type across your fleet. Linking to the component allows you to compare failure rates, maintenance intervals and costs for the same part type installed on different vessels with different OEM engines.
The unified operational data model normalizes these records into one schema with consistent identifiers and typed relationships. This structure holds up when a new tool is pointed at it. The component-level link is what makes the data machine-readable for operational queries, not just human review.
What fields does a fleet schema need beyond telemetry?
Beyond normalized sensor signals, a fleet schema carries warranty terms keyed to component serial numbers. It includes vendor and procurement records tied to the components they supply. Personnel and technician assignments are linked to work orders. Institutional knowledge, such as procedures, manuals and undocumented fixes, is attached to the equipment they apply to. Each of these is a typed relationship in the schema, not a separate file or spreadsheet.
Telemetry is only one layer. The operational value comes from the links between layers. A sensor reading linked to a maintenance event, a warranty term and a technician's note creates a complete picture of an asset's condition and cost. Without these links, you have isolated data points that require manual reconciliation to answer operational questions.
The model-agnostic data layer normalizes an organization's operational data once, so any authorized tool can query it without a custom integration for that source. This includes financial and warranty records alongside telemetry and personnel data. The typed relationships allow a query against one asset to pull all relevant data together, rather than requiring someone to check five separate systems by hand.
How do you map and normalize differing units?
The mapping is done once: each OEM's signal name, unit and identifier is translated into a shared field in the unified schema. The original value is preserved alongside. Units are converted to a canonical unit, such as all temperatures to °C, at load time. The original unit is stored as metadata so no information is lost. The translation is a one-time reconciliation, not a per-query transformation.
This approach prevents meaning loss during normalization. By preserving the original unit and identifier as metadata, you maintain traceability back to the source system. If a discrepancy arises, you can verify the conversion against the raw value. The shared field provides a consistent basis for comparison across assets, while the metadata preserves the specific context of each OEM's output.
This one-time mapping is what makes the schema sustainable. New tools connect to the shared fields, not the raw OEM signals. The translation work is done once, so new models, agents and dashboards connect to the same schema instead of each needing its own connectors. This reduces the integration tax that accumulates when every new tool requires a custom pipeline.
How does a fleet schema differ from a generic CDM?
A generic CDM defines entities like "Asset" or "Equipment" with attributes and relationships. It does not specify the maritime equipment hierarchy, OEM signal mapping tables, work-order-to-component links, or warranty terms keyed to serial numbers. A fleet schema is a CDM instantiated for maritime operations. It inherits the shared-specification pattern and adds the domain-specific fields and typed relationships that make cross-OEM comparison possible.
The table below shows how a generic CDM entity differs from the fleet-specific fields a maritime schema must add.
| Generic CDM Entity | Fleet Schema Addition | Purpose |
|---|---|---|
| Asset | Equipment Hierarchy (Vessel → System → Component) | Enables component-level comparison across vessels |
| Equipment | OEM Signal Mapping Table | Normalizes signal names, units and identifiers |
| Record | Work-Order-to-Component Link | Tracks maintenance history per part type |
| Vendor | Warranty Terms Keyed to Serial Numbers | Links coverage to specific components |
The fleet schema is more specific than a generic CDM. It defines the exact relationships needed for maritime operations, such as linking a procurement record to a component serial number. This specificity is what allows operational queries like cost per operating hour or root-cause tracing across multiple data sources.
What breaks when you skip the shared schema?
Without a unified schema, each new tool needs its own connector to every source system. That is the integration tax: rebuild the same mapping work for every new consumer. A data lake defers the reconciliation to read time, so it repeats on every query. A warehouse forces it at load time but only for the questions someone planned for. The shared schema does the translation once, so any authorized tool queries the same structure.
Consider a fleet running three OEMs plus a historian and a maintenance system. That is five systems. Point-to-point integration requires 10 translators (5×4/2). A canonical model requires 10 mappings (2×5), where each system maps in and out of the shared model. At eight systems, point-to-point requires 28 translators, while the canonical approach needs 16 mappings. The linear scaling of the shared model keeps integration manageable as the fleet grows.
Skipping the schema means every new dashboard, AI model or compliance report triggers a new round of custom connectors. This rework consumes engineering time and introduces inconsistencies between tools. The shared schema eliminates this by providing a single, stable interface for all downstream consumers.
Where does this lead for a fleet operator?
The next step is to see how the unified schema handles a specific operational question. This includes comparing two vessels with different OEM engines, tracing a recurring failure across maintenance logs and procurement records, or calculating true cost per operating hour from linked telemetry, warranty and vendor data. The schema is the foundation; the operational questions are what it answers.
Understanding how AI needs unified telemetry on a mixed-OEM fleet shows the practical benefit of this structure. Similarly, seeing why cost per operating hour calculation breaks down on a mixed fleet without a shared schema highlights the operational gaps that remain when data is siloed. The common data model concept provides the architectural pattern; the fleet schema implements it for your specific operational needs.
To see how this applies to your own systems, contact our team for a demonstration of how the model would be built from your existing data sources.
Related resources
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.