Parking Platform Blueprint

Real-time parking control over the dataBridges communication fabric.

dataBridges delivers a WhatsApp-class real-time communication fabric for business applications — engineered for distributed parking systems. Instead of people exchanging messages, HawkEye edge devices, payment systems, dashboards, valet tools, and emergency applications exchange events and invoke capabilities across a secure, authenticated network.

Managed real-time cloud infrastructure

OAuth2-authenticated devices & apps

Events + remote capabilities (RPC)

WhatsApp vs dataBridges

Conceptual Analogy

People on WhatsApp

Messaging · 1:1 · Groups

Instant communication between people
Group conversations
Phone number as identity
Secure, authenticated access

Apps on dataBridges

App fabric · Events · RPC

Real-time events between applications
Shared event channels across devices & apps
Strong OAuth2-based identity & permissions
Auditable, capability-driven actions

Each parking deployment operates like a secure “group channel” where authenticated components exchange events and invoke only the actions they are permitted to perform.

Part 1

Understanding dataBridges

dataBridges is a distributed real-time communication fabric for connected applications. In every deployment, dataBridges stabilizes the architecture: edge devices remain simple, while value-added workflows — payments, dashboards, emergency control and external integrations — evolve rapidly on the real-time backbone without disrupting field hardware.

dataBridges as a Real-time Application Fabric

Managed real-time communication infrastructure for distributed systems

dataBridges equips devices and applications to communicate reliably and instantly through a managed cloud fabric. It brings WhatsApp-like real-time interaction to complex parking ecosystems — but with enterprise-grade identity, permissions, capability routing and topology awareness.


    ┌──────────────────────────────────────────────────────┐
    │                 dataBridges Fabric                   │
    │             (Managed Real-time Backbone)             │
    │                                                      │
    │  WhatsApp provides:                                  │
    │   • Instant messaging between people                 │
    │   • Groups / broadcast lists                         │
    │   • Secure identities                                │
    │                                                      │
    │  dataBridges provides:                               │
    │   • Real-time events across applications             │
    │   • Shared channels across parking components        │
    │   • Strong OAuth2 identities and permissions         │
    │   • Capability calls (RPC) with topology resolution  │
    └──────────────────────────────────────────────────────┘

Secure Communication with OAuth2

Just like WhatsApp verifies your phone number, dataBridges uses OAuth2 tokens to:

Identify each application (who you are)
Authenticate that the application is legitimate (proof of identity)
Authorize what capabilities it can access (permissions)

Example Token (JWT):
{
  "app_name": "HawkEye_Gateway_Pune_Site1",
  "app_type": "edge_device",
  "site_id": "pune-site-01",
  "capabilities": ["barrier_control", "anpr_publish"],
  "channels": ["prs:anpr", "boombarrier"]
}

This ensures:

✅ Only authorized apps can join your parking network
✅ Apps can only access what they're permitted to
✅ All communication is authenticated and auditable

The Parking Network

Every parking site that JAAN deploys becomes a secure, isolated “Parking Network” running on Optomate’s dataBridges platform. Think of it like a private, authenticated real-time space where only approved applications and devices can participate.

Each Parking Network connects edge devices, ANPR cameras, payment apps, dashboards, and emergency controls — all operating in real time, all protected by OAuth2, and all communicating through events and capabilities.

All applications in this Parking Network are authenticated and can only perform authorized actions.

Global dataBridges Deployment

Optomate runs the dataBridges Platform-as-a-Service across multiple geographies. Each parking deployment connects to the nearest regional cluster — for example, Indian sites connect to the India/Mumbai cluster, while US operator sites connect to the US-East cluster.

This gives JAAN and large operators a reliable, low-latency, enterprise-grade real-time platform where each parking site runs as its own secure Parking Network, but all are centrally managed by Optomate.

On top of this foundation, Optomate engineers a dedicated Parking PAL (Platform Abstraction Layer), so JAAN can simply plug in its parking logic and applications — without having to build or operate the underlying messaging, OAuth2, routing, or multi-site infrastructure.

Optomate provides and operates the managed real-time platform; JAAN focuses on parking operations, payments, and customer experience on top of it.

Two Communication Patterns

Applications communicate through two fundamental patterns:

1. Events (Publish/Subscribe)

Broadcasting "what happened" — real-time notifications sent to all interested subscribers.

Example Event:

Channel: prs:anpr
Event: vehicle.exit
Data: {
  "anpr": "MH02AB1234",
  "camera": "exit_gate_01",
  "timestamp": "2025-11-15 16:30:00"
}

Who receives it? Every application subscribed to prs:anpr channel.

2. Capabilities (Remote Function Calls)

Requesting "something to be done" — direct request/response actions.

The payment app never talks directly to the edge COM port. It sends a logical request into the fabric; OAuth2 validates identity, PAL resolves the correct device, and the edge executes barrier.open().

Part 2

Your Edge Device Integration

HawkEye edge already does ANPR and barrier control. The goal is to plug it into dataBridges with minimal changes, so it can act as a real-time node: publishing events and exposing capabilities.

Understanding Your Current System

Your current program structure:

📂 HawkEye Edge Device Code
├── entry_gate/
│   ├── capture_entry.py          # IP camera capture
│   ├── detect_entry.py           # ANPR detection + barrier control
│   └── send_to_server.py         # API communication
│
├── exit_gate/
│   ├── capture_exit.py           # IP camera capture
│   ├── detect_exit.py            # ANPR detection + barrier control
│   └── send_to_server.py         # API communication
│
└── occupancy/
    ├── camera_capture.py         # Bay monitoring
    ├── occupancy_detection.py    # Bay status detection
    └── send_to_server.py         # API updates

Current Boom Barrier Control

Your barrier control is embedded within detection files using serial communication:

# Current implementation (in detect_entry.py / detect_exit.py):

# Whitelist verification
df = pd.read_excel('Fleet.xlsx')
if plate_number in whitelist:
    
    # Serial communication with barrier controller
    bt_serial = serial.Serial('COM6', baudrate=9600, timeout=1)
    bt_serial.write(b'1')  # Open command
    time.sleep(1)
    bt_serial.write(b'2')  # Reset command
    bt_serial.close()

Hardware: Bluetooth serial adapter (COM6) → Boom barrier controller

The Integration Approach

Optomate provides a platform connector that enables your edge device to participate in the dataBridges network.

What Optomate Provides

hawkEyeDataBridgesPlatform.py — A single connector file that:

Extracts barrier control into a clean, reusable function

This same abstraction model extends to all other device capabilities — LED signage, smart TV displays, payment kiosks, and any future hardware surfaces can be exposed as consistent, reusable functions.

Connects to dataBridges network with OAuth2 authentication
Exposes barrier control as a remotely callable capability
Publishes events for ANPR detections and barrier actions

Integration Changes

Minimal modifications to your existing code:

# detect_entry.py (updated with 2-line addition):

from hawkEyeDataBridgesPlatform import platform, open_barrier

# Your existing ANPR and whitelist logic (unchanged)
if plate_detected and whitelisted:
    
    # Call extracted barrier function
    await open_barrier()
    
    # Publish ANPR event to platform
    await platform.publish_anpr_event(plate, "entry_gate")

That's it. Your core detection logic remains unchanged.

Architecture Overview

Edge remains responsible for local I/O (cameras, serial, sensors).
The connector makes it “speak” dataBridges so higher-level apps can
use its capabilities without knowing hardware details.

What This Enables:

✅ Remote barrier control from any authorized application
✅ Real-time ANPR event broadcasting
✅ Third-party application integration
✅ Emergency evacuation capabilities
✅ Complete audit trail of all actions

Part 3

Platform Abstraction Layer (PAL)

PAL is the intelligent routing layer that decouples applications from the physical wiring. Apps talk in terms of floor, lane, or camera; PAL knows which device actually owns that barrier and calls it.

The Intelligent Routing Layer

Think of PAL as DNS for your parking system — translating logical requests into physical device actions.

Without PAL:

// Applications need to know device details
const deviceID = "abc123xyz";  // Which device? Where is it?
await dbridge.call(deviceID, "open_barrier");

❌ Tightly coupled to physical infrastructure.

With PAL:

// Applications use logical references
await boomBarrier.open({ camera_id: "exit_gate_01" })

✅ Decoupled from physical infrastructure.

1. Device Registry

PAL maintains a live registry of all edge devices and their capabilities.

Devices register themselves with PAL. If a device moves, is replaced, or gains new capabilities, the registry is updated—apps keep calling the same logical APIs.

2. Intelligent Routing

PAL translates logical requests to physical device calls:

Example 1: Location-Based Routing

await boomBarrier.open({ location: "exit", floor: 3 })
PAL Routing:
1. Looks up: location="exit", floor=3
2. Finds device: def456uvw
3. Calls: device.open_barrier()
4. Returns result to application

Example 2: Context-Aware Routing

await boomBarrier.open({ camera_id: "camera04" })
PAL Routing:
1. Looks up: camera04 belongs to device abc123xyz
2. Knows: device abc123xyz is at entry, floor-3
3. Calls: device.open_barrier()
4. Returns result

Example 3: Emergency - Multiple Devices

await boomBarrier.evacuateFloor({ floor: 3, building: 2 })
PAL Routing:
1. Finds ALL devices on floor 3, building 2
2. Calls open_barrier() on all devices simultaneously
3. Returns aggregated results

3. Infrastructure Abstraction & Complete System Architecture

PAL sits between applications and the dataBridges fabric to provide a topology-aware, device-independent API surface.

Complete System Architecture

Applications talk to PAL using logical concepts (lane, floor, camera).
PAL uses its registry and rules to decide which edge device to call.
dataBridges is the underlying fabric carrying events and RPCs.
Edge devices execute physical actions and publish back their status.

Part 4

Use Case Flows

Each use case follows the same structure: high-level scenario, sequence diagram showing who talks to whom, and a detailed textual flow capturing the exact steps.

Use Case 1 · Automated Payment & Barrier Control

ANPR → Payment → Barrier Open

Scenario

A vehicle exits the parking facility. The system automatically detects the vehicle, calculates charges, processes payment, publishes a payment success event, sends notifications, and opens the exit barrier — all in a few seconds.

sequenceDiagram autonumber participant CAM as ANPR Camera (Exit) participant EDGE as HawkEye Edge Device participant DBR as dataBridges (prs:anpr) participant PAY as Payment App participant PROC as paymentProcessor Service participant NOTI as Notification Services (SMS/WA/Email) participant PAL as PAL Router participant DEV as Barrier Device CAM->>EDGE: Detect plate MH02AB1234 EDGE->>DBR: Publish vehicle.exit (prs:anpr) DBR-->>PAY: Deliver vehicle.exit event PAY->>PAY: Lookup session & calculate amount (₹125) PAY->>PROC: charge(anpr, amount, method) (RPC via dataBridges) PROC-->>PAY: { success: true, txn_id: "..." } PAY->>DBR: Publish payment.success (anpr, amount, paymentDetails) DBR-->>NOTI: Fan-out payment.success to SMS / WhatsApp / Email PAY->>PAL: boomBarrier.open({ camera_id: "exit_gate_01", anpr }) PAL->>DEV: RPC open_barrier() DEV-->>PAL: { success: true } PAL-->>PAY: Barrier opened

Flow

┌──────────────────────────────────────────────────────┐
│  Step 1: Vehicle Arrives at Exit                     │
│  ANPR Camera detects: MH02AB1234                     │
└──────────────────────────────────────────────────────┘
         ↓
┌──────────────────────────────────────────────────────┐
│  Step 2: Edge Device Publishes Event                 │
│                                                      │
│  Channel: prs:anpr                                   │
│  Event: vehicle.exit                                 │
│  Data: {                                             │
│    "anpr": "MH02AB1234",                             │
│    "camera": "exit_gate_01",                         │
│    "timestamp": "2025-11-15 16:30:00"                │
│  }                                                   │
└──────────────────────────────────────────────────────┘
         ↓
┌──────────────────────────────────────────────────────┐
│  Step 3: Payment App (Subscribed to prs:anpr)        │
│                                                      │
│  • Receives vehicle.exit event                       │
│  • Looks up parking session                          │
│  • Entry: 14:00, Exit: 16:30                         │
│  • Duration: 2.5 hours @ ₹50/hour = ₹125            │
│  • Prepares payment request                          │
└──────────────────────────────────────────────────────┘
         ↓
┌──────────────────────────────────────────────────────┐
│  Step 4: Payment Processing (charge)                 │
│                                                      │
│  await paymentProcessor.charge({                     │
│    anpr: "MH02AB1234",                               │
│    amount: 125,                                      │
│    method: "credit_card"                             │
│  })                                                  │
│                                                      │
│  Returns: { success: true, txn_id: "..." }           │
└──────────────────────────────────────────────────────┘
         ↓
┌──────────────────────────────────────────────────────┐
│  Step 5: Publish Payment Success                     │
│                                                      │
│  Channel: prs:payment                                │
│  Event: payment.success                              │
│  Data: {                                             │
│    "anpr": "MH02AB1234",                             │
│    "amount": 125,                                    │
│    "method": "credit_card",                          │
│    "txn_id": "..."                                   │
│  }                                                   │
└──────────────────────────────────────────────────────┘
         ↓
┌──────────────────────────────────────────────────────┐
│  Step 6: Notification Services React                 │
│                                                      │
│  • SMS service (sendSMS)                             │
│  • WhatsApp service (sendWhatsapp)                   │
│  • Email service (sendEmail)                         │
│                                                      │
│  All subscribed to payment.success consume the event │
│  and notify the customer with receipt details.       │
└──────────────────────────────────────────────────────┘
         ↓
┌──────────────────────────────────────────────────────┐
│  Step 7: Open Barrier via PAL                        │
│                                                      │
│  await boomBarrier.open({                            │
│    camera_id: "exit_gate_01",                        │
│    anpr: "MH02AB1234"                                │
│  })                                                  │
│                                                      │
│  PAL:                                                │
│  • Resolves camera "exit_gate_01" → device xyz789    │
│  • Calls device.open_barrier()                       │
│  • Device executes serial commands (COM6)            │
└──────────────────────────────────────────────────────┘
         ↓
┌──────────────────────────────────────────────────────┐
│  Step 8: Physical Barrier Opens                      │
│                                                      │
│  • Barrier opens                                     │
│  • Vehicle exits                                     │
│  • Customer receives confirmation (SMS/WA/Email)     │
└──────────────────────────────────────────────────────┘

Technical Benefits

Decoupled architecture: ANPR, payment, notifications, and hardware control are independent services, glued together by dataBridges.
Event-driven fan-out: the same ANPR and payment.success events can feed analytics, billing, and future services without changing edge or payment code.
Scalable & reusable: boomBarrier, charge, and notification capabilities can be reused across multiple sites, operators, and applications.

Use Case 2 · Multi-Payment Method Integration

Intelligent Payment Fallback

The Challenge

India has multiple payment ecosystems (FASTag, UPI, Cards, QR codes). Traditional parking systems require manual intervention when the primary payment method fails, causing delays and frustration.

The Platform Solution

The system intelligently attempts FASTag first for a frictionless 3-5 second exit. If FASTag fails (e.g., insufficient balance), it automatically falls back to QR/UPI payment without any manual intervention or operator involvement. The driver simply sees a QR code on the exit screen and pays with their phone.

💡 See It In Action

Click below to see exactly what the driver sees on the exit terminal screen during QR payment fallback

Watch the automatic payment flow and barrier opening sequence

🎯 Key Platform Value

Zero operator intervention. The Payment App automatically detects FASTag failure and switches to QR/UPI payment through platform events. The driver receives clear instructions on the exit screen. The entire fallback logic is orchestrated by dataBridges—no manual process, no phone calls, no delays.

Technical Implementation Details

📋 Phase 1: Entry & Session Creation (Click to expand)


        ┌──────────────────────────────────────────────────────┐
        │  Step 1: Vehicle Enters                              │
        │  • ANPR: MH02AB1234                                  │
        │  • FASTag: 34161FA100012345                          │
        └──────────────────────────────────────────────────────┘
                 ↓
        ┌──────────────────────────────────────────────────────┐
        │  Step 2: Edge Device Publishes                       │
        │                                                      │
        │  Channel: prs:anpr                                   │
        │  Event: vehicle.entry                                │
        │  Data: {                                             │
        │    "anpr": "MH02AB1234",                             │
        │    "fasttag": "34161FA100012345",                    │
        │    "camera": "entry_gate_01",                        │
        │    "timestamp": "14:00:00"                           │
        │  }                                                   │
        └──────────────────────────────────────────────────────┘
                 ↓
        ┌──────────────────────────────────────────────────────┐
        │  Step 3: Parking Session Created                     │
        │                                                      │
        │  parkingSession.create({                             │
        │    session_id: "sess_12345",                         │
        │    anpr: "MH02AB1234",                               │
        │    fasttag: "34161FA100012345",                      │
        │    entry_time: "14:00:00",                           │
        │    status: "parked"                                  │
        │  })                                                  │
        │                                                      │
        │  Entry barrier opens automatically                   │
        └──────────────────────────────────────────────────────┘

✅ Phase 2A: FASTag Success Path (Click to expand)


        ┌──────────────────────────────────────────────────────┐
        │  Step 4: Vehicle Exits (2.5 hours later)             │
        │  ANPR: MH02AB1234                                    │
        └──────────────────────────────────────────────────────┘
                 ↓
        ┌──────────────────────────────────────────────────────┐
        │  Step 5: Calculate & Attempt FASTag                  │
        │                                                      │
        │  • Duration: 2.5 hours @ ₹50/hr = ₹125               │
        │                                                      │
        │  await paymentProcessor.fastTag({                    │
        │    anpr: "MH02AB1234",                               │
        │    amount: 125,                                      │
        │    fasttag: "34161FA100012345"                       │
        │  })                                                  │
        └──────────────────────────────────────────────────────┘
                 ↓
        ┌──────────────────────────────────────────────────────┐
        │  Step 6: FASTag Success                              │
        │                                                      │
        │  Returns: {                                          │
        │    success: true,                                    │
        │    txn_id: "NPCI_789456",                            │
        │    method: "fasttag"                                 │
        │  }                                                   │
        └──────────────────────────────────────────────────────┘
                 ↓
        ┌──────────────────────────────────────────────────────┐
        │  Step 7: Open Barrier & Print Receipt                │
        │                                                      │
        │  Parallel execution:                                 │
        │  • await boomBarrier.open({ camera: "exit_gate" })   │
        │  • await exitOperation.printReceipt(...)             │
        │                                                      │
        │  Vehicle exits within seconds                        │
        └──────────────────────────────────────────────────────┘

🔄 Phase 2B: Automatic QR/UPI Fallback (Click to expand)


        ┌──────────────────────────────────────────────────────┐
        │  Step 5: FASTag Payment Attempt                      │
        │                                                      │
        │  await paymentProcessor.fastTag({...})               │
        │                                                      │
        │  Returns: {                                          │
        │    success: false,                                   │
        │    error: "insufficient_balance"                     │
        │  }                                                   │
        └──────────────────────────────────────────────────────┘
                 ↓
        ┌──────────────────────────────────────────────────────┐
        │  Step 6: Generate QR Code (Automatic)                │
        │                                                      │
        │  • Create UPI payment request                        │
        │  • Generate QR code                                  │
        │  • Subscribe to: prs:qrcode_payment                  │
        │                                                      │
        │  await exitOperation.displayQRCode({                 │
        │    qr_data: "upi://pay?...",                         │
        │    amount: 125,                                      │
        │    message: "FASTag failed. Scan to pay."            │
        │  })                                                  │
        └──────────────────────────────────────────────────────┘
                 ↓
        ┌──────────────────────────────────────────────────────┐
        │  Step 7: Display on Exit Screen                      │
        │  (See interactive demo above ☝️)                     │
        └──────────────────────────────────────────────────────┘
                 ↓
        ┌──────────────────────────────────────────────────────┐
        │  Step 8: Customer Scans & Pays                       │
        │  Opens GPay/PhonePe, scans QR, confirms payment      │
        └──────────────────────────────────────────────────────┘
                 ↓
        ┌──────────────────────────────────────────────────────┐
        │  Step 9: Payment Gateway Publishes Event             │
        │                                                      │
        │  Channel: prs:qrcode_payment                         │
        │  Event: payment.success                              │
        │  Data: {                                             │
        │    qr_id: "qr_12345",                                │
        │    anpr: "MH02AB1234",                               │
        │    amount: 125,                                      │
        │    txn_id: "UPI_987654"                              │
        │  }                                                   │
        └──────────────────────────────────────────────────────┘
                 ↓
        ┌──────────────────────────────────────────────────────┐
        │  Step 10: Parking Session Receives Confirmation      │
        │                                                      │
        │  • Payment confirmed via event                       │
        │  • Opens barrier                                     │
        │  • Prints receipt                                    │
        │  • Vehicle exits                                     │
        └──────────────────────────────────────────────────────┘

Technical Benefits

Automatic fallback logic: Payment App detects FASTag failure and switches to QR without operator intervention.
Decoupled payment rails: FASTag, UPI, cards, and future payment methods integrate independently through the platform.
Real-time visibility: Driver sees payment status on screen; operator monitors via dashboard—both via platform events.
Resilient architecture: Payment gateway failures don't block exits; system gracefully degrades to alternative methods.
No code changes for new methods: Adding Wallet payments or international cards requires no changes to edge device code.

Use Case 3 · Emergency Evacuation

Global Emergency Control · Floor / Building / Site

The Challenge

Large parking operators manage multiple deployments across regions—US East, Central, West—each with its own ramps, basements, VIP exits, ANPR systems and notification workflows.

In most organizations, emergency evacuation is still manual, fragmented and slow. Each site depends on local controls, call trees, and operator judgement. Multi-site coordination becomes difficult, error-prone, and impossible to audit properly.

The Platform Solution

With dataBridges, a multi-site evacuation tool like Global Emergency Control is just a Platform App. It’s a normal web or mobile application — the intelligence lives inside dataBridges Fabric + PAL.

🌐

One app · many networks

The same console connects to 5, 10 or 50 Parking Networks — each with its own OAuth2 token.
🔐

Security-by-design

Each OAuth2 token has narrow scopes (anpr.*, bayOccupancy, emergencyEvac.*, capability:boomBarrier) so the app only sees and controls what it is allowed to.
⚡

Logical → physical conversion

A simple call like boomBarrier.call("open", "us-east.airport-p4.T2.B1") is resolved by PAL into fast, parallel RPCs to all mapped barriers, while notification apps, valet apps and dashboards react to the same emergency events.

Global Emergency Control · Multi-Network Topology

The Emergency Orchestration Console is simply another dataBridges Platform App. For every Parking Network it controls, it receives its own OAuth2 token with scoped access:

🪪

AppName: "Global Emergency Control"
📡

Events: anpr.entry, anpr.exit, bayOccupancy, emergencyEvac.*
🛠

Capabilities: boomBarrier (resolved by PAL per Parking Network)

This unlocks two major advantages for large parking operators:

⚙️

Developers can build powerful apps extremely quickly

They simply use OAuth2 tokens, subscribe to events, and call capabilities. The fabric + PAL handle routing, topology, and parallel execution.
🏢

Operators can integrate directly into existing NOC dashboards

Optomate provides ready JS / Python evacuation scripts using boomBarrier.call("open", path) and emergencyEvac:evacAlert. This allows multi-site evacuation to be embedded directly into the operator’s own systems — secure, scalable, OAuth2-governed.

💡 See It In Action

Below is a live simulation of the Global Emergency Control console. Change region / site / building / floor and trigger an evacuation. The console shows how a single logical call turns into parallel barrier opens, notifications, and live evacuation telemetry.

Global Emergency Control

Multi-site parking operator · US East / Central / West

Platform powered by dataBridges + PAL

Region

Site

Building

Floor

Command

boomBarrier.call("open", "us-east.nyc-hub.B2.3")

One click issues a logical command · PAL resolves and opens all mapped barriers.

Barriers Opened

0 / 0

Parallel RPC calls via PAL

Notifications Sent

SMS / WhatsApp / Email

Vehicles Exiting

Real-time occupancy feed

Remaining On Floor

Live count from sensors

Evacuation Progress Idle

Demo timeline is ~30 seconds. In a real incident this can span minutes, but the platform keeps a complete audit and telemetry stream.

Live Telemetry (sample)

Waiting for command…

Key Platform Value

One logical app. Many physical networks. The operator builds a single Global Emergency Control console that:

Connects to each Parking Network using its own OAuth2 token.
Issues logical commands (boomBarrier.call("open", "region.site.building.floor")) instead of wiring to devices.
Relies on dataBridges + PAL to resolve capabilities, trigger parallel RPCs, and stream live telemetry back to the console.
Can be deployed as web and mobile consoles reusing the same event model and tokens.

Technical Implementation Details

Internally, the evacuation flow is just a combination of events and RPCs across Parking Networks. The logical call from the console becomes an emergencyEvac:evacAlert event inside the target network, which PAL + apps subscribe to.

sequenceDiagram autonumber participant GEC as Global Emergency Control (App) participant PAL as PAL Router (Parking Network) participant DBR as dataBridges participant D1 as Entry Barrier (F3) participant D2 as Exit Barrier (F3) participant D3 as Service Gate (F3) participant D4 as Emergency Gate (F3) GEC->>DBR: Publish emergencyEvac:evacAlert (building="B2", floor="3") DBR->>PAL: Deliver event to PAL + apps in Parking Network PAL->>PAL: Resolve all devices on B2/F3 with boomBarrier capability PAL->>D1: open_barrier() PAL->>D2: open_barrier() PAL->>D3: open_barrier() PAL->>D4: open_barrier() par All barriers D1-->>PAL: status.opened D2-->>PAL: status.opened D3-->>PAL: status.opened D4-->>PAL: status.opened end PAL->>DBR: Publish emergencyEvac:status + ANPR exit + bay updates DBR-->>GEC: Live telemetry for console (Evacuation Dashboard)

Logical Command Model

The console simply constructs a path from the dropdowns and calls the platform:

// Example: floor-level evacuation for US-East airport, Terminal 2, Basement-1
boomBarrier.call("open", "us-east.airport-p4.T2.B1");

PAL inside the Parking Network takes over:

Resolves which building, floor, ramps and lanes are in scope.
Finds all edge devices with boomBarrier.open() capability.
Executes open_barrier() on every mapped device in parallel.
Publishes status, ANPR exit, bayOccupancy and notification events back to the fabric.

End-to-End Flow (Operator View)

┌──────────────────────────────────────────────────────┐
│  Step 1: Operator selects scope on console           │
│  • Region: US East                                   │
│  • Site:   airport-p4                                │
│  • Building: T2                                      │
│  • Floor:   B1                                       │
└──────────────────────────────────────────────────────┘
         ↓
┌──────────────────────────────────────────────────────┐
│  Step 2: Console issues logical command              │
│                                                      │
│  boomBarrier.call(                                   │
│    "open",                                           │
│    "us-east.airport-p4.T2.B1"                        │
│  );                                                  │
│                                                      │
│  Published as: emergencyEvac:evacAlert event         │
│  into the airport-p4 Parking Network                 │
└──────────────────────────────────────────────────────┘
         ↓
┌──────────────────────────────────────────────────────┐
│  Step 3: PAL + apps react inside Parking Network     │
│  • PAL resolves all barriers on T2/B1                │
│  • Calls open_barrier() on every device in parallel  │
│  • Notif apps send SMS / WhatsApp / Email alerts     │
│  • Valet / operations apps receive same evacAlert    │
└──────────────────────────────────────────────────────┘
         ↓
┌──────────────────────────────────────────────────────┐
│  Step 4: Edge + apps publish live status             │
│  • Barrier status: opened / failed / retry           │
│  • ANPR exit events as vehicles leave                │
│  • bayOccupancy events as floors clear               │
│  • notification.delivery events per message          │
└──────────────────────────────────────────────────────┘
         ↓
┌──────────────────────────────────────────────────────┐
│  Step 5: Console updates real-time evacuation view   │
│  • ✅ All barriers opened (4/4 on T2/B1)             │
│  • ✅ Notifications sent (127 vehicles)              │
│  • ⏱️ Vehicles exiting: 23                            │
│  • 📍 Remaining on floor: 104                        │
│                                                      │
│  Operator can extend to next floor / building with   │
│  another logical call using the same console.        │
└──────────────────────────────────────────────────────┘

Technical Benefits

Parallel execution: dozens of barriers open at once, not sequentially.
Context-aware commands: floor, building, or entire site with a single logical call.
Multi-region ready: the same console handles East / Central / West clusters.
Audit & telemetry: every action and status is logged as an event for post-incident review.
App-first story: operators can build their own web / mobile consoles on top of Optomate’s PaaS.

Real-time parking control over the dataBridges communication fabric.

People on WhatsApp

Apps on dataBridges

Understanding dataBridges

dataBridges as a Real-time Application Fabric

Secure Communication with OAuth2

The Parking Network

Global dataBridges Deployment

Two Communication Patterns

1. Events (Publish/Subscribe)

2. Capabilities (Remote Function Calls)

Your Edge Device Integration

Understanding Your Current System

Current Boom Barrier Control

The Integration Approach

What Optomate Provides

Integration Changes

Architecture Overview

Platform Abstraction Layer (PAL)

The Intelligent Routing Layer

1. Device Registry

2. Intelligent Routing

Example 1: Location-Based Routing

Example 2: Context-Aware Routing

Example 3: Emergency - Multiple Devices

3. Infrastructure Abstraction & Complete System Architecture

Use Case Flows

Scenario

Flow

Technical Benefits

The Challenge

The Platform Solution

💡 See It In Action

🚗 Exit Terminal - Live Demo

Exit Terminal

🎯 Key Platform Value

Technical Implementation Details

Technical Benefits

The Challenge

The Platform Solution

Global Emergency Control · Multi-Network Topology

💡 See It In Action

Key Platform Value

Technical Implementation Details

Logical Command Model

End-to-End Flow (Operator View)

Technical Benefits