The architecture

How Dwaar AI decides every gate event.

Three sensors, one decision engine, an offline-resilient edge node, and a guard with override authority. This is what's actually running every time the boom barrier moves.

trace · gate-01 · evt #84102
FASTag
Tag 9842 · matchedFASTag reader (UHF) · 0.18s · conf 99%
ANPR
KA 05 MH 9842cross-check OK · conf 96%
FACE
Driver: Priya Menonprofile match · conf 97%
Open

The four-second journey of a gate event.

A vehicle approaches. Three sensors fire in parallel. A decision engine reasons. The boom moves — or a guard is alerted.

01

Detect

FASTag (UHF RFID) reader, LPR camera and face camera all fire when motion is detected at 8m. No sequential polling — every modality starts capturing simultaneously.

02

Reason

The edge node correlates the FASTag, plate read and face match against the local whitelist. Confidence scored. Conflicts flagged. All within ~400ms.

03

Act

If confidence clears the threshold, the relay opens the boom barrier locally. Guard sees a green tile. Resident gets a push notification. Log is written.

The fallback chain

If one sensor fails, the others take over.

Every other gate system has a single point of failure. FASTag unreadable? Stop. Camera dirty? Stop. Dwaar AI runs three sensors in parallel and uses confidence-weighted handover — so the gate always has a path forward.

  • FASTag unreadable → ANPR clears the tag-bound vehicle
  • Camera blocked by rain → FASTag alone clears resident vehicles
  • Both fail → AI face check on driver, or guard tap-override
  • Internet down → edge node decides locally from cached whitelist
Get the fallback paper →
1
FASTag primary
99.4% hit rate
2
ANPR fallback
92% in monsoon
3
Face check
resident-only
4
Guard override
human in loop
Edge resilience

No internet? The gate keeps moving.

Each gate runs a Raspberry Pi-class edge node with a synced whitelist of every authorised tag, plate and face vector. When the cloud or internet drops, the gate decides locally and queues events to sync when connectivity returns.

  • Local SQLite whitelist, refreshed every 5 min when online
  • Outbound MQTT queue with at-least-once delivery
  • 4G fallback SIM optional for cloud-critical sites
  • Tamper-evident local logs, signed at edge
See deployment options →
🛰️
Cloud · MQTT brokeraws iot core
● Online
🔌
Edge node · Pi 4local whitelist · 12,408 entries
● Synced
🚧
Boom barrier · relayGPIO · sub-100ms latency
● Ready
The apps

Three apps. One platform.

A resident app (iOS + Android) for visitor passes and notifications. A guard app (Android tablet) for live gate decisions. An admin web portal for the RWA, facilities team or operator. All sharing one event log.

  • Resident: pre-approve visitors, recurring passes, notifications
  • Guard: tablet workstation, photo capture, override controls
  • Admin: multi-gate dashboard, audit reports, role-based access
  • API + webhooks for ERP / accounting / parking integrations
Live event
Gate-01 · 14:32
FASTag matched0.18s
ANPR confirmed0.31s
Face verified0.42s
🚧
Boom openedrelay fired · 0.46s
3
Sensor modalities running in parallel — never sequential
0.4s
Edge decision latency, including relay fire
99.6%
Combined accuracy after fallback chain
Hours of offline operation if cloud goes down

Want a 30-minute walkthrough? We'll show your gate, live.

We come prepared with your site type, hardware compatibility and a real-world fallback simulation.