Chapter 18.2: Bridge Architectures

18.2.1 The Coupling Challenge

Our integrated urban simulation requires communication between heterogeneous components: SUMO (C++), physics engines (Python/NumPy), MFG solvers (Python), signal controllers (potentially Java), and visualisation dashboards (JavaScript). The bridge architecturedetermines how these components exchange data.

The critical constraint is latency within the simulation loop. At each SUMO timestep (0.5–1.0 s simulated time), we must:

Receive vehicle states from SUMO via TraCI
Compute emissions (HBEFA) and canyon concentrations (OSPM)
Run MFG routing update if needed
Send control commands back (reroute, signal changes)

If the total round-trip takes longer than real-time, the simulation slows down. The bridge latency budget is:

$$\tau_{\text{bridge}} < \tau_{\text{step}} - \tau_{\text{SUMO}} - \tau_{\text{TraCI}} - \tau_{\text{physics}}$$

18.2.2 Four Bridge Architectures

1. REST / FastAPI

The simplest architecture: each physics module exposes a REST API. The controller sends HTTP POST requests with JSON payloads. FastAPI (Python) provides automatic OpenAPI documentation and async support.

Latency: ~8 ms per request (HTTP overhead + JSON serialization)
Strengths: easy debugging (curl, Postman), self-documenting
Weakness: HTTP overhead is unnecessary for co-located processes
Best for: prototyping, <100 vehicles

2. ZeroMQ (ZMQ)

ZeroMQ provides brokerless, asynchronous messaging with multiple patterns (REQ/REP, PUB/SUB, PUSH/PULL). Messages are raw bytes—no HTTP overhead, no JSON parsing.

Latency: ~0.8 ms per message
Strengths: 10x faster than REST, multiple messaging patterns, language-agnostic
Weakness: no built-in serialisation (must choose msgpack, protobuf, etc.)
Best for: recommended starting point, 100–1000 vehicles

3. gRPC + Protobuf

gRPC uses HTTP/2 with Protocol Buffers for binary serialisation. It provides type-safe interfaces, bidirectional streaming, and automatic code generation for all major languages.

Latency: ~0.3 ms per message (binary serialisation, HTTP/2 multiplexing)
Strengths: type safety, streaming, production-grade, auto-generated stubs
Weakness: more setup (proto file compilation, generated code)
Best for: production deployment, >1000 vehicles

4. Subprocess stdin/stdout

The simplest possible approach: launch the physics engine as a subprocess and communicate through stdin/stdout pipes with line-delimited JSON.

Latency: ~2 ms (pipe overhead)
Strengths: zero dependencies, trivial to implement
Weakness: single producer-consumer, no multiplexing, buffering issues
Best for: single-module integration, testing

18.2.3 Latency Benchmark Comparison

Architecture	Latency (ms)	Throughput (msg/s)	Serialisation	Type Safety	Scalability
REST/FastAPI	~8.0	~125	JSON	Pydantic	Good
ZeroMQ	~0.8	~1,250	Custom (msgpack)	None	Excellent
gRPC	~0.3	~3,300	Protobuf	Full	Excellent
Subprocess	~2.0	~500	Line JSON	None	Poor

Recommendation:

Start with ZeroMQ for development and testing. Migrate to gRPC when the vehicle count exceeds ~1000 or when you need type safety across Python/Java boundaries. Use REST only for external dashboards and monitoring APIs.

18.2.4 Decision Framework

Choose the bridge architecture based on your deployment scale:

$$N_{\text{vehicles}} < 100 \rightarrow \text{REST} \qquad 100 < N < 1000 \rightarrow \text{ZeroMQ} \qquad N > 1000 \rightarrow \text{gRPC}$$

The total per-step budget for 1000 vehicles at 1-second steps:

$$1000\text{ ms} = \underbrace{20\text{ ms}}_{\text{SUMO}} + \underbrace{5\text{ ms}}_{\text{TraCI}} + \underbrace{0.8\text{ ms}}_{\text{bridge}} + \underbrace{50\text{ ms}}_{\text{physics}} + \underbrace{924.2\text{ ms}}_{\text{headroom}}$$

With ZeroMQ, the bridge adds less than 1 ms of overhead, leaving ample time for physics computations. The bottleneck is typically the physics engine (OSPM + MFG solver), not the communication layer.

18.2.5 Python: ZeroMQ Bridge Implementation

This code implements a complete ZeroMQ bridge with a server (physics engine) and client (SUMO controller), including a latency benchmark.

ZeroMQ Bridge: Architecture & Latency Benchmark

Python

script.py228 lines

import time
import json
import struct
import numpy as np
import matplotlib.pyplot as plt

# ─── Simulated ZeroMQ-style Bridge (without zmq dependency) ───
# We simulate the ZeroMQ REQ/REP pattern using in-memory queues
# to demonstrate the architecture and benchmark serialisation.

class SimulatedZMQSocket:
    """Simulates ZeroMQ REQ/REP for demonstration."""
    def __init__(self):
        self._buffer = []

def send(self, data):
        self._buffer.append(data)

def recv(self):
        if self._buffer:
            return self._buffer.pop(0)
        return None

class PhysicsServer:
    """Physics engine server (would run as separate process with real ZeroMQ)."""

def __init__(self):
        self.canyon_H = 20.0
        self.canyon_W = 20.0
        self.kappa = 0.41
        self.C_D = 0.005
        self.u_H = 5.0

def process_request(self, request_bytes):
        """Process a physics computation request."""
        # Deserialise
        request = json.loads(request_bytes.decode('utf-8'))

if request["type"] == "ospm":
            result = self._compute_ospm(request["data"])
        elif request["type"] == "emission":
            result = self._compute_emission(request["data"])
        elif request["type"] == "batch_ospm":
            result = self._compute_batch_ospm(request["data"])
        else:
            result = {"error": "unknown request type"}

# Serialise response
        return json.dumps(result).encode('utf-8')

def _compute_ospm(self, data):
        q_L = data["emission_density"]
        alpha = self.canyon_H / self.canyon_W
        u_v = self.C_D * self.u_H / ((1 + alpha) * self.kappa)
        u_s = max(u_v * 0.5, 0.3)

C_D_conc = (q_L / (np.sqrt(2*np.pi) * 0.8 * u_s)) * 1e3
        L_R = min(self.canyon_W, self.canyon_H)
        C_R = (q_L * L_R / (u_v * self.canyon_W * self.canyon_H)) * 2.0 * 1e3
        C_total = C_D_conc + C_R + 25.0

return {"concentration": C_total, "C_D": C_D_conc, "C_R": C_R}

def _compute_emission(self, data):
        speed = data["speed"]
        accel = data["accel"]
        m = 1400
        F = 0.01 * m * 9.81 + 0.5 * 1.225 * 0.3 * 2.2 * speed**2 + m * max(accel, 0)
        P_norm = speed * F / 100000
        nox = 0.5 + 8.0 * max(P_norm, 0)
        return {"nox_mg_s": nox, "P_norm": P_norm}

def _compute_batch_ospm(self, data):
        results = []
        for edge in data["edges"]:
            result = self._compute_ospm(edge)
            results.append(result)
        return {"results": results}

class SUMOController:
    """SUMO controller client (would connect via real ZeroMQ)."""

def __init__(self, server):
        self.server = server  # Direct reference for simulation
        self.latencies = []

def request_ospm(self, emission_density):
        request = json.dumps({
            "type": "ospm",
            "data": {"emission_density": emission_density}
        }).encode('utf-8')

t0 = time.perf_counter()
        response = self.server.process_request(request)
        t1 = time.perf_counter()

self.latencies.append((t1 - t0) * 1000)  # ms
        return json.loads(response.decode('utf-8'))

def request_batch_ospm(self, edges):
        request = json.dumps({
            "type": "batch_ospm",
            "data": {"edges": edges}
        }).encode('utf-8')

t0 = time.perf_counter()
        response = self.server.process_request(request)
        t1 = time.perf_counter()

self.latencies.append((t1 - t0) * 1000)
        return json.loads(response.decode('utf-8'))

# ─── Benchmark ───
server = PhysicsServer()
controller = SUMOController(server)

# Single requests
n_requests = 1000
for _ in range(n_requests):
    emission_density = np.random.uniform(0.001, 0.05)
    result = controller.request_ospm(emission_density)

single_latencies = np.array(controller.latencies)
controller.latencies = []

# Batch requests (10 edges per request)
n_batch = 200
for _ in range(n_batch):
    edges = [{"emission_density": np.random.uniform(0.001, 0.05)} for _ in range(10)]
    result = controller.request_batch_ospm(edges)

batch_latencies = np.array(controller.latencies)

# ─── Compare architecture latencies (simulated) ───
architectures = {
    "Subprocess\n(stdin/stdout)": {"base": 2.0, "per_msg": 0.05},
    "REST/FastAPI": {"base": 8.0, "per_msg": 0.02},
    "ZeroMQ": {"base": 0.8, "per_msg": 0.01},
    "gRPC": {"base": 0.3, "per_msg": 0.005},
}

vehicle_counts = [10, 50, 100, 500, 1000, 5000]

fig, axes = plt.subplots(1, 3, figsize=(18, 5))
fig.patch.set_facecolor("#0f172a")

# Plot 1: Latency vs vehicle count
ax1 = axes[0]
colors = ["#94a3b8", "#f59e0b", "#10b981", "#06b6d4"]
for (name, params), color in zip(architectures.items(), colors):
    latencies = [params["base"] + params["per_msg"] * n for n in vehicle_counts]
    ax1.plot(vehicle_counts, latencies, color=color, linewidth=2.5, marker='o', markersize=5, label=name.replace("\n", " "))

ax1.set_xlabel("Vehicle Count", color="white", fontsize=12)
ax1.set_ylabel("Bridge Latency (ms)", color="white", fontsize=12)
ax1.set_title("Bridge Latency vs Scale", color="white", fontsize=13, fontweight="bold")
ax1.set_xscale("log")
ax1.set_yscale("log")
ax1.legend(fontsize=9, facecolor="#1e293b", edgecolor="#334155", labelcolor="white")
ax1.set_facecolor("#0f172a")
ax1.tick_params(colors="gray")
ax1.grid(True, alpha=0.2, color="#334155")
for spine in ax1.spines.values():
    spine.set_color("#334155")

# Plot 2: Single request latency histogram
ax2 = axes[1]
ax2.hist(single_latencies, bins=50, color="#10b981", alpha=0.7, edgecolor="#0f172a")
ax2.axvline(single_latencies.mean(), color="#f59e0b", linestyle="--", linewidth=2,
            label=f"Mean: {single_latencies.mean():.3f} ms")
ax2.axvline(np.percentile(single_latencies, 99), color="#ef4444", linestyle="--", linewidth=2,
            label=f"P99: {np.percentile(single_latencies, 99):.3f} ms")
ax2.set_xlabel("Latency (ms)", color="white", fontsize=12)
ax2.set_ylabel("Count", color="white", fontsize=12)
ax2.set_title("OSPM Request Latency Distribution", color="white", fontsize=13, fontweight="bold")
ax2.legend(fontsize=10, facecolor="#1e293b", edgecolor="#334155", labelcolor="white")
ax2.set_facecolor("#0f172a")
ax2.tick_params(colors="gray")
ax2.grid(True, alpha=0.2, color="#334155")
for spine in ax2.spines.values():
    spine.set_color("#334155")

# Plot 3: Latency budget breakdown
ax3 = axes[2]
components = ["SUMO\nstep", "TraCI\ncomm", "ZMQ\nbridge", "Physics\n(OSPM)", "MFG\nupdate", "Head-\nroom"]
times = [20, 5, 0.8, 50, 100, 824.2]
colors_bar = ["#ef4444", "#f59e0b", "#10b981", "#06b6d4", "#a78bfa", "#334155"]

bars = ax3.bar(range(len(components)), times, color=colors_bar, width=0.6, edgecolor="#1e293b", linewidth=1.5)
ax3.set_xticks(range(len(components)))
ax3.set_xticklabels(components, color="white", fontsize=9)
ax3.set_ylabel("Time (ms)", color="white", fontsize=12)
ax3.set_title("Latency Budget (1000 veh, 1s step)", color="white", fontsize=13, fontweight="bold")
ax3.set_facecolor("#0f172a")
ax3.tick_params(colors="gray")
ax3.grid(True, alpha=0.2, color="#334155", axis="y")
for spine in ax3.spines.values():
    spine.set_color("#334155")

for bar, t in zip(bars, times):
    ax3.text(bar.get_x() + bar.get_width()/2, bar.get_height() + 5,
             f"{t:.1f}ms", ha="center", va="bottom", color="white", fontsize=9)

plt.tight_layout()
plt.savefig("output.png", dpi=120, bbox_inches="tight", facecolor="#0f172a")
plt.close()

# ─── Print results ───
print("=== Bridge Architecture Benchmark ===\n")
print(f"Single OSPM requests ({n_requests} iterations):")
print(f"  Mean latency:   {single_latencies.mean():.4f} ms")
print(f"  Median latency: {np.median(single_latencies):.4f} ms")
print(f"  P99 latency:    {np.percentile(single_latencies, 99):.4f} ms")
print(f"  Throughput:     {1000/single_latencies.mean():.0f} requests/s")
print()
print(f"Batch OSPM requests ({n_batch} iterations, 10 edges each):")
print(f"  Mean latency:   {batch_latencies.mean():.4f} ms")
print(f"  Per-edge:       {batch_latencies.mean()/10:.4f} ms")
print()
print("─── Architecture Comparison (1000 vehicles) ───")
for name, params in architectures.items():
    lat = params["base"] + params["per_msg"] * 1000
    pct = lat / 1000 * 100
    print(f"  {name.replace(chr(10), ' '):>20s}: {lat:6.1f} ms ({pct:.1f}% of 1s budget)")

Click Run to execute the Python code

Code will be executed with Python 3 on the server

18.2.6 Key Takeaways

Four bridge architectures (REST, ZeroMQ, gRPC, subprocess) trade off simplicity against latency by 25x (8 ms vs 0.3 ms).
ZeroMQ at ~0.8 ms per message is the recommended starting point: 10x faster than REST, much simpler than gRPC, and sufficient for up to ~1000 vehicles.
gRPC with protobuf provides the lowest latency (0.3 ms), full type safety, and bidirectional streaming—ideal for production deployments.
The bridge is typically not the bottleneck; physics computation (OSPM, MFG) dominates the latency budget.
Batch requests amortise serialisation overhead: sending 10 edges in one request is 5–8x more efficient than 10 individual requests.

← TraCI Protocol Protobuf Integration →