Лучшие ответы

AveVide (АвеВиде) — это отечественный аналитический программный комплекс, предназначенный для высокоточного мониторинга транспортных потоков и оценки эффективности светофорного регулирования на основе телематических данных [1, 2]. Модуль является частью экосистемы «Ave» и позиционируется как «инженерное ядро» для систем ИТС, позволяющее перейти от субъективных оценок к доказательной аналитике [3, 4].

Основные характеристики и модель развертывания

Система является полностью российской разработкой и может быть развернута как StandAlone-решение на внутренних серверах заказчика (например, ГКУ ДОДД), так и по облачной модели SaaS. Это обеспечивает независимость от зарубежных вендоров и высокий уровень безопасности данных внутри защищенного периметра городской инфраструктуры.

Три источника данных для анализа

Для формирования полной картины трафика (даже в зонах без детекторов) AveVide использует интеграцию трех независимых потоков данных [5, 6]:

1. Треки подсистемы приоритета: данные в реальном времени от бортовых устройств V2X и телематических модулей (OBU) «ЭСКОРТ», установленных на городском транспорте [6, 7].
2. Данные такси и каршеринга: потоки от агрегаторов (Яндекс, 2ГИС), передаваемые городу на основании действующих соглашений и постановлений [5, 6].
3. Телематика общественного транспорта: данные, поступающие через API портала ОРГП напрямую от перевозчиков [5, 6].

Ключевые возможности системы

• Виртуальные детекторы: возможность «установки» измерителя скорости и интенсивности в любой точке дорожной сети без монтажа физического оборудования [8, 9].
• Аудит светофорного регулирования: автоматическое определение фактических параметров циклов (длительность фаз, моменты переключения программ) непосредственно из анализа траекторий ТС [10-12]. Это позволяет выявлять ошибки в настройках адаптивного управления и неактуальность жестких планов [10, 13].
• Контроль приоритета: измерение реального эффекта от предоставления приоритета для каждого конкретного борта ОТ (экономия времени, снижение задержки) и оценка качества настройки приоритетных маршрутов [14-16].
• Статистическая достоверность: система предоставляет объективные данные (средние значения, медианы, дисперсии) в разрезе суточной и недельной динамики, что критично для объектов с нестационарными потоками [17-19].

Инфраструктурные требования и бюджет

Развертывание AveVide в масштабе мегаполиса — это высоконагруженная (High-Load) задача, требующая соблюдения ряда условий:

• Зависимые компоненты: система не работает в отрыве от высокоточного Цифрового двойника (lane-level), формируемого инструментами OSMPIE (редактор геометрии полос) и AveGeo (топологический граф) [2, 6, 20, 21].
• Серверные мощности: необходимо выделение минимум 5 производительных серверов с большим объемом оперативной памяти для потокового «мэтчинга» треков в реальном времени [6, 22, 23].
• Бюджет и сроки: ориентировочная стоимость реализации составляет 120–170 млн рублей, а внедрение проводится поэтапно в течение 1–3 лет [6].

Внедрение AveVide позволяет ГКУ ДОДД не просто наблюдать за оборудованием, а измерять результат управленческих воздействий и обосновывать изменения в организации дорожного движения на основе точных инженерных метрик [3, 24].

Диаграммы «время-путь» (time-space diagrams) нового поколения представляют собой усовершенствованный инструмент визуализации и анализа, предназначенный для глубокой диагностики работы систем светофорного регулирования и эффективности приоритетного проезда общественного транспорта (ОТ) [1, 2].

В отличие от традиционных графиков, новые компоненты интерфейса АСУДД должны обладать следующими характеристиками:

1. Детализация внутренних состояний фаз

Новое поколение диаграмм, ориентируясь на передовые зарубежные системы (например, LISA+), отображает не просто сигналы «красный/зеленый», а более подробную информацию о работе контроллера [1, 3]:

• Границы длительностей: Визуализация границ минимального и максимального зеленого сигнала [1, 2].
• Стратегии приоритета: Отображение конкретных алгоритмов, сработавших в данном цикле (например, продление зеленого или удержание фазы для приближающегося трамвая) [2].
• Промежуточные такты: Учет и визуализация матриц межзеленых интервалов и переходных состояний [4, 5].

2. Многомаршрутность и сетевой подход

Существующие инструменты часто ограничены анализом одного конкретного маршрута [3]. Новое поколение предполагает:

• Отображение всех ТС на участке: Возможность видеть на одном графике движение всех транспортных средств (или различных маршрутов ОТ), проходящих через данный сегмент дороги одновременно [1, 3].
• Переход к аналитике по зонам: Отказ от жесткой привязки к «маршруту приоритета» в пользу анализа дорожных сегментов («палок») и привязанных к ним зон обнаружения [1, 3, 6].
• Выявление конфликтности: Инструменты для идентификации перекрестков, где одновременно скапливается несколько единиц ОТ (например, более двух автобусов), требующих приоритета [2, 7].

3. Интеграция с реальными данными (Треки поверх графиков)

Ключевым отличием является наложение реальных траекторий (треков) движения транспортных средств непосредственно на график сигналов светофора [2]. Это позволяет:

• Визуально подтвердить факт проезда или остановки ТС в конкретном цикле [2].
• Оценить эффект от «условного приоритета» (сколько времени было сэкономлено и как это повлияло на отставание от графика) [2, 8].
• Анализировать «пачкообразный» характер потока и распад пачек при движении между светофорами [9].

4. Инструментарий и техническая реализация

• Интерактивность: Возможность редактирования планов координации («зеленых волн») прямо на диаграмме путем перетаскивания графиков сигналов мышью (реализовано в компоненте Avenue) [10].
• Высокое разрешение: Для построения таких диаграмм требуется получение от дорожных контроллеров детализированных логов (событий высокого разрешения с дискретностью 0,1 сек) [1, 11].
• Режим отладки (Debug): Возможность удаленного включения расширенного логирования на выбранных контроллерах для детального разбора проблемных ситуаций на определенных участках [1, 11].

Внедрение таких диаграмм в ЕПУТС СПб позволит перейти от оценочных моделей к непрерывному измерению реальных показателей эффективности (ATSPM) и оперативному улучшению режимов координации [2, 12].

Ниже представлен список источников с краткими аннотациями в формате Markdown:

Список источников по автоматизированным показателям эффективности светофорного регулирования (ATSPM)

1. Руководство NCDOT по автоматизированным показателям эффективности светофоров (NCDOT Guide on ATSPM)

   • Аннотация: Практическое руководство Министерства транспорта Северной Каролины, описывающее причины внедрения ATSPM, необходимое оборудование и варианты программного обеспечения [1-3]. Документ включает рекомендации по приоритизации перекрестков и результаты пилотных проектов штата [4, 5].

2. Процедуры обработки данных для показателей эффективности систем светофорного регулирования (Purdue e-Pubs: Data Reduction Procedures)

   • Аннотация: Рабочий документ Университета Пердью, в котором описывается техническая база для связи базы данных штата Индиана (INDOT) с веб-интерфейсом [6, 7]. Содержит детальное описание структуры таблиц базы данных и SQL-запросы для расчета таких показателей, как длина цикла, объемы трафика и задержки [8-11].

3. Детали компонентов ATSPM Министерства транспорта Джорджии (GDOT Component Details)

   • Аннотация: Техническая документация, описывающая архитектуру и пользовательский интерфейс системы ATSPM в Джорджии [12, 13]. Включает инструкции по конфигурации сигналов и детекторов, управлению ролями пользователей и навигации по карте и спискам объектов [14-16].

4. Детали отчетности ATSPM Министерства транспорта Джорджии (GDOT Reporting Details)

   • Аннотация: Подробное руководство по интерпретации отчетов и графиков, генерируемых системой ATSPM [17, 18]. Описывает алгоритмы сбора данных и требования к детекторам для каждой метрики, включая задержки на подходах, координационные диаграммы Пердью и прибытие на красный свет [19-21].

5. Показатели эффективности для систем светофорного регулирования: подход, ориентированный на результат (Purdue: Outcome-Oriented Approach)

   • Аннотация: Научный отчет Университета Пердью, представляющий методологию использования данных высокого разрешения для оценки систем светофорного регулирования [22]. Фокусируется на таких аспектах, как пропускная способность, качество прогрессии и мультимодальные операции [23, 24].

6. Масштабируемая панель для идентификации сбоев распределения фаз и эвристика для перераспределения времени (Purdue e-Pubs: Scalable Dashboard)

   • Аннотация: Исследовательская работа, посвященная разработке инструментов для автоматического выявления «сбоев расщепления» (split failures) на основе данных высокого разрешения [25]. Предлагает алгоритмы для оптимизации временных интервалов светофорных фаз [26, 27].

7. Показатели эффективности светофорного регулирования: Итоговый отчет (Florida DOT Traffic Signal Performance Measures)

   • Аннотация: Обзорный отчет для Министерства транспорта Флориды, обобщающий опыт различных штатов США по внедрению ATSPM [28, 29]. Рассматривает преимущества (снижение затрат, улучшение обслуживания) и основные проблемы (хранение данных, техническая поддержка), с которыми сталкиваются агентства [30, 31].

8. План управления светофорными объектами штата Орегон (ODOT Traffic Signal Management Plan)

   • Аннотация: Стратегический документ Министерства транспорта Орегона, определяющий цели и задачи по проектированию, эксплуатации и техническому обслуживанию светофорных систем [32, 33]. Описывает тактики мониторинга в реальном времени и интеграции новых технологий для повышения безопасности и эффективности движения [34, 35].

9. Методика оценки эффективности светофорного регулирования на основании навигационных данных (ЭБ СПбПУ)

   • Аннотация: Научная статья (2025 г.), предлагающая методику анализа работы светофоров с использованием данных GPS и ГЛОНАСС [36, 37]. Подход позволяет рассчитывать среднюю задержку и скорость транспортных средств для динамической оптимизации режимов регулирования в составе интеллектуальных транспортных систем [37, 38].

Координационная диаграмма Пердью (PCD) — это мощный визуальный инструмент, который отображает время прибытия транспортных средств относительно состояния светофора (зеленый, желтый, красный) для каждого цикла [1, 2]. На графике каждое срабатывание детектора представлено в виде отдельной точки; точки выше зеленой линии соответствуют прибытию на зеленый свет, а ниже — на красный [1, 3].

Основные характеристики и польза диаграмм:

• Визуализация прибытия и взводности: Диаграмма позволяет наглядно увидеть, как транспортные средства группируются в «взводы» (платуны) и в какой момент цикла они достигают перекрестка [1, 4]. Это дает возможность оценить, насколько эффективно работает «зеленая волна» [5].
• Оценка качества прогрессии: С помощью PCD рассчитываются ключевые показатели эффективности, такие как процент прибытия на зеленый (AoG) и коэффициент взводности (platoon ratio) [1, 6, 7]. Коэффициент взводности нормализует данные о прибытии на зеленый, учитывая долю времени, в течение которого горел зеленый сигнал в цикле [1, 8].
• Оптимизация сдвига фаз (offsets): Диаграммы Пердью крайне полезны для корректировки сдвига фаз на перекрестках [5]. Сравнение графиков до и после изменений позволяет инженерам подтвердить, что корректировка привела к увеличению числа автомобилей, прибывающих на зеленый свет [9, 10].
• Проверка параметров сигнализации: Инструмент помогает проверить правильность настройки таких параметров, как длина цикла, и убедиться, что они соответствуют реальному спросу на дороге в разное время суток [5, 11].
• Дистанционный мониторинг и экономия ресурсов: PCD позволяет выявлять проблемы в работе светофорных объектов удаленно, без необходимости проведения дорогостоящих полевых обследований и ручного сбора данных [12-14].

Для построения точной диаграммы требуется наличие детекторов продвинутого типа (advance detection), установленных на расстоянии примерно 350–400 футов (100–120 метров) от стоп-линии, чтобы фиксировать автомобили до того, как они попадут в очередь перед светофором [15-17].

Координационная диаграмма считается одной из наиболее информативных метрик в системах ATSPM, так как она объединяет данные о состоянии контроллера и обнаружении транспортных средств в единую пространственно-временную картину [12, 18].

В «Подсистему 1. Подсистема аналитики и контроля эффективности ИТС» необходимо добавить следующий блок функциональных требований, касающийся внедрения инструментов ATSPM (автоматизированных показателей эффективности светофорного регулирования):

1.5. Модуль визуализации и анализа показателей ATSPM

Главной целью модуля является переход от прогнозного моделирования к непрерывному измерению реальных показателей работы светофорных объектов на основе данных высокого разрешения [1, 2].

1.5.1. Инструменты визуализации и типы диаграмм

Необходимо реализовать поддержку следующих ключевых инструментов анализа:

• Координационные диаграммы Пердью (Purdue Coordination Diagram, PCD): Визуализация моментов прибытия транспортных средств в привязке к фазам светофорного цикла (красный, желтый, зеленый) [3, 4]. Позволяет оценивать качество «зеленой волны», рассчитывать процент прибытия на зеленый (AoG) и коэффициент взводности (platoon ratio) [3, 5].
• Отчеты о завершении фаз (Purdue Phase Termination): Графическое отображение причин прекращения фаз (разрыв интервала — Gap Out, достижение максимума — Max Out, принудительное завершение — Force Off) для выявления неэффективного использования зеленого времени [6, 7].
• Мониторинг распределения времени (Split Monitor): Анализ фактической длительности фаз в сравнении с запрограммированными значениями для оптимизации планов координации [8, 9].
• Анализ сбоев распределения фаз (Purdue Split Failure): Использование коэффициентов занятости на зеленом (GOR) и в первые секунды красного сигнала (ROR) для автоматического определения циклов, в которых очередь не была полностью обслужена [10-12].
• Диаграммы «время-путь» нового поколения: Насыщение диаграмм данными о внутренних состояниях фаз (например, длительность минимального зеленого) и отображение всех ТС на участке (многомаршрутность) [13-15].
• Дополнительные метрики: Задержки на подходе (Approach Delay), объемы трафика (Approach Volume), скорость прибытия (Approach Speed) и нарушения проезда на красный свет [16-19].

1.5.2. Получение данных от дорожных контроллеров (ДК)

Для работы модуля система должна обеспечивать:

• Сбор данных высокого разрешения: Получение логов событий с дискретностью 0,1 секунды [20, 21].
• Поддержка стандартных перечислений (Enumerations): Использование единого протокола кодирования событий (Indiana/Purdue standard), поддерживаемого большинством современных контроллеров (Econolite, Peek, Siemens, Intelight и др.) [21, 22].
• Требования к детекции: Для построения PCD необходимы детекторы продвинутого типа (advance detection) на расстоянии 100-120 метров от стоп-линии; для анализа сбоев фаз — детекторы занятости на стоп-линии [23-26].
• Каналы передачи: Автоматизированная выгрузка данных по оптическим каналам или LTE; для объектов без связи — поддержка периодической ручной загрузки данных с локальных накопителей или специализированных устройств (например, Raspberry Pi) [27-29].

1.5.3. Хранение и выдача через API

• Централизованное хранилище: База данных должна обеспечивать нормализацию и хранение необработанных логов событий в стандартном формате [30, 31].
• Выдача через API: Система должна предоставлять внешним потребителям (например, «Яндексу») как сырые данные о конфигурациях (сигнальные группы, «стрелки»), так и рассчитанные показатели эффективности через унифицированные эндпоинты [14, 32-34].
• Вероятностное прогнозирование: Реализация через API выдачи прогнозов времени переключения фаз с указанием доверительных интервалов (минимальное/максимальное время ожидания) [14, 35].

1.5.4. Инструменты UI АСУДД

• Dashboard (Панель мониторинга): Единый интерфейс для идентификации «горячих точек» — перекрестков с наибольшими задержками или частыми сбоями фаз [36, 37].
• Режим оперативного наблюдения в МПТП: Визуализация потоков с детекторов «здесь и сейчас» (за последний час/сутки) с наложением на карту города [38, 39].
• Модуль «Здоровье приоритета»: Специализированный интерфейс для контроля качества входных данных и статусов контроллеров в контексте приоритетного проезда ОТ [39, 40].
• Интегрированное моделирование: Возможность проведения экспериментов и расчета координации в «виртуальной среде», являющейся репликой боевой системы [41-43].

Важное решение: Внедрение системы аналитики ATSPM должно сопровождаться закупкой производительного серверного оборудования (минимум 5 серверов), так как потоковая обработка таких данных является высоконагруженной (high-load) задачей [14, 43, 44].

Идея создания изолированной реплики системы (виртуального контура) заключается в развертывании полнофункциональной программной среды, которая полностью дублирует состояние и логику «боевой» системы управления дорожным движением, но физически отделена от неё [1-3].

Ниже приведено подробное описание того, зачем это нужно и какие преимущества дает этот подход:

1. Безопасное нагрузочное тестирование

В текущей ситуации проведение нагрузочных испытаний (например, совместно с «Яндексом») непосредственно на «боевых» серверах сопряжено с огромными рисками [1].

• Зачем это нужно: Виртуальный контур позволяет имитировать тысячи одновременных запросов к API, проверяя «предел прочности» системы [1, 3].
• Что это даст: Возможность зафиксировать изменение ключевых метрик (время отклика эндпоинтов, переполнение очередей, нагрузка на базу данных) под давлением, не опасаясь, что реальные светофоры города перестанут отвечать на команды управления [1, 4].

2. Защита от «дружеского» DOS-атак при интеграциях

Внешние потребители данных (Яндекс, 2ГИС, Атлант) могут стать источником неконтролируемого потока запросов из-за ошибок в их собственном коде или прихода новых разработчиков [1].

• Зачем это нужно: Реплика служит «буфером» для всех внешних интеграций. Любые эксперименты партнеров замыкаются внутри изолированной среды [1].
• Что это даст: Гарантированную стабильность основного контура. Даже если внешняя система начнет слать аномальное количество запросов («дружеский» DOS), это «завалит» только реплику, но не повлияет на управление движением [1, 3].

3. Работа внешних подрядчиков и безопасность

Привлечение сторонних разработчиков к сложной системе ИТС всегда несет риски безопасности и конфиденциальности.

• Зачем это нужно: Подрядчикам предоставляется доступ только к виртуальному контуру, где они могут тестировать свои модули, используя актуальные, но изолированные данные [2, 5].
• Что это даст: Возможность ограничить доступ к критическим компонентам инфраструктуры и паролям. Это предотвращает случайное или преднамеренное удаление данных напрямую из основной базы данных [5, 6].

4. Безопасная отладка новых сервисов (Debug)

Разработка сложных функций, таких как вероятностное прогнозирование фаз («V2X без V2X») или расчет координации в «Авеню», требует длительной отладки на реальных данных [7, 8].

• Зачем это нужно: Разработчики могут проводить эксперименты в режиме «песочницы», проверяя гипотезы и исправляя ошибки в реальном времени [1, 8].
• Что это даст: Повышение качества ПО перед его выкаткой в «прод». Ошибки в логике или «падение» экспериментального сервиса останутся внутри тестового контура [3].

5. Исключение рисков для реального движения

Транспортная система города — это критическая инфраструктура, где цена ошибки может измеряться заторами или безопасностью людей на дорогах [9].

• Зачем это нужно: Создание реплики отделяет ИТ-эксперименты от транспортной работы [1, 3].
• Что это даст: Полное отсутствие влияния тестовых сценариев на управление реальным движением. ИТ-команда получает свободу для инноваций и тестирования high-load архитектуры, в то время как ГКУ ДОДД сохраняет полный контроль над текущей дорожной ситуацией [1, 3].

Техническая реализация: Для создания полноценной реплики недостаточно одной виртуальной машины. Требуется проектирование сложной архитектуры размещения (предположительно в РРЦОД), включающей механизмы репликации состояния боевой системы, разграничение прав доступа и систему мониторинга эндпоинтов [3, 5, 10].

В сводные предложения по развитию ЕПУТС СПб необходимо включить раздел, посвященный контролю за действиями пользователей и обеспечению прослеживаемости изменений в системе:

6. Подсистема Audit Logs (Аналитика действий пользователей)

Целью данной подсистемы является создание надежного механизма полной трассировки изменений, что необходимо для облегчения поиска причин неисправностей, диагностики проблем и предотвращения несанкционированных действий [1].

6.1. Функциональные требования к фиксации данных

Система должна обеспечивать автоматическую регистрацию следующих параметров для любого изменения в системе:

• Идентификация автора: фиксация логина пользователя или системного процесса, инициировавшего изменение [1, 2].
• Временная метка: точное время внесения изменений [1, 3].
• Источник (Интерфейс): указание на то, через какой интерфейс было внесено изменение — веб-интерфейс (UI) или программный интерфейс (API) [1, 3].
• Объект изменений: перечень измененных сущностей (дорожный контроллер, детектор, канал связи, конфигурация сигнальных групп и т.д.) [1, 3].
• Состав изменений: хранение истории «было/стало» для каждого атрибута объекта, что позволит отслеживать ревизии параметров (например, историю изменения IP-адреса устройства) [2, 4].

6.2. Техническая реализация и High-load архитектура

Для предотвращения деградации производительности основной системы при массовых изменениях через API предлагается следующая схема [2, 3]:

• Асинхронный сбор событий: перехват всех POST/PUT запросов к API и отправка событий в отдельный сервис логирования.
• Фильтрация «шумных» событий: исключение из аудита часто повторяющихся данных (например, показаний детекторов), чтобы не перегружать базу данных [2, 3].
• Масштабируемое хранение: использование key-value хранилищ с настроенной политикой ротации (retention policy) для долгосрочного хранения архивов изменений [3].

6.3. Визуализация и аналитика (UI АСУДД)

• Контекстная история: при открытии свойств любой сущности (контроллера или детектора) в интерфейсе АСУДД должна отображаться полная история действий по этому объекту [1].
• Dashboard статистики: визуализация аналитики — кто из пользователей чаще всего вносит правки, какие объекты являются наиболее «изменчивыми», распределение активности по времени суток [1, 3].
• Выявление аномальной активности: автоматизированный поиск подозрительных паттернов, таких как массовое удаление объектов или серия неудачных попыток изменения конфигурации, с генерацией уведомлений для администраторов безопасности [3, 5].

6.4. Разграничение понятий

Важно разделять аудит действий (историческая запись фактов изменений) и технический мониторинг (метрики нагрузки на эндпоинты в реальном времени), хотя обе эти функции критически важны для стабильности системы [6, 7].

Внедрение Audit Logs позволит ГКУ ДОДД иметь «единый источник правды» при разборе конфликтных ситуаций и обеспечит прозрачность работы всех подрядных организаций, имеющих доступ к API платформы [8, 9].

В дополнение к ранее сформулированным пунктам, предлагается включить в программу развития ЕПУТС приобретение и внедрение аналитического модуля AveVide, который станет «инженерным ядром» системы для оценки реальной эффективности управления дорожным движением.

1.6. Аналитический модуль AveVide: Инженерный контроль и трековая аналитика

Предлагается приобретение лицензий и выполнение работ по интеграции отечественного программного комплекса AveVide. Данное ПО предназначено для развертывания по модели StandAlone на внутренних серверах ГКУ ДОДД (или по сервисной модели SaaS) и обеспечивает переход от субъективных оценок к доказательной транспортной аналитике [1-3].

1.6.1. Полномасштабный мониторинг без привязки к «железу»

• Виртуальные детекторы: Система позволяет «установить» виртуальный детектор в любой точке дорожной сети, обеспечивая измерение скорости и интенсивности движения даже там, где отсутствует физическое детекторное оборудование [4-6].
• Устранение слепых зон: На основе мапмэтчинга (привязки) GPS/ГЛОНАСС-треков к высокоточной пополосной модели УДС (lane-level) формируется полная картина трафика во всем городе [7, 8].

1.6.2. Оценка эффективности светофорного регулирования и координации

• Аудит работы контроллеров: Модуль автоматически определяет фактические параметры циклов (длительность цикла, фаз, моменты переключения программ) непосредственно из анализа траекторий движения ТС [9, 10].
• Диагностика адаптивного и жесткого управления: Система позволяет соотнести выделенное зеленое время с реальным уровнем обслуживания (LoS) и задержками, выявляя ошибки в настройках адаптивных алгоритмов или неактуальность жестких планов [9, 11, 12].
• Анализ координации: С помощью инструментов анализа структуры задержек и треков на перегоне оценивается качество «зеленой волны»: система наглядно показывает «пачки» автомобилей, их распад и места необоснованных остановок в зоне координации [13-15].

1.6.3. Контроль качества приоритетного проезда

• Измерение эффекта приоритета: AveVide позволяет точно оценить, насколько качественно настроен приоритет на конкретном маршруте, измеряя время проезда и задержку для каждого борта ОТ [14, 16, 17].
• Выявление «конфликтности»: Анализ треков на перекрестке позволяет зафиксировать случаи, когда алгоритмы приоритета не справляются с нагрузкой или работают в ущерб общему потоку [18, 19].

1.6.4. Статистическая достоверность и динамика

• Объективные показатели: В отличие от экспертных оценок, система предоставляет статистически достоверные данные (средние значения, медианы, дисперсии), позволяющие оценивать объекты с нестационарными свойствами в условиях меняющихся потоков [3, 16, 17].
• Суточная и недельная аналитика: Модуль формирует профили скорости и интенсивности в разрезе часов, суток и недель, что позволяет инженерам АСУДД видеть динамику развития заторов и эффективность принятых мер по дням недели [5, 20, 21].

1.6.5. Интеграция в экосистему ЕПУТС

• Связь с Цифровым Двойником: AveVide использует данные пополосной модели УДС из OSMPIE и топологический граф AveGeo, обеспечивая математическую точность привязке всех измерений [7, 22, 23].
• Единый API: Все рассчитанные KPI (интенсивность, поток насыщения, LoS, задержки) выдаются на системный API для отображения в UI АСУДД и передачи в смежные системы (Яндекс, МПТП) [22, 24, 25].

Обоснование реализации: Внедрение AveVide позволит ГКУ ДОДД не просто наблюдать за состоянием оборудования, а измерять результат управленческих воздействий, оптимизировать режимы работы светофоров на основе реальных данных и обосновывать изменения в организации дорожного движения [3, 10, 22]. При этом реализация системы как высоконагруженного (high-load) сервиса требует соответствующих серверных мощностей и проектирования архитектуры хранения данных [20, 26].

Идея внедрения MCP (Model Context Protocol) в экосистему ЕПУТС СПб представляет собой создание стандартизированного «интерфейса общения» между сложными подсистемами ИТС и нейросетевыми агентами. Это позволяет превратить разрозненные модули (аналитику, реестры, управление) в элементарные блоки «ЛЕГО», из которых ИИ-агент может собирать сложные цепочки автоматизации, анализировать данные и выполнять управляющие действия.

Ниже представлено подробное описание того, как эта концепция может быть реализована для основных модулей системы:

1. Архитектурный принцип: ИТС как набор инструментов (Tools)

В рамках MCP каждая подсистема ЕПУТС предоставляет нейросети набор инструментов (tools) и ресурсов (resources).

• Ресурсы: это пассивные данные (состояние контроллера, геометрия перекрестка в OSMPIE [1, 2], логи действий пользователей [3]).
• Инструменты: это активные функции (сменить план координации в АСУДД [4], запустить расчет оптимизации в Avenue [5], построить диаграмму Пердью в AveVide [6]).

2. Применение MCP по ключевым модулям ЕПУТС

2.1. Подсистема мониторинга и контроля эффективности

• Для мониторинга потока: ИИ-агент через MCP получает доступ к данным «здесь и сейчас» из МПТП [7, 8]. Он может самостоятельно вызывать инструмент get_current_traffic_state для выявления аномальных задержек или падения скорости на конкретном участке [9, 10].
• Для технического мониторинга: Агент контролирует состояние ~300 эндпоинтов системы [11]. В случае роста ошибок (4xx, 5xx) он может сопоставить это с данными из Audit Logs, чтобы понять, какие изменения в конфигурации привели к сбою [12, 13].

2.2. Модуль аналитики и оптимизации (AveVide и Avenue)

• Инженерная аналитика: Агент может «заказать» у AveVide расчет уровня обслуживания (LoS) для перекрестка [14, 15] или анализ цикличности работы светофоров [16].
• Автоматизация оптимизации: Получив данные о плохой прогрессии из координационной диаграммы Пердью [17], агент может использовать API модуля Avenue для автоматического запуска симуляции и расчета нового плана «зеленой волны» [5, 18].

2.3. Цифровой двойник (OSMPIE и AveGeo)

• Оперирование геометрией: Через MCP агент получает машиночитаемое описание пополосной модели УДС [1, 19].
• Контроль качества данных: Если треки ТС начинают «уплывать» (например, из-за спуфинга), агент может запросить сверку с эталонной геометрией в OSMPIE и предложить корректировку или пометить данные как недостоверные («АвиаДата») [20, 21].

2.4. Реестры оборудования, режимов и База знаний

• Инвентаризация и аудит: ИИ-агент через MCP может проверять соответствие фактической конфигурации в контроллере той, что записана в реестре [22]. Если обнаружено расхождение (например, локальная заливка через флеш-карту), агент уведомляет службу безопасности [23].
• Интеллектуальный помощник (RAG): Подключаясь к «порталу знаний» (Wiki проекта), агент помогает новым сотрудникам ГКУ ДОДД быстро разобраться в API или настройках конкретного типа контроллера (КРОСС, РУКОН и др.) [4, 24].

3. Как это работает: сценарии «ЛЕГО-автоматизации»

Благодаря MCP, нейросетевой агент может выполнять комплексные сценарии, которые раньше требовали ручной работы инженера:

1. Обнаружение проблемы: Агент видит в мониторинге МПТП резкий рост задержки на подходе [8].
2. Диагностика: Он вызывает инструмент AveVide get_track_analytics и видит, что ТС простаивают по 4 цикла [25, 26]. Параллельно он проверяет Audit Logs и видит, что 10 минут назад другой пользователь изменил длительность фазы [3].
3. Решение: Агент обращается к базе знаний, чтобы проверить допустимые границы фаз для этого перекрестка [24], и через интерфейс АСУДД («псевдо-Спектр») возвращает корректную конфигурацию [27].
4. Отчет: Агент формирует отчет о событии, указывая, сколько времени было сэкономлено благодаря оперативному вмешательству [28, 29].

4. Преимущества внедрения

• Снижение зависимости от «ручного» управления: ИИ берет на себя рутинный мониторинг тысяч эндпоинтов и контроллеров [11, 30].
• Преодоление «капсульности» систем: MCP связывает разрозненные отечественные продукты (AveVide, Avenue, OSMPIE) в единый рабочий контур без написания сложного жесткого кода интеграции [4, 31].
• Безопасность: Работа агентов может происходить в «виртуальной реплике» системы, что исключает риск влияния на реальное дорожное движение до момента подтверждения решения человеком [32, 33].

Реализация MCP-интеграций превращает ЕПУТС из простого набора программ в динамическую интеллектуальную среду, способную к самодиагностике и оперативной оптимизации на основе объективных инженерных метрик [34, 35].

Согласно источникам, в качестве базисного (стандартного) потока насыщения для расчётов в среде Transyt-7FR и сервисе AveVide принимается значение 1800 ТС/час (автомобилей в час зелёного сигнала) на одну полосу [1-3].

Это значение является единым стартовым параметром для всех типов манёвров, однако оно корректируется в зависимости от направления движения и других факторов [4, 5]:

• Для прямого движения: Базовое значение 1800 ТС/час остаётся основой, к которой применяются коэффициенты, учитывающие ширину полосы, наличие грузового транспорта, уклоны и остановки автобусов [2, 4, 5].
• Для поворотных манёвров: В расчётах также используется тот же базисный поток (1800), но он обязательно умножается на специальные поправочные коэффициенты по манёврам ($K_m$ или $F_{lt}$, $F_{rt}$) [3, 4].
  • Эти коэффициенты учитывают сложность поворота, радиус и влияние пешеходных или велосипедных потоков, пересекающих путь автомобиля [4, 6].
  • В результате корректировки реальный (расчётный) поток насыщения для поворотов может быть значительно ниже базового. Например, в практических примерах для поворотов направо он может составлять около 600 ТС/час, в то время как для движения прямо — 1700–1800 ТС/час [7, 8].

Таким образом, 1800 ТС/час — это эталонная величина «свободного» потока без учёта влияющих факторов, а специфика прямого движения или поворотов учитывается через систему понижающих коэффициентов [3-5].