Bus-Depot Breakdown & Spare-Parts Analytics System for a State Transport Division (Spring Boot + Python)

Depot Breakdown & Spare-Parts Analytics System (DBSAS) is a web application for one bus depot of a fictional state transport undertaking, the Sahyadri State Road Transport Corporation (SSRTC), Hunsur Depot of its Mysuru Division. A depot of this size runs 80–120 buses. Today every breakdown is written into a job-card register, spare parts leave the depot store against paper indent slips, and nobody knows which route or model fails most until the monthly statement is compiled.

DBSAS has two parts. The operational web application, built with Java 17, Spring Boot, Spring Data JPA, Thymeleaf and MySQL 8, lets the depot foreman open a job card for a bus, record the symptom and failure cause, assign a mechanic, issue spare parts from the store (stock is reduced in the same transaction) and close the job card with labour hours. The storekeeper gets reorder alerts when a part falls below its reorder level.

The analytics module, written in Python with pandas, Matplotlib and scikit-learn, runs as a nightly scheduled job behind a small REST endpoint. It computes mean kilometres between failures (MKBF, the distance form of MTBF) per route and per bus model, a failure-cause Pareto chart, parts-consumption trends and a monthly demand forecast for fast-moving parts, and writes the results back to MySQL for the depot manager's dashboard.

The work maps to Advanced Java/J2EE (22MCA341), Web Technologies (22MCA24), DBMS (22MCA21) and Data Analytics with Python (22MCA31). Flask is used only as an industry-standard wrapper to expose the Python job.

Abstract

State transport depots lose revenue every time a bus breaks down on the road: the trip is cancelled or delayed, a relief bus is sent, and the failed part often turns out to be out of stock in the depot store. This project builds a Depot Breakdown & Spare-Parts Analytics System that digitises job cards and store issues for a single depot and converts that data into maintenance intelligence — MKBF per route and bus model, a Pareto of failure causes and a forecast of monthly spare-part demand. The system uses a Spring Boot + MySQL web tier and a Python analytics tier connected through a scheduled REST call.

Introduction

In a typical Karnataka-style depot, the foreman opens a job card when a bus comes in with a complaint (air-pressure drop, clutch slip, overheating, electrical fault). Mechanics are assigned verbally, parts are drawn from the store on indent slips, and the storekeeper reorders when a shelf looks empty. The depot manager must still answer questions from the division office: why did breakdowns per 10,000 km rise this month, which model needs a campaign, how many brake-lining sets to indent next month. DBSAS answers them from recorded data.

Existing System

• Job cards and indent slips are paper documents; they are summarised by hand once a month.
• Store stock is tracked in a ledger or a stand-alone spreadsheet, so reorder decisions are reactive.
• Failure causes are written as free text, which makes counting and comparison impossible.
• Limitations: no link between a breakdown, the bus's kilometres run and the parts consumed; no trend or forecast.

Proposed System

• Structured job cards with a coded failure-cause master, mechanic assignment and time stamps.
• Store issue linked to the job card; stock, reorder level and receipts maintained in MySQL with transactional updates.
• Nightly Python analytics: MKBF by route and model, cause Pareto, consumption trend and a forecast compared against naive and moving-average baselines.
• Role-based dashboards for Depot Manager, Foreman and Storekeeper.

Literature Gap

Reliability textbooks define MTBF and Pareto analysis, and fleet-management products exist commercially, but students rarely see an end-to-end system that joins transactional maintenance data with a reproducible analytics pipeline and an honest forecast evaluation. That integration is the novelty claimed.

Feasibility

• Technical: Java, Spring Boot, MySQL and Python are all taught in the VTU MCA scheme and are free.
• Economic: runs on one depot PC or a low-cost VM; no licence cost.
• Operational: screens mirror the existing job-card and indent formats, so foremen need about an hour of training.

A bus depot of a state transport undertaking maintains around a hundred buses but records breakdowns, mechanic work and spare-part issues on paper. Because the job card, the kilometres run by the bus and the parts drawn from the store are never linked, the depot cannot compute basic reliability measures such as mean kilometres between failures per route or bus model, cannot see which few failure causes account for most breakdowns, and reorders spares only after a stock-out has already kept a bus off the road. Monthly statements to the division office are compiled manually, arrive late and cannot be drilled down.

There is a need for a transactional, role-based web system that records job cards, mechanic assignments and store issues with integrity guarantees, maintains reorder levels, and feeds a scheduled analytics pipeline that reports MKBF, a failure-cause Pareto and a validated parts-demand forecast, so that the depot manager can plan preventive maintenance and indents from evidence instead of memory.

In scope

• One depot with its fleet (about 90–120 buses), routes, bus models, mechanics and depot store.
• Three roles: Depot Manager, Foreman and Storekeeper.
• Job-card lifecycle: Open → Assigned → Parts Issued → Closed, with coded failure causes.
• Store: part master, receipts, issues against job cards, reorder levels and alerts.
• Daily odometer (kilometres run) entry per bus, used as exposure for MKBF.
• Nightly analytics: MKBF, Pareto, consumption trend, parts forecast; charts and CSV exports.

Out of scope

• Multi-depot or division-wide consolidation, purchase orders and vendor payments.
• Telematics/GPS integration and real-time sensor data.
• Real SRTC data: the bundle ships with a synthetic data generator only.

The project follows an Incremental model with a data-analysis track, aligned to VTU's two-phase structure. Phase-1 (22MCAL35, Semester 3) delivers requirements, design and a prototype; Phase-2 (22MCA44, Semester 4) delivers the full system, analytics and evaluation.

Forecast evaluation protocol: for each of the top 15 parts by issue volume, train on months 1..t and predict month t+1, rolling t from month 12 to month 17. Compare (a) naive last-month, (b) 3-month moving average and (c) a random-forest regressor on lag-1, lag-2, lag-3, month-of-year and fleet-kilometre features. Report MAE and MAPE in a results table; the model is only claimed useful if it beats both baselines.