Building FleetFlowsFull-Stack Fleet Tracking: CAN Bus to Cloud at Scale (Currently Live)

The CAN Bus Challenge

Modern vehicles use CAN (Controller Area Network) bus — a protocol where every electronic control unit (ECU) broadcasts data constantly. The challenge: every manufacturer uses different CAN message IDs and data formats. For example, in Tata Ace BS-IV/BS-VI models, Speed data comes on PGN/ID 0xF005 (61445) or 0x0100 (Speedometer), bytes 2-3 (Wheel-based vehicle speed) requiring the formula (raw value / 256) km/h, while engine coolant temperature data is on PGN/ID 0xFEEE (65262) or 0x0105, byte 1 (ECT) with formula (raw value - 40)°C. Getting this wrong means displaying nonsensical data or potentially damaging the vehicle's network.

The important part here is to understand that each vehicle, even between model years and trims, has different CAN frames and protocols of communicating. Some vehicles will not send you raw CAN data when you listen to all messages, in which case, you need to poll for the same by sending in specific "request" CAN messages to the vehicle, and it'll return the requested frame to you.

Reverse Engineering

This meant I had to research and reverse engineer quite a lot of CAN frames coming from specific vehicles, and make a dictionary out of that. This essentially boils down to sniffing CAN data (F-CAN not B-CAN) from vehicles, dumping into large logs, then filtering and putting various formulae on each frame raw data to check if we get meaningful values or not.

After 1-2 weeks of doing this, I had a meaningful set of data for many common fleet vehicles, which meant moving forward to the hardware next, where I focused on making the tracker a single-piece product with a proper PCB with temperature and vibration tolerance, moving away from test connections.

Hardware Lookup

Initially I tested the hardware stack on 4-5 different MCU and external module development boards, with breadboard or prototype PCB connections being used between all. This was important to get MQTT connections to securely work along with the A7672S modem, with SSL, which AWS IoT needs.

MCU & modem selection would play a significant role in the future viability and cost-to-make for each tracker device, along with other factors such as power consumption, features such as debuggability, memory or flash headroom, in-built CAN, power/sleep states and the like - All of which greatly influenced my design.

As observed on the table, I tested the stack on 4-5 different MCU development boards with external module boards, with breadboard or prototype PCB connections being used between all. This was important to get MQTT connections to securely work along with the A7672S modem, with SSL, which AWS IoT needs.

Each had it's trade-off, the ESP32 was overkill and it's WiFI/BT didn't justify the high power consumption as this project doesn't need any of them. Switching to STM32 MCUs gave better industrial characteristics, such as increased temperature range, decreased power consumption, and better hardware debugging and PCB designs support. Eventually, considering that I could remove the external MCP 2515 CAN module by choosing an MCU with in-built CAN controller, I came to the final design.

The same process went behind the selection choices for the modem. SIM800 modules, though very cheap to acquire, were out of question as 2G has been phased out pretty much everywhere. Similarly, SIM7000 modules seemed way too overkill with upto 150MBps transfer speeds. NB192 IOT modules are much more power efficient but they need specialized NB-IoT networks, which are not as widespread yet in even major carriers in countries such as India. So the network constrain was 4G CAT1 / 5G, the modem chip had to be relatively cheap and readily available with good AT command stability and support.

Final Hardware Stack

The hardware I finally selected used production automotive/industrial-grade components:

Connection Strategy

I used the standard OBD-II port which is present on most vehicles after 2002, avoiding voiding warranties by direct CAN tapping gauge cluster CAN lines. This required locating pinouts for SAE J1850 Bus, ISO 15765-4 and ISO9141 CAN/K-line on the OBD2 vehicle female connector, for which I used a DB9-OBD2 connector initially, mapping matching pins and soldering splice connectors without cutting factory wires, and adding TVS diode protection with a 1.5A fuse for safety.

Core Responsibilities

The CAN Profile System

To constrain what exact vehicle users are allowed to work with, I added in another DB table for vehicle catalog entries (Admin accounts). This means logged in users can only add new tracked vehicles/specific can profiles by make, model and year-range filters, based only on available catalog, with sanitisation on backend for the same. This secured the server-managed CAN profile system. Instead of hardcoding vehicle-specific parameters in firmware, the device fetches a JSON profile on boot. This means I can add support for new vehicle models without touching the hardware — just create a profile in the admin panel.

// Example CAN Profile (stored on server)
{
  "make": "Honda",
  "model": "Accord",
  "year_min": 2008,
  "year_max": 2012,
  "baud_rate": 500000,
  "profile_data": {
    "speed": {
      "can_id": "0x158",
      "start_byte": 4,
      "length": 2,
      "formula": "value / 100",
      "unit": "km/h"
    },
    "rpm": {
      "can_id": "0x1DC",
      "start_byte": 1,
      "length": 3,
      "formula": "(value / 500) * 2",
      "unit": "rpm"
    },
    "fuel_level": {
      "can_id": "0x3B3",
      "start_byte": 2,
      "length": 1,
      "formula": "(value / 255) * 100",
      "unit": "%"
    }
  }
}

Why AWS IoT Core?

I evaluated several approaches for handling device connectivity. Running my own MQTT broker (Mosquitto on EC2) would require managing certificates, scaling, and availability. AWS IoT Core provided a managed solution with built-in security, automatic scaling, and pay-per-message pricing that made it cost-effective even at scale. To highlight what I wanted from an IoT endpoint -

Certificate Management & Security

Each device requires three components for authentication: Amazon Root CA 1 (public), a unique device certificate (per-device public key), and a private key that never leaves the device. When deploying at scale, every device batch gets its own certificate-key pair, deployed during device flashing stage by a company Admin. Devices are differentiated using the device_uuid in the message payload, along with a salted secret which can only be decrypted by server.

MQTT Topic Strategy

// Topic Architecture
vehicles/{device_uuid}/telemetry  → Device publishes telemetry
vehicles/{device_uuid}/commands   → Backend sends remote commands
vehicles/{device_uuid}/config     → Backend sends CAN profile updates

// IoT Policy (per-device authorization)
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["iot:Publish"],
      "Resource": ["arn:aws:iot:region:account:topic/vehicles/${iot:ClientId}/telemetry"]
    },
    {
      "Effect": "Allow",
      "Action": ["iot:Subscribe", "iot:Receive"],
      "Resource": ["arn:aws:iot:region:account:topicfilter/vehicles/${iot:ClientId}/*"]
    }
  ]
}

This policy ensures devices can only publish to their own telemetry topic and subscribe to their own command topics. Even if a certificate is compromised, the attacker cannot access other vehicles' data.

Security Architecture

My earlier iterations had client-supplied account_id in requests, when locally testing backend-frontend flow on docker. This was an obvious but temporary security hole, which was refactored to extract identity from cryptographically verified JWT tokens, added database-level Row-Level Security policies, and implemented account-scoped WebSocket rooms. Defense in depth at every layer.

Technology Choices

-- Create hypertable (automatic partitioning by time)
SELECT create_hypertable('telemetry', 'time');

-- Add compression policy (90% storage reduction)
SELECT add_compression_policy('telemetry', INTERVAL '7 days');

-- Query last 24 hours (uses time-based indexes)
SELECT * FROM telemetry 
WHERE linked_vehicle_id = $1 
  AND time > NOW() - INTERVAL '24 hours'
ORDER BY time DESC;

Securing the backend so far, I also had to make sure the client company's Admin/Editor user(s) managing their fleet, would always have a smooth experience with good visual feedback on every page they visit on the console.

So I started building the blocks for each page the website would have, testing user flow for not just an account for lesser vehicles, but also accounts having a massive number of vehicles (2000+). Eventually, I went with the following setup -

Tech Stack

React and Vite with React DOM routing were obvious choices, along with Socket.IO for this project's dynamic needs, given that the site would definitely extend into AI based visuals down the line, meaning extending into more pages. Even at scale.

For realtime map views though, I had initially implemented Leaflet JS, a very popular library used for map views on sites. Though easier to incorporate, one major downside in Leaflet (as of this post) is that it uses raster graphics to render map sections. This was not only slow to render, but wasn't aesthetically pleasing either (heavy aliasing). I bit the bullet and switched to MapLibre GL, using MapTiler as the provider. The implementation is a little deeper, but the experience is miles ahead, with Vector graphics being used instead thanks to WebGL under it's hood.

Key Features

Being in the AWS ecosystem for this platform (Based on client's per/vehicle budget and preference), I took advantage of Cognito and SSM to manage authentication and secrets for server environment variables.

This allowed me to use AWS amplify along with Cognito JWT and sessions on react frontend, meaning exponentially more straightforward and scalable auth session and token management.

// OAuth + Email/Password unified flow
1. User signs up via Google/Microsoft/Email
2. Redirected to callback page with Cognito token
3. Check if account exists in database
4. If not → profile completion form
5. Create account record with Cognito user ID
6. Navigate to dashboard with JWT stored in session

useEffect(() => {
  const initSocket = async () => {
    const session = await fetchAuthSession();
    const token = session.tokens?.idToken?.toString();

    const socket = io(API_URL, {
      auth: { token },  // JWT authentication at handshake
      transports: ['websocket']  // Skip polling
    });

    socket.on('connect', () => {
      console.log('Connected to telemetry stream');
    });

    socket.on('telemetry', (data) => {
      // Update vehicle card in real-time
      setLiveTelemetryDataSet(prev => ({
        ...prev,
        [data.linkedVehicleId]: data  // Immutable update
      }));
    });

    socket.on('disconnect', () => {
      console.warn('Telemetry stream disconnected');
    });
  };

  initSocket();
}, []);

// Master catalog includes:
- 30+ Manufacturers: Tata, Mahindra, Ashok Leyland, etc.
- 200+ Models: Tata Ace, BharatBenz 1617R, Eicher Pro 2049, etc.
- Vehicle metadata: Gross Vehicle Weight, Engine Type, Fuel
- Standardized names (no duplicates or typos)

// Bulk import via Excel/CSV
- Upload spreadsheet with: registration_number, chassis_number, make, model
- Parse with SheetJS (supports .xlsx, .xls, .csv)
- Staging table pattern for idempotent inserts
- ON CONFLICT DO NOTHING (prevents duplicate registrations)
- Import 500+ vehicles in under 30 seconds

Dashboard Layout

The primary dashboard layout is segregated into three major blocks. This is the page a user first sees when logging into their account. The site has a persistent left-side vertical navigation bar which is how the user travels around the console.

Caddy Configuration

As indicated before, the client wanted me to setup the server such that they could test another backend on the same (Which they would then eventually remove again respecting security isolation principles), so I set up reverse proxies and security headers accordingly.

// Caddyfile - Multiple domains on one instance
api.fleetflows.app {
    reverse_proxy localhost:3001
    
    @websocket {
        header Connection *Upgrade*
        header Upgrade websocket
    }
    reverse_proxy @websocket localhost:3001
}

Note: I've redacted other security details from here, which have been implemented.

// What Caddy Does (Automatically):
1. Obtains SSL certificates from Let's Encrypt
2. Renews certificates before expiry (every 60 days)
3. Redirects HTTP → HTTPS
4. Handles WebSocket upgrades
5. One config file for multiple domains
6. Zero-downtime certificate rotation

Testing Methodology

Results

Bottleneck Analysis

With large scale fleet vehicles, the bottleneck wasn't AWS IoT Core (which scales to no almost no end) or the microservices (easily horizontally scalable). It was the frontend rendering. Updating 500 vehicle cards 60 times per second caused browser frame drops. So I had to additionally implemented virtualized scrolling (react-window) to only render visible cards, reducing DOM nodes from 500 to ~15.

This is pretty much where map clustering was of huge help. Initially without clustered vehicle nodes rendered on map view on dashboard, the whole site lagged when we had even 200+ vehicles on a typical non-eGPU laptop displaying the site. With clustering enabled, not only was the map hugely less crowded, but I could render 2000+ nodes without the site lagging at all. Because the GET endpoints gave paginated responses, the load time for fleet management page's vehicle/driver/device lists with a massive number of entries, wasn't behind either.

Technical Insights

Architecture Decisions

Version Control & DevOps

It was absolutely essential that I commit to both frontend and backend efficiently and keep a track of my changes, and setting up a repository on both backend server and frontend (vercel auto deploy) allowed me to directly publish changes right from inside Webstorm IDE.

There were times where I had to create a temporary branch and work there, before going back to main, in order to keep things clean. VC helps immensely here. Also, one important aspect of VC was that the client tech team could easily keep track of the development cycle of the platform, without redundant meetings for technical progress.

Open Source Components Used

Development of this platform would be harder without TimescaleDB for time-series extensions, Caddy for making SSL trivial, AWS for generous IoT Core free tier, Vercel for frontend hosting, and the open-source community for countless libraries and tools.