01

Context and problem

Fleet operators often notice engine faults only after a breakdown, resulting in expensive repairs and vehicle downtime. Diagnostic equipment provides an accurate answer, but requires disassembly and time. There was no quick, non-invasive check available on site.

The task was to design an interface for mechanics: start sound-based diagnostics and receive a clear result without taking the engine apart.

AI Business SPb hackathon, 48 hours. NeuroDVS brought a real business case: data and a problem without a solution. I participated with the exception:teapots development team and designed the interface from scratch.

02

Workflow

Four steps designed for real working conditions: a mechanic in a noisy workshop, oily hands and a tablet on the workbench.

Metadata

Make, model, fuel type and mileage. Engine context is part of the analysis.

Recording

A large start button. Nothing extra — just recording.

Analysis

The ML model processes the recording and looks for deviations from normal operation.

Outcome

An anomaly score with an explanation. A decision without disassembly.

Start diagnostics — enter vehicle details

Make, model, mileage and fuel type. The model needs context: the same knock in a 2.5L and a 3.5L engine can indicate different faults. The form is short enough for a mechanic to complete in 20 seconds.

EnginEar — starting diagnostics and entering vehicle details

Monitoring — anomaly score and details

78% is more than a number. Alongside it are a spectrogram, anomalies by frequency, priority and a recommendation. Mechanics can see exactly what is wrong and what to do next.

EnginEar — anomaly monitoring, anomaly score and component details

Diagnostic history — trends for each vehicle

All recordings in one place. Search and sorting by date, make and status. A color indicator and anomaly percentage make it clear whether things have improved or worsened since the last check.

EnginEar — diagnostic history with statuses and vehicle trends
03

Key decisions

I designed for real working conditions rather than an ideal test environment.

A tablet rather than a phone

The screen is readable at arm's length and can be mounted on a stand.

Large buttons

Easy to tap without careful aiming. One button starts the recording.

Minimal text

Statuses are clear at a glance, and the result is immediate.

High contrast

Readable in different lighting: in an inspection pit, under the hood or outdoors.

04

An unexpected win

We presented last and did not expect to win. At the last moment, we rebuilt the presentation, strengthened the product reasoning and showed how the interface connected to the ML model.

Our ML engineer joined remotely. We brought a laptop on stage, connected a video call and held the microphone near its speaker. The judges heard the answers from the stage. It worked.

We took first place in two categories. NeuroDVS took the interface and ML solution forward for implementation.

The EnginEar team at the AI Business SPb hackathon — presentation and project pitch