Strategic Positioning

dataBridges for HawkEye: From Product to Platform

Understanding Your Foundation

Your Current Architecture (v2.0) - Works Well

Current Focus: Parking Gate Automation Company (Product Focus)

Business model:

  • Sell complete parking gate solutions
  • Each deployment is self-contained
  • Direct integration with customer systems
  • Deployment-specific customization

Technology approach:

  • Gateway = complete solution
    • Smart gateways with edge ML and ANPR processing with no cloud dependency
    • Local decision-making and barrier control
    • Deployment-specific logic embedded in each gateway
  • Outbound REST integrations
    • Direct REST API integrations with third-party systems (payment gateways, other software)
  • Site-by-site deployment model
✓ Our Position

If HawkEye's vision is:

  • Be the best parking gate automation company
  • Sell complete, integrated solutions
  • Control the full customer experience
  • Deployment-by-deployment growth

Then: Stay with current architecture. It works beautifully for this model. dataBridges adds complexity with no benefit.

Strategic Evolution

When dataBridges Becomes Useful

HawkEye 2.0 is a high-performance product with proven technology. Its current architecture is well-suited for direct deployments where you deliver complete solutions and manage the customer relationship end-to-end.

dataBridges becomes relevant only if your strategy evolves toward becoming a technology platform—where your ML detection and automation capabilities become building blocks that partners use to create their own solutions.

In a platform model:
  • System integrators build smart-campus and smart-city solutions using HawkEye as foundational infrastructure
  • Service providers operate managed parking services for multiple clients from a central operations center
  • Distributors create vertical-specific offerings (retail, airports, hospitals, logistics) tailored to their markets
  • Partners integrate HawkEye capabilities into broader facility management or smart city systems
Platform architecture makes sense if your vision includes:
  • Expanding ML detection capabilities beyond parking-specific workflows (security, traffic management, facility operations)
  • Integrating and orchestrating a broader range of automation devices (EV chargers, signage, environmental controls)
  • Enabling partners to build applications on your technology foundation with standard APIs
  • Scaling through channel partners and integrators rather than direct, site-by-site deployments
  • Creating recurring revenue through platform licensing, API access, or data services
  • Unlocking network effects as more partners and applications join the ecosystem
⚖️ The Strategic Decision

If this aligns with your growth strategy, platform architecture becomes essential—and dataBridges provides the real-time connectivity infrastructure to build a platform and make it practical and scalable.

If your focus remains on direct customer relationships and self-contained product deployments, your current architecture is already optimized for success.

The decision is strategic, not technical. You understand your market, your customers, and your distribution model better than anyone. dataBridges simply enables the platform path.

💰 The Business Model Reality

Honest answer: dataBridges is infrastructure for a channel-driven business model, not a direct revenue generator.

Your current architecture already works well for direct customer deployments. dataBridges becomes relevant if your growth strategy involves system integrators, distributors, or service providers who need to build solutions on top of your technology. These partners typically want standardized APIs to access your real-time events and automation capabilities so they can integrate HawkEye into larger, multi-vendor solutions for their customers.

You know your market and distribution strategy better than we do. If your vision is channel-driven growth through partners and integrators, platform architecture becomes essential. If you're focused on direct customer relationships, your current approach is already optimal.

Evolution Path

How This Happens: From Capabilities to Platform

When your ML and automation capabilities become platform-accessible, three things evolve naturally:

  1. Your ML team expands detection beyond parking-specific workflows
  2. Your automation team integrates more devices for broader use cases
  3. Your application team builds reference apps that demonstrate platform value to integrators

1. Your ML Team Expands Detection Capabilities

🎯 HawkEye Today
├─ ANPR (license plates) ├─ Vehicle type detection └─ Vehicle color, make, model
🚀 Platform-Ready Capabilities
Core Detection: ├─ ANPR (license plates) ├─ Vehicle type & size ├─ Vehicle color, make, model ├─ Parking space occupancy ├─ Dwell time measurement └─ Entry/exit direction Specialized Detection: ├─ Handicap placard (ADA) ├─ EV vs. ICE classification ├─ Abandoned vehicle detection ├─ Load/cargo status ├─ Trailer detection └─ Vehicle brand recognition
💡 Why this matters for integrators
A security integrator can use your vehicle detection for perimeter monitoring. A logistics company can use cargo detection for warehouse automation. Same ML capability, multiple revenue streams.

2. Your Automation Team Integrates More Devices

🎯 HawkEye Today
├─ Boom barriers (serial) └─ LED displays (bay indicators)
🚀 Platform-Ready Automation
Core Parking Automation: ├─ Barriers (standard, fast-lane, bollards) ├─ Digital Signage (guidance, occupancy, rates) ├─ Traffic Control (lights, lane indicators) └─ Audio Systems (intercom, announcements) EV Infrastructure (Critical): ├─ EV Charger Integration ├─ Session control & monitoring ├─ Overstay detection └─ OCPP Protocol Support Smart Facility Features: ├─ Environmental (CO2, smoke, air quality) └─ Intelligent Lighting
💡 Why this matters for integrators
A mall integrator orchestrates barriers, signage, and EV chargers into a seamless customer experience. A smart city partner uses your automation layer to coordinate parking with traffic systems. One platform, multiple applications.
Reference Applications

3. Your Application Team Builds Core Platform Apps

HawkEye's gateway already handles ML detection and device automation brilliantly. The next step in a platform model is providing reference applications that:

These apps consume gateway capabilities (events + functions) and turn them into complete business workflows.

How System Integrators Use Core Apps

Core Apps are production-ready but designed to be extended. They run anywhere—integrator's office, customer's server, dedicated hardware—because dataBridges handles connectivity without requiring public IPs or firewall changes.

The integrator workflow:

1. Download & Customize
Apps delivered as Python/Node.js source code with clear documentation
2. Secure by Default
HawkEye issues OAuth2 tokens per deployment
3. Deploy Flexibly
Run anywhere—behind firewalls, no VPN needed
4. HawkEye Support
Extend apps, certified add-ons, co-delivery services

The value proposition:
Integrators get a strong foundation—they add domain expertise and customer-specific logic. HawkEye provides building blocks. Integrators assemble vertical solutions. Customers get faster deployments and better customization—without gateway firmware changes.

Core Platform Applications - Reference Library

App 1: ANPR Whitelist Manager
Centralized management of authorized vehicles across single or multiple sites
▼

What it does:

  • Web interface + REST API for whitelist management
  • Add/remove vehicles with metadata (name, expiry date, access zones)
  • Bulk import (CSV, Excel)
  • Sync to one or all gateways instantly
  • Audit trail (who added what, when)

Why integrators need this:

  • Every deployment needs access control
  • Standardizes what would otherwise be custom code
  • Integrators extend it to connect with:
    • HR systems (employee vehicles)
    • CRM platforms (visitor pre-registration)
    • Property management systems (tenant vehicles)
    • Loyalty programs (VIP access)
📝 Example extension
A residential community integrator adds resident portal where homeowners manage their own guest passes—automatically synced to gate.
App 2: ANPR Authentication Service
The decision engine that connects gateway events to customer business logic
▼

What it does:

  • Subscribes to vehicle.entry events from all gateways
  • Checks authorization against:
    • Local whitelist (fast path)
    • External systems (hotel PMS, employee directory, booking system)
    • Custom business rules (time-of-day restrictions, quota limits)
  • Makes allow/deny decision
  • Calls gateway.barrier.open() if authorized, or displays denial message

Why integrators need this:

  • This is where business logic lives (not in the gateway)
  • Keeps gateway firmware standard
  • Logic stays behind customer's firewall
  • Can integrate with ANY customer system
📝 Example extension
A hospital integrator connects to patient scheduling—validates that visiting vehicle matches an appointment time, opens barrier if valid, denies if appointment is tomorrow.
App 3: Parking Session Manager
Turns raw ANPR events into structured parking sessions for billing and analytics
▼

What it does:

  • Subscribes to vehicle.entry and vehicle.exit events
  • Creates and tracks sessions:
    Session for MH12AB1234: ├─ Entry: 10:05 AM, Gateway: Mall-Gate-1 ├─ Exit: 12:42 PM, Gateway: Mall-Gate-3 ├─ Duration: 2h 37m ├─ Status: Completed └─ Fee: ₹60 (calculated by billing rules)
  • Handles edge cases:
    • Lost ticket scenarios
    • Overnight parking (multi-day sessions)
    • No-exit detected (overstay alerts)
  • Exposes clean API for downstream systems

Integration with ticketing systems:

For deployments using entry tickets (QR codes, barcodes):

  • Listens to ticket.issued (at entry) and ticket.scanned (at exit)
  • Links ANPR + ticket ID for cross-validation
  • Supports three flow modes:
    • ANPR-only (ticketless)
    • Ticket-only (manual ANPR fallback)
    • Hybrid (ANPR + ticket for fraud prevention)

Why integrators need this:

  • Every parking deployment needs session tracking
  • Standardizes what would be custom per deployment
  • Provides single source of truth for billing
📝 Example extensions
  • Mall integrator: Adds loyalty rewards—free parking if spent >₹5,000 in stores (integrates with POS)
  • Airport integrator: Adds flight integration—extends parking if flight delayed (integrates with airline API)
  • Corporate integrator: Adds employee subsidies—first 4 hours free for staff (integrates with HR system)

Deployment flexibility:
Runs anywhere—on-prem, integrator's cloud, customer's server—connects via dataBridges without exposed ports.

Practical Implementation

How a Partner Customizes: Real Example

Let's take the ANPR Authentication Service app and see how a partner modifies it for their specific use case.

📋 Scenario
A corporate campus integrator needs to validate vehicles against their client's HR system.

Instead of using a simple whitelist, they want to check employee status, parking permits, and daily entry limits in real-time against the company's HR database.
1
Download HawkEye's Reference App

HawkEye provides the ANPR Authentication Service as a reference implementation that works out of the box with a simple whitelist.

# HawkEye's ANPR Authentication Service (reference implementation) from databridges_sio_client_lib import dBridges class ANPRAuthService: def __init__(self, auth_url, appkey): self.dbridge = dBridges() self.dbridge.auth_url = auth_url self.dbridge.appkey = appkey async def start(self): await self.dbridge.connect() # Subscribe to vehicle entry events channel = self.dbridge.channel.subscribe("ANPR") channel.bind("vehicle_entered", self.handle_entry) async def handle_entry(self, event): plate = event["anpr"] gateway_id = event["gateway_id"] # CHECK AUTHORIZATION authorized = await self.check_authorization(plate) if authorized: # Open barrier await self.dbridge.rpc.call("gateway.barrier.open", gateway_id=gateway_id) else: # Display denial message await self.dbridge.rpc.call("gateway.led.show", gateway_id=gateway_id, message="ACCESS DENIED") async def check_authorization(self, plate): # DEFAULT IMPLEMENTATION: Check local whitelist return plate in self.local_whitelist
✓ This is HawkEye's Reference Code

This reference implementation:

  • ✅ Handles all dataBridges connectivity
  • ✅ Subscribes to vehicle entry events
  • ✅ Controls barriers based on authorization result
  • ✅ Works immediately with a simple whitelist

Integrators receive this as Python source code with full documentation.

2
Integrator Copies and Customizes

The integrator keeps the dataBridges connectivity code unchanged, but modifies the check_authorization() function to integrate with the client's HR system:

# Corporate Campus Integrator's Customization import requests class CorporateCampusAuthService(ANPRAuthService): async def check_authorization(self, plate): # INTEGRATOR'S CUSTOM LOGIC: Check HR system # Call customer's HR API hr_api_url = "https://client-corp.com/api/hr/validate-vehicle" headers = {"Authorization": f"Bearer {self.client_api_token}"} response = requests.post(hr_api_url, json={"license_plate": plate}, headers=headers) if response.status_code == 200: data = response.json() # Check if employee is active if data["employee_status"] == "active": # Check if parking permit is valid if data["parking_permit_valid"]: # Check if not exceeded daily entry limit if data["entries_today"] < data["daily_limit"]: return True return False

📊 What Changed vs. What Stayed the Same

✅ Unchanged (HawkEye's Code)

  • dataBridges connection setup
  • OAuth2 authentication
  • Event subscription logic
  • Barrier control commands
  • LED message display

🔄 Customized (Integrator's Code)

  • Authorization logic
  • HR API integration
  • Employee validation rules
  • Parking permit checks
  • Daily limit enforcement
⚡ The Key Insight
The integrator modified ~20 lines of business logic while keeping ~80 lines of infrastructure code unchanged.

This is exactly what platform architecture enables: rapid customization without reinventing connectivity, authentication, and device control.
3
Deploy

The integrator runs this customized app in one of several flexible deployment options:

🏢 Customer's Server
Behind customer's firewall, ensuring data sovereignty and compliance
🎯 Integrator's NOC
Centralized operations center managing multiple client deployments
☁️ Cloud (Optional)
AWS, Azure, or GCP if preferred, but not required

Deployment Steps:

  1. Install dependencies:
    pip install databridges_sio_client_lib requests
  2. Configure OAuth2 token (issued by HawkEye):
    export HAWKEYE_APPKEY="eyJhbGci0iJIUzI1NiIsInR5cCI6IkpXVCJ9..." export HR_API_TOKEN="client_provided_hr_token"
  3. Run the application:
    python corporate_campus_auth.py
✓ What Happens Automatically
  • No public IP needed - App connects outbound to dataBridges
  • No VPN configuration - Works through standard firewalls
  • No exposed endpoints - All connections are outbound only
  • Automatic reconnection - SDK handles network interruptions
  • Encrypted communication - TLS 1.3 by default

💚 The Value for All Parties

For the Integrator:
  • 80% code provided by HawkEye
  • 20% custom business logic
  • Deployment time: Days not months
  • No infrastructure complexity
For HawkEye:
  • Standardized gateway firmware
  • No customer-specific code
  • Platform licensing revenue
  • Scalable channel model
For the Customer:
  • Exactly what they need
  • Fast deployment timeline
  • No vendor lock-in
  • Proven foundation
Impact Assessment

What Stays vs. What Changes

✅ What Doesn't Change
  • Gateway v2.0 functionality remains 100% intact
    Local ML processing, local decision-making continue. Everything works exactly as before—even if dataBridges is unavailable.
  • Offline operation guaranteed
    Gateway operates autonomously if network fails. Safety and basic functionality never depend on platform connectivity. dataBridges is additive capability, not critical dependency.
  • You still own the technology
    Your ML algorithms, your device automation logic, your customer relationships, your intellectual property.
  • Zero changes to existing deployments
    Current gateways continue operating as products. Platform capability is opt-in per deployment. No forced migration.
🔄 What DOES Change
  • Your technology becomes composable
    ML outcomes can be used separately from parking logic. Device automation can be orchestrated in new ways. System integrators build custom solutions using your primitives.
  • Scaling becomes exponential, not linear
    One system integrator can deploy to 100 customers using your platform. One distributor can create 10 vertical solutions. Network effects: more apps = more valuable platform = more partners.
  • Market expands beyond parking
    Traffic management systems, smart city infrastructure projects, security and access control applications, logistics and fleet management, any vertical needing visual intelligence + automation.

The Platform Value Proposition

For System Integrators

Instead of building from scratch, they get:

  • Real-time ML intelligence - ANPR, vehicle detection, occupancy tracking
  • Device automation library - Barriers, LEDs, signage, EV chargers, audio
  • Standard APIs - Subscribe to events, call gateway functions
  • Event streams - Real-time data from hundreds of gateways
  • Core platform apps - Production-ready foundation to customize
  • No infrastructure complexity - No public IPs, VPNs, or cloud servers required

They can now build:

  • Custom parking solutions for specific verticals
  • Traffic management systems for cities
  • Security access control for campuses
  • Smart facility management platforms
  • Logistics and fleet optimization tools

All using HawkEye as the foundational technology.

For Distributors

They can create vertical-specific offerings:

  • Retail: Mall parking with POS integration, loyalty rewards
  • Healthcare: Hospital parking with patient scheduling, visitor pre-registration
  • Aviation: Airport parking with flight integration, airline partnerships
  • Corporate: Employee parking with HR integration, subsidized rates
  • Municipal: City parking with traffic systems, citizen apps
  • Hospitality: Hotel parking with PMS integration, guest auto-sync

All built on the same HawkEye platform—configured and extended per vertical.

Technical Foundation

Why Applications Need to Be Written

Understanding dataBridges: Infrastructure, Not Application Logic

dataBridges is a secure messaging and connectivity infrastructure for distributed systems—not a business logic engine.

💡 Think of it like electricity
  • The power grid delivers electricity to buildings
  • But you still need to build appliances that use that power
  • The power company doesn't decide whether you build a refrigerator or a television
Similarly with dataBridges
  • dataBridges delivers events and routes function calls between applications
  • These applications can be deep inside private networks—no public IPs, no exposed ports
  • But you still need to write the applications that process events and make business decisions
  • The platform doesn't contain your business logic—it only transports information

What Applications Do vs. What dataBridges Does

Applications (Built by HawkEye, Integrators, Partners)
  • Dashboard visualizing occupancy across 100 gateways
  • Pricing engine adjusting rates based on real-time demand
  • Integration with city traffic control systems
  • Authorization service deciding who can enter
  • Billing system calculating fees and processing payments

These contain business logic—decisions, workflows, integrations.

dataBridges (Infrastructure Layer)
  • Real-time event delivery from all gateways to authorized applications
  • Remote function calls—apps calling gateway functions securely
  • OAuth2 authentication and access control
  • Cross-firewall connectivity without public IPs or VPNs
  • End-to-end encryption and secure routing
  • Automatic reconnection and network resilience

This is pure platform networking infrastructure—the core building block that simplifies distributed systems into simple, connected apps.

💡 The Core Value:
dataBridges makes applications behind different firewalls communicate as if they're running on the same machine—without VPNs, public IPs, or exposed ports. It handles routing, delivery, connectivity, security, and authentication so you can focus on building platform features, not wrestling with network infrastructure.

The dataBridges SDK: Making Distributed Systems Simple

To understand what we mean by "dataBridges SDK" or "dataBridges library," let's start with a simple concept that applies to all software development.

What is a Library/SDK? A Simple Example

When developers write programs to accomplish specific tasks, they don't write everything from scratch. Instead, they use libraries (also called SDKs) — pre-built tools that handle complex technical work so developers can focus on their business logic.

Here's a practical example:

Using a Python Library for Image Analysis

Scenario: You need a Python program that can analyze a photo and detect if people are present in the image.

🤔 The Challenge
Writing code to detect people in photos is extremely complex — it requires understanding computer vision, machine learning algorithms, image processing mathematics, and more. A developer would need months or years to build this from scratch.

The Solution: Instead, developers use a specialized library called OpenCV — a pre-built toolkit that already knows how to detect people in photos.

# Import the computer vision library import cv2 # OpenCV SDK - provides face detection # Load image image = cv2.imread('photo.jpg') # Use library function to detect faces faces = cv2.detectMultiScale(image) # Your business logic - decide what to do with results if len(faces) > 0: print("Person detected!") # Your code here: send alert, log event, etc.

What the library (OpenCV) does:

  • Complex ML algorithms for face detection
  • Image processing and analysis
  • Handles technical details of computer vision

What your code does:

  • Decide which image to analyze
  • Decide what to do when faces are detected
  • Implement your specific business logic

Same Pattern with dataBridges SDK

Scenario: You need an application that monitors parking gateways (behind firewalls in different locations) and makes authorization decisions.

🤔 The Challenge
Writing code to connect applications across different networks and firewalls is extremely complex — it requires understanding network protocols, authentication systems, message routing, firewall traversal, reconnection logic, and more. A developer would need months to build this infrastructure from scratch.

The Solution: Instead, developers use the dataBridges SDK — a pre-built toolkit that already knows how to connect distributed applications securely.

# Import the dataBridges library from databridges_sio_client_lib import dBridges # Connect to dataBridges network dbridge = dBridges() dbridge.auth_url = "https://platform-us-east-cluster-21.databridges.io" dbridge.appkey = "your_oauth2_key" # Defines permissions and access await dbridge.connect() # Subscribe to parking events from gateways channel = dbridge.channel.subscribe("ANPR") channel.bind("vehicle_entered", handle_entry) # Your business logic - decide what to do with events async def handle_entry(event): plate = event["anpr"] gateway = event["gateway_id"] # Your authorization logic if is_authorized(plate): # Call gateway function remotely await dbridge.rpc.call("gateway.barrier.open", gateway_id=gateway)

What the SDK (dataBridges) does:

  • Network connectivity across firewalls
  • OAuth2 authentication and authorization
  • Message delivery (events) between applications
  • Remote function call routing
  • Automatic reconnection if network fails
  • Encryption and security

What your code does:

  • Business logic (is this vehicle authorized?)
  • Integration with external systems (databases, APIs)
  • Decision-making (allow or deny entry)
  • Calling gateway functions when appropriate
✓ The Pattern is the Same

Just as OpenCV handles complex computer vision so you can focus on your image analysis logic...

...dataBridges handles complex distributed networking so you can focus on your platform business logic.

💡
dataBridges makes applications behind different firewalls communicate as if they're running on the same machine—without VPNs, public IPs, or exposed ports.

Your authorization app in Delhi and a gateway in a Mumbai mall can call each other's functions as naturally as function_call() in local code—even though they're separated by firewalls, NAT, and different networks.

What This Means for HawkEye

⚡ The Operational Win

With this architecture, your gateway firmware freezes—all deployment-specific logic moves to applications.

  • New customer workflow? Update your app.
  • Bug fix? Deploy to your server.
  • Partner integration? Build a new app.

Zero gateway updates. Zero site visits. Zero SSH sessions.

This is how you scale from 10 deployments to 100 without exponential engineering effort.

What the SDK Enables

When you use the dataBridges SDK, your application can:

1. Subscribe to Events
SDK handles delivery across networks. You handle business logic.
▼
# Listen to events from all gateways channel = dbridge.channel.subscribe("parking.entry") channel.bind("vehicle_entered", your_handler)

SDK handles delivery across networks. You handle business logic.

2. Call Remote Functions
SDK routes through firewalls. Gateway executes. Result returns to your app.
▼
# Call a function on a gateway behind its firewall await dbridge.rpc.call("gateway.barrier.open", gateway_id="GATE-01")

SDK routes through firewalls. Gateway executes. Result returns to your app.

3. Expose Your Own Functions
SDK handles authentication. Only authorized apps can call your function.
▼
# Make your application's functions callable by others @dbridge.rpc.register("billing.calculate_fee") async def calculate_fee(entry_time, exit_time): duration = exit_time - entry_time return {"fee": calculate(duration), "currency": "INR"}

SDK handles authentication. Only authorized apps can call your function.

Access Control with OAuth2

The appkey in the connection code is an OAuth2 token that defines:

This means:

Why This Architecture Matters

❌ Traditional Approach
❌ Application needs public IP or VPN to reach gateway ❌ Gateway must expose API endpoint (security risk) ❌ Complex firewall configuration per deployment ❌ Polling for events (slow, inefficient)
✅ dataBridges Approach
✅ Application connects outbound to dataBridges (no exposed ports) ✅ Gateway connects outbound to dataBridges (no exposed ports) ✅ Both can now communicate securely ✅ Real-time event delivery (no polling) ✅ Works from behind any firewall

Summary

You write applications that:
  • Implement business logic and make decisions
  • Integrate with customer systems (PMS, ERP, billing)
  • Process events and trigger actions
dataBridges SDK provides:
  • Connectivity across networks and firewalls
  • Event delivery and function call routing
  • Authentication and access control
  • Infrastructure reliability at scale
🚀 The development pattern
  1. Install SDK: pip install databridges_sio_client_lib
  2. Connect with OAuth2 token
  3. Subscribe to events, publish events, call functions
  4. Focus on business logic—SDK handles networking

Same as using any library—but for distributed systems instead of local code.