How we automated the Electric train management system in Kazakhstan
service
IT product development
stack
Phalcon, VueJS, React Native, MongoDB, Git, Kebernetes
development period
4 months
Our case involves a state-owned organization, JSC "Suburban Transport," a subsidiary of Kazakhstan Temir Zholy (KTZH).
Tasks
They approached us with a request to create a control and management system for suburban trains.
Previous methods of managing electric trains at KTZ had become outdated, so our task was to create a simple and intuitive system. To accomplish this, we needed to connect sensors, organize video streaming, photos, and other data directly from each train. Thus, we developed both software and hardware components.
Previous methods of managing electric trains at KTZ had become outdated, so our task was to create a simple and intuitive system. To accomplish this, we needed to connect sensors, organize video streaming, photos, and other data directly from each train. Thus, we developed both software and hardware components.
Key challenges
- Poor communication quality between cities
- Huge amount of traffic when transmitting photos/video streams
- Communications and coordination
I think there's no point in delving into each item separately; we've all been outside the city at some point, tried downloading a movie, and encountered bureaucracy.
Timelines
- The actual implementation timeline was 4 months. That’s how long we worked on the project, writing code, testing the system, configuring transmission protocols, etc.
- The real implementation timeline was 6 months, taking into account the approvals and bureaucratic procedures.
- Technical support for 12 months starting from the project handover date
Process
We started with gathering and processing information. The first challenge was poor communications. It's a common story when you enter a government company, and nobody takes responsibility for anything.
The good old Eisenhower Matrix helped us create a mind map of the project, which we then transferred to the technical specifications (TS). An important point is that we indicated a single responsible person in the TS, who became the head of the IT department. He made decisions and worked with us directly. This simple step allowed us to save a lot of time, something we previously lacked.
Work began, and we faced terrible communication quality between cities. Each car has about 10 cameras.
The good old Eisenhower Matrix helped us create a mind map of the project, which we then transferred to the technical specifications (TS). An important point is that we indicated a single responsible person in the TS, who became the head of the IT department. He made decisions and worked with us directly. This simple step allowed us to save a lot of time, something we previously lacked.
Work began, and we faced terrible communication quality between cities. Each car has about 10 cameras.
We decided to transmit the data using 3G. I can't describe the compression and optimization methods used for the video stream right now, BUT after tedious calculations, the cheapest solution was to install a mini-PC in each train, which is what we did.
The mini-PC acted as both a router and controller. We configured it so that the entire stream from all the cameras would be transmitted to the main server in the most optimized form possible. In case of a connection interruption, the transmission would automatically resume.
If there was no connection, the manager received a message: "Camera broadcast unavailable. The train whose cameras you want to view is out of range." However, the recording up until the disconnection remained accessible to the user.
Once the connection was restored, the recordings were merged (they weren't interrupted, as everything was stored on the mini-PC), and the user received a notification: "Train back in range. You can start the live broadcast in the 'Video/Photo' section."
The mini-PC also transmitted data from various sensors, which we'll discuss in subsequent sections.
The mini-PC acted as both a router and controller. We configured it so that the entire stream from all the cameras would be transmitted to the main server in the most optimized form possible. In case of a connection interruption, the transmission would automatically resume.
If there was no connection, the manager received a message: "Camera broadcast unavailable. The train whose cameras you want to view is out of range." However, the recording up until the disconnection remained accessible to the user.
Once the connection was restored, the recordings were merged (they weren't interrupted, as everything was stored on the mini-PC), and the user received a notification: "Train back in range. You can start the live broadcast in the 'Video/Photo' section."
The mini-PC also transmitted data from various sensors, which we'll discuss in subsequent sections.
Sections
- OverviewGathering information about the train's condition and its location, with the ability to track it on a map. We used Yandex.Maps for display, as they're #1 in Kazakhstan.
If the train is delayed, the system sets off an alarm and notifies the staff. If everything is fine, it marks the train green. Updates occur every 5 seconds. Let me answer a potential question: why isn't it faster? Because we're transmitting:- 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
- PassengersThe system can count passenger flow at a given time in each train. This isn't our achievement; we read the information from sensors installed by "Transtelesoft". It counts those who entered and exited during a period and generates an automatic exportable report
- StationsThis section tracks passenger flow at each individual station. It records those who entered and exited during a period. An automatic exportable report is sent to the responsible user daily
- DatabaseAs I mentioned earlier, KTZ is a state-owned company with around 150,000 employees across the country (almost 1% of the population). Of these, 15,000 work on suburban passenger trains—electric trains.
The database contains personal and professional data for all employees, including current information. You can edit, add, dismiss, and manage the "career fate" of employees. A crucial function is maintaining and updating information about locomotive and train crews on regional routes
- SettingsThe system has countless settings—from route planning and station management to employee administration and report configuration. But I suppose that's not essential here
Result
After six months of development, we successfully organized the collection and processing of real-time transportation data for KTZ, creating a system without precedent at the time. Sorry, RZD, but we know it's true.
CEO Michael Kortyum personally reviewed the system. We consider our job well done.
CEO Michael Kortyum personally reviewed the system. We consider our job well done.
✦ Schedule your consultation right now
and learn more about how the implementation of IT solutions can help your business become better