Как мы автоматизировали систему управления «электричками»

Привет народ!

Меня зовут Максим, я управляю студией разработки Sailet, которая занимается разработкой разных полезных вещей для государственного и корпоративного сектора. Например, корп. порталы, системы управления ресурсами, системы мониторинга ключевых показателей, внутренние мобильные приложения и бла бла бла.

За несколько лет у нас накопилось опыта и кейсов, которыми мы хотим поделиться с миром. Надеюсь, это поможет кому-то, возможно мы найдем так новых сотрудников, партнеров и клиентов. Кейс двухгодичной давности, поэтому некоторые грабли для нас были первыми.

Наш кейс, связан с государственной организацией АО «Пригородные перевозки», дочка Казахстан Темир Жолы (КТЖ). Это аналог РЖД в Казахстане.

Кабина машиниста

К нам обратились с просьбой создать систему контроля и управления пригородными поездами.

Прежние способы управления электричками в КТЖ морально устарели, поэтому перед нами встала задача сделать простую и понятную систему. Для этого нужно было подключить датчики, организовать передачу видеопотока, фото и прочих данных напрямую с каждого поезда. Таким образом мы делали софтверную и хардверную части.

Ключевые проблемы

  • Отвратительное качество связи между городами;
  • Гигантское количество трафика при передачи фото/видеопотока;
  • Коммуникации и согласования.

Думаю нет смысла раскрывать каждый пункт отдельно, все мы когда-то выезжали за город, скачивали фильм и сталкивались с бюрократией.

Команда

  • PM;
  • крутой VueJS;
  • сеньор и миддл Laravel;
  • дизайнер;
  • сертифицированный сеньор сетевик;
  • и остальные ребята, привлекаемые в моменте: аналитик, тех. пис., пара джунов на рутину.

Сроки

Фактический срок реализации — 4 месяца. Именно столько времени, мы работали над проектом, писали код, тестили систему, настраивали протоколы передачи и т.д.

Реальный срок реализации — 6 месяцев. С учетом согласований и бюрократии.

Тех. поддержка 12 месяцев со дня сдачи проекта.

Процесс

Начали мы со сбора и обработки информации. Первым вызовом были плохие коммуникации. Это стандартная история, когда ты приходишь в гос. компанию, а никто ни за что не отвечает.

Старая добрая Матрица Эйзенхауэра помогла составить mindmap проекта, который перенесли в ТЗ. Важный пункт, что в ТЗ мы указали единственного ответственного, им стал руководитель IT-отдела, который принимал решения и работал с нами напрямую. Этот простой пункт, позволил сэкономить кучу времени. Ранее у нас его просто не было.

Работа началась и мы уперлись в отвратительное качество связи между городами. В каждом вагоне имеется +-10 камер.

Было принято решение, передавать данные с помощью 3g. Я не смогу сейчас описать использованные методы сжатия и оптимизации видеопотока, НО. После нудных просчетов, самый дешевый вариант был установить в каждый поезд mini-pc, что мы и сделали.

Mini-pc стал роутером и контроллеров в одном лице. Мы сделали так, чтобы весь поток со всех камер, передавался на основной сервер в максимально оптимизированном состоянии. В случае обрыва связи, передача автоматически восстанавливалась.

Если связи нет, менеджеру выдается сообщение: «Трансляция с камер недоступна. Поезд, камеры которого Вы хотите просмотреть находится вне зоны деиствия.». При этом пользователю была доступна запись до момента обрыва.

После восстановления соединения, передачи и склейки записи (она не прерывалась, все было на mini-pc), пользователь получал оповещение: «Поезд в зоне доступа. Можете запустить онлайн-трасляцию в разделе »Видео/Фото«.».

Mini-pc также передавал данные с датчиков, о которых мы расскажем в разделах.

Разделы

Обзор

Сбор информации о состоянии поезда, его местоположении с возможностью отслеживания на карте. Использовали Яндекс.Карты для вывода. В Казахстане они № 1.

Если, поезд опаздывает, то система ставит будильник и оповещает сотрудника. Если всё в порядке, то помечает зеленым цветом. Обновление производится раз в 5 секунд. Отвечаю на мнимый вопрос — это не быстро, потому что мы передаем:

  • Координаты;
  • Скорость;
  • Текущая станция;
  • Состояние дверей (количество открытых);
  • Количество вагонов в составе;
  • Данные с пульта управления электропоездом;
  • Техническое состояние электропоезда.

Пассажиры

Система умеет считать пассажиропоток в конкретное время в каждом поезде. Это не наше достижение, мы считываем информацию с датчиков, установленных компанией «Транстелесофт». Считает вошедших и вышедших за период, составляет автоматический экспортируемый отчет.

Видео/Фото

Описал выше.

Станции

В этом разделе, считается пассажиропоток по каждой конкретной станции. Вошедшие и вышедшие за период. Автоматический экспортируемый отчет отправляется ответственному пользователю ежедневно.

База данных

Как я писал выше, КТЖ государственная компания, в которой работает около 150 тысяч человек по всей стране (почти 1% населения). 15 тысяч из них, сотрудники пригородных пассажирских поездов – электричек.

В базе данных содержатся личные и служебные данные по всем сотрудникам с актуальной информацией. Можно редактировать, добавлять, увольнять и играться с «карьерной судьбой» сотрудников. Важная функция — это учёт и ведение информации локомотивных и поездных бригад региональных участков.

Настройки

В системе +100500 различных настроек. От построения маршрутов и управления станциями, до ведения сотрудников и настройки отчетности. Но, думаю это неважно.

Итого

В итоге после 6 месяцев разработки мы смогли организовать сбор и обработку актуальных данных по перевозкам для КТЖ., аналогов которой на тот момент не было. Прости РЖД, но мы знаем что это факт.

Генеральный директор Михаель Кортюм лично знакомился с системой. На чем считаем свою работу выполненной успешно.

Если у вас после прочтения кейса, возникли вопросы, задайте их в комментариях и я постараюсь на них ответить!; )

Комментарии 0

Авторизуйтесь чтобы оставить комментарий