Interactive field notes · 01
Maritime Twin Lab
From sensor to decision.
Explore a small connected fleet. Follow engine telemetry, isolate an unreliable sensor and turn a sustained anomaly into a maintenance decision.
Runs on your device. Threshold-based detection, simulated edge/cloud synchronisation and local maintenance proposals. All session data resets when you reload.
Data model · DTDL v3 + Avro v1
The data model, from type to measurement
Classes define what a measurement means. Vendor models inherit classes and capabilities; each installed sensor links that contract to a fleet asset.
- 01
Classes & capabilities
4
- 02
Vendor models
3
- 03
Installed sensors
6
- 04
Canonical event
SensorObservation v1
Actual catalogue inheritance
The highlighted path shows every ancestor of the selected model, including multiple inheritance.
Sensor
Base contract
Calibratable capability
Base contract
Temperature sensor
Extends: Sensor
Vibration sensor
Extends: Sensor
Northstar T100
Extends: Temperature sensor
Harbor T200
Extends: Temperature sensor + Calibratable capability
Harbor V200
Extends: Vibration sensor + Calibratable capability
Instance & context
- sensorId
- aurora-engine-temperature
- modelId
- dtmi:info:giacomel:maritime:HarborT200;1
- assetId
- aurora-main-engine
- adapterId
- harbor-v1
Resolved properties · Harbor T200
sensorIdstring · inheritedDefined in: Sensor
firmwareVersionstring · inheritedDefined in: Sensor
temperaturedouble · inheritedDefined in: Temperature sensor · UCUM: Cel
lastCalibrationAtdateTime · inheritedDefined in: Calibratable capability
Normalised observation · onboard preview
Synthetic values follow the demo clock. This preview precedes the quality gate: a score >50 prevents the twin from updating.
Show full JSON
{
"eventId": "local-preview:aurora-engine-temperature:0",
"schemaVersion": 1,
"eventType": "sensor.observed",
"source": "demo:harbor-v1",
"sessionId": "local-preview",
"sensorId": "local-preview:aurora-engine-temperature",
"modelId": "dtmi:info:giacomel:maritime:HarborT200;1",
"assetId": "aurora-main-engine",
"vesselId": "aurora",
"sequence": 0,
"observedAt": 1771934400000,
"ingestedAt": 1771934400000,
"quantity": "temperature",
"value": 74,
"unit": "Cel",
"qualityScore": 10,
"traceId": null
}Two contracts, two responsibilities
DTDL v3 describes twin types and properties. Avro SensorObservation v1 defines the message: identity, versioned model, asset, quantity, unit, quality and UTC timestamps. The demo generates JSON in the browser; this preview does not prove Kafka delivery.
To grow: add catalogue instances; a new vendor extends an existing class. A new quantity needs a class, adapter and dedicated rules/views. The event contract is shared across sensors.
- Vessels
- 3
- Assets in alert
- 0
- Buffered packets
- 0
- Rejected packets
- 0
Fleet overview
Asset context
- Fleet
- Vessel · Aurora
- Propulsion system
- Main engine
- Temperature / vibration sensors
Containment establishes where a measurement belongs. The selected vessel drives the charts and maintenance context.
Engine telemetry · Aurora
Latest accepted sample: T+0Last 48 accepted readings · horizontal axis: simulated minutes
Latest onboard sample: 74.0 °C · 1.7 mm/s · T+0
Connectivity lab
ConnectedDisconnect, advance the clock, then reconnect. Onboard readings continue; the shore-side twin stays at its last accepted state until replay.
Buffer capacity: 180 vessel packets, each aggregating two sensors. Oldest packets are discarded when full; rejected readings never update the twin. Quality score ≤50 accepted; higher values rejected.
Maintenance decision
Proposal after 3 consecutive valid readings at ≥90°C or ≥4.5 mm/s. Illustrative thresholds; this is condition monitoring with rules.
No maintenance proposal for this vessel.
Approval records a local demonstration decision. No work order is sent to an external system.
Decision trail
- Change a scenario or disconnect the link to generate events.
What this demonstrates
A measurement becomes useful when it has asset context, trusted quality and an accountable operational decision. Connectivity and data quality affect what the decision-maker can safely know.
Path to production
The blog describes the Azure implementation: IoT Edge → IoT Hub → Functions → Azure Digital Twins → downstream systems. This lab demonstrates the behaviour locally. A production rollout adds device identity, durable ingestion, access control, trained-model evaluation and CMMS integration.
Cost boundary
No new backend, database or AI API calls. The page uses the website’s existing hosting for delivery; hosting quotas and plan eligibility still apply.