![](https://habrastorage.org/files/fec/01a/da6/fec01ada65ce4ebf836897080294fd68.jpeg)
Тестирование
Для того чтобы обеспечить высокое качество обслуживания пассажиров и надёжную эксплуатацию пассажирской инфраструктуры, нужен хороший инструментальный контроль. Проще говоря — системы снятия информации и её обработки. Центральной пригородной пассажирской компании (это те, кто возит вас электричками в Подмосковье) в какой-то момент захотелось прорыва в плане ухода от ручных технологий управления. Главная идея была в создании единого мозгового центра, чтобы следить, контролировать, понимать и предсказывать операционные процессы, оперативно реагировать на внештатные ситуации.
![](https://habrastorage.org/files/a03/cca/def/a03ccadefa3048ab99f4021a49b65ae1.jpeg)
Вот так САЦ встроился в архитектуру ЦППК. Два года на проект. Два года! Вендоры такие: модуль нормативно-справочной информации — 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. По сути, это система тикетов Центральной ППК.
![](https://habrastorage.org/files/c16/d9f/6d8/c16d9f6d88d6490aa6fa0655548e169d.jpeg)
Используются вот такие терминалы: принцип тот же, что у сине-красной колонны на станциях метро
— Данные от смежных компаний. Например, разные ремонтные службы дают информацию о состоянии оборудования на участках. Непосредственно РЖД даёт свои данные в ЦППК, что позволяет чётко видеть отклонения от расписания.
— Статическая (точнее, не обновляемая в реалтайме) информация про участки, перегоны, полигоны — это важно для аналитики проблем. Но, кстати, применение у неё не очень широкое: сетка расписания очень близка к максимальной и так. Даже если мы благодаря аналитике поймём, что нужен ещё поезд в 9:05, уложить его в сетку будет сложно. Либо больше просто не пустишь физически, либо нужно пропускать «Сапсан», либо куча других ограничений. Поэтому это пример того, как хорошая аналитика легко упирается в реальный мир. Из того, что можно сделать физически, — очень хочется варьировать длину состава, но у нас, в отличие от некоторых заморских стран, нет ещё механики garbage collector — простого возврата «порожняковых» вагонов (на уровне архитектуры). Поэтому придётся как-то таскать их обратно вручную, что довольно сложно. Соответственно, вариант оптимизации на уровне состава, а не расписания тоже не подходит. По крайней мере, в ближайшие пару лет. Пока про «в аэропорт идут только первые два вагона» забудьте.
Фильтрация и корреляция событий
Есть события, которые не требуют вмешательства человека и просто обрабатываются по определённым правилам. Например, некритичные опоздания (до 5 минут) берутся из подсистемы мониторинга поездов (основанной на GPS-датчиках и сигнализации РЖД) и выводятся сразу на системы информирования пассажиров (дисплей на станции, как ниже). В случае длинной очереди тоже триггерится автоматическая реакция по итогам системы анализа видеоаналитики.
Следующий тип события — предсказание или корреляция. Например, если поезд такой-то опаздывает, то тот, что идёт за ним по той же паре рельсов (путь, как правило, один), тоже будет опаздывать, если первый не нагонит расписание. Соответственно, можно выстроить матмодель и сразу спрогнозировать опоздание уже для двух поездов. Потом — для третьего, затронутого этим изменением, четвёртого и так далее, пока «круги на воде» не утихнут. И, опять же, сразу же проинформировать пассажиров автоматически.
Технически система генерирует кучу единичных событий. Информация агрегируется в кучу и вычисляется максимальное опоздание. Вычисляется, сколько станций нужно уведомить. Как правило, если опоздание короткое — можно только следующую или ещё пару. Если длинное, то надо уведомлять 7–10 станций без шанса нагнать (на самых маленьких кассиры кричат в рупор, на станциях побольше действует автоматическая система обновления расписания).
Бывают события, требующие отложенной реакции человека. К примеру, нашлась какая-то проблема — встал тикет. В поезде что-то некритичное поломалось — нужно закончить маршрут и решить, ставить его на внеплановый ремонт или же делать что-то другое. И если ставить, то куда. Иногда просто нужно уведомить кого-то о событии или сделать что-то в ЦППК. Тогда тикет идёт в автоматизацию бизнес-процессов. Если есть неисправность билетопечатающего автомата, то заявка автоматически прилетает подрядной организации в зависимости от того, кто и где обслуживает эти автоматы. Если речь про инфраструктуру платформы (провис навес, отогнулась крыша от ветра) — ещё один процесс, тоже сразу ответственным.
Ещё одна полезность: раньше о косяках подрядчиков можно было узнать в конце месяца, сейчас — сразу, и, как правило, оперативный звонок от топа резко меняет ситуацию, если где-то что-то не так.
Следующий тип события — тревоги, то есть вещи, которые требуют реакции диспетчера здесь и сейчас. Тревоги делятся по приоритетам важности. Пример такого события — обнаруженная на видеонаблюдении оставленная сумка. Куда чаще триггерами бывают сообщения сотрудников ЧОП со станций или кассиров.
Также бывают сложные корреляции, которые нужны для изучения долговременных процессов работы компании. Например, одна из самых интересных корреляций — это как движение поездов влияет на продажу билетов на станциях. Для этого исследования снимаются данные с автоматов и турникетов. На достаточно больших выборках можно вычислить, в какой поезд люди сели и куда поехали. Плюс вычислять населённость поезда. Почему нужно вычислять населённость поезда с помощью аналитики, а не подсчётов по камерам — вопрос отдельный. Во-первых, во многих составах камер нет. Во-вторых, там, где они есть, это охранные камеры. В мировой практике по таким камерам никто поток не считает, ведь главное требование — направление сверху вниз, чтобы считать по головам. Ещё в России были попытки считать людей на основе датчиков, но их банально откручивают или разбивают вандалы. Вообще, любая неприваренная деталь поезда будет очень быстро разбита или откручена. Или сначала откручена, а потом разбита. Поэтому — аналитика.
![](https://habrastorage.org/files/1b5/2f2/d39/1b52f2d39d7a42b7a3ea35ddf4d415bb.jpeg)
Это был наш опытный проект, который к ситуационному центру пока привязан ограниченно и в пилотном режиме
Но вернёмся к пассажиропотоку. Центральной ППК интересно, сколько денег везёт поезд и нет ли перенаселённости. То есть им стоит понимать пики и участки их действия. Например, есть совершенно точный пик с 6 до 8 вечера — он действует до Одинцово по Белорусскому направлению, а после уже сглаживается.
![](https://habrastorage.org/files/0e0/65a/2cd/0e065a2cdc3e482ab8714443f5e504e5.png)
В реальном времени работает геоинформационная система. На этой ГИС показывается, какой поезд куда идёт, где какие инциденты случились. Это самое важное средство визуализации того, что происходит по зоне ответственности. Центральная ППК использует кастомизированную систему РЖД, учитывающую очень много специфики именно ЦППК, но при этом она в обязательном порядке интегрирована с ГИС владельца инфраструктуры, то есть РЖД.
Чтобы понять, чем ГИС железнодорожника отличается от реального мира, стоит просто вспомнить о другой координатной сетке. Километровые столбы сами по себе у нас в стране стоят достаточно аккуратно. А вот длина блок-участков (базовых элементов системы управления) может колебаться от 700 до 1300 метров. Можно было бы предположить, что когда-то в XIX веке шёл Кузьма какой-нибудь, ставил отметки для светофоров. Выпил водки, поиграл на балалайке и породил кучу проблем разработчикам. Но на деле это, конечно, не так.
Последняя часть реакции — обратная связь от кассиров станций, ответственных за инфраструктуру и других сотрудников. Их отчётом цепочка обработки замыкается. Далее — общая статистика, отчётность, прогнозы, BI, разные разрезы — в общем, всё то, что нужно топ-менеджменту для принятия решений. Делается периодический анализ — смотрят, что и где поменять. На простом уровне: если часто отказывают билетопечатающие автоматы, появилась возможность принимать мотивированные организационные и технические решения.
Как это выглядит
В системе сейчас 43 отчёта и 5 инфопанелей, где выводятся эти данные в сборке. По беглому взгляду на панель диспетчер определяет, что и как, как лётчик по приборам видит всё и сразу, не вглядываясь в каждый. И есть отчёты для стратегических решений.
Примеры отчётов:
![](https://habrastorage.org/files/131/335/f84/131335f849e640f38cda15ae93443d14.png)
Есть отдельная панель, где сотрудник ЦППК может увидеть резкое изменение от типовых показателей на станциях (это внештатная ситуация):
![](https://habrastorage.org/files/49b/85d/da3/49b85dda3f324774b9c7ba271971dedf.png)
Для отчётов есть визуальный конструктор, чтобы диспетчер не звал айтишников. Просто мышкой столбики перетаскивать. Удобно. Максимум 5 минут на нужный отчёт в нужном периоде. Конструкторы отчётов — как правило, средства анализа (например, где лучше поставить автоматы — на Выхино или на узловой станции дальше).
Информационные дисплеи на станциях почти как у немцев. Обновляется информация каждые 30 секунд. На дисплеи приходит статика типа расписания на день, «быстрые» апдейты с изменениями, отменами и допназначениями, и в реальном времени (раз в 30 секунд) подтягиваются отклонения поездов от графика с GPS, ГЛОНАСС, сигнализации РЖД.
![](https://habrastorage.org/files/833/f0b/04b/833f0b04b6a5469ba193dc16228a7eba.jpeg)
![](https://habrastorage.org/files/ae9/62c/fa5/ae962cfa54bc469baf57c263feafcf76.jpeg)
Реальная трансляция
![](https://habrastorage.org/files/fdd/d53/352/fddd53352302412991195849ceff3cfa.png)
Экран кассира на станции
Ещё информация выгружается в IVR. Мы сделали API и для других систем.
Для полевых сотрудников на планшеты выводится облегчённая версия системы ситуационного центра — там уведомления о том, что происходит, но, грубо говоря, без инфографики на панели. У кассиров на АРМ тоже похожий кусок данных выводится, чтобы были в курсе.
![](https://habrastorage.org/files/5eb/758/ffc/5eb758ffcf35490196b394175f138b82.jpeg)
В центре
Новый ситуационный центр начали делать ещё в сентябре 2013 года, но работ ещё много. Кстати, благодаря срокам видеоаналитику, в частности, протестировали во все сезоны.
Резюме
САЦ стал ядром мониторинга, управления и анализа всей операционной деятельности перевозчика. Вот что мы сделали в итоге на сегодняшний день:
- Обслуживание билетопечатающих автоматов: внедрили процесс сопровождения сети БПА с вовлечением подрядных организаций и контролем выполнения нормативных сроков. Теперь ни один профаченный дедлайн не остаётся без тёплого дыхания руководителя на затылке. Сделали дополнительный интерфейс регистрации заявок по БПА для использования на планшетах: прямо со станции можно отправить тикет, если мониторинг не покажет проблему. Реализована информационная панель по обслуживанию БПА — есть специальный «командный вид» на карте ситуационного центра, где можно посмотреть аналитику в нужных разрезах. Сделали детализированный регламентный отчёт по инцидентам категории «Неисправность пассажирских обустройств» (это чтобы понимать что, как, где и почему). Реализован сводный отчёт по работе диспетчера с инцидентами категории «Неисправность пассажирских обустройств» (это чтобы у проблем была фамилия), плюс сделан отчёт для внутреннего пользования по инцидентам категории «Неисправность пассажирских обустройств», обрабатываемым с нарушением срока. И ещё такой же отчёт для руководства и ежедневный оперативный отчёт по тому, что и как делается, статистика по работоспособности отдельных устройств, инвентаризация. Это всё было на 2013-й. В 2014-м уже есть аналитика автосоединения тикетов в один, если они дублируются из разных источников, плюс продление закрытых уже тикетов, по которым проблема возникла ещё раз. Есть автоматическая и ручная приоритизация инцидентов. Составлена документация по обслуживанию БПА. В планах — отчёт для отслеживания ситуаций нарушения трудовой дисциплины специалистами по направлению плюс инфопанель по отслеживанию работоспособности БПА на станциях. Уф… Но пойдём дальше, это только одно направление.
- Обслуживание пассажирских устройств: сделали панель по обслуживанию и ремонту видеокамер, такая же схема контроля подрядчиков, как выше (автоматические заявки, тикеты, документы и т. п. — ломается камера, сразу падает письмо с заявкой и делается нужный документ, например). Такие же отчёты для сервисной службы, сводный отчёт по обработке заявок и детализированный отчёт по инцидентам. Большая часть работ — 2014 год.
- Обращения граждан: полуавтоматическая тикет-система категоризацией, проброска тикетов в нужные структуры, есть работа со всеми подразделениями ЦППК и контролем выполнения нормативных сроков. Чуть позже дорабатывали ITSM для хранения файлов — сканы жалоб, текст ответа и т. п. Потом понадобилось ставить тикеты по обращению на диспетчеров САЦ и на сотрудников остановочных пунктов с рабочими местами САЦ — тоже сделали. Реализовали детализированный отчёт по инцидентам, в планах — сводный отчёт.
- Оповещение сотрудников ЦППК о событиях, влияющих на обслуживание пассажиров. Это автоматическая регистрация инцидентов категории «График движения» в случае отставания электропоездов от графика по информации, поступающей из подсистемы мониторинга движения поездов. 10 станций пилотной зоны автоматически отдают события «пересечение периметра» (по итогам — проще поставить больше сотрудников охраны, слишком частые сработки), научились считать длину очереди у кассы на основе данных видеокамер, сделали панель по видеоаналитике для ситуационного центра, сделали авторассылки с оповещениями сотрудников ЦППК по электронной почте и с помощью СМС-сообщений о событиях, влияющих на обслуживание пассажиров, в частности об отклонениях от графика движения электропоездов. Сделали отчёты: реестр инцидентов, отчёты и триггеры по любым нетипичным событиям, травматизму. Позже прикрутили информирование о сильно запаздывающем поезде для дальних станций. По отчётам делаются автосправки, требующиеся по нормативам.
- Для информационно-аналитического обеспечения специалистов ЦППК сделали приём данных из источников по инцидентам разных категорий, внедрили новую промышленную платформу (Oracle BI), сконфигурировали конструктор оперативных отчётов, перенесли базовые отчёты на новую панель (чтобы они уже могли работать с ней). Потом постепенно докручивали то, что появлялось по другим направлениям.
- Привлечение к процессу обнаружения неисправностей и их исправлению сотрудников остановочных пунктов. Среди прочего — развернули на 38 станциях АРМ с доступом к «тактическому виду» для сотрудников станций.
- Актуальное расписание на остановках: в 2013 году был вывод расписания движения поездов на 10 остановочных пунктах Казанского направления. Потом — на 15 дополнительных станциях установлено 83 монитора для отображения расписания движении поездов. Реализован пилотный вывод тарифов на станции Выхино. По предложениям, поступившим от пассажиров, оптимизирован вывод расписания: теперь расписание в обоих направлениях (из Москвы / на Москву) отображаются на одном экране. В настоящее время установлено 170 дисплеев на 25 ж/д станциях в Москве и области.
- Экстренная связь: сделали оперативно-экстренную связь, установили стойки с кнопкой экстренной связи.
- Для ситуационного центра: реализован диспетчерский центр. Разработан интерфейс ведения сотрудниками ЦППК справочника оборудования, выполнено первоначальное наполнение справочника БПА. Плюс куча доработок, например, автоматическая отправка заинтересованным лицам уведомлений об истечении действия соглашений об уровне оказания услуг, расширен состав атрибутов карточки БПА в справочнике оборудования, доработан интерфейс справочника оборудования для ведения справочника объектов пассажирских обустройств.
- Мониторинг движения поездов: реализована подсистема мониторинга движения поездов (натыкали много датчиков в вагоны). Запилен отчёт «График движения», реализована информационная панель диспетчера расписания и подвижного состава. Продолжаем устанавливать датчики в поезда.
- Внешнее взаимодействие: реализован информационный обмен с внешними ресурсами, в частности РЖД, для обеспечения доступа к 15 справочникам, включая справочники расписания и остановочных пунктов.
Кто знает подобные истории — за каждой фразой адская работа как минимум десятка человек как минимум в течение нескольких месяцев. Задачи были от простых («измажься в солидоле и смонтируй железо во всех поездах») до сложных (вроде «отобрази в отчётах информацию обо всём оборудовании ЦППК»). Работы было много и инженерам-практикам, и аналитикам, и архитекторам, и админам, и, конечно, разработчикам.
Я участвовал и продолжаю участвовать в проекте. Если у вас есть вопросы по проекту или его деталям (здесь я призову на помощь коллег — руководителей команд, отвечающих за участок), мы с удовольствием расскажем подробнее в комментариях, что можно. Но сразу скажу, что можно не всё, железная дорога всё ещё остаётся довольно специфическим с точки зрения открытости информации объектом.
Если есть вопросы — задавайте в комментариях или пишите на asmirnov@croc.ru.
Комментарии (41)
wizard_s
17.12.2015 11:03+6Интересно, а можно в тамбурах поставить датчики дыма и
(засыпать курящих порошком из огнетушителя)автоматически к курящим вызывать ЧОП или СП? Или вообще делать фото (в новых составах вроде как камеры уже стоят), а потом распознавать, на какой станции индивид вышел и там его тепленьким оформлять. Вот, если честно, не столько напрягают опоздания поездов на несколько минут, сколько ежедневные поездки с курильщиками.AleSmirn
17.12.2015 11:58Это больше про поезда дальнего следования. В целом пока закон ещё не очень работает, но, видимо, в будущем будет лучше.
Amikko
17.12.2015 13:00Хорошая идея. В дальних поездах курильщиков ощутимо придавили (по крайней мере, последние пару лет я с ними не сталкивался).
VeterVeter
22.12.2015 13:48а можно поставить датчики чеснока, лука, пота, мегапарфюма, плохой еды, пива? И сразу нах высаживать их. Очень напрягают ежедневные поездки с такими индивидами.
mayorovp
17.12.2015 11:03+1Два года на проект. Два года!
Странно, что так быстро справились…
Вендоры такие: модуль нормативно-справочной информации — Talend MDM.
...AleSmirn
17.12.2015 12:04Если бы это была самая сложная часть проекта… Вы еще не пробовали получать разрешение на сверление отверстий на станциях. А если серьезно, то работы по созданию единого источника НСИ прошли достаточно гладко, что обычно редкость в таких проектах.
mayorovp
17.12.2015 19:07+1Как вообще можно использовать Talend MDM в качестве единого источника НСИ, если он не умеет рассылать информацию произвольному списку получателей? Или такая возможность есть, только ее от нас в секрете держат? :)
AleSmirn
23.12.2015 15:36Talend и руки программиста — лучше, чем просто Talend. Пришлось немного покодировать, но делали это на базе тех возможностей, которые предоставляет платформа (а конкретно – Talend DI). Работает, кстати, неплохо.
sutasu
17.12.2015 11:19+2Очень интересно! А почему для аналитики выбран Oracle и Pentaho, если СУБД MS SQL Server? MS Analysis Services не подошел по функционалу? Обычно встречал наоборот решения — MSAS над оракловым хранилищем…
AleSmirn
17.12.2015 12:10Я бы рассматривал эту архитектуру как промежуточную, сейчас идет движение к переносу практически всей корпоративной отчетности в единое хранилище данных, которое реализовано на базе Oracle BI + EMC Greenplum. Чтобы минимизировать количество используемых программных платформ, упростить архитектуру, поддержку и остальное, используем тот же BI-движок, что и в «большом» хранилище.
mickvav
17.12.2015 12:21+2Вы к аналитике следствий изменения расписания добавьте еще вставшие переезды — на переезде в Лобне, к примеру, образуется пробка на пару-тройку километров и пару часов, если вдруг поезда решают идти «впритык» — так, что переезд не открывается вовсе. Посмотреть пространственный масштаб можно на яндексе — maps.yandex.ru/21641/lobnja/?l=trf%2Ctrfe, но с временем проезда он в таких случаях врёт безбожно.
denis-isaev
17.12.2015 12:44+3Еще с переездами, расположенными прямо возле станций беда дикая. Пока поезд стоит на станции (причем переезд он уже мог проехать), переезд всё время закрыт т.к. чтобы он открылся, поезд должен отъехать на определенное расстояние. Учитывая частоту хождения электричек, выходит, что такие преезды в часы пик больше закрыты, чем открыты.
А еще если у поездов впереди некоторый затык и он от станции не отъезжает, ожидая своего зеленого светофора, то вместе с ним всё это время переезд остается закрытым.
denis-isaev
17.12.2015 12:30поддерживать оперативное принятие управленческих решений, нацеленных на повышение качества транспортных услуг, с опорой на комплексную аналитику
Буду вспоминать эти слова, заходя в неотапливаемый вагон с деревянными сиденьями :)vanxant
17.12.2015 21:40Очень давно не видел таких в МСК.
Templier
18.12.2015 16:49На курском направление после 7-8 вечера большой риск нарваться на эл-ку с деревянными лавками. С отоплением траблы бывают во всех.
WEStor
21.12.2015 10:15На киевском 2 вида электричек: морозно-освежающие и слегка испепеляющие. Либо ты замерзнешь пока доедешь до дома, либо можешь расплавить подошву ботинок об обогреватель. Что Вам больше по душе, выбирайте сами. Ах, да, про сиденья, туалеты и прочую утварь говорить вообще смысла нет. Это, конечно, хорошо, что мониторинг, все дела. Только вот не там, где нужно опять.
Evengard
17.12.2015 13:46+3Ещё бы убрали эти идиотские перерывы на Савёловском направлении. Поезда ходят чуть ли не раз в 20-30 минут, иногда вовсе какие-то непонятные перерывы на час или больше… И это в Москве на платформе, где останавливаются все электрички!
SlimHouse
17.12.2015 16:12Очень интересно как это все тестировалось?
AleSmirn
17.12.2015 17:36Первый час сидели с треугольными глазами и мыслями «Куда бежать, за что хвататься, это же такая большая система, ААААА!». А затем успокоились, выдохнули, и разбили всю эту большую не укладывающуюся в головы систему на области – отдельные варианты использования. Составили наиболее вероятные тест-кейсы, а также маловероятные заковыристые по каждому процессу. Начали тестировать. Много тестировать. Особо мучали всё, что связано с расписаниями поездов и билетопечатающими аппаратами. Вот это было довольно сложно, потому что расписание и опоздания поездов – каждый день уникальные, а ошибки хочется воспроизводить несколько раз, а не только один.
Из инструментов тестирования: JMeter, SOAP UI, и, конечно, глаза, руки и мозги, куда без них. Ну и конечно, у нас был развернут отдельный тестовый стенд, очень похожий по характеристикам на промышленный. Без этого никак.
Самым сложным процессом оказалось тестирование видеоаналитики в полях, которое, как это часто бывает в России, попало на морозы. Группа студентов с механическими счетчиками разъехалась по нескольким пилотным платформам и начала считать людей в очередях и зайцев. Хоть все студенты-счетчики и сопровождались охраной, но зайцы все равно нервно реагировали на людей, которые смотрят на них и чем-то щелкают в руках.
za90
17.12.2015 17:51> (натыкали много датчиков в вагоны)
Реквестую подробностей про это. Что за датчики? И кстати сколько вагонов/поездов всего в цппк (если не секрет)?AleSmirn
17.12.2015 20:03Много – наверное, немного преувеличили. Если посчитать в абсолютном количестве, то не так уж и много, но с другой стороны, если посчитать с точки зрения тех сложностей, которые все это сопровождали, то нереально много. Датчики – ГЛОНАСС/GPS навигаторы отечественной разработки, которые умеют интегрироваться с автоматизацией поездов и передавать сигналы в управляющий центр. Поставили датчики в 45 поездов, в головные вагоны.
Всего в зоне обслуживания ЦППК курсирует 535 подвижных составов – электрички, рельсовые автобусы и другие необычные средства передвижения.za90
17.12.2015 22:58> умеют интегрироваться с автоматизацией поездов
Ух ты, всё интересней и интересней! Этому «датчику» прямо таки необходима рельсовая цепь например или он её с успехом «эмулирует»?AleSmirn
18.12.2015 10:36Не, рельсовая цепь не нужна, рельсовая цепь используется для других целей (например, по ней отслеживают положение поездов без датчиков ГЛОНАСС/GPS). Датчики, про которые я говорил, интегрируются с телеметрией поездов, чтобы иметь возможность передавать, например, информацию о температуре в вагонах, открытии/закрытии дверей и многом другом. Пока это не используется активно, но, в целом, направление перспективное.
za90
18.12.2015 11:12М, вон о чем речь. А нам надо наоборот — отслеживать положение поездов без рельсовых цепей. Соблюдение интервала движения, локомотивные СЦБ, отображение на пульт-табло, вот это вот всё.
Хотя про телеметрию вагонов тоже конечно тема объемная и интересная. Расскажите!AleSmirn
23.12.2015 15:33Эта тема заслуживает отдельного поста. Если заказчик позволит, постараюсь как-нибудь рассказать)
ibex
17.12.2015 18:34Теперь стало жутко интересно узнать как устроено ОАО РЖД внутри.
za90
17.12.2015 21:24Это немного не РЖД насколько я понял. Просто пользуют инфраструктуру
ibex
18.12.2015 12:38+1То, что это не РЖД я понял по тексту)
Намедни был разговор с друзьями на тему эффективности управления на РЖД и оправданности таких высоких окладов среди топ-менеджеров. Моя позиция больше напоминает статью на Лурке (монополия сосущая деньги из государства), у оппонентов, главный аргумент — большая структура/протяженность путей => сложность управления + заведомая убыточность => оправданные ЗП.
Вот и стало интересно глянуть на внутреннюю кухню, чтобы оценить текущее положение дел и всю сложность.
Конечно, даже по вышеприведенной информации, можно сказать, что транспортная логистика, дело не простое, но если ей заниматься, то никакой магии не нужно да и свехрбюджетов тоже.
platinum07
17.12.2015 19:30+1Было бы неплохо, если бы данные об опоздании поездов, например, использовались в мобильных приложениях ЦППК или, если они не могут, были бы доступны через API.
AleSmirn
18.12.2015 10:48Вы только подумали, мы уже сделали. API уже есть, правда, не публичный. Используется в IVR (да, можно позвонить на бесплатную линию и железный робот расскажет про поезда и опоздания), используется для передачи данных в вышестоящие аналитические центры. Скоро будет использоваться на сайте и в мобильном приложении. Такую информацию грех прятать.
MaxGR
17.12.2015 20:14+2Про ваши информационные табло — habrahabr.ru/post/251875
AleSmirn
18.12.2015 11:12+2Этот пост мы видели, и обсуждали с заказчиком. Что-то учли, что-то поняли, что неприменимо вообще, хотя и полезно. Что-то не учитывает реалий. Но, в любом случае, и мы и ЦППК будем рады услышать предложения и идеи.
150Rus
23.12.2015 01:26Спасибо, познавательно. А когда сделаете чтобы электрички на табло на станциях (по крайней мере в Мытищах такая проблема) показывали ту электричку, которая реально приходит к платформе, а не ту, которая должна придти по расписанию?
Сейчас если, условно говоря, должна в 20:20 прийти эл-ка на Фрязино, ровно в 20:20 информация на табло сменяется под следующую по расписанию эл-ку, даже если электричка на Фрязино опоздала на 3-5 минут.AleSmirn
23.12.2015 15:29На самом деле, не совсем так. Табло показывают ближайшие электрички уже с учетом опозданий, то есть, если мы знаем, что поезд в 20:20 опаздывает, то до тех пор, пока он будет опаздывать, он будет отражаться на табло. Другое дело, что опоздание до 6 минут (5 минут включительно) во всей железнодорожной отрасли опозданием не считается. Так что такие ситуации, про которые вы пишете, могут иногда случаться.
norlin
Раз у вас есть с этими ЦППК какие-то связи – передайте, пожалуйста, чтоб они в поездах-экспресс Москва-Тула вагоны по-порядку пронумеровали.
AleSmirn
Проверено лично – сработает гораздо быстрее, если написать об этом вот сюда. Ваше предложение сразу же поступит в обработку, будет контролироваться и никуда не потеряется. Если ваш тикет относится не к ЦППК, а к РЖД, они сами передадут.