The problem this solves
Organisations that move goods or deploy equipment across wide areas often run on partial information. Drivers phone in their positions, dispatchers chase updates over messaging apps, and the first sign of a refrigeration failure is a rejected consignment. Assets such as generators, containers or construction equipment are harder still to account for, because nobody is with them most of the time.
This blueprint shows how Twara Technologies would design a connected monitoring platform for that situation. It covers vehicles and unpowered assets alike, and it treats the device, the network, the cloud platform and the people using the data as one system. It is a reference design, not a description of a deployed system. A typical implementation starts with a defined set of questions (“Where is it? Is it healthy? Is it where it should be?”) and builds outward from there.
Architecture
The design separates data collection, real-time decisions and long-term analysis, so each layer can scale and change independently.
[Tracker / sensors] --(MQTT over TLS, cellular)--> [Device gateway]
| |
local buffer [Stream processor]
during outages / | \
[Rules & alerts] [Time-series DB] [Raw archive]
| |
[Notifications] [API layer] --> ERP / TMS / CMMS
|
[Ops dashboard] [Driver app]- Devices sample position and sensor values on a configurable interval, timestamp them locally and publish over cellular. When coverage drops, they store readings and replay them in order once reconnected.
- The gateway authenticates each device, enforces topic-level permissions so a device can publish only its own data, and hands messages to a stream.
- The stream processor enriches each message (asset, route, customer), evaluates rules and writes to storage. Alerts go to dashboards, email, SMS or push notifications according to severity.
- Storage keeps recent high-resolution data for replay and investigation, and summarised data for trend analysis. Raw messages land in low-cost object storage for reprocessing.
- The API layer serves both the web console and the mobile app, and exposes the same data to enterprise systems.
Key design decisions
Messaging protocol. MQTT is the default choice for constrained devices on unreliable links. Its publish/subscribe model and small overhead suit cellular telematics, and it is an OASIS standard. HTTPS polling is simpler to debug but costs more bandwidth and battery. Where devices already speak a vendor protocol, the gateway can translate rather than forcing a firmware change.
Managed or self-hosted ingestion. Managed services such as AWS IoT Core or Azure IoT Hub handle device identity, scaling and certificate rotation, at the cost of some platform lock-in. A self-hosted broker such as EMQX or Eclipse Mosquitto gives full control and portability but places operations on the client’s team. The decision usually rests on fleet size, in-house operations capacity and data-residency preferences.
Storage engine. Purpose-built time-series databases (TimescaleDB, InfluxDB) handle high write rates and time-window queries well. PostgreSQL with PostGIS covers geofencing and spatial queries; TimescaleDB runs on PostgreSQL, so both needs can share one engine. Very large fleets may add a columnar analytics store for reporting.
Edge versus cloud rules. Some rules belong on the device: a temperature excursion in a reefer unit should trigger a local alarm even with no signal. Most business rules belong in the cloud, where they can be changed without a firmware release. The blueprint keeps a small, safety-relevant rule set at the edge and everything else centrally.
Sampling strategy. Higher reporting frequency improves trip replay but raises data and battery costs. The design uses adaptive sampling: frequent while moving, sparse while parked, immediate on events such as harsh braking or a door opening.
Security and compliance
Location and driving behaviour linked to an identifiable driver is personal data. Under India’s Digital Personal Data Protection Act, 2023, section 8(5) requires a Data Fiduciary to take reasonable security safeguards to prevent a personal data breach. Rule 6 of the DPDP Rules, 2025 sets out what those safeguards include at a minimum: measures such as encryption, obfuscation or masking; access control; logging and monitoring of access; backups; and retention of the relevant logs for one year unless another law requires otherwise. Rule 7 requires a detailed breach report to the Data Protection Board within seventy-two hours of becoming aware of a breach. These rules come into force eighteen months after their publication on 13 November 2025, so new platforms should be built to them from the start.
The blueprint responds with:
- unique credentials per device, mutual TLS, and the ability to revoke a single device without affecting the rest of the fleet;
- role-based access, so a customer sees only their consignments and a driver sees only their own trips;
- configurable retention and pseudonymisation of driver identity in analytics datasets;
- tamper-evident audit logs of who viewed or exported location history.
Organisations covered by CERT-In’s Directions of 28 April 2022 must also synchronise system clocks with NTP servers of NIC or NPL (or sources traceable to them), report listed incident types within six hours, and keep ICT system logs for a rolling 180 days within Indian jurisdiction. The platform’s time synchronisation, log pipeline and hosting region are chosen with those requirements in view. Client counsel should confirm which obligations apply in each case.
Phased rollout
- Discovery and device selection. Define the questions the platform must answer, list the assets, test candidate devices on real routes and confirm network coverage.
- Pilot. Instrument a representative subset of the fleet, run the gateway, core rules and dashboard, and validate data quality against manual records.
- Operational rollout. Extend to the full fleet with automated provisioning, introduce the driver app and connect the first enterprise integration.
- Optimisation. Add predictive maintenance signals, route analytics and reporting tuned to how operations teams actually use the system.
- Run and evolve. Ongoing monitoring of device health, firmware updates, rule tuning and capacity planning under a support and maintenance arrangement.
Risks and how the design handles them
| Risk | How the design responds |
|---|---|
| Patchy cellular coverage creates gaps and out-of-order data | Store-and-forward on the device, device-side timestamps and ordering logic in the stream processor |
| Alert fatigue causes real exceptions to be ignored | Severity levels, suppression windows, and rules tuned during the pilot with dispatchers |
| Compromised or cloned devices inject false data | Per-device certificates, topic-level permissions, anomaly checks on impossible movements |
| Device vendor lock-in | A normalisation layer that maps each vendor’s payload to a common internal schema |
| Drivers resist being tracked | Transparent notices, clear purpose limits, and driver-facing features that make the app useful to them |
| Data volumes outgrow the database | Downsampling, tiered storage and partitioning planned from the first release |