DynDaCo

Vessel tracking that knows what the ship is doing

Sector
Inland and maritime shipping
Period
2016–present
Role
Architect and lead developer
Stack
Ruby on Rails · PostgreSQL · PostGIS · AIS · Binary TCP protocols

Situation

An operator with vessels, trucks and cars in the field could answer "where is it" and almost nothing else. Position came from whichever tracker had been fitted, and different assets had different hardware from different eras, each speaking its own protocol.

Position alone turns out to be a thin answer. Knowing a vessel is mid-river does not tell you whether it is under way or idling, how much fuel it has burned getting there, whether a generator has been running all night, or whether the crew aboard is the crew that should be aboard. That information existed — on the vessel, in the onboard systems — and stayed there.

What I built

One map, one fleet. Vessels, trucks and cars are all tracked targets on a single map with layered overlays, live and historic. An operator scrubs back through a day and watches the route replay rather than reading coordinates.

Onboard data alongside position. The tracked payload is not limited to a fix. Readings pulled from onboard systems — engine and machinery state, tank and fuel levels, running hours, equipment-specific counters — travel with the position report and are stored against it. The result is a track you can ask questions of: not just where the vessel went, but what it was doing while it went there, and what that cost in fuel.

A receiver that speaks whatever is fitted. Trackers connect over TCP, and they do not agree on anything. Several speak proprietary binary formats; others arrive as AIS feeds or as customer-specific streams. A standalone receiver daemon holds one handler per protocol, decodes the binary frames field by field, and detects which protocol a connecting device is using rather than requiring a port per vendor. Fitting a different tracker means adding a handler, not reworking the system — which matters when hardware is replaced piecemeal over a decade.

Zones that raise alarms. Areas are drawn as real geometry and held in PostGIS, so "is this vessel inside that zone" is a spatial query rather than an approximation. Entering or leaving a zone raises an alarm routed to the people who care about that asset.

Who is aboard. Crew and contractors register on board with badges and contact keys, against a record of which authorisations each person holds. The fleet view answers "who is on that vessel right now, and are they cleared for it" — a question that turns out to matter more than fleet software usually assumes.

Outcome

The operator moved from a position display to an operational record. Fuel and machinery data sitting next to position means consumption can be attributed to actual voyages, and zone alarms mean exceptions surface instead of being noticed later.

The lesson I keep taking from this one: the hard part was never the map. It was accepting that the fleet will always be a museum of tracker hardware, and building the ingest so that a new device is a small, isolated addition.

← All work