Background
I have lived in BGC (Bonifacio Global City) for a long time, and one thing about its traffic signals has left a strong impression on me: BGC's road layout is not especially complicated, and its network is fairly regular, yet some of its traffic lights are controlled remarkably poorly. Nearby intersections can even create congestion for each other.
The clearest examples are these:
- At McKinley Parkway and 10th Ave, I often see little evidence of effective traffic-responsive control at the individual intersection. Even when one direction visibly has no vehicles, traffic in the other direction may still wait through what looks like a fixed cycle.
- Near McKinley Parkway, 7th Ave and Rizal Drive, two signalized intersections sit only a few dozen meters apart, yet the first is often green while the second is red.
- Cars clear the first intersection only to stop at the next red light a few dozen meters later. As the queue grows, it can back up into the first intersection.
- Some signal cycles feel close to 120 seconds, making a poorly chosen offset especially painful.
BGC promoted adaptive traffic signals years ago and later built what was described as an AI-powered smart traffic system. But from the experience of using these roads, at least some intersections do not behave as if they have mature corridor-level coordinated control.
My basic judgment
Solving this does not actually require a complex system in which “real-time AI controls the traffic lights.”
For an area like BGC, with limited size, relatively fixed road topology and traffic patterns that repeat strongly from day to day, established traffic engineering methods, together with today's inexpensive cameras, edge computers, 5G connections and servers, should be enough to improve the experience substantially.
The core principle is:
AI should not decide online how the lights change in the next second. Its most valuable work should happen offline: using real traffic data to find better signal-control plans. What finally runs on the road should instead be a simple, stable, deterministic and auditable algorithm backed by a library of preset plans.
Stage one: measure what is really happening
Install cameras at the main intersections.
Depending on the actual field of view, an intersection could use one four-direction camera, four separate cameras or another suitable combination.
The video does not need to be streamed continuously to a central server.
Give each intersection a connected edge computer to identify and count vehicles locally. It only needs to output structured data such as:
- Traffic volume by direction
- Turning proportions
- Queue length
- Lane occupancy
- Average vehicle passage time
- P95 passage time
- Changes in volume by time of day
- Remaining capacity on downstream roads
Collect data continuously for several weeks, covering at least:
- Weekday morning peak
- Midday
- Evening peak
- Nighttime
- Weekends
- Unusual congestion
The result would be a model of actual traffic demand across BGC's road network, instead of a guess about how many seconds of green each direction needs.
Stage two: build a digital twin and let the computer experiment offline
Use the actual road layout, number of lanes, turning movements, pedestrian phases and camera-collected traffic data to build a digital twin of BGC in SUMO, Vissim or a similar microscopic traffic simulator.
Then let an optimization program try many combinations of signal settings.
The main variables are:
- Cycle: the length of a complete signal cycle
- Split: how much green time each movement receives
- Offset: the difference between the start times of green signals at adjacent intersections
- Phase sequence: the order of different traffic phases
AI could be used here, as could more traditional optimization methods, including:
- Genetic algorithms
- Bayesian optimization
- Reinforcement learning
- Other combinatorial optimization methods
Codex/LLMs are better suited to helping build the simulation, write optimization programs, analyze results and generate candidate plans than to acting directly as production traffic controllers.
The objective cannot be average speed or throughput alone.
At a minimum, it should optimize:
- Average delay
- Number of stops
- Average travel time
- P95 travel time
- Maximum queue length
- Corridor throughput
- Pedestrian waiting time
- Queue spillback
Queue spillback should carry a high penalty.
The reason is simple:
If an upstream green light releases many vehicles into a road segment only a few dozen meters long while the downstream light is red, system-wide average throughput might still look acceptable. On the ground, the experience will be terrible, and the queue may even block the previous intersection.
The McKinley Parkway / 7th Ave / Rizal Drive area is a classic example of this kind of situation.
Stage three: once AI has done its job, make the results fixed
After extensive simulation, there is no need for AI to keep controlling the lights online.
Instead, create something like a:
BGC Signal Plan Library
It might contain 10–20 simulation-validated plans, for example:
- Normal
- Low Traffic / Night
- AM Peak
- PM Peak
- McKinley Northbound Heavy
- McKinley Southbound Heavy
- 32nd Street Heavy
- 26th Street Heavy
- Local Incident
- Lane Blockage
- Gridlock Recovery
- Special Event
In practice, perhaps only 5–8 main plans would cover most of the day, with the others handling unusual situations.
Each plan would specify:
cycle + split + offset + phase sequence
So the production system would not have to solve a complicated mathematical problem in real time.
Stage four: the online system only decides which state we are in
The cameras would continue to measure traffic conditions in real time.
Every 1–5 minutes, the central system would ask:
Which preset traffic state best matches the current conditions?
For example:
Normal → McKinley Southbound Heavy
If a state persists for a specified period, say three consecutive minutes or two observation windows above a threshold, the central system switches to the corresponding signal plan at a safe cycle boundary.
This prevents the system from constantly switching back and forth.
What the system really needs to do is:
Traffic State Classification → Signal Plan Selection
Even this step may not need AI.
A transparent rule-based algorithm could do it. For example:
If the McKinley southbound queue exceeds X for Y minutes while downstream capacity is above Z, enter the Southbound Heavy state.
That is more dependable than an opaque real-time AI controller.
Communication does not need millisecond precision
Intersections could communicate with the central system over 5G.
But 5G should not be a safety-critical, real-time control bus.
The central system should not send the instruction:
“Turn the northbound light green now.”
It should send:
“Begin Signal Plan 07 at the next safe transition point.”
That way, network delays of tens or hundreds of milliseconds, or occasionally even a few seconds, do not affect the system's logic.
If the network fails, each intersection continues to run its current plan. If the central connection is lost for a long time, it falls back to a preset time-of-day plan.
A very important safety design
The central server should never directly control the electrical state of red, yellow and green lamps.
The actual enforcement of:
- Minimum green
- Yellow interval
- All-red clearance
- Pedestrian clearance
- Conflicting phase protection
- Fail-safe behavior
should remain with a certified local traffic signal controller.
The central system can only select a validated signal plan.
That means even if:
- The 5G connection drops
- The central server crashes
- The program has a bug
- The optimization system produces a bad result
it cannot create a safety incident by turning two conflicting directions green at the same time.
The worst case is an automatic return to traditional fixed timings.
Why the “green wave” matters so much
For adjacent intersections, especially those only a few dozen meters apart, the key is not just the length of each green light. It is the offset.
Suppose two intersections are 50 meters apart and vehicles travel at about 25 km/h.
It takes roughly:
50 m ÷ 6.9 m/s ≈ 7 seconds.
The downstream green should therefore account for approximately seven seconds of travel time.
That is the most basic form of signal progression, or a green wave.
If, instead, the sequence is:
First intersection green → second intersection red
and then:
First intersection red → second intersection green
the two signals take turns turning the few dozen meters between them into a parking lot.
This is not a problem that requires advanced AI. It is a basic signal-coordination problem.
Add spillback protection, too
If a downstream camera detects:
Downstream road occupancy > 85%
then the upstream intersection could temporarily reduce the number of vehicles it releases into that segment, even if its normal timing would call for green, and give the time to other directions instead.
Once the downstream road has room again, it can release the upstream platoon.
So the system should have both:
Green Wave
and:
Queue Spillback Protection
The first reduces stops; the second prevents local congestion from spreading into gridlock.
The best way to implement this in BGC is not to rebuild every intersection at once
There is no need to overhaul all of BGC in the first stage.
Start with a:
McKinley Parkway Corridor Pilot
Pick roughly 5–8 consecutive intersections.
The steps:
- Collect real traffic data with cameras.
- Measure all current signal timings.
- Build a corridor digital twin.
- Reproduce current congestion in the simulation.
- Automatically optimize cycle / split / offset.
- Generate 5–10 signal plans.
- Validate them in simulation.
- Roll them out gradually on real roads.
- Run them continuously for one month.
- Compare the results with the pre-pilot baseline using an A/B comparison.
Core KPIs:
- Average travel time
- P95 travel time
- Average delay
- Stops per vehicle
- Maximum queue length
- Spillback events
- Corridor throughput
If the McKinley Parkway pilot shows a clear improvement, expand gradually across BGC.
The central idea
What makes this project interesting is precisely that:
We do not need to worship AI.
AI is well suited to a job humans are reluctant to do:
Take weeks or months of real traffic data, run thousands upon thousands of signal combinations through a digital twin and find a set of very good plans.
But once those plans have been found, AI's job is effectively done.
The system managing BGC's daily traffic could be an ordinary, stable, transparent, deterministic program:
Sense → Classify → Select Plan → Execute → Measure
Every few months, feed the newly accumulated data back into the digital twin, rerun the optimization and update the Signal Plan Library.
In other words:
AI learns and designs; conventional software executes.
For an area like BGC, with a limited road network, recognizable traffic patterns and an existing signal-coordination experience that feels less than ideal, this may be easier to implement, safer and easier to prove effective than an expensive, complex, fully real-time “AI Traffic Control System.”