Ercan LabsBus Rotation Planner
Weekly duty and rotation planning for a city bus fleet, with rule checks and an Excel handover.
How this was measured: Test count from dotnet test output; screens counted from view models; LOC via wc over tracked .cs files.
- DESKTOP
- Avalonia7 ekran
- RULES
- kural tablosu
- kısıt denetimi
- ENGINE
- rotasyon planlayıcı
- OUT
- SQLite
- Excel
Problem
A city bus fleet is planned on paper every week: which driver takes which bus on which shift, who rests, who is owed a weekend. The rules are known by the dispatcher, not written anywhere, so the plan is only as good as the person making it.
The job was to write the rules down as code, produce a weekly plan that never breaks them, and hand it over in the format the office already uses.
Constraints
- Windows and Linux desktops in the same office: a cross-platform UI, not a web app.
- The dispatcher's rules change; adding a constraint must not mean rewriting the planner.
- Output must open in Excel without conversion — the office does not adopt new tools.
Architecture decisions
Avalonia instead of a browser app
The office has no server and no habit of browser tabs; a native window that starts in a second fits the shift-change reality.
Cost: XAML layout work replaces CSS, and cross-platform packaging is the price.
Rules as data, planner as a separate layer
Rotation constraints live in their own table and are evaluated before the plan is written. A new rule is a row and a check, not a change to the scheduling algorithm.
Cost: More indirection than a hard-coded loop.
Test the planner, not the window
326 tests run against the scheduling engine with fixture fleets; the UI is thin on purpose so the rules can be verified without a display.
Cost: UI regressions are only caught by hand.
Excel as the delivery format
ClosedXML writes the workbook the office already knows, with the same column names. Adoption cost zero.
Cost: A formatting adapter that has to follow the office template.
Proof
- Tests326 green (Windows + Linux CI)
- Screens7 (fleet, lines, timetable, weekly plan, rules, reports, Excel)
- C# files209
- Lines of code25.798
Known limits
- The plan is verified by rules, not by driver satisfaction — no post-week feedback is recorded yet.
- Single office, single fleet; multi-depot planning is not implemented.
- Real usage time is short; the case reports tests, not saved hours.
What I learned
A planner is a rule engine with a calendar attached. The moment the rules are written down, the dispatcher stops being the only person who can produce the plan — that is the actual deliverable, the Excel file is just the receipt.