DTDLAzure Digital TwinsIoTMaritimeDigital Twin

DTDL Models for Maritime Assets

A complete guide to modelling vessels, equipment and IoT systems with Digital Twin Definition Language on Azure Digital Twins — including ISA-95 integration, edge computing and predictive maintenance.

Alberto Giacomel24 February 202612 min read

DTDL Models for Maritime Assets

Imagine receiving an alert at 03:00 that your vessel's main engine shows abnormal vibrations — before any mechanical failure actually occurs. This is the promise of maritime digital twins: a real-time virtual replica of the physical asset, continuously fed with sensor data, enabling predictive decisions instead of reactive ones.

The Digital Twin Definition Language (DTDL) is the standard that makes this possible on Azure Digital Twins. This guide walks through how to model vessels, engines, sensors and critical systems using DTDL v3 — from ontology design to cloud deployment.

Why DTDL for Maritime?

The maritime sector faces mounting pressure: IMO 2050 decarbonisation targets, rising fuel costs and ageing fleets demand smarter operations. Digital twins address all three:

Fuel optimisation — real-time hull/engine efficiency modelling can cut consumption by 10–15%
Predictive maintenance — condition-based monitoring reduces unplanned downtime by up to 25%
Regulatory compliance — structured telemetry simplifies CII (Carbon Intensity Indicator) reporting
Remote monitoring — shore-based teams gain full fleet visibility without physical presence

DTDL provides the semantic layer that connects raw IoT data to business-meaningful models — bridging the gap between OT (Operational Technology) and IT systems.

Introduction to DTDL

What is the Digital Twin Definition Language?

DTDL is a language based on JSON-LD (JavaScript Object Notation for Linked Data) that enables describing digital twin models and interfaces in a standardised, platform-independent way. Think of it as a schema language for physical assets: it defines what properties an asset has, what telemetry it streams, and how it relates to other assets.

Supported Versions

Version	Status	Notes
DTDL v2	✅ Supported	Legacy, still functional in ADT
DTDL v3	✅ Recommended	Feature complete, best practice for Azure Digital Twins
QuantitativeTypes	✅ Extension	Semantic units: knot, bar, degreeCelsius

Key Features

Platform-independent — Based on W3C standards (JSON-LD, RDF)
Versioning — Supports model evolution with versioned DTMIs (dtmi:maritime:Vessel;2)
Multiple Inheritance — Interfaces can extend multiple parent interfaces
Semantic Types — With QuantitativeTypes extension for units like knot, bar, litrePerHour
Graph relationships — Models the physical world as a queryable property graph

Azure Digital Twins, IoT Plug and Play, IoT Central, and the Device Models Repository natively support DTDL v3.

Structure of a DTDL Model

Every DTDL model is a JSON-LD file. The minimal structure requires @context, @id, @type and contents:

json

{
  "@context": "dtmi:dtdl:context;3",
  "@id": "dtmi:maritime:Vessel;1",
  "@type": "Interface",
  "displayName": "Vessel",
  "contents": [
    {
      "@type": "Property",
      "name": "imoNumber",
      "schema": "string",
      "comment": "IMO number — globally unique vessel identifier"
    },
    {
      "@type": ["Property", "Velocity"],
      "name": "speedOverGround",
      "schema": "double",
      "unit": "knot",
      "comment": "GPS-derived speed relative to the seabed"
    },
    {
      "@type": "Relationship",
      "name": "contains",
      "target": "dtmi:maritime:System;1",
      "comment": "Hierarchical link to onboard systems"
    }
  ]
}

Core Constructs

Construct	Purpose	Maritime Example	ADT Support
Properties	Configurable/queryable state	`imoNumber`, `vesselType`	✅ Full
Telemetry	Real-time data streaming	`speedOverGround`, `engineTemperature`	⚠️ Routing only
Commands	Executable actions	`startEngine`, `emergencyStop`	❌ Not supported
Relationships	Links between entities	`contains`, `powers`, `monitors`	✅ Full
Components	Reusable sub-systems	`navigationSystem`, `propulsionSystem`	✅ Full

ADT Note: In Azure Digital Twins, Commands aren't natively executed and Telemetry isn't stored in twin state. Route telemetry via IoT Hub → Azure Functions → ADT Property updates for queryable state.

Maritime Digital Twin Architecture

Asset Hierarchy

The ontology for maritime assets follows a 5-level hierarchy aligned with ISA-95 functional levels:

┌─────────────────────────────────────────────────────────────┐
│  Level 1: Fleet                                             │
│  └── contains → Vessel (IMO-registered)                     │
├─────────────────────────────────────────────────────────────┤
│  Level 2: Vessel                                            │
│  └── contains → System (functional grouping)                │
├─────────────────────────────────────────────────────────────┤
│  Level 3: System  (propulsion, power, cargo, nav...)        │
│  └── contains → Equipment                                   │
├─────────────────────────────────────────────────────────────┤
│  Level 4: Equipment  (engines, pumps, generators...)        │
│  └── monitoredBy → Sensor                                   │
├─────────────────────────────────────────────────────────────┤
│  Level 5: Sensor  (IoT — temp, pressure, vibration...)      │
└─────────────────────────────────────────────────────────────┘

ISA-95 Alignment

Maritime operations map naturally to the ISA-95 functional hierarchy used in industrial automation:

ISA-95 Level	Maritime Equivalent	DTDL Model
Enterprise (L4)	Shipping company	`dtmi:maritime:Company;1`
Site (L3)	Fleet / Port	`dtmi:maritime:Fleet;1`
Area (L2)	Vessel	`dtmi:maritime:Vessel;1`
Work Center (L1)	System (propulsion, cargo)	`dtmi:maritime:System;1`
Work Unit (L0)	Equipment + Sensor	`dtmi:maritime:Equipment;1`

This alignment enables bidirectional data flow: operational commands flow downward (L4→L0) while sensor data and KPIs aggregate upward (L0→L4), powering dashboards and ERP integration.

Relationship Types

Relationship	Direction	Description
`contains`	Fleet → Vessel → System	Hierarchical containment
`monitors`	Sensor → Equipment	Real-time monitoring
`partOf`	Equipment → System	Membership
`powers`	Engine → Propeller	Energy supply chain
`registeredTo`	Vessel → Company	Ownership
`berthedAt`	Vessel → Port	Operational context

Multiple Inheritance

DTDL v3 supports multiple inheritance to specialise models without duplication:

json

{
  "@id": "dtmi:maritime:MainEngine;1",
  "@type": "Interface",
  "extends": [
    "dtmi:maritime:Equipment;1",
    "dtmi:maritime:Monitored;1",
    "dtmi:maritime:Powered;1"
  ]
}

Changes to any base interface automatically propagate to all derived models, ensuring ontology consistency across the fleet.

Critical Ship Systems

Propulsion System

Components: Main Engine, Propeller, Gearbox, Shaft Line

Key Telemetry: RPM, shaft torque, oil pressure, bearing temperature, vibration signature

Use Case: Torque/RPM ratio analysis detects early propeller fouling — scheduling cleaning at port saves 3–5% fuel.

Power Generation

Components: Generators, Switchboards, UPS, Battery Banks

Key Telemetry: Voltage, current, frequency, active/reactive power, load factor

Use Case: Generator load forecasting enables intelligent load shedding during peak demand.

Cargo Systems

Components: Cargo Tanks, Ballast Tanks, Pumps, Valves, Inert Gas System

Key Telemetry: Liquid level, flow rate, pressure differential, temperature, vapour content

Navigation & Safety

System	Components	Critical Telemetry
Navigation	GPS/GNSS, AIS, ECDIS, Radar	Lat/Lon, SOG, COG, Heading, HDOP
Safety	Fire Detection, Bilge, EPIRB	Alarm state, bilge level, smoke density
Environmental	EGCS (Scrubber), NOx Monitor	SO₂/NOx ppm, wash water pH

Core Asset Models

Base Model: MaritimeAsset

All maritime assets extend this base interface for consistency:

json

{
  "@context": "dtmi:dtdl:context;3",
  "@id": "dtmi:maritime:MaritimeAsset;1",
  "@type": "Interface",
  "displayName": "Maritime Asset",
  "contents": [
    {
      "@type": "Property",
      "name": "assetId",
      "schema": "string",
      "writable": false,
      "comment": "Immutable unique identifier set at provisioning"
    },
    {
      "@type": "Property",
      "name": "operationalStatus",
      "schema": {
        "@type": "Enum",
        "valueSchema": "string",
        "enumValues": [
          { "name": "operational", "enumValue": "OPERATIONAL" },
          { "name": "degraded",    "enumValue": "DEGRADED" },
          { "name": "failed",      "enumValue": "FAILED" },
          { "name": "maintenance", "enumValue": "MAINTENANCE" }
        ]
      },
      "writable": true
    },
    {
      "@type": "Property",
      "name": "lastUpdated",
      "schema": "dateTime",
      "writable": true
    }
  ]
}

Vessel Model

json

{
  "@context": [
    "dtmi:dtdl:context;3",
    "dtmi:dtdl:extension:quantitativeTypes;1"
  ],
  "@id": "dtmi:maritime:Vessel;1",
  "@type": "Interface",
  "extends": "dtmi:maritime:MaritimeAsset;1",
  "contents": [
    { "@type": "Property", "name": "imoNumber",    "schema": "string" },
    { "@type": "Property", "name": "vesselType",   "schema": "string" },
    { "@type": "Property", "name": "flagState",    "schema": "string" },
    { "@type": "Property", "name": "yearBuilt",    "schema": "integer" },
    { "@type": ["Property", "Mass"],     "name": "grossTonnage",     "schema": "double", "unit": "tonne" },
    { "@type": ["Property", "Velocity"], "name": "speedOverGround",  "schema": "double", "unit": "knot" },
    { "@type": ["Property", "Velocity"], "name": "speedThroughWater","schema": "double", "unit": "knot" },
    { "@type": "Property", "name": "ciiRating",
      "schema": { "@type": "Enum", "valueSchema": "string",
        "enumValues": [
          {"name":"a","enumValue":"A"}, {"name":"b","enumValue":"B"},
          {"name":"c","enumValue":"C"}, {"name":"d","enumValue":"D"},
          {"name":"e","enumValue":"E"}
        ]
      },
      "comment": "IMO Carbon Intensity Indicator rating"
    },
    { "@type": "Relationship", "name": "contains",      "target": "dtmi:maritime:System;1" },
    { "@type": "Relationship", "name": "registeredTo",  "target": "dtmi:maritime:Company;1" },
    { "@type": "Relationship", "name": "berthedAt",     "target": "dtmi:maritime:Port;1" }
  ]
}

Main Engine Model

json

{
  "@context": [
    "dtmi:dtdl:context;3",
    "dtmi:dtdl:extension:quantitativeTypes;1"
  ],
  "@id": "dtmi:maritime:MainEngine;1",
  "@type": "Interface",
  "extends": "dtmi:maritime:Equipment;1",
  "contents": [
    { "@type": "Property", "name": "engineType",     "schema": "string" },
    { "@type": "Property", "name": "manufacturer",   "schema": "string" },
    { "@type": "Property", "name": "cylinders",      "schema": "integer" },
    { "@type": ["Property", "Power"],          "name": "powerRating",     "schema": "double", "unit": "kilowatt" },
    { "@type": ["Property", "Temperature"],    "name": "engineTemperature","schema": "double", "unit": "degreeCelsius" },
    { "@type": ["Property", "Pressure"],       "name": "oilPressure",      "schema": "double", "unit": "bar" },
    { "@type": ["Property", "VolumeFlowRate"], "name": "fuelConsumption",  "schema": "double", "unit": "litrePerHour" },
    { "@type": "Property",                     "name": "rpm",              "schema": "double" },
    { "@type": ["Property", "Acceleration"],   "name": "vibrationLevel",   "schema": "double", "unit": "metrePerSecondSquared" },
    { "@type": "Property",                     "name": "runningHours",     "schema": "double", "comment": "Cumulative running hours — drives maintenance scheduling" },
    { "@type": "Property",                     "name": "nextServiceDue",   "schema": "dateTime" },
    { "@type": "Relationship", "name": "powers", "target": "dtmi:maritime:Propeller;1" }
  ]
}

Sensors and Telemetry

Category	Measurements	Unit	Frequency	ADT Pattern
Temperature	Coolant, oil, exhaust, bearings	°C	1–10 Hz	Avg → Property
Pressure	Fuel injection, hydraulics, water	bar / psi	5–50 Hz	Avg → Property
Vibration	Engine, shaft, structure	m/s² / g	100–1000 Hz	RMS → Property
Flow	Fuel, cargo pumps, bilge	L/min, m³/h	1–5 Hz	Avg → Property
Level	Cargo, fuel, ballast tanks	m / %	0.1–1 Hz	Direct → Property
Position/GPS	Coordinates, AIS, gyrocompass	deg / knot	1–10 Hz	Direct → Property
Emissions	NOx, SO₂, CO₂	ppm / g/kWh	0.1–1 Hz	Aggregate → Property

Telemetry Pipeline

IoT Sensor
    │
    ▼
Azure IoT Edge  ◄── Local filtering, aggregation, ML inference
    │
    ▼
Azure IoT Hub   ◄── Message routing, device registry
    │
    ▼
Azure Functions ◄── Business logic, anomaly detection, ADT updates
    │
    ▼
Azure Digital Twins ◄── Twin state, graph queries, event routing
    │
    ▼
Event Grid / Event Hubs ◄── Fan-out to downstream consumers
    │
    ├── Power BI / ADT Explorer  (visualisation)
    ├── Azure ML                 (predictive models)
    └── ERP / CMMS               (maintenance work orders)

Edge-first strategy: Deploy Azure IoT Edge on vessel gateways to handle intermittent satellite connectivity. Models run inference locally and sync state when bandwidth is available.

Predictive Maintenance with Digital Twins

The combination of DTDL models and Azure ML enables condition-based maintenance — moving from fixed-interval servicing to data-driven interventions.

Failure Patterns Detectable via ADT

Failure Mode	Leading Indicators	Detection Method
Bearing failure	Vibration RMS ↑, temperature ↑	FFT analysis + threshold
Injector fouling	Fuel consumption ↑, RPM instability	Regression vs baseline
Propeller fouling	Speed/Power ratio ↓	Hull performance model
Pump cavitation	Pressure fluctuation + noise	Spectral analysis
Generator overload	Load factor > 85% sustained	Time-series anomaly

Data Quality Indicator

Each sensor reading should carry a quality flag to filter unreliable data:

Value	Status	Action
0–50	✅ Good	Valid for analytics and twin updates
51–80	⚠️ Uncertain	Flag for calibration review
81–99	❌ Bad	Exclude from models, raise alert
100	🚨 Sensor Error	Immediate maintenance ticket

ADT as Maintenance Context Engine

json

// Twin state after ML inference enrichment
{
  "$dtId": "main-engine-001",
  "operationalStatus": "DEGRADED",
  "vibrationLevel": 4.7,
  "predictedRUL": 312,
  "predictedRULUnit": "hours",
  "maintenanceRecommendation": "Inspect bearing #3 within 2 port calls",
  "lastUpdated": "2026-02-24T01:00:00Z"
}

Azure Digital Twins Implementation

Pre-Deployment Checklist

Define complete asset ontology — validate against ISA-95 hierarchy
Validate DTDL models with the official Azure DTDL parser before upload
Configure RBAC: Azure Digital Twins Data Owner for ingestion services, Data Reader for dashboards
Set up Azure Monitor alerts on twin property change events
Define telemetry retention policy (IoT Hub: 7 days; ADT properties: persistent)
Test offline edge scenario: validate IoT Edge buffering and sync behaviour

Querying the Twin Graph

ADT Query Language (ADT-QL) is SQL-like and supports graph traversal:

sql

-- All operational vessels
SELECT * FROM DIGITALTWINS
WHERE IS_OF_MODEL('dtmi:maritime:Vessel;1')
  AND operationalStatus = 'OPERATIONAL'

sql

-- Engines with high temperature — priority maintenance
SELECT E.$dtId, E.engineTemperature, E.vibrationLevel
FROM DIGITALTWINS E
WHERE IS_OF_MODEL(E, 'dtmi:maritime:MainEngine;1')
  AND E.engineTemperature > 90
ORDER BY E.engineTemperature DESC

sql

-- Full vessel → system → equipment traversal
SELECT V.$dtId, S.$dtId, E.$dtId
FROM DIGITALTWINS V
JOIN S RELATED V.contains
JOIN E RELATED S.contains
WHERE V.$dtId = 'vessel-001'
  AND IS_OF_MODEL(E, 'dtmi:maritime:Equipment;1')

sql

-- Fleet-wide CII rating distribution
SELECT V.imoNumber, V.ciiRating, V.grossTonnage
FROM DIGITALTWINS V
WHERE IS_OF_MODEL(V, 'dtmi:maritime:Vessel;1')

Implementation Roadmap

Phase	Activity	Output	Duration
1 — Discover	Asset inventory + ontology definition	Fleet asset mapping, DTMI naming convention	4 weeks
2 — Model	DTDL model development + validation	v3 models for Vessel, Engine, Sensor, Relationships	6 weeks
3 — Deploy	ADT instance setup + IoT Hub provisioning	Working cloud infrastructure, RBAC, model upload	3 weeks
4 — Connect	IoT Edge + IoT Hub integration	Live telemetry flow, Azure Functions processors	8 weeks
5 — Insight	Dashboards + ML models + alerting	Power BI fleet view, predictive models, CMMS integration	6 weeks

Total: ~27 weeks for a full fleet deployment of 10–20 vessels.

Expected ROI

Metric	Typical Benefit	Driver
Maintenance costs	−20 to −30%	Predictive vs. corrective
Fuel consumption	−10 to −15%	Hull/engine efficiency models
Unplanned downtime	−25%	Early fault detection
CII reporting effort	−60%	Automated data collection
Operational efficiency	+15 to +20%	Real-time decision support

Further Resources

Article by Alberto Giacomel — February 2026