Тестирование

Для того чтобы обеспечить высокое качество обслуживания пассажиров и надёжную эксплуатацию пассажирской инфраструктуры, нужен хороший инструментальный контроль. Проще говоря — системы снятия информации и её обработки. Центральной пригородной пассажирской компании (это те, кто возит вас электричками в Подмосковье) в какой-то момент захотелось прорыва в плане ухода от ручных технологий управления. Главная идея была в создании единого мозгового центра, чтобы следить, контролировать, понимать и предсказывать операционные процессы, оперативно реагировать на внештатные ситуации.


Вот так САЦ встроился в архитектуру ЦППК. Два года на проект. Два года! Вендоры такие: модуль нормативно-справочной информации — Talend MDM. Комплексная система аналитики — Oracle BI 11g, Pentaho DI (опенсорсные аналоги — Pentaho BA, Spago BI, JasperSoft BI,), СУБД -MS SQL Server 2012, аудиовизуальные комплексы — YCD, Samsung, колонны связи — отечественные производители, камеры видеоаналитики и видеонаблюдения — «Синезис», Samsung, Verint, Axis. IP-телефония — Cisco.

В общем, сейчас покажу, откуда мы собирали данные и что с ними делали. И почему километр железной дороги в нашей координатной сетке заменяют блок-участки, длина которых может колебаться от 700 до 1300 метров.

Задача центра

Общая — осуществлять централизованное управление процессами обслуживания пассажиров и поддерживать оперативное принятие управленческих решений, нацеленных на повышение качества транспортных услуг, с опорой на комплексную аналитику. Результаты вы уже могли видеть: табло с расписанием в реальном времени на станциях, сильно уменьшившиеся очереди в кассы благодаря видеоаналитике и развитию сети билетопечатающих автоматов, плюс из того, что «за кулисами», — множество инфраструктурных изменений.

Кроме долговременных задач есть и требующие оперативного решения. Например, если одна из подсистем сообщает, что поезд задерживается, пассажиры дальше по ветке сразу же предупреждаются об опоздании (на дисплеях для этого есть отдельная колонка). Расчёт отклонений от графика движения происходит автоматически по определённому алгоритму на основе информации с ГИС, диспетчерского пункта РЖД и подсистемы ГЛОНАСС/GPS-мониторинга.

Внедрение всех подсистем — от диспетчерского центра и информирования пассажиров до инфраструктур вроде ЛВС — и написание логики сопоставления данных заняло два года (и ещё продолжается). Мы клали кабель, монтировали колонны, писали кучу софта по аналитике, соединяли информационный обмен, ставили железо и вообще делали всё то, что делается на таких больших проектах. Результаты видны не только сотрудникам ситуационного центра, но и пассажирам.

Вот что из источников есть на входе

— GPS/ГЛОНАСС в поездах (покрыты поезда собственного парка ЦППК) плюс инфраструктура РЖД. Поставить эти устройства было сложно как организационно (некоторые поезда в аренде, а не в собственности, собственник — РЖД), так и чисто физически. Про то, как коллеги ставили эти железки, возможно, мы как-нибудь расскажем в очередном посте баек. Нужны эти датчики для того, чтобы точно знать, где поезд. В далёкие времена, до появления подобных датчиков, вся диспетчеризация делалась по служебной сигнализации железной дороги. После срабатывания сигнализации, чтобы следить за перемещением поездов, раньше двигали макеты. Погрешность 10 минут, но зато это весьма надёжная система, где нет «шумных» данных.

— Камеры видеоаналитики на остановочных пунктах. Мы прикручивали видеоаналитику по опасным ситуациям на платформе (например, пересечение края платформы). Но понятно, что ж/д полигон — это не очень тепличные условия: рябь снега, блики солнца, блестящие поезда… — всё это может приводить к ложным срабатываниям и требует долгого обучения алгоритмов. В помещениях с видео — чуть проще. Например, мы, опираясь на данные видео, в реальном времени считаем количество людей у касс. Если очередь превышает 4 человека, то старшие кассиры станций могут получать автоматическое уведомление и открывать дополнительную кассу либо направлять пассажиров к билетопечатающим автоматам.

— Обращения граждан. Как персонал ЦППК (люди на станциях), так и пассажиры (особенно, надо признать, пенсионеры) пишут разные пожелания о том, что делать и как. Эти обращения, а также все остальные собранные данные с систем и датчиков пишутся в систему оперативного мониторинга и управления, построенную на базе ITSM. По сути, это система тикетов Центральной ППК.


Используются вот такие терминалы: принцип тот же, что у сине-красной колонны на станциях метро

— Данные от смежных компаний. Например, разные ремонтные службы дают информацию о состоянии оборудования на участках. Непосредственно РЖД даёт свои данные в ЦППК, что позволяет чётко видеть отклонения от расписания.

— Статическая (точнее, не обновляемая в реалтайме) информация про участки, перегоны, полигоны — это важно для аналитики проблем. Но, кстати, применение у неё не очень широкое: сетка расписания очень близка к максимальной и так. Даже если мы благодаря аналитике поймём, что нужен ещё поезд в 9:05, уложить его в сетку будет сложно. Либо больше просто не пустишь физически, либо нужно пропускать «Сапсан», либо куча других ограничений. Поэтому это пример того, как хорошая аналитика легко упирается в реальный мир. Из того, что можно сделать физически, — очень хочется варьировать длину состава, но у нас, в отличие от некоторых заморских стран, нет ещё механики garbage collector — простого возврата «порожняковых» вагонов (на уровне архитектуры). Поэтому придётся как-то таскать их обратно вручную, что довольно сложно. Соответственно, вариант оптимизации на уровне состава, а не расписания тоже не подходит. По крайней мере, в ближайшие пару лет. Пока про «в аэропорт идут только первые два вагона» забудьте.

Фильтрация и корреляция событий

Есть события, которые не требуют вмешательства человека и просто обрабатываются по определённым правилам. Например, некритичные опоздания (до 5 минут) берутся из подсистемы мониторинга поездов (основанной на GPS-датчиках и сигнализации РЖД) и выводятся сразу на системы информирования пассажиров (дисплей на станции, как ниже). В случае длинной очереди тоже триггерится автоматическая реакция по итогам системы анализа видеоаналитики.

Следующий тип события — предсказание или корреляция. Например, если поезд такой-то опаздывает, то тот, что идёт за ним по той же паре рельсов (путь, как правило, один), тоже будет опаздывать, если первый не нагонит расписание. Соответственно, можно выстроить матмодель и сразу спрогнозировать опоздание уже для двух поездов. Потом — для третьего, затронутого этим изменением, четвёртого и так далее, пока «круги на воде» не утихнут. И, опять же, сразу же проинформировать пассажиров автоматически.

Технически система генерирует кучу единичных событий. Информация агрегируется в кучу и вычисляется максимальное опоздание. Вычисляется, сколько станций нужно уведомить. Как правило, если опоздание короткое — можно только следующую или ещё пару. Если длинное, то надо уведомлять 7–10 станций без шанса нагнать (на самых маленьких кассиры кричат в рупор, на станциях побольше действует автоматическая система обновления расписания).

Бывают события, требующие отложенной реакции человека. К примеру, нашлась какая-то проблема — встал тикет. В поезде что-то некритичное поломалось — нужно закончить маршрут и решить, ставить его на внеплановый ремонт или же делать что-то другое. И если ставить, то куда. Иногда просто нужно уведомить кого-то о событии или сделать что-то в ЦППК. Тогда тикет идёт в автоматизацию бизнес-процессов. Если есть неисправность билетопечатающего автомата, то заявка автоматически прилетает подрядной организации в зависимости от того, кто и где обслуживает эти автоматы. Если речь про инфраструктуру платформы (провис навес, отогнулась крыша от ветра) — ещё один процесс, тоже сразу ответственным.

Ещё одна полезность: раньше о косяках подрядчиков можно было узнать в конце месяца, сейчас — сразу, и, как правило, оперативный звонок от топа резко меняет ситуацию, если где-то что-то не так.

Следующий тип события — тревоги, то есть вещи, которые требуют реакции диспетчера здесь и сейчас. Тревоги делятся по приоритетам важности. Пример такого события — обнаруженная на видеонаблюдении оставленная сумка. Куда чаще триггерами бывают сообщения сотрудников ЧОП со станций или кассиров.

Также бывают сложные корреляции, которые нужны для изучения долговременных процессов работы компании. Например, одна из самых интересных корреляций — это как движение поездов влияет на продажу билетов на станциях. Для этого исследования снимаются данные с автоматов и турникетов. На достаточно больших выборках можно вычислить, в какой поезд люди сели и куда поехали. Плюс вычислять населённость поезда. Почему нужно вычислять населённость поезда с помощью аналитики, а не подсчётов по камерам — вопрос отдельный. Во-первых, во многих составах камер нет. Во-вторых, там, где они есть, это охранные камеры. В мировой практике по таким камерам никто поток не считает, ведь главное требование — направление сверху вниз, чтобы считать по головам. Ещё в России были попытки считать людей на основе датчиков, но их банально откручивают или разбивают вандалы. Вообще, любая неприваренная деталь поезда будет очень быстро разбита или откручена. Или сначала откручена, а потом разбита. Поэтому — аналитика.


Это был наш опытный проект, который к ситуационному центру пока привязан ограниченно и в пилотном режиме

Но вернёмся к пассажиропотоку. Центральной ППК интересно, сколько денег везёт поезд и нет ли перенаселённости. То есть им стоит понимать пики и участки их действия. Например, есть совершенно точный пик с 6 до 8 вечера — он действует до Одинцово по Белорусскому направлению, а после уже сглаживается.



В реальном времени работает геоинформационная система. На этой ГИС показывается, какой поезд куда идёт, где какие инциденты случились. Это самое важное средство визуализации того, что происходит по зоне ответственности. Центральная ППК использует кастомизированную систему РЖД, учитывающую очень много специфики именно ЦППК, но при этом она в обязательном порядке интегрирована с ГИС владельца инфраструктуры, то есть РЖД.

Чтобы понять, чем ГИС железнодорожника отличается от реального мира, стоит просто вспомнить о другой координатной сетке. Километровые столбы сами по себе у нас в стране стоят достаточно аккуратно. А вот длина блок-участков (базовых элементов системы управления) может колебаться от 700 до 1300 метров. Можно было бы предположить, что когда-то в XIX веке шёл Кузьма какой-нибудь, ставил отметки для светофоров. Выпил водки, поиграл на балалайке и породил кучу проблем разработчикам. Но на деле это, конечно, не так.

Последняя часть реакции — обратная связь от кассиров станций, ответственных за инфраструктуру и других сотрудников. Их отчётом цепочка обработки замыкается. Далее — общая статистика, отчётность, прогнозы, BI, разные разрезы — в общем, всё то, что нужно топ-менеджменту для принятия решений. Делается периодический анализ — смотрят, что и где поменять. На простом уровне: если часто отказывают билетопечатающие автоматы, появилась возможность принимать мотивированные организационные и технические решения.

Как это выглядит

В системе сейчас 43 отчёта и 5 инфопанелей, где выводятся эти данные в сборке. По беглому взгляду на панель диспетчер определяет, что и как, как лётчик по приборам видит всё и сразу, не вглядываясь в каждый. И есть отчёты для стратегических решений.

Примеры отчётов:



Есть отдельная панель, где сотрудник ЦППК может увидеть резкое изменение от типовых показателей на станциях (это внештатная ситуация):



Для отчётов есть визуальный конструктор, чтобы диспетчер не звал айтишников. Просто мышкой столбики перетаскивать. Удобно. Максимум 5 минут на нужный отчёт в нужном периоде. Конструкторы отчётов — как правило, средства анализа (например, где лучше поставить автоматы — на Выхино или на узловой станции дальше).

Информационные дисплеи на станциях почти как у немцев. Обновляется информация каждые 30 секунд. На дисплеи приходит статика типа расписания на день, «быстрые» апдейты с изменениями, отменами и допназначениями, и в реальном времени (раз в 30 секунд) подтягиваются отклонения поездов от графика с GPS, ГЛОНАСС, сигнализации РЖД.




Реальная трансляция


Экран кассира на станции

Ещё информация выгружается в IVR. Мы сделали API и для других систем.

Для полевых сотрудников на планшеты выводится облегчённая версия системы ситуационного центра — там уведомления о том, что происходит, но, грубо говоря, без инфографики на панели. У кассиров на АРМ тоже похожий кусок данных выводится, чтобы были в курсе.


В центре

Новый ситуационный центр начали делать ещё в сентябре 2013 года, но работ ещё много. Кстати, благодаря срокам видеоаналитику, в частности, протестировали во все сезоны.

Резюме

САЦ стал ядром мониторинга, управления и анализа всей операционной деятельности перевозчика. Вот что мы сделали в итоге на сегодняшний день:

• Обслуживание билетопечатающих автоматов: внедрили процесс сопровождения сети БПА с вовлечением подрядных организаций и контролем выполнения нормативных сроков. Теперь ни один профаченный дедлайн не остаётся без тёплого дыхания руководителя на затылке. Сделали дополнительный интерфейс регистрации заявок по БПА для использования на планшетах: прямо со станции можно отправить тикет, если мониторинг не покажет проблему. Реализована информационная панель по обслуживанию БПА — есть специальный «командный вид» на карте ситуационного центра, где можно посмотреть аналитику в нужных разрезах. Сделали детализированный регламентный отчёт по инцидентам категории «Неисправность пассажирских обустройств» (это чтобы понимать что, как, где и почему). Реализован сводный отчёт по работе диспетчера с инцидентами категории «Неисправность пассажирских обустройств» (это чтобы у проблем была фамилия), плюс сделан отчёт для внутреннего пользования по инцидентам категории «Неисправность пассажирских обустройств», обрабатываемым с нарушением срока. И ещё такой же отчёт для руководства и ежедневный оперативный отчёт по тому, что и как делается, статистика по работоспособности отдельных устройств, инвентаризация. Это всё было на 2013-й. В 2014-м уже есть аналитика автосоединения тикетов в один, если они дублируются из разных источников, плюс продление закрытых уже тикетов, по которым проблема возникла ещё раз. Есть автоматическая и ручная приоритизация инцидентов. Составлена документация по обслуживанию БПА. В планах — отчёт для отслеживания ситуаций нарушения трудовой дисциплины специалистами по направлению плюс инфопанель по отслеживанию работоспособности БПА на станциях. Уф… Но пойдём дальше, это только одно направление.
• Обслуживание пассажирских устройств: сделали панель по обслуживанию и ремонту видеокамер, такая же схема контроля подрядчиков, как выше (автоматические заявки, тикеты, документы и т. п. — ломается камера, сразу падает письмо с заявкой и делается нужный документ, например). Такие же отчёты для сервисной службы, сводный отчёт по обработке заявок и детализированный отчёт по инцидентам. Большая часть работ — 2014 год.
• Обращения граждан: полуавтоматическая тикет-система категоризацией, проброска тикетов в нужные структуры, есть работа со всеми подразделениями ЦППК и контролем выполнения нормативных сроков. Чуть позже дорабатывали ITSM для хранения файлов — сканы жалоб, текст ответа и т. п. Потом понадобилось ставить тикеты по обращению на диспетчеров САЦ и на сотрудников остановочных пунктов с рабочими местами САЦ — тоже сделали. Реализовали детализированный отчёт по инцидентам, в планах — сводный отчёт.
• Оповещение сотрудников ЦППК о событиях, влияющих на обслуживание пассажиров. Это автоматическая регистрация инцидентов категории «График движения» в случае отставания электропоездов от графика по информации, поступающей из подсистемы мониторинга движения поездов. 10 станций пилотной зоны автоматически отдают события «пересечение периметра» (по итогам — проще поставить больше сотрудников охраны, слишком частые сработки), научились считать длину очереди у кассы на основе данных видеокамер, сделали панель по видеоаналитике для ситуационного центра, сделали авторассылки с оповещениями сотрудников ЦППК по электронной почте и с помощью СМС-сообщений о событиях, влияющих на обслуживание пассажиров, в частности об отклонениях от графика движения электропоездов. Сделали отчёты: реестр инцидентов, отчёты и триггеры по любым нетипичным событиям, травматизму. Позже прикрутили информирование о сильно запаздывающем поезде для дальних станций. По отчётам делаются автосправки, требующиеся по нормативам.
• Для информационно-аналитического обеспечения специалистов ЦППК сделали приём данных из источников по инцидентам разных категорий, внедрили новую промышленную платформу (Oracle BI), сконфигурировали конструктор оперативных отчётов, перенесли базовые отчёты на новую панель (чтобы они уже могли работать с ней). Потом постепенно докручивали то, что появлялось по другим направлениям.
• Привлечение к процессу обнаружения неисправностей и их исправлению сотрудников остановочных пунктов. Среди прочего — развернули на 38 станциях АРМ с доступом к «тактическому виду» для сотрудников станций.
• Актуальное расписание на остановках: в 2013 году был вывод расписания движения поездов на 10 остановочных пунктах Казанского направления. Потом — на 15 дополнительных станциях установлено 83 монитора для отображения расписания движении поездов. Реализован пилотный вывод тарифов на станции Выхино. По предложениям, поступившим от пассажиров, оптимизирован вывод расписания: теперь расписание в обоих направлениях (из Москвы / на Москву) отображаются на одном экране. В настоящее время установлено 170 дисплеев на 25 ж/д станциях в Москве и области.
• Экстренная связь: сделали оперативно-экстренную связь, установили стойки с кнопкой экстренной связи.
• Для ситуационного центра: реализован диспетчерский центр. Разработан интерфейс ведения сотрудниками ЦППК справочника оборудования, выполнено первоначальное наполнение справочника БПА. Плюс куча доработок, например, автоматическая отправка заинтересованным лицам уведомлений об истечении действия соглашений об уровне оказания услуг, расширен состав атрибутов карточки БПА в справочнике оборудования, доработан интерфейс справочника оборудования для ведения справочника объектов пассажирских обустройств.
• Мониторинг движения поездов: реализована подсистема мониторинга движения поездов (натыкали много датчиков в вагоны). Запилен отчёт «График движения», реализована информационная панель диспетчера расписания и подвижного состава. Продолжаем устанавливать датчики в поезда.
• Внешнее взаимодействие: реализован информационный обмен с внешними ресурсами, в частности РЖД, для обеспечения доступа к 15 справочникам, включая справочники расписания и остановочных пунктов.

Кто знает подобные истории — за каждой фразой адская работа как минимум десятка человек как минимум в течение нескольких месяцев. Задачи были от простых («измажься в солидоле и смонтируй железо во всех поездах») до сложных (вроде «отобрази в отчётах информацию обо всём оборудовании ЦППК»). Работы было много и инженерам-практикам, и аналитикам, и архитекторам, и админам, и, конечно, разработчикам.

Я участвовал и продолжаю участвовать в проекте. Если у вас есть вопросы по проекту или его деталям (здесь я призову на помощь коллег — руководителей команд, отвечающих за участок), мы с удовольствием расскажем подробнее в комментариях, что можно. Но сразу скажу, что можно не всё, железная дорога всё ещё остаётся довольно специфическим с точки зрения открытости информации объектом.

Если есть вопросы — задавайте в комментариях или пишите на asmirnov@croc.ru.