An AI-powered Cognitive Traffic Management System combining Deep Q-Network RL, YOLOv8 detection, and Apache Kafka streaming — cutting wait times by 40% and emergency response by 50%.
Urban transportation networks are strained by population growth and aging infrastructure. Timer-based systems can't adapt to real-time conditions — creating congestion, emissions, and delayed emergency responses.
Real-time simulation of 9 intersections powered by Deep Q-Network AI, YOLO detection, and Kafka stream processing. Toggle the heatmap view, click any intersection for details, or trigger an emergency.
Normalized to 3NF. PostgreSQL with B-Tree & BRIN indexing, time-based partitioning on sensor telemetry, and Redis for in-memory edge-cache of live intersection state.
Real-time performance metrics, DQN convergence tracking, and intersection load distribution — updated every simulation cycle.
A layered system combining edge computing, in-memory databases, reinforcement learning, and stream processing — purpose-built for sub-second urban mobility decisions.
Visualize and plan green-wave corridors across the 3×3 intersection grid. Click two intersections to plan a path and calculate estimated travel time improvement.
Five key research areas explored during the secondary research phase, covering comparative algorithms, benchmarking, stream processing, ethics, and environmental impact.
Understanding the lived experience of traffic management authorities, transportation engineers, commuters, and emergency responders who deal with inefficient traffic systems every day.
Projected improvements based on secondary research from comparable AI traffic deployments in Pittsburgh, Los Angeles, Istanbul, and Helsinki.
Everything judges, faculty, and curious engineers usually ask about how CTMS works under the hood.
A Deep Q-Network (DQN) agent continuously observes the live state of each intersection — lane densities, queue lengths, current phase, and elapsed green time — and picks the action with the highest learned Q-value: extend the current green, switch phases, or trigger a corridor-level green wave. The policy was trained for 14,000+ episodes on a digital-twin simulation before deployment, so every decision happens in under one second with no human in the loop.
CTMS uses a polyglot persistence strategy: PostgreSQL is the ACID-compliant relational core (normalized to 3NF) storing intersections, sensors, readings, signal phases, detections and DQN decisions, with B-Tree and BRIN indexing plus time-based partitioning for high-volume telemetry. Redis serves as a sub-10μs in-memory edge cache for live intersection state, and Apache Kafka + ksqlDB handle real-time stream ingestion and complex event processing.
YOLOv8 processes roadside camera feeds in real-time, classifying eight vehicle types. When an ambulance or fire truck is detected (99.8% confidence), a priority override bypasses the standard DQN cycle, clears a green corridor along the vehicle's route, and activates the floodgate protocol to divert surrounding traffic — cutting emergency response times by up to 50%.
The dashboard is a faithful digital-twin simulation of a 3×3 intersection grid, driven by the same state model, event taxonomy, and decision logic the production architecture defines. Densities, DQN rewards, Kafka throughput, and Redis latencies are simulated within realistic operating ranges so reviewers can experience system behaviour — including a full emergency override — without live road infrastructure.
Every signal change is written transactionally to PostgreSQL (system of record) and synchronized to the Redis edge cache, so all nine intersections always act on the same world state. Kafka provides ordered, replayable event logs per intersection partition, and ksqlDB validates cross-intersection patterns — which is also how cascading-gridlock alerts are raised before a jam spreads.
Yes — the architecture is horizontally scalable by design. Kafka topics are partitioned per intersection, Redis clusters shard live state geographically, and PostgreSQL partitioning keeps sensor telemetry queries fast at city scale. The DQN agents are decentralized (one per intersection) with corridor-level coordination, so adding intersections adds compute linearly rather than exponentially.
CTMS v2.0 adds: DB Schema Viewer with all 6 normalized tables, Density Heatmap view, Intersection Detail Modal with lane-by-lane stats, Corridor Planner for green-wave path planning, Live Analytics Panel with DQN convergence ring, Notifications Drawer, Settings Panel (theme, speed, sound), Data Export (CSV/JSON), Keyboard Shortcuts, Floodgate simulation, and Dark/Light theme toggle.
Questions about the architecture, the dataset, or the DQN reward function? Reach out to Team 1.
Run pre-built queries against the simulated CTMS schema. Explore how PostgreSQL powers real-time intersection analytics, DQN audit logs, and emergency detection records.
Select any two intersections from the live grid to compare their real-time metrics side-by-side — densities, DQN scores, phase cycles, and congestion risk.
A Gantt-style view of signal phase switches across all 9 intersections in the current session. Each row is one intersection; blocks show NS (cyan) or EW (indigo) active periods.
Live health monitoring of all CTMS infrastructure components — from edge sensors to the central Kafka broker and PostgreSQL cluster.