Live from the engine room.

− 0600 M

Chapter 01 · 2022 · Greenfield

One ferry

There was a prototype and not much else. The team's tech lead knew me from our emetriq years and brought me in as the UX allrounder, the one who bridges design, development and business. The honest version of the brief was to do whatever the product needs.

It needed one big thing first. The vessel's live data, brought ashore and onto a screen. Engines first, and soon far more than engines: vibration, oil quality, position, whatever the vessel reports, until the picture is the whole ship. See what your vessel is doing in that moment. Then turn around and study the same data historically. Live and history in one picture; that pairing is still the heart of the platform.

Within the first year it was running on a production vessel, a high-speed passenger ferry, and standing on a fair stand at SMM 2022. From nothing to production in year one.

− 1100 M

Chapter 02 · The product's face

The face of the fleet

For the crew, a cockpit and a bridge view, the vital signs of engines and systems, right where the vessel is run. For shore, a fleet overview and trend analysis, every vessel on one screen, weeks and months of behavior instead of a phone call and a guess.

The piece I am proud of is self-serve analytics. We built a chart and dashboard builder so that anyone, a superintendent, a service engineer, can answer their own question on their own data. Pick the signals, set the axes, save the view. No ticket. No developer. No waiting.

Around it, the features that speak the operator's language: trips you can compare, load profiles across an engine's life, emissions views. Not charts for their own sake; answers.

− 1600 M

Chapter 03 · The turn

From alarms to foresight

The platform started where every monitoring system starts, with alarms. Something trips, somebody reacts.

Then the quieter work. Sensors fail more often than engines do, so we built data-quality guards: flag faulty sensors, show only plausible data, never let a broken probe impersonate a broken engine.

On clean data we could build anomaly detection, and weekly emails that tell operators what has started to drift before it becomes a problem. That shift took years, and it changed the product's job, from reacting to alarms to being told before it matters.

− 2100 M

Chapter 04 · Whatever is already on board

One computer, everyone's equipment

A vessel is not a greenfield. Engines, gearboxes, vibration sensors and navigation gear are already installed, chosen years before anyone thought about monitoring, each speaking whatever its maker decided.

The usual answer is another box for each system that wants data. Do that across a fleet and the owner pays several suppliers to install several boxes, each collecting a slice of the same ship.

One small edge computer on board reads all of it. Modbus, OPC-UA, NMEA and the vibration protocol the sensors speak, each with its own connector, so a vessel joins on the equipment it already carries. Nothing in the platform assumes the engine maker's hardware.

Ashore, the fleet side receives what the ship sends. Everything between them moves as messages on a topic grammar we treat as a contract. Rename a topic quietly and the shore stops seeing part of what the ship is saying, with nothing appearing to break.

− 2600 M

Chapter 05 · Offline by design

When there is no network at all

Some fleets can never touch the internet. The network does not exist, and it will not be built.

So the whole system travels instead. It exports as a portable, versioned package of its own services, carried in by hand and stood up inside the facility. Nothing phones home, because there is nothing to phone.

Data arrives as files and leaves as files. Imports run in batches, accept only engines the system already knows, and repair themselves when a file turns up damaged. Exports cover the datasets, the charts as images, the numbers behind those charts, and full-rate dumps of every parameter. Each output is marked with its classification automatically, because in a facility like that an unmarked file is a problem of its own.

Updates travel the same road. A patch is encrypted and signed before it leaves and checked before it is applied, so nothing changes the system inside unless it provably came from outside.

Nothing here is a cut-down edition. It is the same platform with the network taken away.

− 3100 M

Chapter 06 · Below the waterline

The unsexy hard problem: mapping

Data means nothing until every signal is mapped to the right name. Every engine generation names its sensors differently. Every vessel is wired a little differently again.

Get one column wrong and your history is quietly false. Charts that look right and lie. So mapping is not a config chore here. It is a first-class product problem, and I keep pushing on it.

The current frontier is making it less manual, with tooling that proposes mappings and makes every vessel's mapping state visible, instead of trusting a spreadsheet and one careful person. That work is in progress, not shipped. It is the part of the iceberg nobody shows at a fair.

− 3600 M

Chapter 07 · Convergence

The complete picture

A prediction is only useful next to reality. What was actually serviced, when, and at how many running hours. So the platform grew maintenance features: upload the records, see upcoming and completed tasks next to the live data. Running hours themselves had to be made trustworthy first, because every service schedule hangs off them.

The newest piece is service integration: platform data, maintenance history and the people who actually fix engines, meeting in one place.

Which is the point of this whole page. The prediction this site leads with works because someone integrated data collection across different spots and different teams: service with development with product with design, down to the workshop where repairs happen. That took four years. It was worth it.