On-Demand · Route-Based · Intelligent Transit
A system that gives UTM's buses the ability to think — and gives students the information they actually need.
UTM's campus spans approximately 1,222 hectares. You can't walk from your college to your faculty. You depend entirely on the bus — but the bus has no idea you're waiting.
UTM's campus shuttle services operate on fixed schedules with no mechanism to detect or respond to real-time passenger demand — leaving students stranded at stops during peak periods with no information on bus location, arrival time, or seat availability.
Every bus follows a fixed clock — 3 students or 40 students at the stop, the bus behaves identically. There is no feedback between real demand and the schedule.
Extended service gaps during pre-lecture peaksNo app, no screen, no sign at the stop tells you when the next bus comes or how full it is. You stand, you wait, and you hope. The myUTM app has no bus information at all.
Zero bus tracking in myUTM todayThere is no live view of queues building, buses running early or late, or corridors under pressure. Problems are discovered after they happen — not while they're happening.
No real-time fleet dashboard existsA RM188,127 UTM-funded research project (2026–2028) formally documents the same problem: overcrowding, unpredictable bus frequency, and students at KDOJ and KDSE specifically burdened by long waits with no notifications.
The published UTM bus schedule confirms all 19 services operate on fixed timetables with no demand-sensing mechanism of any kind — arrival times are explicitly stated as not guaranteed.
Preliminary consultation with UTM students who regularly use campus shuttle services confirmed recurring experiences of extended waits during pre-lecture periods and no access to real-time bus information.
Each layer solves a different piece of the puzzle. Together, they form a smart, demand-aware campus transit system — built on top of the routes that already exist.
Students open a simple page on their phone at the bus stop and tap where they want to go. That's it. In return, they immediately see when the next bus arrives, how full it is, and where it last was. No download. No login. Works on any smartphone.
Every bus and every bus stop is an autonomous agent — a tiny decision-maker that operates independently. When a stop detects a big queue building, it sends a signal. The right bus evaluates: leave a little earlier? Hold and wait? Flag the problem for management? All automatically, in real time, with every decision explained and logged.
Fleet managers get a live view of the entire campus network — every bus, every stop, every queue, right now. They can see exactly what decision the system made at any moment and why. And they can override any bus manually at any time. For the first time, UTM Fleet has complete operational visibility.
A funded UTM research initiative is already deploying GPS tracking infrastructure across all campus corridors. ORBIT is the coordination intelligence layer above it — not competing with it, complementing it.
Buses respond to real demand, not just the clock. Long gaps during the rush before lectures are detected and corrected automatically.
ETA, seat availability, last known bus position — delivered on any phone browser, right at the stop, with no friction.
Agents work together without a central controller. No single point of failure. If one part breaks, the rest keeps running on schedule.
For the first time, management can see the whole network live — and get a complete explanation for every decision the system made.
No routes change. No buses are moved. Only departure timing is gently adjusted, within strict safety limits, when justified.
Every student tap builds a richer picture of real demand patterns on campus. The more students use it, the more accurate the system becomes.
Student phones, bus GPS trackers, and future smart sensors at stops all speak the same protocol — MQTT, the backbone of modern IoT. The system is ready for physical hardware without redesign.
A lightweight AI model watches incoming demand signals and flags anything that looks abnormal — protecting the system from bad data before it can trigger a wrong decision.
Every UTM-specific detail lives in a config file. Any university, hospital shuttle, or corporate bus operator can deploy the same system by swapping config — no code changes needed.
PSM1 is the full blueprint. PSM2 is the construction — layer by layer, in order of student impact. The system has standalone value at every stage.
Full system design: architecture, agent behaviour rules, app screens, database structure, and every design decision documented with honest reasoning.
Chapters 1 – 5Build the student-facing layer first — it has standalone value and produces the real demand data the agents need. Working on a real phone by Week 6.
Demo 1 — 40%Add the smart coordination layer and fleet dashboard. Full three-layer system running live by Week 15, verified against defined test scenarios.
Final Demo — 100%Bus corridors modelled in simulation — not all 19. Bus B, E, and F. Representative, not exhaustive.
Physical hardware on real buses. The entire PSM2 evaluation runs on software-in-the-loop simulation with a virtual data injector.
Layers built in priority order. Even if the dashboard is incomplete, the app and MAS backend constitute a working, demonstrable system.
Head start. PSM1 approval is now. PSM2 build semester starts next academic year — preparation begins immediately.
All core components are free and run locally. IoT hardware marked with * is Future Work — the architecture already supports it through a pluggable sensor interface.
Every UTM-specific detail — stop names, routes, schedules, capacity — lives in a config file. Any transit operator swaps their own config and the system works. No code changes. No redesign.