The post has been translated automatically. Original language: Russian
Hi folks!
My name is Maxim, I manage Sailet development studio, which develops various useful things for the public and corporate sector. For example, corporate portals, resource management systems, KPI monitoring systems, internal mobile applications and blah blah blah.
For several years we have accumulated a lot of experience and cases, which we want to share with the world. I hope it will help someone, maybe we will find new employees, partners and customers that way. The case is two years old, so some of the rake was a first for us.
Our case, related to the state organization JSC "Suburban Transportation", a subsidiary of Kazakhstan Temir Zholy (KTZ). This is the analogue of Russian Railways in Kazakhstan.
We were asked to create a system for controlling and managing suburban trains.
KTZ's previous methods of controlling commuter trains were obsolete, so we were tasked with making a simple and understandable system. To do that, we had to connect sensors, organize transmission of video stream, photos and other data directly from each train. That's how we did the hard- and software part.
The key problems
Terrible quality of connection between the cities;
Giant amounts of traffic when transferring photo/video streams;
Communication and coordination.
I think there is no point in explaining each point separately, we all have traveled out of town at some point, downloaded film and encountered bureaucracy.
Team
PM;
cool VueJS;
Laravel señor and middling;
designer;
a certified señor networker;
and the rest of the guys involved in the moment: an analyst, a tech writer, a couple of jouns on the routine.
Timeline
The actual timeframe for implementation was 4 months. That is how long we were working on the project, writing code, testing the system, setting up transfer protocols, etc.
The real term of implementation - 6 months. Including approvals and bureaucracy.
The technical support is 12 months from the date of delivery of the project.
The process
We started with gathering and processing information. The first challenge was poor communications. This is the standard story when you come to a government company and nobody is responsible for anything.
The good old Eisenhower Matrix helped us to draw up a project mindmap, which we transferred to ToR. An important point that we made in the TOR was that the only person responsible for the project was the head of the IT-department, who made the decisions and worked directly with us. This simple point saved a lot of time. Previously we simply did not have it.
The work started and we got stuck with the disgusting quality of communication between the cities. Each car had +-10 cameras in it.
It was decided to transmit data via 3g. Now I can't describe all compression and video stream optimization methods used, BUT. After tedious calculations, the cheapest option was to install mini-pc in each train, which we did.
The mini-pc became a router and controller in one. We ensured that all streams from all cameras would be transmitted to the main server in the most optimized way. In case of a connection failure, the transfer was automatically restored.
If there is no connection the manager receives a message: "Broadcast from cameras is not available. The train whose cameras you want to view is out of range.". At the same time, the user had access to the recording until the moment of interruption.
After the connection was restored, the recording was transferred and stitched together (it was not interrupted, everything was on the mini-pc), the user received a notification: "The train is in the access area. You can start an online broadcast in the "Video/Photo" section.".
The mini-pc also transmitted data from the sensors, which we will talk about in the sections.
Sections
Overview
Collecting information about the state of the train, its location with the ability to track on the map. Used Yandex.Maps for output. They are #1 in Kazakhstan.
If, the train is late, the system sets an alarm and notifies the employee. If everything is fine, it marks it in green. Updating is done every 5 seconds. The answer to the imaginary question is that it's not fast because we transmit:
Coordinates;
Speed;
Current station;
Door status (number of open doors);
Number of cars in the train;
Data from the electric train control panel;
Technical condition of the electric train.
Passengers
The system is able to read the passenger flow at a specific time on each train. It is not our achievement, we read information from sensors, installed by Transtelesoft. Counts those who entered and exited for the period, makes an automatic exportable report.
Video/Photo.
Described above.
Stations
In this section, counts passenger traffic for each particular station. In and out for the period. Automatic exported report is sent to the responsible user daily.
Database
As I wrote above, KTZ is a state-owned company that employs about 150,000 people nationwide (almost 1% of the population). 15,000 of them, employees of suburban passenger trains - electric trains.
The database contains personal and service data on all employees with up-to-date information. You can edit, add, fire, and play with the "career fate" of employees. An important function is accounting and maintenance of information of locomotive and train crews of regional sections.
Settings
There are +100500 different settings in the system. From creating routes and controlling stations, to staff record keeping and report settings. But I think this is not important.
Bottom line
As a result, after 6 months of development, we were able to organize the collection and processing of the actual data on traffic for KTZ. Sorry RZD, but we know that this is a fact.
CEO Michael Kortum personally familiarized himself with the system. On which we consider our job done successfully.
If you have any questions after reading the case, ask them in the comments and I will try to answer them! ;)
Привет народ!
Меня зовут Максим, я управляю студией разработки 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 месяцев разработки мы смогли организовать сбор и обработку актуальных данных по перевозкам для КТЖ., аналогов которой на тот момент не было. Прости РЖД, но мы знаем что это факт.
Генеральный директор Михаель Кортюм лично знакомился с системой. На чем считаем свою работу выполненной успешно.
Если у вас после прочтения кейса, возникли вопросы, задайте их в комментариях и я постараюсь на них ответить!; )
Share
