Case study · Enterprise IoT and fleet telematics

Who is actually behind the wheel?

A GPS ping proves a vehicle was on a road. It does not prove who was driving it, whether they were authorized to, or what happened in the four seconds before a harsh-brake event. This is the platform built to answer all three, in real time, at fleet scale.

Biometric edge verification
Event-driven microservices
Zero-loss video evidence
Live WebRTC on demand
Voice announcements on demand
StatusDelivered
6
layers, each able to fail without taking another down
3
storage tiers before a clip can be lost
5
capabilities on one event backbone
0
silent failures, by design
6 layers

Edge device to cloud identity provider, decoupled end to end. No tier blocks another.

3-tier fallback

Event partition, rolling buffer, local SQLite queue, so an incident never loses its video.

mTLS and Protobuf

Every edge device authenticates on a client certificate before a byte of telemetry moves.

OTA model swaps

New cabin-safety behaviors ship to the fleet without touching a single piece of hardware.

The client

Not a dashcam, and not a tracker.

A commercial fleet technology group serving operators who run mixed HazMat, last-mile delivery and ride-hailing fleets: the segment of the market where "where is the vehicle" has always been solved, and "who is driving it, and how" is the question that actually decides a liability case.

The brief

One production platform

One in-vehicle edge agent, one event backbone, one video pipeline, serving every fleet type the group's customers operate.

The surfaces

Three, on one stack

Driver-monitoring safety alerts, biometric access control, and on-demand live video to dispatch.

The constraint

No stack per use case

Every fleet type the group's customers run, served without a different architecture behind each one.

Where this starts

A GPS ping proves a vehicle was on a road. What the group's customers were absorbing as risk was everything that ping could not show.

The challenge

GPS answers where. It has never answered who, or how.

Three things a location signal could not show, and that the group's customers were absorbing as risk instead.

Could not show 01

No proof of who was driving

A vehicle ID and a GPS trace say a truck moved from A to B. They say nothing about whether the person behind the wheel was the authorized driver, a sub-contracted operator, or someone who should not have had the keys.

Could not show 02

No defensible evidence after the fact

When a harsh-brake or collision event happened, the only record was whatever the driver reported: unverifiable, and useless against a liability claim or an insurance dispute.

Could not show 03

Risk was reactive, not real-time

Fatigue, distraction and lane departure were things a fleet manager learned about after an incident, from a report, not something the vehicle itself could catch and act on in the moment.

What it cost

A location ping proves a truck was on a road. It does not prove who was driving it, whether they were fit to, or what happened in the four seconds before the harsh-brake event. Operators were making six-figure liability decisions on the one signal that answers none of that.

The mandate

Four things that had to be true at once.

Q1 · Identify

Verify who is physically operating each vehicle

At ignition, without bolting on new hardware.

Q2 · Prove

Preserve tamper-proof video the instant an incident-grade event fires

Even under storage or link failure.

Q3 · Contain

Keep vehicles inside approved geography

And let dispatch see the cabin live, on demand.

Q4 · Scale

Do all of it as decoupled, event-driven microservices

Any fleet size can sit behind them.

Non-negotiable

Zero silent failures. A critical event has to produce evidence even when the storage layer is under contention or the network drops entirely. The moment a fleet needs proof most is exactly the moment conditions are worst.

Delivery constraint

Runs on commodity in-vehicle IoT hardware and standard cloud primitives the operator can audit. No proprietary black box between the edge and the evidence.

The solution

One event backbone, five capabilities riding on it.

Identity, evidence, live visibility, access and driver communication are not five products bolted together. They are five consumers of the same telemetry stream, each reacting to the events it cares about.

Who is driving?
Edge-to-cloud face-vector match against the authorized registry at ignition.
What just happened?
An ADAS/DMS alert triggers a three-tier storage fallback that guarantees a clip reaches the cloud.
Can dispatch see it live?
An on-demand WebRTC tunnel via AWS Kinesis Video, opened and torn down per request.
Is the vehicle where it should be?
Real-time geofence evaluation against approved boundaries.
Can dispatch talk to the driver?
A recorded or uploaded audio announcement sent to one or many devices, queued if offline and tracked through to played.
Did we lose anything?
Every write path degrades in tiers. Nothing simply drops.
The five, one at a time
IdentityEdge-to-cloud biometric matching
On ignition, the cabin DMS camera captures a face vector and streams it to the cloud, which runs similarity matching against the authorized-driver registry. An unrecognized face publishes an alert across the message broker and commands the edge device to upload a high-resolution photo for dispatch review.
EvidenceAlert-to-video, with nowhere for data to disappear
A critical ADAS/DMS event first attempts an atomic extraction from the dedicated Event Storage Partition. A flash write-lock or sector timeout falls back to a non-blocking read of the rolling Normal Storage partition. If the network is gone entirely, the task queues in a local transactional SQLite buffer with exponential backoff. Under erratic 4G/5G, nothing is lost.
LiveWebRTC video, dormant until asked for
Cellular video connections stay off until a dispatcher requests one. The platform commands the device to open a secure, temporary cloud tunnel; AWS STS issues short-lived credentials for a Kinesis Video signaling channel; the moment the dispatcher closes the stream, the tunnel tears down.
AccessGeofencing bound to biometric identity
Boundary breaches and unauthorized operators are the same class of event to the platform. Both are evaluated in real time and routed through the identical alerting path dispatch already watches.
VoiceAudio announcements, queued and tracked
Cloud users outside the Fleet Viewer role upload or record short AAC/MP3 clips, up to five per fleet, five megabytes each, with unique names between three and thirty characters, and send them to a single device or many at once. An offline target is not dropped, it is marked Queued and delivered the moment it reconnects, with a duplicate send blocked until that queue clears. Every send is tracked through to sent, played, timed out (fifteen minutes by default), failed or aborted, with the same controls available straight from the vehicle page, next to the live-video button dispatch already uses.
Architecture

Six layers, and every one can fail without taking another down.

A layered, event-driven microservices architecture built to decouple device ingress, asynchronous event processing and synchronous command routing from each other.

Edge to cloud
Edge
Smart telematics unitGPS, IMU, dual camera and DMS, with a local SQLite flash buffer as the offline cache
Ingress
TCP/TLS gatewayCarries mTLS and Protobuf frames, and publishes telemetry onward
Backbone
Kafka event brokerProtobuf payload, consumer fan-out to five services
Services
Five NestJS microservicesgeofence, notification, data-api, video and profile, each independent of the others

The edge unit is the only device on the network. Everything past the gateway is a Kafka consumer, so adding a service never means touching the vehicle.

Where it lands
Enterprise data and storage
Redis cache, gateway sessions
AWS S3, media and clips
MongoDB, structured records
Cloud and identity
Kinesis Video and STS
WebRTC signaling
Cognito / OIDC
The life of an event, end to end
01
Ignition trigger. The DMS camera captures a face vector locally, on the vehicle.
02
Persistent connection. The unit's mTLS session to the gateway carries the vector as a Protobuf frame.
03
Event publish. The gateway forwards it to the Kafka backbone as a telemetry event.
04
Fan-out. Five microservices consume the same event independently; none is coupled to another.
05
Match and branch. profile-service resolves the vector; a mismatch fires an alert and requests a high-res photo from the edge.
06
Persist. Records land in MongoDB, session state in Redis, media in S3, and live signaling brokers through Kinesis and STS.
Why it matters

Governance lives in one place, the gateway and the identity provider, instead of five services each deciding for itself what a trusted device looks like.

Inside the build

Five decisions that carry the whole design.

Decision A

Protobuf over JSON on every wire

Not just a bandwidth choice. A strict, versioned schema means the contract between edge firmware and cloud services cannot silently drift as either side evolves: a serialization decision doubling as an API contract.

Decision B

Kafka as the only writer path

Every microservice is a consumer, never a direct recipient of device traffic. A storm of road-event traffic during rush hour or bad weather backs up the broker, not the geofence check or the dispatcher's UI.

Decision C

A three-tier storage fallback, not a single write path

Event partition, then a non-blocking read of the rolling buffer, then a local SQLite queue with exponential backoff. This is the unglamorous logic that decides whether video evidence exists at all when the flash controller locks or the link drops, precisely when a fleet needs it most.

Decision D

On-demand tunneling, never an always-on stream

Cellular video is the most expensive resource on the vehicle. The platform keeps it dormant until a dispatcher asks for it, then tears the tunnel down the instant they hang up. Bandwidth spent only when someone is actually watching.

Decision E

Announcements queue, they do not fail silently

An offline device does not drop a send request, it gets marked Queued and delivered the moment the device reconnects: the same dormant-until-needed instinct behind the video tunnel, applied to voice. A duplicate send is blocked while one is still queued, and only reopens once that request resolves to sent, played, aborted, failed or timed out, so dispatch never wonders whether an announcement actually went anywhere.

The unglamorous five percent

Storage fallback logic is the unglamorous five percent of an IoT platform that decides whether the other ninety-five percent is trustworthy in court.

Fail safe

Built to fail safe, not just to work.

A platform whose output is liability evidence has to treat failure modes as first-class design targets, not edge cases handled by a retry decorator.

Flash write-lock or sector timeout
Non-blocking fallback readFrom the rolling Normal Storage partition.
Total network loss
Local transactional SQLite bufferTask queues with exponential backoff retry.
Duplicate footage requests
Reference-aware deduplicationOverlapping requests point back to one S3 asset, not a new copy.

On the security side, every device authenticates over a persistent TCP/TLS connection with client-side certificate verification; live video channels are brokered through AWS STS short-lived credentials rather than a standing key. That combination sets a materially higher bar than the password-based auth most IoT fleets still run on.

The distinction the model enforces

A password can be shared across a hundred devices. A client certificate and a short-lived STS token cannot. The security model was built to make that distinction, not just document it.

In the field

One platform, three very different fleets.

HazMat transport

Absolute route adherence and driver alertness verification

Instant geofence alerts on lane deviation; live DMS streaming lets dispatch confirm alertness on long-haul night transits.

Last-mile delivery

High-density urban route monitoring and driver safety coaching

Automated tracking of infractions, phone use and distraction, feeds localized scorecards managers use to curb risky behavior.

Ride-hailing and transit

Driver compliance and rapid insurance turnaround

Biometric validation blocks unverified operators; automated video upload gives rapid proof to settle disputes and protect liability.

Why a new fleet type is not a new integration

All three run on the same event contract. A new fleet type is a new set of geofence rules and alert thresholds, not a new integration. The same is true for a new way to reach the driver: audio announcements ride the identical send-to-device, queue-if-offline, track-to-resolution pattern already built for video.

Outcomes

What the platform replaces.

Driver safety and fatigue
Reported after the factif at all
Caught in the cabinADAS and DMS detect drowsiness, distraction and lane risk in real time
Liability after an incident
The driver's wordunverifiable
A tamper-proof clipautomatically isolated and uploaded on trigger
Unauthorized operation
Assumedfrom the vehicle ID alone
Biometric match at ignitiongeofence-bound, both routed through one alert path
Operational cost
Manual reviewand generic incentives
Per-driver scorecardstelemetry rolls up into them automatically
Dispatch-to-driver communication
A phone callif the driver picks up, unlogged either way
A queued announcementstamped through to played, timeout or abort
The edge

The competitive edge.

What the committee could do

The committee did not need to trust a vendor's claim. They could trace every alert back to the exact frame of video that produced it.

What is next

The same contract, extended.

Seatbelt compliance

New DMS model, shipped OTA to existing camera hardware.

In-cabin smoking detection

Same containerized update path, no new sensor.

Extended HazMat lane models

Route-specific alertness thresholds per corridor.

New device types

Onboarded against the same event contract, not a new stack.

The pattern

The reusable pattern.

Six rules, in order, and the platform is an instance of them rather than an exception to them.

01

Capture at the edge, in a strict schema, from day one.

02

Authenticate the device before a byte of telemetry moves.

03

Decouple every consumer through one event broker. Never a direct write.

04

Fan out to independent services that share a contract, not a database.

05

Degrade storage in tiers. Never in silence.

06

Expose identity and video through short-lived cloud credentials, not standing keys.

Technology stack

Five layers, one contract.

Edge

ST
Smart telematics unit
GP
GPS
IM
IMU
DC
Dual camera
DM
DMS
SE
SQLite (edge)

Transport

TT
TCP/TLS gateway
MT
mTLS
PR
Protobuf

Services

NE
NestJS
KA
Kafka

Data

MO
MongoDB
RE
Redis
AS
AWS S3

Video and identity

KV
Kinesis Video
AS
AWS STS
WE
WebRTC
CO
Cognito
Let's build

The platform your fleet's liability decisions can stand on.

If where the vehicle is happens to be a solved problem for you, and who is driving it, and how, is not yet, that is the gap this platform was built to close.