Technical architecture
Terms and abbreviations
AMQP (Advanced Message Queuing Protocol) — an open protocol for passing messages between system components through a broker.
CSS (Cascading Style Sheets) — the style language describing the appearance of HTML documents: colours, fonts, layout and element responsiveness, separating content from presentation.
EGTS — a telematics data transmission protocol.
HLS (HTTP Live Streaming) — a video streaming protocol over HTTP, used for video archive playback.
HTML (HyperText Markup Language) — the standard markup language for building the structure of web pages.
HTTP (HyperText Transfer Protocol) — the application protocol for data exchange between a browser and a server on a request-response model.
JavaScript (JS) — a high-level, interpreted, multi-paradigm programming language, the standard for building interactive web sites.
JWT (JSON Web Token) — the access token format used to authorise API requests.
MCP (Model Context Protocol) — the protocol by which external clients and software agents connect to the system's application functions.
Nginx — a web server and reverse proxy running on Unix-like operating systems.
PostGIS — an open-source extension for the PostgreSQL DBMS that turns it into a full spatial database. It adds support for geographic objects (points, lines, polygons, rasters), lets them be stored, and enables complex spatial analysis and fast location search using SQL.
PostgreSQL — a free, open-source relational database management system focused on extensibility and SQL standard compliance.
Protobuf (Protocol Buffers) — the binary serialisation format used as the primary transport format of the application API.
RabbitMQ — an open-source message broker for asynchronous data exchange between applications and microservices. It uses AMQP for reliable delivery, temporary storage and complex routing of messages, providing fault tolerance and scalability.
RTSP (Real Time Streaming Protocol) — the protocol controlling video streaming from surveillance cameras.
Ruby on Rails — a framework written in the Ruby programming language, implementing the Model-View-Controller architectural pattern for web applications and integrating them with a web server and a database server. It is open-source software distributed under the MIT licence.
TimescaleDB — a PostgreSQL extension for high-performance real-time analytics over time series and events.
WebRTC — a set of protocols for low-latency real-time video delivery.
WebSocket — a bidirectional protocol over a single persistent connection, used to deliver real-time data.
Wialon — a GPS/GLONASS monitoring platform that allows users to track mobile and stationary objects (vehicles); the software supports the protocol of the same name for data from onboard terminals.
Road network — the street and road network used for routing.
1. General
RUBIN-T software is intended for vehicle monitoring and for transport security at observation sites: monitoring vehicle location, speed compliance, distance travelled, adherence to routes and visits to predefined places, and recording vehicle passages by registration plate.
RUBIN-T is used by organisations and institutions that manage commercial, passenger, freight and specialised transport.
RUBIN-T automates fleet management and reduces operating costs.
2. Overall architecture
RUBIN-T implements a three-tier client-server architecture:
- client tier — the web interface and the mobile applications;
- application tier — the web server, the application server, the telematics ingestion and video analytics subsystems, and the message broker;
- data storage tier — the database servers.
3. Client tier
At the client tier, a web browser must be running on the user's workstation, whatever its platform (hardware plus operating system).
The browser executes the code delivered from the application tier. That code builds the user interface, which in turn provides interactive communication between the user and the software, carries data in both directions, and passes the user's control actions to the software. The client application executes code in HTML, CSS and JavaScript.
The web interface is a single-page application built on the React library with TypeScript typing. Navigation between screens happens on the client side; data exchange with the server uses HTTP.
The client tier comprises:
| Component | Purpose |
|---|---|
| Web interface | The operator's main workstation |
| Mobile applications (Android, iOS) | Map, vehicle cards and alerts away from the workstation |
| External information systems | Integration through the REST API and the MCP endpoint with token authorisation |
The client's mapping subsystem draws objects (vehicles, geofences, cameras, cargo) as layers over a basemap, with hardware-accelerated rendering.
Real-time data (current vehicle coordinates, device states, events) is delivered to the browser over a persistent WebSocket connection, without periodic polling. Live video is delivered over WebRTC; archive playback uses HLS.
4. Application tier
4.1 Nginx web server
At the application tier, access to the software and data exchange with the user tier over HTTP is provided by the Nginx web server.
Nginx:
- stores and serves the static content of the user interface in HTML, together with the accompanying CSS and JavaScript files;
- acts as a reverse proxy, routing application API requests to the application server;
- terminates secure connections;
- proxies the WebSocket connections that carry real-time data.
4.2 Application server
The Ruby on Rails application server is a set of services implemented in the Ruby programming language. It runs in API mode: no HTML is generated on the server, and the entire user interface is built at the client tier.
The application server implements:
- the business logic of vehicle, geofence, camera and cargo monitoring;
- translation of HTTP requests into DBMS queries (the data storage tier);
- authentication and access control;
- statistics computation and report generation, including XLSX export;
- servicing the persistent WebSocket connections that deliver real-time data;
- integration with external subsystems.
The primary transport format of the application API is Protobuf; JSON is used for individual data structures. Spatial data is delivered as GeoJSON. For the same resource the response format is selected automatically according to the client's request, which reduces the volume transferred when working with large result sets.
To serve user requests and implement the business logic, the application server interacts:
- with the RabbitMQ message broker, which coordinates data transfer between the subsystems of the software architecture;
- with the DBMS, where data is selected and processed;
- with the telematics server, which receives data from the onboard terminals fitted to vehicles;
- with the video analytics subsystem and the video recording service, which connect to video streams, store the video archive, provide live camera viewing, and recognise vehicles, plates and faces;
- with the routing and geocoding services.
4.3 Background workers
Long-running and periodic operations are executed outside the user request cycle by separate processes:
| Task group | Contents |
|---|---|
| Statistics | Hourly and daily aggregation of vehicle positions, trips, camera fixations and device states |
| Destinations | Route and arrival forecast computation, arrival detection, alert dispatch |
| Public transport | Stop arrival forecasts, schedule adherence monitoring |
| Notifications | Composing and delivering alerts by email, Telegram, in-app notification, webhook and push notification |
| Integrations | Synchronising geofences and observed objects with the telematics server and the video subsystem |
| Housekeeping | Refreshing location addresses, purging obsolete service records |
4.4 RabbitMQ message broker
To coordinate data transfer between the subsystems of the software architecture, the RabbitMQ message broker interacts:
- with the Nginx web server;
- with the Ruby on Rails application server;
- with the telematics server;
- with the video analytics subsystem.
Using a broker decouples the subsystems in time and load: the stream of telematics messages and video analytics events lands in queues, and the consumers take messages at whatever rate their capacity allows. The failure or restart of one consumer does not lose data.
The following processing queues are defined:
| Queue | Contents |
|---|---|
| Positions | Coordinates, speed, course and service parameters from vehicle terminals |
| Position cache | The operational layer of current vehicle positions for real-time display |
| Events | Monitoring events: geofence entry and exit, started moving, stopped, overspeed, alarm, terminal state change |
| Video analytics | Messages about detected objects and recognised registration plates |
High-frequency messages are grouped and rate-limited on write, which prevents duplicate records of the same kind close together in time.
4.5 Telematics ingestion subsystem
The telematics server receives telematics data from the onboard terminals fitted to vehicles, parses the common telematics transmission protocols (Wialon, EGTS and others) and generates events.
Subsystem functions:
- receiving data in the onboard terminals' protocols;
- normalising coordinates, speed, course and service parameters;
- detecting geofence boundary crossings and forming the corresponding events;
- passing normalised data and events to the message broker.
Onboard terminals are tracked by a unique device identifier; the binding of a terminal to a vehicle is kept with history, so data is reconstructed correctly when equipment is replaced.
4.6 Video surveillance and video analytics subsystem
The subsystem connects to video streams, stores the video archive, provides live camera viewing and recognises vehicles, registration plates and faces. It comprises the following components.
The video analytics service processes video streams in real time. It works by state convergence: a single supervising process watches the list of active cameras in the database and starts one processing thread per camera. All threads share one set of machine-learning models, which allows many cameras to be served within one process and one compute-device context. For every object in frame the service performs detection, tracking across frames and class-specific deep analysis, including registration-plate recognition. The result is a record of the object's presence with a full lifecycle: the record is created when the object appears in frame and closed when it leaves, so a long vehicle stop is recorded once rather than as many repeated entries.
The video recording service records camera streams over RTSP into fixed-length files without re-encoding, maintains a segment registry, and serves the recordings on demand as an HLS stream for timeline playback, as well as producing export files. Storage may be on disk or on object storage. This service also works by state convergence: the list of cameras to record is read from the database, and any divergence between desired and actual state is resolved automatically, so recording recovers from failures and restarts without manual intervention.
The stream publishing service delivers live video to the browser over WebRTC. Streams are published separately per resolution, which allows the quality to be chosen according to available bandwidth and the number of cameras viewed simultaneously.
4.7 Routing, geocoding and road graph services
The routing service builds routes over the road network: a route between given points with turn-by-turn directions, a public-transport route line through a sequence of stops, and a route to an assigned destination with an arrival time estimate.
The geocoding service converts coordinates into an address for displaying a vehicle's current location, and back.
The road graph service maintains the transport graph: creating and editing road segments, assigning attributes to graph objects and exporting the map. The graph is the input data for the routing service.
5. Data storage tier
The database tier of the software architecture holds a PostgreSQL 16 DBMS with the PostGIS and TimescaleDB extensions.
PostgreSQL provides data caching services for the software's target functions. It holds the database storing all data, including geodata. Geodata is also processed by PostGIS, a PostgreSQL add-on and open-source software that adds support for geographic objects to the relational PostgreSQL database.
The following databases are used:
| Database | Extensions | Purpose |
|---|---|---|
| Application database | PostGIS, pg_trgm, pgcrypto | Vehicle, geofence, camera, cargo, route and stop records; events, trips, fixations, statistics, users and access rights |
| Telematics database | TimescaleDB | The stream of telematics data from onboard terminals, position history |
| Road graph database | TimescaleDB | The transport graph of the road network |
The extensions serve the following purposes:
- PostGIS — storing and processing spatial data types (vehicle position points, geofence polygons, route and track lines) and running spatial queries: point-in-polygon, area and perimeter computation, proximity search;
- TimescaleDB — high-performance storage and aggregation of telematics time series;
- pg_trgm — fuzzy text search, used when matching the names of related objects during data import;
- pgcrypto — cryptographic functions.
Large tables are partitioned by time, which keeps query time predictable as the accumulated data grows.
The video archive is stored outside the DBMS — on the file system or on object storage; the database holds a registry of recorded segments bound to a camera and a time interval.
6. Component interaction
| Exchange | Protocol, format |
|---|---|
| Browser ⇄ web server | HTTP, HTML/CSS/JS |
| Client ⇄ application API | HTTP, Protobuf (primary), JSON, GeoJSON, XLSX |
| Client ⇄ application server (real time) | WebSocket |
| Client ⇄ video subsystem (real time) | WebRTC |
| Client ⇄ video subsystem (archive) | HLS over HTTP |
| Onboard terminal ⇄ telematics server | Wialon, EGTS and other terminal protocols |
| Camera ⇄ video subsystem | RTSP |
| Subsystem ⇄ subsystem | AMQP through the RabbitMQ broker |
| External systems ⇄ software | REST API, MCP endpoint |
Real-time delivery channels to the browser are separated by object type: vehicle positions, vehicle states, events, geofences, cameras, camera fixations and recognised registration plates. The client subscribes only to the channels the current screen needs.
7. Access control
Users authenticate with an email and password pair and receive a JWT access token; sign-in through external identity providers is supported. Passwords are stored as irreversible hashes.
Authorisation is enforced at the application server: every object type has access policies restricting both the operations available and the subset of data visible to a given user.
Programmatic access uses API tokens with a restricted scope (read only, or read and write) and an expiry. A token carries the permissions of the user who issued it and can be revoked at any time.
Changes to key objects are recorded with version history.
8. Deployment
RUBIN-T is delivered as a set of containers deployed with Docker on server hardware running Ubuntu. Container images are published to an internal image registry.
The deployed containers are:
| Container | Purpose |
|---|---|
| Web server | Static user-interface content, reverse proxying |
| Application server | Application API request handling |
| Background worker | Deferred and periodic tasks |
| Queue consumers | Processing positions, position cache, events and video analytics messages (one container per queue) |
| Telematics server | Receiving data from onboard terminals |
| Video subsystem | Object detection and recognition, video archive recording |
| Message broker | Data exchange between subsystems |
| Database servers | Application database, telematics database, road graph database |
| Road graph service | Maintaining the transport graph |
| Migration containers | Bringing database schemas to the current version on upgrade |
Upgrades replace container images after applying database schema migrations. Horizontal scaling is achieved by increasing the number of application server and queue consumer instances.
The deployment procedure is given in Installation.
Printable version
The PDF edition of this document is available in Russian:
⬇ Download PDF (RU)