Розробка AI-системи управління трафіком та оптимізація світлофорів

Розробка AI-системи управління трафіком та оптимізація світлофорів

Світлофори з фіксованим циклом — причина 30% затримок у міському трафіку. Щодня мільйони водіїв втрачають години в заторах, а міста зазнають економічних втрат. Ми розробляємо адаптивні системи на основі багатоагентного RL (MARL), які знижують середній час очікування на 15-30%. Наприклад, у Ханчжоу впровадження такої системи скоротило затори на 22%, а в Саудівській Аравії — на 18%. Наш підхід використовує MARL: кожне перехрестя — агент з локальним спостереженням, який оптимізує фази в реальному часі. Отримайте консультацію щодо вашого проєкту — оцінимо за 2 дні.

Чому RL і MARL — найкращий підхід для управління світлофорами?

Фіксовані цикли працюють добре при передбачуваному потоці, але в реальності трафік непередбачуваний. Адаптивні системи (SCOOT, SCATS) вимагають ручного калібрування і погано справляються з аномаліями. RL-агент оптимізує фази безпосередньо під поточний трафік без ручного налаштування і адаптується до ДТП, дощів, заходів. Навчання відбувається в симуляторі, потім переноситься на реальні контролери. За нашими тестами, MARL на 20-30% ефективніший за SCOOT за середнім часом у дорозі.

Задача: N перехресть, у кожного K фаз (напрямків). Агент вибирає поточну фазу і тривалість → мінімізація сумарного часу очікування.

Середовище симуляції та навчання

CityFlow — середовище симуляції

import cityflow # конфігурація міста з JSON (дороги, перехрестя, трафік) eng = cityflow.Engine('config.json', thread_num=4) # стан перехрестя lane_vehicles = eng.get_lane_vehicle_count() # машин у кожній смузі lane_waiting = eng.get_lane_waiting_vehicle_count() current_phase = eng.get_current_phase(intersection_id) # дія: змінити фазу eng.set_tl_phase(intersection_id, new_phase) eng.next_step() 

Для детальної мікросимуляції використовуємо також SUMO — він точніше моделює поведінку окремих автомобілів.

Gym-сумісне середовище

class TrafficEnv(gym.Env): def __init__(self, n_intersections, config_path): self.n = n_intersections self.eng = cityflow.Engine(config_path) # observation per intersection: vehicle counts + waiting + phase obs_dim = 12 + 12 + 8 # 12 під'їзних смуг, 8 фаз self.observation_space = spaces.Box( low=0, high=100, shape=(n_intersections, obs_dim)) # action: вибір фази для кожного перехрестя self.action_space = spaces.MultiDiscrete([8] * n_intersections) def step(self, actions): for i, action in enumerate(actions): self.eng.set_tl_phase(f'intersection_{i}', int(action)) # кілька кроків симуляції на одне рішення агента for _ in range(self.control_interval): # 10–30 сек self.eng.next_step() obs = self._get_obs() reward = -self.eng.get_average_travel_time() # мінімізуємо ATT return obs, reward, False, False, {} 

Побудова MARL-системи

Алгоритми кооперації

Independent DQN (InDQN) — простий baseline: кожне перехрестя навчається незалежно, інші агенти — частина середовища. CoLight використовує attention для врахування сусідніх перехресть:

class CoLightAttention(nn.Module): def forward(self, own_obs, neighbor_obs): # own_obs: [batch, obs_dim] # neighbor_obs: [batch, n_neighbors, obs_dim] query = self.q_proj(own_obs).unsqueeze(1) keys = self.k_proj(neighbor_obs) values = self.v_proj(neighbor_obs) attention = F.softmax( torch.bmm(query, keys.transpose(1,2)) / math.sqrt(self.d_k), dim=-1 ) context = torch.bmm(attention, values).squeeze(1) return self.output_proj(torch.cat([own_obs, context], dim=-1)) 

MPLight поєднує pressure-based feature engineering (queue pressure) з MARL, показуючи найкращі результати на CityFlow benchmarks.

Вибір винагороди

Pressure-based reward дає найкращі результати в багатоагентному середовищі.

Інтеграція з реальними контролерами

Більшість міст використовують SCATS (Австралія) або SCOOT (Великобританія). Наше RL-рішення формує сигнали у форматі цих систем через NTCIP протокол (національний стандарт ITS). Для сумісності реалізовано адаптер SNMP. При відмові RL (мережевий збій) — автоматичний перехід на actuated control з детекторами транспорту. NTCIP 1202 v03 — ключовий стандарт для взаємодії.

Які дані потрібні?

Джерела даних: відеодетектори (черги в реальному часі), індуктивні петлі (точний підрахунок), GPS-флот (travel time feedback), Connected Vehicles (V2X/C-V2X) для проактивної оптимізації. MLOps-пайплайн автоматично оновлює модель за новими даними. Для навчання достатньо 1-3 місяців записів з детекторів. Якщо доступні дані V2X, точність підвищується на 10-15%.

Які KPI відстежуються?

Зв'яжіться для персоналізованої оцінки ваших KPI.

Процес роботи

1. Аналітика: збір даних про трафік, калібрування симулятора. Складаємо digital twin району. Налаштовуємо предиктивну модель.
2. Проектування: вибір топології агентів (Independent / CoLight / MPLight), дизайн винагороди.
3. Реалізація: навчання в CityFlow (1000+ епізодів), тестування на реальних сценаріях.
4. Тест: A/B тестування на виділеному перехресті, верифікація KPI.
5. Деплой: інтеграція з NTCIP-контролерами, fallback-режими, моніторинг через MLOps.

Що входить у розробку

• Модель MARL з підтримкою CoLight/MPLight
• Симулятор CityFlow з конфігом під ваш район
• Reward engineering під ваші KPI
• Адаптер для NTCIP (SCATS/SCOOT)
• Документація, навчання операторів, підтримка 3 місяці

Скільки часу займає впровадження?

Одне перехрестя в симуляції — 4 тижні. Район (20-50 перехресть) з координованими агентами — 12 тижнів. Повне впровадження з міською інфраструктурою — 20-24 тижні.

Готові оцінити ваш проєкт за 2 дні. Зв'яжіться для консультації — наші інженери мають досвід реалізації в містах з населенням 5+ млн осіб і гарантують зниження заторів.