Asset Management Dashboard For A Railway Giant

Although the scope of the project was initially defined, we still chose to adopt an Agile approach towards development. We wanted to make sure that the user experience is great and all relevant information is available on screen and not missed out. For that, we kept sharing builds with the client constantly for feedback. A total of three milestones were decided which would hold multiple sprints within them. The first step in the development process was to set up the infrastructure for the apps and design login screens and UI. This involved creation of Access suites, Asset summaries UI and basic layout of the apps, followed by integration of Dashboard API and maps integration. The second milestone involved the creation of the actual train models and screens for their detailed view through the Fleet Screen. Creating accurate models for the trains and rendering them on the web and mobile app were the heavy ones here and were handled smoothly. The third milestone was to build a report system for train health and defects as well as plotting graphs to visualize overall health of each sensor on the vehicle. This task was divided into integrating APIs for maps in vehicle screens, assed details, Ui for reports and history screens. All these tasks were completed while the mobile app was being built simultaneously and resulted in a perfectly working asset monitoring web app.

The decisions made to translate the web app into the mobile app were precise due to the nature of the backend that was provided by the client. The tech stack was already in place and our work here was to translate the web app in to the existing mobile app as an enhancement. For the mobile app, the assets used were common from the web-app and the real changes lay in the development process. The entire revamping process was divided into two phases. In the first phase, the entire codebase was efactored and a search feature was added.This feature was particularly tricky because we had to implement caching of responses to have it in-app. Subsequently, chart generation was improved and alarms were listed user management features were added. In the second phase, mixed trains model to top train view compositions were added with event failure feedback and performance improvements for larger fleets.

Both the apps were tested manually and rigorously. Every new feature that was built was tested through different scenarios and re-tested with newer features. At every sprint, a fully tested build was shared with the client to test and report any bugs or discrepancies found in the app. A separate time frame was set to fix such anomalies and, at the end, provide a fully functional app to the client.

The sheer technicality of this project posed a lot of functional challenges in front of our developers but they found a way to beat them all. The app was going to handle a large number of network requests, which involved fetching information such as updates from sensors, which were made possible through large API calls to fetch data. This greatly increased load times and sometimes led to infinite loading screens. This was fixed my digging into the API call and isolating the important and relevant calls by priority and loading them first while loading the rest in a background thread, utilizing parallelism. As the server was overloaded with calls, to prevent failure, it started rejecting these calls. To fix this problem, a custom queuing service was built which would sit in between the API service layer and the controller. This service identified calls that were successful and the ones that failed and gave controller its tasks so that the calls in the app don't expire. Another major roadblock was the sheer number of trains and their individual designs. The challenge here was to detect and visualize alarms on trains easily and efficiently. Keeping in mind the different compositions of trains, we made individual assets which represent a single entity and built an algorithm to detect the type of trains the build parts and bogies automatically. In the mobile and web app, with so many features on-board, there was a matter of performance. Performance was managed by making good use of lazy loading on the JS based pages and uglifying and minifying, that helped us reduce the size of the app.