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