Real-time passenger monitor system
Background
The Federal Ministry for Digital and Transport started an innovation initiative under the name of mFUND for bringing digitalization in Germany on the next level. Many facilities, organizations and companies come together in several projects to research how to generate and use data for a new generation of mobility in Germany. Using public transportation with an handicap, like being dependend on a wheel chair, is challenging. The goal of the specific project, that I am a part of, is to give those people a better user experience while commuting every day with public transportation. As a Full Stack Engineer I am responsible for several tasks, such as creating a web frontend, designing and implementing a microservice architecture in the backend, database design, unit testing and deploying both aspects, as well as a bit of UI/UX Design. In the beginning of the project I also contributed to the algorithm and software design on the embedded microcontroller units.
Hardware & Software
Our team is responsible for building a hardware, that can generate passenger data, based on the amount of incoming and outgoing people. We use several sensors that are measuring the current occupancy and based on that amount of people, who would use the space, which is reserved for wheel chair users. The hardware consists of several sensor units and a master unit. The sensor units count the people who enter or leave the vehicle, whenever that vehicle is stopping at a bus or tram stop. After finishing the counting algorithm, they send the results to the master unit, which then sends that result to our servers.
As soon as the data arrive on the backend, they get stored in a database and then internally get distributed to several microservices for a real time monitoring in the frontend (later more).
Our hardware team, consisting of electronic engineers built that hardware from scratch based on an ESP32 microcontroller. I helped developing the first versions of the counting algorithmn, which is based on a 2-dimensional matrix and detects the occupied fields, that passengers could stand or sit in. Later on it got improved and another dimension was added for evaluating the height of each person standing in that matrix, for a more precise prediction.
Quite soon, I moved on by engineering every aspects of handling that prediction data on our servers.
The Frontend
"Design is not just what it looks like and feels like. Design is how it works."
A famous quote that Steve Jobs, co-found of Apple Inc. said many years ago and I couldn't agree more. On that project I am fully responsible for the UX/UI Design, alongside to my coding jobs. I even came up with that product name Urbanlift, which essentially is a bit of slangish for using transportation (getting a lift) in an urban environment such as cities.After designing a logo in an U-shape, I started to plan the design and functionality of that web frontend by applying requirement engineering with my team.
Tech stack
We decided to use React with Typescript and TailwindCSS. That way we can deliver software components faster, more robust and reusable. Moreover using Tailwind works charmingly when designing different responsive viewports by using their breakpoint classes. Internally I use Immer for working with immutable states. For sharing data across several components I use the Context API, which doesn't require Redux or any other global state management anymore.
Login & User management
The whole web application is for authorized people only. Therefore it needs a sign-in landing page, which manages login data that is mapped to existing users in the database, who have particular permissions for resources based on their responsiblity. Admins can add users, who then can login into the system and manage their information, such as changing their profile picture or password (based on a challenge-response mechanism) and more.
Mobile First - Everything has to be fully responsive, so that on every device users get a proper view of that application, regardless if they use a desktop, tablet or phone. Moreover the whole web application supports dark / light mode by using a toggle switch.
Dashboard
The dashboard is the heart of that application. It shows in real-time the current data, that gets predicted for each vehicle / station. It is still currently under development, since there is more work to do, especially in regards of data that I need to present everything as planned. In the future, it will be visible to see a live and historic view, with several filter options of every vehicle. The history information will show every people counter for every station and even for every door! That way, transportation companies can determine the current occupancy and can possibly react to it, especially in regards of people with an handicap who need space for a wheel chair. They can react to live data, as well as making analysis based on data from the past. I will update more about the progress as time goes by, so stay tuned ✌️.
Map
The map is showing the current vehicles inreal time. It is connected via REST and WebSocket. As soon as there will be any update of any vehicle it will immediately send it to the map, which is subscribed to an update event.
I generated my own tiles of Germany and then use those tiles to run my own tile server, which then serves the vector tiles with MapLibre GL JS.It's blazing fast, everything is hosted on our servers, and most of all, it isfree. Other map services charge fees, depending on how many tiles you request, which can get pretty pricey at some point. Every vehicle has a popup on click which sticks to it and shows more detailed data about it. At this point it is actually really amazing to see something visually of all the dots connecting and working together. Starting from the hardware devices to the backend architecture via the frontend and tileserver, to finally to the result of seeing an actual vehicle driving in real time. Moments like this are very satisfying as a Full Stack Engineer.
Vehicle management
Every vehicle is mapped to a specific master unit. Since the master unit sends the current predicted data, it is important to know which vehicle and line is currently active. A user can add, edit and delete a vehicle, specifying the vehicle data, such as manufacturer, type and so on. It is designed in a way, so that it can be configured for all types of public transportation vehicles, regardless if it's a train, bus, tram or subway.
The Backend
I decided to use NodeJS with Typescript for our backend, since it is super fast, in its performance as well as implementing time. NodeJS offers a whole bunch of npm packages, which simplifies certain coding tasks quite easily. The data gets persistently stored in a PostgreSQL database. Before I wrote any code for the backend I designed a data model for our purpose, which I later adjusted gradually.
Microservices
Instead of implementing everything in a monolithic backend software, these days it is highly recommended to use a microservices architecture. If one service crashes, the other ones are usually not affected, they are independend, can be deployed distributed on several servers and scaled individually.
REST
A microservice can communicate with the frontend or another microservice via REST, in my case I use HTTP with Express in NodeJS. I implemented my own middlewares for security and authentication.
WebSocket
For real-time and push communication I implemented my own WebSocket libraries, which also support security and authentication features. I created a WebSocket server library, as well as a client library. Moreover it detects broken connections and reconnects automatically if a connection is online again. I defined a transport structure in a JSON schema, for sending and receiving data. For receiving data a client can subscribe to a specific custom event, which can be used multiple times in code, so that for instance React components receive data in real-time and can render it into the UI. SocketIO and MQTT work very similar, so they inspired me to use a design mechanism like that. The WebSocket Server is a standalone microservice, which then sends data across other microservices and frontend clients.
The IoT devices in the vehicles send data to a webservice, stores those data in the database and simultaneously distributes those data to all connected WebSocket clients in the frontend. It's blazing fast anddoesn't require any refresh or long polling in the browser.
Containerization
Every microservice runs in its own container environment using Docker. Often times code needs to be shared among microservices. In order to avoid code duplication I created a shared library, which can be used in all microservices. In our case I use shared volumes in Docker, for mutual access.
Image manipulation on the fly
Data assets such as images, videos or documents are hosted in a seperate microservice, so they are also accessable via a REST API. Since the frontend uses profile pictures for their users, every user can upload their own picture and crop it during the upload process. After completing the upload, the picture gets cropped, compressed and resized into several sizes. Based on the query params of the URL, the picture can get fetched in several different sizes on the fly. I also enabled caching which improves the performance even more. Of course it also supports authentication, so that only authorized users can upload, fetch or manipulate images or other assets only.
Unit Testing
Both - Frontend & Backend use unit tests. The frontend uses React Testing Library and Jest. HTTP Requests are getting mocked. The backend uses Chai and Supertest in order to test the HTTP interfaces properly.
Deployment
The software is deployed on several Linux machines. I wrote a few shell scripts, which deploy that software by pulling the newest updates, testing all components and then deploy on the webserver, like a minimal CI/CD pipeline. Every communication is encrypted via HTTPS or WSS.