AccAnalysisAccAnalysis
Transportation & Logistics

Speed, position and road limit on the same screen, every five seconds

An oil distributor with a fleet of more than 150 tankers wanted to hold driver behaviour to actual road limits rather than to a general policy. We built the device layer, the data path and the dashboard behind it.

At a glance
Status
Delivered
Region
United States
Engagement model
Joint lab

Status: Delivered. Described from our own delivery records. Client identity, brand and commercial terms are withheld. Figures, where given, cover the period stated and nothing beyond it.

The organisation

Context

An oil and gas distributor operating a fleet of over 150 tankers. Safety performance mattered commercially and legally.

The available picture of driver behaviour was coarse: a general speed policy applied uniformly, with no reference to the limit actually in force on the stretch of road being driven.

The brief

The problem

  • Speed compliance was assessed against a blanket policy rather than the posted limit.
  • Route-specific restrictions — the ones that exist for a reason on a tanker route — could not be enforced at all.
  • Position and speed data were not being captured at a frequency that made behaviour visible.
  • There was no basis on which to reward good driving, only to react to incidents.
The work

What we built

An on-vehicle capture device

Single-board computers programmed and installed across the fleet, reporting position and speed every five seconds.

A data path

Pushing that telemetry into telematics and speed-reference services, so each reading could be compared against the limit applicable at that location.

Geofencing for route-specific restrictions

So a lower limit on a particular stretch is enforced as such rather than being invisible.

A dashboard

Presenting driver and vehicle behaviour in a form the operations team could act on.

Method

How we delivered it

  1. 1

    Frame the question first

    What “unsafe” means in measurable terms, agreed before any hardware was fitted.

  2. 2

    Prototype on a small number of vehicles

    In a lab arrangement with the client's own operations team.

  3. 3

    Prove the data path

    Capture frequency, transmission reliability, and the accuracy of limit matching.

  4. 4

    Fit the fleet in stages

    With a check that the data from each stage was sound before the next.

  5. 5

    Build the reporting layer

    Once the data was trusted, not before.

Sequence

How it was phased

PhaseDurationWhat happens
1Framing
1–2 wks

Definition of the measures, success threshold

2Prototype
3–4 wks

Devices on a handful of vehicles, data path proven

3Geofencing & limit matching
2–3 wks

Route restrictions, reference-data integration

4Fleet fitting
6–10 wks

Staged installation with per-stage data validation

5Dashboard
3–4 wks

Operations reporting, driver and route views

Indicative phasing for work of this shape. Actual duration varies with data quality, access and decision speed.

Hand-over

What the client keeps

  • The device configuration and firmware
  • The data pipeline and integration code in their own repository
  • The geofence definitions
  • The dashboard
Stack
Raspberry PiPythonTelematics and speed-reference APIsGeofencingDashboard reporting
Keep reading

Related

Related case studies

Tell us what your current system can't do, and we'll tell you what it would take to change that.