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! ;)