Automated Weighbridge System

At the height of harvest, a weighbridge is the bottleneck the whole site runs through. Every tractor that arrives has to be identified, weighed in, sent to the right drop off point, weighed out, and reconciled against the batch it belongs to. I replaced a fragmented, paper-driven version of that process with a guided workflow that runs across a web platform and two purpose built Android apps, and writes straight into SAP.

The problem

The existing process depended on people remembering things and writing them down. An operator had to leave the office to identify each arriving vehicle, read the scale, and record tare and gross weights by hand. That docket then had to be keyed into SAP separately, often well after the truck had left. Matching a load to the correct almond batch and route relied on the operator knowing which job was which. Queues built during peak periods. Transcription errors surfaced days later at reconciliation. Drivers idled at the lane with no clear instruction on whether to move or hold. And no one had a live view of what was active, queued or complete.

Why RFID

We considered three options for identifying vehicles at the lane.

  1. Manual entry was mostly working, and reliable enough, but it put an operator in the loop for every single movement and was the root cause of the double handling.
  2. ANPR (automatic number plate recognition) looked attractive, but a weighbridge on a working plant is a hostile environment for cameras, dust, mud on plates, low sun at harvest hours, and tractors that don't always have a clean, consistent plate.
  3. Passive RFID won because the tag is cheap, needs no power, tolerates dust and rain, and reads reliably at lane distances regardless of light. A tag fitted once to a vehicle keeps identifying it for years with no operator involvement.

What I built

The web platform

Office staff assign each tractor to the correct almond batch and route before it reaches the bridge. That single step is what makes everything downstream automatic, the system already knows what a vehicle is carrying and where it's going by the time it's recognised at the lane.

Staff also get a live operational view of what's active, what's queued, and what's completed.

The weighbridge controller app

An Android app running on a fixed RFID scanner (Chainway URA4) runs the lane. It recognises the vehicle on approach, pulls the next assigned job, and captures a stable reading directly from the connected weighbridge scales, waiting for the scale to settle rather than trusting a snapshot. No transcription, no docket book.

The in vehicle driver app

Drivers run a second Android app in the vehicle, which tells them exactly what to do next:

  • Pending job information before arrival
  • The active ticket, with drop-off details
  • Stop and go instructions while the scale settles
  • Warning messages for exceptions
  • Tare, gross and net weights as they're captured

The driver never has to guess, and only needs to be flagged by the operator when there are exceptions.

SAP integration

Tickets are created and updated in SAP as the weigh cycle happens, not at the end of the day. Weights, timestamps, ticket status and the job the load belongs to all land in one place, tied together. Closed tickets become a review task rather than a data entry task.

Technical stack

  • Identification: Fixed passive RFID reader at the lane, tagged vehicles
  • Weight capture: Serial integration with connected weighbridge scales over TCP/IP bridge
  • Field apps: Two Android applications, weighbridge controller, in vehicle driver app
  • Platform: Django, PostgreSQL, SQLite and Kotlin
  • Integration: SAP ticket creation and update via custom REST API
  • Timeline: 6 weeks from start to finish

Weighbridge Flow