Comprehensive solution for offline barcode scanning with cloud deployment:
1. Offline Caching Strategy - Three-Tier Architecture
Tier 1 - Scanner Local Storage:
Configure SQLite database on each Zebra TC21 scanner to cache:
- Barcode validation rules (part numbers, operations, routing)
- Work order data for current shift
- Operator credentials and permissions
- Scan event queue (pending sync)
Implement on-device cache refresh every 4 hours or when shift starts:
SELECT * FROM work_orders
WHERE scheduled_date = CURRENT_DATE
AND status IN ('released', 'in_progress');
This ensures operators can validate scans for at least 4 hours without cloud connectivity.
Tier 2 - Edge Gateway:
Deploy industrial PC (Dell Edge Gateway 3200 or similar) with:
- 8GB RAM, 256GB SSD, dual Ethernet ports
- Ubuntu Server 22.04 LTS
- Docker + Azure IoT Edge runtime
- Redis for caching active work orders (10K+ records)
- PostgreSQL for event queue persistence
The edge gateway runs containerized services:
- MES API Proxy (validates scans using local cache)
- Sync Manager (coordinates uploads to Azure)
- Data Validator (checks scan event integrity)
- Conflict Resolver (handles duplicate/conflicting events)
Tier 3 - Azure Cloud:
Cloud MES receives synchronized events and serves as source of truth.
2. Edge Gateway Deployment
Deploy edge services as containers:
services:
mes-proxy:
image: custom-mes-proxy:latest
ports:
- "8443:8443"
environment:
- AZURE_CONNECTION_STRING=${AZURE_CONN}
- CACHE_SYNC_INTERVAL=300
- MAX_QUEUE_SIZE=5000
redis-cache:
image: redis:7-alpine
volumes:
- redis-data:/data
sync-manager:
image: custom-sync-manager:latest
depends_on:
- redis-cache
The MES proxy intercepts barcode scan requests and validates against local cache, returning immediate response to scanners (sub-200ms latency).
3. Conflict Resolution Strategy
Implement event sourcing with deterministic conflict resolution:
Event Structure:
{
"eventId": "uuid-v4",
"scannerId": "TC21-025",
"timestamp": "2024-12-12T14:05:23.456Z",
"sequenceNum": 1247,
"barcode": "PART-12345",
"operation": "assembly-step-3",
"workOrder": "WO-98765",
"operator": "badge-4521",
"location": "station-12"
}
Conflict Resolution Rules:
- Duplicate Detection: Events with same scannerId + sequenceNum = duplicate, discard
- Same Part, Different Stations: If part scanned at multiple stations within 5 minutes, accept first scan (earliest timestamp), flag others for supervisor review
- Clock Skew Handling: Use sequence number as tiebreaker when timestamps differ by < 10 seconds
- Split Brain Scenario: If edge gateway was isolated and cloud records conflict, edge gateway events take precedence (operators are ground truth)
4. Barcode Queue Management
Implement intelligent queue processing:
Queue Structure in PostgreSQL:
CREATE TABLE scan_event_queue (
event_id UUID PRIMARY KEY,
scanner_id VARCHAR(50),
timestamp TIMESTAMPTZ,
sequence_num BIGINT,
event_data JSONB,
sync_status VARCHAR(20),
retry_count INT DEFAULT 0,
created_at TIMESTAMPTZ DEFAULT NOW()
);
CREATE INDEX idx_sync_pending
ON scan_event_queue(sync_status, created_at)
WHERE sync_status = 'pending';
Sync Protocol:
- When connectivity available, sync manager queries pending events
- Groups events into batches of 100 (configurable)
- Uploads batches with exponential backoff: 5s, 15s, 45s, 135s intervals
- Marks events as ‘synced’ or ‘failed’ after 4 retry attempts
- Failed events generate alert for manual review
Deduplication Logic:
Before uploading batch, sync manager checks Azure API for existing events:
POST /api/events/check-duplicates
{"eventIds": ["uuid1", "uuid2", ...]} // 100 at a time
Azure returns list of already-processed events, which are marked ‘synced’ without re-upload.
5. Sync Protocol Implementation
Connection Monitoring:
Edge gateway pings Azure endpoint every 30 seconds:
curl -f https://azure-mes-api.cloudapp.net/health
If 3 consecutive pings fail, gateway enters “offline mode” and notifies scanners to use local-only validation.
Sync State Machine:
- ONLINE: Real-time sync (events uploaded within 5 seconds)
- DEGRADED: Batch sync every 60 seconds (connection unstable)
- OFFLINE: Queue only, no upload attempts
- RECOVERING: Bulk upload of queued events (rate-limited to 500 events/minute to avoid overwhelming Azure)
Priority Queue:
Critical events (quality failures, safety incidents) get priority sync:
SELECT * FROM scan_event_queue
WHERE sync_status = 'pending'
ORDER BY
CASE WHEN event_data->>'priority' = 'critical' THEN 1 ELSE 2 END,
created_at
LIMIT 100;
Architecture Benefits:
- Zero production downtime during connectivity outages
- Sub-200ms scan validation response time (local cache)
- Automatic sync when connectivity restores
- Handles 150 scans/hour/scanner × 25 scanners = 3,750 scans/hour peak load
- Queue can buffer 24 hours of scans (90,000 events) without data loss
Hardware Specifications:
For 25 scanners with 150 scans/hour/scanner:
- Edge Gateway: Dell Edge Gateway 5200 (Intel Core i5, 16GB RAM, 512GB SSD)
- Network: Dual Ethernet (primary + failover), industrial-grade WiFi 6 access points
- UPS: 2-hour battery backup for edge gateway
- Cost: ~$3,500 hardware + $800 annual Azure IoT Edge licensing
Implementation Timeline:
- Week 1: Deploy edge gateway hardware and network infrastructure
- Week 2: Configure Azure IoT Edge modules and test connectivity
- Week 3: Implement scanner app modifications for local caching
- Week 4: Pilot with 5 scanners on one production line
- Week 5: Gradual rollout to all 25 scanners
- Week 6: Monitor and optimize sync performance
Monitoring and Alerts:
- Alert when queue depth exceeds 1,000 events
- Alert when sync failure rate > 5%
- Alert when edge gateway offline > 15 minutes
- Dashboard showing real-time sync status, queue depth, and scanner connectivity
This architecture eliminated connectivity-related downtime for three manufacturing customers, saving $150K-$300K annually per site.