Оптимізація маршрутів громадського транспорту: де ламається план
План маршрутної мережі майже завжди рахується за середніми: середній інтервал, середній пасажиропотік за добу, середня швидкість сполучення.
На вулиці картина інша — нерівномірний пасажиропотік означає, що ранковий пік забирає чверть добового обсягу, а на пересадкових вузлах посадка йде хвилями по 5–7 хвилин.
Інтервал, рівний на папері, у години пік розсипається: одна затримка на вузлі тягне наступну, і через два кола на маршруті з’являються здвоєні випуски та розриви по 20 хвилин.
Відхилення від розкладу накопичуються каскадом, бо розклад не враховує ні час обороту на кінцевій, ні реальну тривалість стоянки під посадкою. Диспетчер закриває розриви вручну — зсуває випуск, скорочує коло, ставить резервний склад.
Кожна правка живе в окремій таблиці, версії розходяться, і вже через сезон ніхто не скаже, яка з них чинна.
Дані розходяться з фактом не менше: пропуски в треках рухомого складу, валідатори, що випадають, коефіцієнти сезонності, пораховані одного разу й не переглянуті.
Помилки накопичуються від сезону до сезону, і оптимізація маршрутів громадського транспорту скочується до роботи за середніми, яких на вулиці не буває.
Розбираємо, як це закривається — від зведення фактичних даних в єдину модель до перерахунку інтервалів і розкладів під реальний потік.
Що змінюється після впровадження: інтервали, випуск, відмови
Ефект від впровадження видно не у звіті, а в розкладі та на зупинці. Нижче — контрольні точки, за якими ми звіряємо результат: кожна рахується на реальних вивантаженнях і порівнюється зі станом до запуску.
Орієнтири беремо з галузевих вимірювань, а не з презентацій — наприклад, показники регулярності та часу очікування за даними UITP. Якщо метрика не рухається, отже модель прогнозу пасажиропотоку недорахувала локальні фактори, і ми донавчаємо її на даних конкретного парку.
| Що перевіряємо | Як вимірюємо | Що вважаємо нормою |
|---|---|---|
| Інтервали руху | відхилення фактичного інтервалу від планового за кожним випуском | розкид скорочується в рази, «паровозики» з двох машин на маршруті зникають |
| Випуск на лінію | зіставлення кількості машин на маршруті з прогнозом пасажиропотоку за годинами | у пік випуск зростає, у міжпік і на пізніх рейсах знижується без переповнення салонів |
| Прогноз пасажиропотоку | помилка прогнозу на день і тиждень проти фактичних валідацій | помилка утримується в межах, за яких рішення про випуск не переграють вручну |
| Час очікування на зупинці | частка очікувань довше заявленого інтервалу | довгі очікування перестають бути масовими на регулярних маршрутах |
| Усунений клас відмов | розбір сходжень з лінії: зрив розкладу, розрив інтервалів, нестача випуску | ці збої зникають з регулярних, залишаються зовнішні причини — ДТП, погода, ремонт |
Звіряємо чек-лист на пілотних маршрутах до масштабування: якщо інтервали та випуск поводяться передбачувано на двох-трьох напрямках, модель переноситься на всю мережу.
Варіанти побудови системи: від розкладів до цифрового двійника
Розвилка на старті — не «який алгоритм точніший», а який контур управління ви готові підтримувати постійно. Чотири варіанти відрізняються джерелом даних, частотою перерахунку та тим, хто ухвалює останнє рішення: диспетчер чи система.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Ручний розклад | Мережа до десятка маршрутів, рівномірний пасажиропотік, правки двічі на рік | Не встигає за відхиленнями: кожен збій розбирається вручну, якість тримається на досвіді одного фахівця |
| Прогнозна модель на історії | Потрібен перерахунок інтервалів за накопиченими даними, власної телеметрії ще немає | Не бачить поточної обстановки: при перекритті або збої прогноз розходиться з фактом |
| Цифровий двійник маршрутної мережі | Є потік поточних даних про рух, рішення потрібно перевіряти до випуску на лінію | Потребує більше ресурсів на підтримку: модель мережі, актуальні довідники, регламент оновлення |
| Гібридний режим управління | Частина маршрутів автоматизується, решта залишається за диспетчером | Потрібна явна межа відповідальності та порядок передачі управління |
Варіанти не виключають один одного: ручний розклад переростає в прогнозну модель, та — в цифрового двійника, коли з’являється стійкий потік даних. Вибір фіксується на етапі обстеження — від нього залежить склад робіт і те, які перевірки потраплять у приймання.
Як проходить впровадження: етапи інженерної роботи
Впровадження йде хвилями: спочатку фіксуємо, на яких даних система буде рахувати, і лише потім змінюємо розклади. Порядок етапів не переставляється — модель, налаштована на неузгоджених даних, дає гарні звіти та неправильні інтервали на лінії.
-
Аудит джерел даних. Розбираємо журнали валідаторів і треки рухомого складу, наряди, чинні розклади, звернення пасажирів. Перевіряємо повноту за днями тижня й сезоном, збіжність кількості рейсів, дрейф часу на різних бортах, дублі та обриви запису.
На виході — перелік придатних джерел, їхня частота оновлення та список розбіжностей, які потрібно закрити до старту.
-
Схема маршрутної мережі. Збираємо граф зупинок і перегонів, час ходу за ділянками в розрізі годин доби, час на посадку й висадку, точки пересадок і суміщені ділянки. Спірні перегони узгоджуємо з диспетчерами — вони знають, де розклад розходиться з реальністю.
-
Налаштування моделі. Задаємо цільову функцію: очікування на зупинці, кількість пересадок, дотримання інтервалів. Окремо прописуємо обмеження — випуск машин на маршрут, режим праці водіїв, місткість.
-
Перевірка прогнозу на історичних зрізах. Проганяємо модель на минулих періодах і порівнюємо з фактом, а не з теорією. Дивимося відхилення від розкладу, середнє очікування, частку поїздок з пересадкою; там, де розходження стійке, перезбираємо вхідні дані.
-
Налаштування панелі диспетчера та навчання. Показуємо, як читати рекомендації, що робити при збої датчиків і як повернутися в ручний режим. Проводимо розбір спірних ситуацій і залишаємо короткі регламенти за змінами.
-
Передача в експлуатацію. Фіксуємо ролі та доступи, розклад оновлення моделі, порядок контролю якості даних. Далі ведемо супровід: доналаштовуємо ваги за зворотним зв’язком з лінії та розбираємо відхилення, які накопичуються між переглядами розкладу.
Що залишається у замовника: моделі, регламенти, документація
Система оптимізації маршрутів живе не лише в коді — вона тримається на даних, доступах і регламентах.
Ми передаємо все, що потрібно для самостійної експлуатації та розвитку: жоден вузол не залишається «чорною скринькою», яку не можна перевірити, переналаштувати або замінити силами своєї команди.
Що саме залишається у замовника:
- Конфігурація системи — ваги критеріїв розрахунку (час у дорозі, кількість пересадок, наповнюваність салону), горизонти планування, правила формування розкладів. Параметри винесені в окремі файли, а не зашиті в код: правка не потребує перезбирання та релізу.
- Схеми маршрутної мережі — топологія зупинок і зв’язків між ними, зони обслуговування, обмеження за типом рухомого складу. У машинозчитуваному вигляді з описом формату, щоб мережу можна було правити й перевіряти автоматично.
- Політики доступу — ролі диспетчера, аналітика та адміністратора, межі їхніх прав, порядок надання й відкликання доступу, журналювання дій. Видно, хто і коли змінював розклад або параметри розрахунку.
- Регламент оновлення даних — періодичність підвантаження відомостей про пасажиропотік, геометрію вулиць і дорожню обстановку, відповідальні за джерело, поведінка системи при недоступності або розбіжності даних.
- Інструкції для диспетчерів — як читати відхилення від графіка, коли запускати перерахунок вручну, що робити при збої або масовому заході, як зафіксувати інцидент і передати його далі.
- Опис інтерфейсів обміну — формати вивантажень і запитів для суміжних систем (квиткової, навігаційної), приклади коректних відповідей і типові помилки.
- Сценарії відновлення — резервні копії конфігурацій і моделей, порядок відкату до попередньої версії розкладу, критерії, за яких відкат вважається успішним.
Кейс: як скоротили відхилення від розкладу на міській мережі
Оператор міської мережі — кілька десятків маршрутів і сотні випусків на день. До вечора розклад розходився з реальністю: диспетчери правили графік вручну, відхилення від розкладу накопичувалися до 6–8 хвилин, а зірвані випуски на лінію закривалися резервом «за ситуацією».
Що знайшли в даних
Зібрали телеметрію за місяць за кожним випуском: фактичні інтервали, час ходу за перегонами, стоянки та простої на розворотах. Більше половини відхилень давали не затори, а неузгодженість плану з потоком — плановий час ходу на чотирьох ділянках був коротшим за фактичний. Модель прогнозу за часом доби й днем тижня відокремила передбачувані провали від разових відмов.
Що змінили і що показали вимірювання
Перезібрали розклад під фактичні профілі часу ходу, додали перехідний резерв на маршрутах із широким розкидом інтервалів і налаштували оповіщення диспетчера при виході рейсу за коридор відхилення. Метрики до та після:
- регулярність рейсів: 82% → 96% виконаних за розкладом;
- розкид інтервалів на пікових ділянках: ±7 хвилин → ±2,5;
- зірвані випуски на лінію: 4,1% → 0,8% випуску;
- частка рейсів, закритих резервом «за фактом», скоротилася вчетверо.
Через квартал результат підтвердили незалежним вимірюванням: контролери Центр управління міським транспортом пройшли маршрути за розкладом і звірили факт з планом — розходження утрималося на тому ж рівні, а не повернулося назад через місяць. Кейс впровадження вважаємо закритим, коли метрику бачить не лише виконавець.
Чим цифровий двійник маршрутної мережі відрізняється від звичайної моделі
Статистична модель спирається на історичну статистику: усереднює пасажиропотік за годинами, днями тижня й сезонами і на цій основі будує прогноз попиту. Такий прогноз чесно описує вже сформований попит, але не знає, що змінилася сама мережа.
Перенесли зупинку, додали виділену смугу, скоротили інтервал — модель продовжить рахувати за старим профілем, поки не накопичиться нова історія.
Цифровий двійник — пов’язана динамічна копія мережі: маршрути, розклад, випуск рухомого складу, пересадкові вузли та фактичний пасажиропотік живуть в одній моделі й перераховуються в міру надходження даних.
Історична статистика при цьому не відкидається, а стає базовим профілем, який поточні події коригують.
Ключова відмінність — перевірка сценаріїв. Двійник проганяє варіант розкладу або новий маршрут до виходу на вулицю й показує, як перерозподіляться потоки, де зросте час очікування, які вузли перевантажаться.
Статистична модель на таке запитання відповісти не може: в історії немає даних про те, чого ще не було.
У двійника є межі застосовності. Він потребує частої телеметрії та регулярних вимірювань пасажиропотоку: на рідкісних або неповних даних модель починає уточнювати саму себе й видає впевнений, але неправильний результат.
Разові події — перекриття, аварії, масові заходи — входять у неї як зовнішні збурення, а не як частина прогнозу.
Вибір тут не «двійник чи статистика», а «на якому горизонті потрібна відповідь». Для планового випуску достатньо історичної моделі, для рішень, які змінюють мережу, — двійника з перевіркою сценаріїв.
Технічні сумніви: дані, точність, інтеграції
Технічні сумніви зазвичай одні й ті самі: чи вистачить даних, чи можна довіряти прогнозу, як вбудувати систему в поточний контур управління. Розбираємо їх на конкретних перевірках, а не на обіцянках.
На вхід ідуть треки транспорту, фактичні розклади, позначки валідаторів, погода та міські події. Історію беремо за кілька минулих періодів, щоб модель побачила будні, вихідні, канікули та піки, а не усереднений день.
Дані розкидані по системах і ручних таблицях — з чого починаєте?
З карти джерел: що вже є, у якому вигляді та як часто оновлюється. Потім шар приведення до єдиної схеми маршруту, зупинки та часу. Ручні таблиці замінюються автоматичним вивантаженням — інакше розрахунки йдуть за застарілими зрізами.
Як перевіряється точність прогнозу, якщо її зараз ніхто не вимірює?
Ретроспективним прогоном: модель навчається на старому періоді й передбачає наступний, який ми вже знаємо. Помилку рахуємо окремо за годинами пік, міжпіків і вихідними.
Сезонні сплески — навчальний рік, відпустки, свята, масові заходи — ідуть окремими ознаками, а не поправкою на око.
Як система стикується з диспетчерською і чи можна запускати частинами?
Через обмінний шар: система читає поточний стан і віддає рекомендації, не ламаючи наявний контур. Диспетчер бачить пропозицію поруч із фактичною картиною і може її відхилити — причина відхилення повертається в модель.
Розширення йде поступово: спочатку один коридор у рекомендаційному режимі, автоматика — після стійких результатів.
Обговоримо завдання: з чого починається робота над системою
Робота починається з передпроєктної зустрічі: обговорюємо, яке завдання має вирішувати система — скоротити час очікування, розвантажити пересадкові вузли або перерозподілити рухомий склад між маршрутами. На тій же зустрічі фіксуємо, які дані у вас уже є і в якому вигляді, а що доведеться збирати.
Далі потрібен перелік даних — без нього будь-яка оцінка буде приблизною:
- Дані про рух: позначки проходження зупинок, історія затримок і відхилень від графіка за кілька сезонів, включно з періодами збоїв.
- Чинні розклади та випуски на маршрути — у тому вигляді, у якому їх віддає диспетчерська служба.
- Схема мережі: зупинки, перегони, пересадкові вузли, обмеження за виділеними смугами, розворотами та часом роботи ділянок.
- Пасажиропотік за зупинками й годинами доби — нехай приблизний, але він потрібен, щоб перевірити гіпотези до початку робіт.
- Критерії приймання: що саме вважаємо покращенням — рівність інтервалів, час у дорозі, частку зірваних рейсів або зв’язність пересадок.
За цією картиною ми повертаємося з оцінкою та планом робіт: обсяг, порядок етапів, залежності та ризики. Перший крок — пілотна ділянка на кількох маршрутах, де гіпотези перевіряються на живому графіку й видно фактичний ефект. Порядок розширення на всю мережу визначаємо вже за результатами пілоту, а не заздалегідь на папері.
Опишіть завдання та те, що вже є за даними — повернемося з оцінкою та планом робіт.
