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

Dynamic max limit (динамический максимум) — это функция современных дорожных контроллеров (например, «СПЕКТР-II»), которая позволяет автоматически изменять максимальную длительность разрешающего сигнала (зеленого света) в зависимости от текущей нагрузки на перекрестке [1, 2].

В отличие от фиксированного параметра «Maximum Green» (максимальный зеленый), который ограничивает фазу при наличии постоянного спроса, динамический лимит работает по следующей логике:

• Принцип работы: Если фаза несколько раз подряд завершается по «максимуму» (max-out), что означает наличие неразряженной очереди, контроллер начинает постепенно увеличивать текущий лимит времени [3, 4].
• Увеличение: Длительность увеличивается на определенный шаг (например, параметр dynamicMaxStep) до тех пор, пока фаза не начнет завершаться по «разрыву» потока (gap-out), то есть когда все ожидающие транспортные средства будут обслужены [2, 3].
• Ограничение: Рост этого времени ограничен параметром dynamicMaxLimit — абсолютным верхним пределом, выше которого контроллер не будет продлевать фазу даже при наличии очереди [2].
• Возврат: Когда нагрузка снижается и фаза стабильно завершается по разрыву, динамический максимум начинает постепенно сокращаться до своего первоначального базового значения [3].

Основные параметры настройки (согласно конфигурации контроллера «СПЕКТР-II») [2]:

• maxGreen: Базовое значение максимального зеленого.
• dynamicMaxLimit: Предельное значение, до которого может вырасти максимум.
• dynamicMaxStep: Величина приращения времени при каждом цикле перегрузки.

Назначение функции: Использование динамического максимума позволяет системе гибко реагировать на кратковременные всплески трафика, не устанавливая при этом чрезмерно длинные циклы для периодов с низкой интенсивностью движения [3, 5]. Это помогает избежать «провалов цикла» (cycle failure), когда часть транспортных средств остается стоять у стоп-линии после окончания зеленого сигнала [6, 7].

Многокольцевая структура фазирования — это объект организации внутренней программной логики дорожного контроллера, который позволяет управлять набором бесконфликтных направлений движения (сигнальных групп) независимо друг от друга в рамках нескольких параллельных последовательностей (колец) [1, 2].

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

Основные понятия

• Кольцо (Ring): Заданная в сигнальном плане последовательность подфаз (этапов для конкретных направлений), которые конфликтуют между собой и потому должны следовать строго друг за другом [5, 6].
• Барьер (Barrier): Точка синхронизации всех колец. Все кольца обязаны «пересечь» барьер одновременно. Это гарантирует, что не возникнет конфликта между группами направлений, разделяемых барьером (например, потоки по главной улице не пересекутся с потоками по второстепенной) [7, 8].
• Подфаза (Sub-phase): Элемент внутри кольца, управляющий набором совместимых сигнальных групп и имеющий собственные временные параметры [1, 2].

Зачем нужна многокольцевая структура?

1. Повышение пропускной способности (эффективности):

   • Она позволяет одновременно выполнять неконфликтующие маневры из разных колец. Например, если в одном кольце встречный левый поворот уже завершился, контроллер может сразу запустить попутный прямой поток, не дожидаясь окончания левого поворота в другом кольце [9, 10].
   • Устраняется «пустое» время (slack time) в цикле, так как каждое кольцо может завершать свои подфазы по мере фактического отсутствия транспорта (gap-out) [11, 12].

2. Гибкость и адаптивность:

   • Пропуск фаз: Если на каком-то направлении нет заявок от детекторов или кнопок, эта подфаза в конкретном кольце просто пропускается, и время отдаётся другим участникам движения [12, 13].
   • Динамическое продление: Каждое направление может продлеваться индивидуально на основе данных детекторов транспорта [12, 14].

3. Унификация и современные стандарты:

   • Многокольцевой принцип рекомендован для использования в Интеллектуальных транспортных системах (ИТС), так как он лучше всего подходит для реализации адаптивных алгоритмов и сетевой оптимизации [12, 15].
   • Такой подход позволяет перейти от управления «фазами» к более точному активному управлению по направлениям [3, 16].

4. Сложные сценарии регулирования:

   • Эта структура необходима для реализации «двойного цикла» (double cycling), когда некоторые направления (например, пешеходные или второстепенные) обслуживаются чаще или реже других в рамках одного общего цикла [17, 18].
   • Она позволяет эффективно настраивать сложные развязки и пересечения с трамвайными путями, обеспечивая приоритет общественному транспорту без полной остановки всего перекрёстка [19, 20].

В российских стандартах (ГОСТ Р 71096-2023 и ПНСТ 894-2023) многокольцевой способ формирования цикла признан предпочтительным для современных адаптивных дорожных контроллеров [12, 15].

Пополосная модель цифрового двойника (lane-level) представляет собой математически точный фундамент улично-дорожной сети, который переводит моделирование из разряда теоретических предположений в плоскость точных инженерных расчетов [1-3].

Основные преимущества такой модели для моделирования включают:

1. Высокая геометрическая точность и детализация

В отличие от обычных карт, пополосная модель описывает не просто дороги, а конкретные полосы движения, стоп-линии, поворотные карманы, трамвайные пути и зоны конфликтов [1, 4-6]. Это позволяет:

• Учитывать реальную пропускную способность каждой полосы [7, 8].
• Точно моделировать сложные маневры и перестроения [9, 10].
• Визуализировать объекты регулирования (светофоры, детекторы) с привязкой к конкретным координатам [4, 6].

2. Реалистичное микромоделирование и виртуальные тесты

Пополосная модель служит основой для запуска микроуровневых имитационных моделей (например, в SUMO, Aimsun или VISSIM) [11-13].

• Технологии SITL и HITL: Вы можете использовать точную алгоритмическую копию дорожного контроллера внутри виртуальной среды («песочницы») [14-16]. Это позволяет проводить неограниченные эксперименты с настройками адаптивного управления и приоритетного проезда без риска для безопасности реального движения [14, 16].
• Оценка «до / после»: Модель позволяет сравнить различные сценарии организации дорожного движения и выбрать наиболее эффективный до начала строительных работ [17-19].

3. Точная аналитика и мапмэтчинг треков

Цифровой двойник позволяет выполнять сверхточную привязку GPS/ГЛОНАСС-треков транспортных средств к конкретным полосам движения [1, 20, 21]. Это дает возможность получать объективные метрики:

• Задержки на конкретных подходах и стоп-линиях [8, 17].
• Уровень обслуживания (LoS) для каждого направления движения [22, 23].
• Реальный поток насыщения и объемы трафика [7, 8, 24].

4. Фундамент для V2X и беспилотного транспорта

Модель является основой для генерации машиночитаемых данных, необходимых для сервисов подключенного транспорта:

• Генерация сообщений MAPEM (топология перекрестка) и SPATEM (состояние сигналов светофора и прогноз их смены), которые передаются на борт автомобиля [5, 25-27].
• Высокоточная навигация и маневренное руководство для беспилотных ТС [25].

5. Инженерный расчет программ регулирования

На основе данных о конфликтных точках и длине пешеходных переходов, заложенных в модель, система может автоматически рассчитывать безопасные промежуточные такты (матрица InterGreen) и минимальные длительности фаз [11, 28-30].

В конечном итоге, использование пополосного цифрового двойника позволяет перейти от субъективного восприятия ситуации («кажется, здесь пробка») к доказательной аналитике и обоснованным управленческим решениям [31, 32].

Хотите подробнее узнать, как именно пополосная модель помогает в настройке приоритета для общественного транспорта или как работает интеграция с сервисами оптимизации вроде Avenue 2.0? [33, 34]

Матрица межзеленых интервалов (Intergreen Matrix, IGM) — это структурированная база данных в памяти дорожного контроллера или системы проектирования, которая определяет минимально допустимое время между окончанием «зеленого» для одного направления движения и началом «зеленого» для другого, конфликтующего с ним направления [1-3].

В современных интеллектуальных транспортных системах (ИТС) использование такой матрицы является стандартом (например, закреплено в ГОСТ Р 71096—2023 и ПНСТ 894-2023) [4].

Зачем использовать матрицу межзеленых?

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

1. Максимальная безопасность (Доказательный расчет) Матрица позволяет рассчитывать безопасный промежуточный такт «на лету» для каждой пары конфликтующих направлений [5]. Расчет основывается на:

• Конфликтных точках: Точных местах пересечения траекторий транспортных средств [6].
• Геометрии перекрестка: Длине пешеходных переходов и путей разъезда, заложенных в цифровой двойник [6, 7]. Это исключает ошибки «человеческого фактора» при ручном программировании фаз и гарантирует, что автомобиль или пешеход успеет безопасно покинуть зону конфликта [5, 8].

2. Гибкость и эффективность (Переход от «фаз» к «направлениям») Традиционное управление использует жесткие фазы, где группы светофоров включаются одновременно. Матрица межзеленых позволяет реализовать активное многокольцевое управление по направлениям [3, 9].

• Зеленый сигнал для конкретной полосы может начаться или закончиться независимо от других, как только это станет безопасно согласно матрице [10, 11].
• Это позволяет системе адаптивно «подстраиваться» под реальный спрос, не тратя время на ожидание окончания всей фазы, если по одному из направлений поток уже иссяк [5, 10].

3. Автоматизация проектирования и моделирования Матрица служит фундаментом для автоматической генерации программ регулирования в специализированном ПО (например, Avenue 2.0 или OSMPIE) [6, 12].

• Данные матрицы позволяют визуализировать схемы пофазного разъезда и проводить микромоделирование транспортных потоков (в среде SUMO или Aimsun) для оценки задержек еще до внедрения режима на реальном перекрестке [6, 13, 14].
• Она также является основой для генерации V2X-сообщений (SPATEM), передающих на борт автомобилей прогноз смены сигналов [7, 15].

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

В АСУДД «Спектр» реализована многоуровневая система обеспечения приоритетного проезда, которая сочетает различные архитектурные подходы и современные технологии обнаружения транспортных средств.

Ниже приведен подробный разбор способов и архитектур реализации приоритета:

Архитектурные подходы

1. Централизованная архитектура: Управляющий центр АСУДД получает данные о местоположении транспорта (например, через ГЛОНАСС/LTE) и передает прямые команды управления на дорожный контроллер [1, 2]. В этой схеме могут использоваться виртуальные детекторы — программные зоны на карте, при пересечении которых система инициирует запрос на приоритет [2, 3].
2. Децентрализованная (локальная) архитектура: Дорожные контроллеры объединяются в локальную сеть связи и передают друг другу данные о прохождении транспортным средством меток [4]. Это позволяет строить прогноз прибытия на перекресток за 30–40 секунд непосредственно на периферийном уровне [4].
3. Архитектура на базе V2X: Транспортное средство, оснащенное бортовым устройством (OBU), передает сообщение о приоритете (CAM/SAM) непосредственно на придорожный блок (RSU), подключенный к дорожному контроллеру [1, 5].
4. Унификация через МФУ: Для контроллеров сторонних производителей используется многофункциональное устройство (МФУ), которое выступает периферийным модулем логики и наделяет «старое» оборудование функциями активного и условного приоритета [6, 7].

Технологии обнаружения и связи

Система поддерживает широкий стек технологий для идентификации приоритетных ТС:

• V2X (ITS-G5 / C-V2X 5G): Обеспечивает надежный канал связи с низким временем задержки для передачи данных о фазах (SPaT) и геометрии (MAP) [8].
• RFID-метки: Проверенное решение (проект «Чижик»), использующее радиочастотную идентификацию для точного контроля прохождения трамваями контрольных точек [9, 10].
• BLE-маяки: Используются для обеспечения навигации и приоритета в условиях подавления спутникового сигнала (РЭБ) [11, 12].
• Интеллектуальная видеоаналитика: Использование ИИ-детекторов для автоматического обнаружения спецтранспорта или пешеходов (например, распознавание колясочников для продления фазы) [12-14].

Способы и стратегии реализации

В «Спектре» выделяются следующие типы приоритета:

• Активный приоритет: Светофорный объект активно реагирует на индивидуальный запрос от конкретного транспортного средства [15].
• Пассивный приоритет: Создание «зеленых коридоров» и координация движения с учетом расчетных скоростей общественного транспорта [15].
• Условный приоритет: Предоставление преимущества только при выполнении определенных условий, например, если автобус отстает от расписания [11, 16].
• Алгоритмы управления: Приоритет может реализовываться через продление зеленого сигнала, сокращение красного (раннее включение), вставку специальной фазы или пропуск неконфликтных фаз [17-19].

Активное управление по направлениям (вместо жестких фаз) является фундаментом эффективности этих систем, так как позволяет гибко подстраивать работу каждой сигнальной группы под запрос приоритетного ТС [20, 21].

Опыт и экспертиза компании РИПАС на российском рынке характеризуются переходом от разработки отдельных устройств к созданию комплексной экосистемы Интеллектуальных транспортных систем (ИТС), основанной на открытых стандартах и высокоточных данных. Компания обладает более чем 25-летним опытом разработки технологий управления дорожным движением [1].

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

1. Платформенные решения и АСУДД «СПЕКТР»

РИПАС разработал современную российскую платформу верхнего уровня, которая функционирует по принципу «ЛЕГО для ИТС» [1, 2]. Это позволяет гибко масштабировать систему от одного перекрестка до уровня региона, добавляя нужные модули без переписывания всего кода [1, 3]. Платформа является реально действующим ПО, которое уже внедрено в таких городах, как Санкт-Петербург, Краснодар, Ярославль, Пермь и Тюмень [4, 5].

2. Экспертиза в аппаратном обеспечении

Компания производит дорожные контроллеры нового поколения «СПЕКТР-II», которые отличаются:

• Открытой архитектурой: Работа на ОС Linux и поддержка пользовательских скриптов на JavaScript [6, 7].
• Многокольцевым управлением: Регулирование ведется по конкретным направлениям движения, а не просто по фазам [8, 9].
• Матрицами InterGreen: Автоматический расчет безопасных промежуточных тактов «на лету» в соответствии с ГОСТ Р 71096—2023 [8, 10].

3. Цифровые двойники и Lane-level моделирование

Экспертиза РИПАС включает создание высокоточных пополосных моделей УДС (lane-level) [11, 12]. Инструменты компании (OSMPie, Net329Edit) позволяют формировать математически точный цифровой двойник города, который служит основой для:

• Микромоделирования транспортных потоков (SITL/HITL технологии) [13, 14].
• Сверхточной привязки GPS-треков для аналитики [11, 15].
• Генерации данных для беспилотного транспорта и V2X-сервисов [16, 17].

4. Лидерство в реализации приоритетного проезда

РИПАС обладает уникальным практическим опытом реализации активного приоритета для общественного транспорта, включая знаковый проект «Чижик» в Санкт-Петербурге [18, 19]. Компания применяет различные архитектуры:

• RFID и BLE-технологии: Обеспечение навигации и приоритета даже в условиях работы средств РЭБ [19, 20].
• V2X сервисы: Трансляция сообщений SPaT (сигналы и прогнозы) и MAP (карты) непосредственно на борт транспортных средств [17, 21].

5. Разработка отраслевых стандартов

Компания активно участвует в стандартизации отрасли, предлагая открытый протокол низкоуровневого доступа «Сигнал-2» [22, 23]. Этот протокол призван устранить проблему «зоопарка» оборудования разных вендоров, обеспечивая минимальный слой совместимости для любых контроллеров внутри городской ИТС [23, 24].

6. Доказательная аналитика и инструменты оптимизации

Экспертиза компании подкреплена мощными инструментами контроля эффективности:

• AveVide: Система измерения реальной работы УДС на основе треков, позволяющая уйти от субъективных оценок к точным KPI (задержки, скорость, уровень обслуживания LoS) [25-27].
• Avenue 2.0: Онлайн-сервис для автоматического расчета программ координации («зеленая волна») и сетевой оптимизации [28-30].

Результаты работы РИПАС показывают, что внедрение даже простых мер приоритета позволяет сократить задержки транспорта на 10–40%, что в масштабах города эквивалентно высвобождению нескольких единиц подвижного состава без потери качества обслуживания пассажиров [31-33].

Хотите подробнее рассмотреть архитектурную схему интеграции платформы «СПЕКТР» с внешними городскими системами или узнать о том, как МФУ помогает модернизировать старое оборудование?

Архитектура платформы «СПЕКТР» и возможности МФУ (многофункционального устройства) позволяют построить гибкую ИТС, объединяющую современные цифровые сервисы и уже существующую городскую инфраструктуру.

1. Архитектура интеграции платформы «СПЕКТР»

Платформа функционирует как «ЛЕГО для ИТС», где модульная архитектура и открытые интерфейсы позволяют бесшовно подключать внешние системы [1, 2].

• Открытый API (OpenAPI/Swagger): Центр управления предоставляет полностью документированный REST API. Это позволяет внешним подсистемам (навигация, биллинг, мониторинг трафика, РНИС) запрашивать данные о состоянии дорожной сети и управлять объектами [2, 3].
• Единый цифровой двойник (Lane-level): Все подсистемы работают с общей пополосной моделью УДС. Модель доступна через API и обеспечивает «единый источник правды» для моделирования, навигации высокой точности и V2X-сервисов [3, 4].
• Унифицированная аутентификация: Использование JWT-токенов обеспечивает единую систему управления правами доступа как для пользователей, так и для микросервисов внутри экосистемы [3, 4].
• Интеграция с информационными табло (АСУ УТ): Благодаря открытым протоколам платформа позволяет подключать динамические табло и медиаэкраны любых производителей для автоматического вывода предупреждений о заторах, ДТП или ЧС [5-7].
• Связка с инструментами оптимизации: Платформа полностью интегрирована с сервисом Avenue 2.0 для автоматического расчета программ «зеленой волны» и сетевой адаптивности [8, 9].

2. Модернизация старого оборудования с помощью МФУ

МФУ (многофункциональное устройство) выступает в роли вынесенного «мозга» периферийного уровня, позволяя преодолеть проблему «зоопарка» контроллеров (ДК) от разных вендоров [10, 11].

• Унификация через «Сигнал-2»: МФУ подключается к стороннему контроллеру через открытый протокол низкоуровневого доступа «Сигнал-2». Это обеспечивает минимальный слой совместимости, позволяя управлять сигнальными группами и фазами ДК любого производителя в реальном времени [10, 12].
• Придание системных свойств: Старый («жесткий») контроллер, будучи подключенным к МФУ, получает возможности, которые ранее были ему недоступны [10, 13]:
  • Адаптивное управление: реализация алгоритмов управления по направлениям и сетевой оптимизации;
  • Активный приоритет: поддержка приоритетного проезда для спецтранспорта и трамваев (на базе ГЛОНАСС, RFID или BLE);
  • V2X сервисы: генерация и передача сообщений SPATEM (сигналы/прогнозы) и MAPEM (топология) для подключенных ТС.
• Локальная обработка данных: МФУ берет на себя взаимодействие с детекторами (поддерживает более 5 протоколов), обработку данных от BLE-маяков и RFID-меток, а также обеспечивает ГОСТ-шифрование и буферизацию связи с центром [10, 13].
• Виртуальная «песочница» (SITL/HITL): МФУ работает на базе ОС Linux и позволяет запускать точные алгоритмические копии контроллера в виртуальной среде. Это дает возможность тестировать сложные сценарии управления и приоритета в «цифре» перед их внедрением на реальном перекрестке [14-16].

Таким образом, МФУ позволяет сохранить существующий парк контроллеров, наделив их функциями современных интеллектуальных устройств, и объединить их в единую технологическую экосистему управления [13, 17].

Сравнение дорожных контроллеров (ДК) «Спектр» (преимущественно модели «Спектр-II») и «Синтез» позволяет выделить их технологические особенности в контексте современных национальных стандартов ПНСТ 894-2023 (требования к адаптивным ДК) и ГОСТ Р 71096-2023 (общие требования к подсистемам светофорного управления).

Оба контроллера являются современными отечественными разработками, внесенными в реестр ПАК и поддерживающими работу на базе ОС Linux [1, 2]. Однако их архитектурные подходы и соответствие критериям классификации ПНСТ различаются.

1. Способ организации цикла (Критерий О)

• ДК «Спектр-II»: Построен на принципе активного многокольцевого управления по направлениям (соответствует О3 по ПНСТ 894-2023) [3, 4]. Это позволяет управлять каждой сигнальной группой (направлением) независимо, что является наиболее эффективным для адаптивного регулирования [5, 6].
• ДК «Синтез»: Поддерживает управление как по фазам, так и по направлениям [7]. Однако его базовая логика чаще ориентирована на фазный (поэтапный) тип (О2), что характерно для традиционных систем координации [4, 7].

2. Формирование промежуточных тактов (Критерий П)

• ДК «Спектр-II»: Реализует динамическое формирование промежуточных тактов на основе полных матриц переходов (Intergreen Matrix) (соответствует П2) [3, 8, 9]. Это обеспечивает расчет безопасных интервалов «на лету» для любых комбинаций сигнальных групп, что прямо рекомендуется ГОСТ Р 71096-2023 [10, 11].
• ДК «Синтез»: В доступной документации акцент сделан на контроле токов и напряжений для безопасности (защита от «зеленого с красным»), но глубокая поддержка матриц InterGreen как основы формирования тактов не выделяется как ключевое преимущество [12, 13].

3. Адаптивность и логика управления (Критерии А и Л)

• ДК «Спектр-II»: Ориентирован на активное управление (А3) — обработку активирующих событий в реальном времени с возможностью изменения последовательности подфаз [2, 14]. Поддерживает пользовательские сценарии на JavaScript (Л2), что позволяет реализовывать произвольную логику без перепрошивки [2, 15].
• ДК «Синтез»: Поддерживает транспортно-зависимое (А1) и адаптивное управление (А2) на основе детекторов [7, 16, 17]. В части настройки безопасности предусмотрен автоматический переход в жесткий цикл при отказе детекторов [18].

4. Сервисы V2X и высокоточная топология (Критерий Х)

• ДК «Спектр-II»: Имеет встроенную поддержку протоколов V2X и генерацию сообщений SPATEM (сигналы и прогнозы) и MAPEM (топология УДС на уровне полос — lane-level) [19, 20]. Это соответствует требованиям к перспективным ИТС по ГОСТ Р 71096-2023 [21].
• ДК «Синтез»: Фокусируется на поддержке протоколов централизованного управления, таких как UTMC, STCIP и UG405 [7, 22]. Поддержка формирования MAPEM-сообщений непосредственно контроллером в источниках не детализирована.

5. Интеграция и открытость (ГОСТ Р 71096-2023)

• ДК «Спектр-II»: Предлагает расширяемую открытую архитектуру с OpenAPI/Swagger и JSON-конфигурациями [2, 23, 24]. Полностью готов к работе в виртуальной среде (SITL/HITL моделирование), что позволяет отлаживать алгоритмы в «цифровом двойнике» перед внедрением [3, 25].
• ДК «Синтез»: Обеспечивает интеграцию через стандартные интерфейсы и специализированное ПО «Синтез-конфигуратор» [7]. Управление и диагностика доступны через веб-интерфейс, включая доступ к информации о токах групп [26, 27].

Итоговое сопоставление (по ПНСТ 894-2023):

Вывод: ДК «Спектр-II» является более «цифровизованным» решением, ориентированным на активное управление по направлениям и интеграцию с беспилотным транспортом (V2X), что делает его базовым элементом для систем нового поколения [30]. ДК «Синтез» — это надежное индустриальное решение, эффективно работающее с классическими протоколами ИТС и обеспечивающее высокую плотность подключения периферии (до 130 групп) [7].

Параметры JSON-конфигурации дорожного контроллера «Спектр» напрямую связаны с обеспечением безопасности дорожного движения через управление временными интервалами, предотвращение конфликтов и мониторинг состояния оборудования.

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

1. Матрица межзеленых интервалов (IGM / Intergreen Matrix)

Это главный «предохранитель» системы. В JSON-файле блок IGM описывает задержки включения разрешающего сигнала (entering) после выключения конфликтующего (clearing) [1, 2].

• Безопасный переход: Матрица гарантирует, что между конфликтующими потоками будет выдержана пауза, достаточная для того, чтобы транспорт или пешеходы успели покинуть зону пересечения [3, 4].
• Динамический расчет: Контроллер рассчитывает промежуточные такты «на лету» на основе этой матрицы, обеспечивая оптимальные и безопасные интервалы для любой комбинации переключаемых групп [4, 5].
• Приоритет безопасности: В примере конфигурации одна из матриц прямо обозначена атрибутом "safety": true [2].

2. Параметры сигнальных групп (signalGroups)

Этот блок определяет физику работы светофора:

• amber (желтый): Предупреждает о смене права проезда. Слишком малая длительность может создать «зону дилеммы», когда водитель не может ни безопасно остановиться, ни успеть проехать перекресток [6, 7].
• greenBlink (зеленое мигание): Информирует о скором окончании разрешающего сигнала, предотвращая резкое торможение и попутные столкновения [6, 8].
• minGreen (минимальный зеленый): Исключает нарушение ожиданий водителей; слишком короткий сигнал может привести к росту числа наездов сзади [6, 9].

3. Защита уязвимых участников движения (pedestrianGreen, pedestrianRecall)

Параметры пешеходного регулирования в JSON критически важны для защиты людей:

• pedestrianGreen и интервалы очистки: Гарантируют время, необходимое пешеходам для завершения перехода дороги [7, 10].
• pedestrianRecall: Если этот параметр в значении true, пешеходная фаза вызывается в каждом цикле автоматически, что важно в зонах с высоким пешеходным спросом [10, 11].
• Детекция ИИ: Система позволяет увеличивать длительность сигналов при обнаружении медленных пешеходов или людей в колясках [12].

4. Активное управление и «зона дилеммы» (passage, minGap)

Параметры логики Volume-Density (объем-плотность) в блоке MultiRing помогают избежать аварий на высоких скоростях:

• passage (время проезда): Позволяет продлевать зеленый сигнал, пока детектор фиксирует идущий плотным потоком транспорт [10, 13].
• minGap (минимальный зазор) и timeToReduce: Эти параметры позволяют системе безопасно завершить фазу, когда в транспортном потоке появляется разрыв, минимизируя вероятность того, что водитель окажется в «зоне дилеммы» в момент включения желтого [10, 14, 15].

5. Мониторинг и отказоустойчивость (sensors, recall)

Система JSON включает параметры контроля за состоянием самого объекта:

• Сенсоры: Параметры door (открытие шкафа), power (отсутствие напряжения) и reset (нажатие кнопки сброса) позволяют оперативно реагировать на вмешательство или технические сбои [16].
• Режим recall (вызов): В случае неисправности детекторов (например, через emergencyTimeout), контроллер использует параметры вызова (например, MIN или SOFT), чтобы перевести объект в безопасный фиксированный режим работы и избежать блокировки движения [17-19].

6. Инновационная безопасность (V2X)

Контроллер использует данные JSON (такие как SPATEM — прогнозы сигналов и MAPEM — топология) для трансляции на борт автомобилей [20, 21]. Это позволяет подключенному транспорту заранее знать о состоянии светофора и избегать опасных маневров [22, 23].

Для разъяснения вопросов по алгоритмам адаптивного управления, представленным в источниках для систем «СПЕКТР», «СИНТЕЗ» и общих национальных стандартов (ПНСТ 894-2023, ГОСТ Р 71096—2023), ниже приведены подробные ответы:

1. «Мягкий» режим актуализации (на примере ДК УК5/Спектр)

Хотя термин «мягкий» применительно к актуализации последовательности фаз в источниках не имеет прямого определения в одном предложении, он концептуально связан с понятием «плавного втягивания» или «плавного перехода». Согласно ПНСТ 894-2023 и ГОСТ Р 71096—2023, при переопределении параметров сигнального плана (например, смещения координации или длительности фаз) алгоритм должен обеспечивать плавный переход, исключающий резкие изменения, которые могут дезориентировать водителей [1]. В системах координации это часто реализуется за счет распределения коррекции времени на 2–3 цикла [1]. Также существует понятие «мягкого вызова» (Soft Recall), когда фаза обслуживается только при отсутствии конфликтующих запросов, что позволяет системе гибко «пропускать» направления без жесткой привязки к циклу [2, 3].

2. Параметры многокольцевого алгоритма

Для задания адаптивного управления в многокольцевом режиме (например, в ДК «СПЕКТР-II») используется унифицированный JSON-формат конфигурации [4, 5].

• Унификация: Описание параметров (таких как minGreen, maxGreen, passage, minGap и др.) является аппаратно-независимым стандартом [4]. Это означает, что конфигурация алгоритма будет идентичной как для контроллера «СПЕКТР», так и для стороннего оборудования, подключенного через МФУ, которое выступает «мозгом» периферийного уровня и наделяет старые ДК новыми системными свойствами [6, 7].
• Перечень атрибутов: Включает в себя распределение сигнальных групп по фазам, параметры безопасности (InterGreen Matrix) и динамические шаги изменения (dynamicMaxStep, dynamicMaxLimit) [4].

3. Алгоритм «Пешеходный» и параметры зазора

В алгоритмах управления по направлениям (подфазах) указываются все связанные сигнальные группы (СГ) — и транспортные, и пешеходные [8].

• Состав фаз: Определяется по назначенному типу СГ в конфигурации [8, 9]. Пешеходные интервалы (Walk и FDW) обычно привязываются к параллельным транспортным фазам [10, 11].
• Параметры зазора (Gap Reduction):
  • Минимальный зазор (Minimum Gap): Минимальное время между срабатываниями детекторов, до которого система может сократить время продления «зеленого» [12-14].
  • Время уменьшения зазора (Time to Reduce): Интервал времени, в течение которого допустимый зазор линейно уменьшается от начального значения до минимального [13, 15, 16].
  • Время до начала уменьшения (Time Before Reduction): Задержка (обычно 1/3 от макс. зеленого) после появления конфликтующего вызова, прежде чем система начнет «поджимать» зазор для ускорения смены фазы [13, 17-19].

4. «Пассивный» алгоритм

Под «пассивным» управлением (или категорией А0) понимается регулирование по заранее рассчитанным жестким программам или сигнальным планам, которые выбираются по расписанию в зависимости от времени суток и дня недели, без использования текущих данных от детекторов транспорта [20-22]. В контексте приоритета «пассивный приоритет» — это создание «зеленых волн» под расчетную скорость движения [23].

5. Групповое адаптивное управление

Стратегия группового управления («адаптивная система») реализуется через взаимодействие с верхним уровнем платформы (например, Avenue 2.0) [23, 24].

• Механизм: Система получает данные от локальных ДК и детекторов через API (OpenAPI/Swagger), выполняет сетевую оптимизацию и возвращает обновленные параметры координации или номера планов [25-27].
• Скрипты: Поддержка пользовательских сценариев на языке JavaScript (ECMA-262) в контроллерах «СПЕКТР-II» позволяет реализовывать произвольную логику взаимодействия группы объектов без изменения прошивки [28-30].

6. Пороговые значения и сценарии для групп

Да, существуют алгоритмы, работающие по принципу Traffic Responsive [31]. Они используют целевые значения (targets) или пороги (thresholds) интенсивности и занятости полос для автоматического переключения программ координации во всей группе контроллеров [32-34]. Современные системы также поддерживают предиктивное проактивное управление с горизонтом прогноза 15–30 минут на основе ИИ-моделей [23].

7. Автоматическое защитное отключение (Fallback)

В ПО дорожных контроллеров (например, семейства «СИНТЕЗ») предусмотрены настройки безопасности по детекторам [35].

• Логика: Если в течение заданного интервала времени (например, от 120 до 720 минут) детектор находится в состоянии «постоянно включен» или «постоянно выключен» (признак неисправности), ДК автоматически переводит объект из адаптивного режима в режим работы с фиксированным временем фаз [36, 37]. Это предотвращает работу алгоритмов на основе недостоверных данных.

Soft Recall (Мягкий вызов) — это параметр дорожного контроллера, который автоматически активирует вызов для обслуживания определенной фазы только при условии отсутствия активных вызовов от конфликтующих направлений [1-3].

Основные характеристики и принципы работы Soft Recall:

• Логика работы: Контроллер размещает вызов на фазу с этой настройкой только тогда, когда нет других обслуживаемых вызовов, которые бы ей препятствовали [4-6].
• Длительность сигнала: В режиме Soft Recall фаза будет обслуживаться как минимум в течение времени минимального зеленого интервала [6]. Если детекторы фиксируют транспорт, фаза может быть продлена по обычным правилам [6].
• Типичное применение: Чаще всего этот режим используется для главных направлений магистрали (обычно фазы 2 и 6) на некоординируемых перекрестках [6-8].
• Преимущества:
  • Режим ожидания («отдыха»): Позволяет перекрестку оставаться (dwell) в зеленом сигнале для главной дороги в периоды низкой интенсивности движения, если на второстепенных улицах нет транспорта [6, 7].
  • Гибкость: В отличие от «минимального вызова» (Minimum Recall), Soft Recall позволяет пропускать фазу, если на данном направлении нет транспорта, а на конфликтующих направлениях (боковых улицах) вызовы есть [7].

В современных системах, таких как ДК «СПЕКТР-II», этот режим настраивается в унифицированной конфигурации алгоритма (например, через параметр "recall": "SOFT") для обеспечения адаптивного управления и эффективного распределения зеленого времени в зависимости от реального спроса [9, 10].

Для настройки многокольцевого адаптивного управления в системах компании РИПАС (платформа «СПЕКТР» и МФУ) используется унифицированный перечень параметров, представленный в хорошо структурированном формате JSON [1, 2].

1. Единый стандарт и аппаратная независимость

Описание параметров алгоритма является аппаратно-независимым стандартом [3]. Это означает, что конфигурация многокольцевого управления (Multiring) не отличается для собственного контроллера «СПЕКТР-II» и стороннего оборудования, подключенного через МФУ (многофункциональное устройство) [4, 5]. МФУ выступает «мозгом» периферийного уровня, обеспечивая сквозную системную идеологию и бесшовность алгоритмов вне зависимости от конкретного вендора контроллера [4, 6].

2. Описание специфических параметров из вашего запроса

Приведенные вами параметры относятся к расширенным функциям адаптивного управления и приоритетного проезда, определенным открытыми стандартами (HCM2010 и NTCIP 1202) [2].

• PedestrianRecall (Пешеходный вызов): Параметр, который автоматически размещает запрос на обслуживание пешеходной фазы в каждом цикле, независимо от того, была ли нажата кнопка вызова. Это гарантирует включение интервалов Walk и Flashing Don't Walk (FDW) каждый раз, когда это безопасно [7, 8].
• timeSvcDes (Time Service Desired / Желаемое время обслуживания): Используется в модуле приоритета (priorityRequests) для указания расчетного времени (в секундах от начала цикла или иного референса), когда транспортному средству с приоритетом (например, трамваю) требуется разрешающий сигнал [9].
• timeEstDep (Time Estimated Departure / Оценочное время убытия): Прогноз времени, когда приоритетное транспортное средство полностью освободит перекресток (уйдет за стоп-линию), что позволяет системе своевременно завершить фазу приоритета и вернуться к обслуживанию других направлений [9, 10].
• LockTime (Время удержания/блокировки): В контексте запросов приоритета определяет время, в течение которого вызов удерживается в памяти контроллера, даже если сигнал от датчика (например, RFID-метки) пропал, что обеспечивает надежность обслуживания в зонах с неустойчивым приемом [9, 11].
• headway (Временной интервал/дистанция): Минимальный временной разрыв между транспортными средствами или последовательными запросами на приоритет, необходимый для принятия решения о продлении или завершении фазы [9, 12, 13].

3. Блок параметров координации (coordination)

Этот раздел описывает логику синхронизации контроллера с общегородским планом («зеленой волной»):

• longCorrection (17) / shortCorrection (12): Максимальное время (в секундах или процентах), на которое контроллер может удлинить или сократить текущий цикл за один шаг, чтобы войти в синхронизацию с центральными часами [14, 15].
• forceMode ("FLOATING"): Режим «плавающих» отсечек. При этом режиме неиспользованное зеленое время от любого не координируемого направления передается исключительно координируемой фазе (магистрали), а не следующей по очереди фазе [16-18].
• correctionMode ("SHORTWAY"): Режим «кратчайшего пути» (также известен как Smooth). Контроллер автоматически выбирает, что быстрее: добавить время к циклу или отнять его, чтобы максимально оперативно достичь нужного смещения (offset) [19-21].
• maximumMode ("MAX_INH" / Inhibit Max): Параметр «Запрет максимума». В режиме координации он заставляет контроллер игнорировать настройки максимального зеленого для фаз, позволяя им работать дольше (до достижения точки отсечки по расщеплению), если это необходимо для поддержания структуры цикла [12, 22-24].
• DWELL: Режим «ожидания» (dwell). Если этот режим активен, контроллер будет удерживать зеленый сигнал на координируемой фазе до тех пор, пока не наступит момент синхронизации с главным планом, после чего перейдет к обычному выполнению цикла [21, 25, 26].

Для изучения методической информации и практической настройки алгоритмов в формате JSON для ДК «Спектр-2», Вере Соколовой стоит придерживаться следующего системного подхода, опираясь на предоставленные источники:

1. Где искать методическую информацию?

Поскольку документация на конкретные ПАК может быть сжатой, фундаментальную логику параметров (таких как зазоры, типы вызовов и координация) следует изучать в национальных стандартах, которые легли в основу решений РИПАС:

• ПНСТ 894-2023 «Средства для обеспечения адаптивного управления светофорными объектами»: Это базовый документ, в котором закреплены классификации (критерии А, О, Л), терминология «активного многокольцевого управления» и требования к матрицам переходов [1-3].
• ГОСТ Р 71096—2023 «Подсистема светофорного управления»: Здесь описаны функциональные требования к адаптации программ и взаимодействию с ИТС [4, 5].
• Avenue 2.0 (Методики оптимизации): Онлайн-сервис и его документация помогут понять графо-аналитические методы расчета «зеленых волн» и пофазного разъезда, которые затем переносятся в JSON [6, 7].
• AveVide (Методический документ): Позволяет понять, как «читать» результаты работы алгоритма через инженерные метрики (задержки, LoS, очереди), что критично для тонкой настройки [8, 9].

2. С чего начать изучение «Примера конфигурации JSON ДК Спектр-2»?

Изучение JSON-конфигурации лучше всего разбить на логические блоки в порядке их приоритетности для безопасности и управления [10]:

1. Блок signalGroups (Сигнальные группы): Начните с определения типов групп (транспортные, пешеходные, стрелки) и их базовых параметров горения (мигание, желтый). Это фундамент физического уровня [10, 11].
2. Блок IGM (Intergreen Matrix / Матрица межзеленых): Это «предохранитель» системы. Изучите, как задаются задержки включения между конфликтующими группами. Согласно ПНСТ, ДК должен рассчитывать промтакты «на лету» именно на основе этой матрицы [12-14].
3. Блок MultiRing (Многокольцевое управление): Самый сложный и важный раздел.
   • Изучите phases (подфазы): какие группы в них входят и какие подфазы в других кольцах могут работать одновременно (concurrency) [15, 16].
   • Разберитесь с логикой Volume-Density через параметры passage (время проезда), minGap (мин. зазор) и timeToReduce. Эти параметры определяют, как контроллер «поджимает» фазу при наличии очереди на других направлениях [15, 17].
4. Блок coordination (Координация): Посмотрите, как задаются способы коррекции цикла (shortway, longCorrection) и режимы удержания фаз (forceMode), чтобы понять, как объект вписывается в сетевую «зеленую волну» [18, 19].

3. Рекомендация по практическому освоению

Лучший способ проверить понимание JSON — использовать технологию SITL/HITL (программно-аппаратное моделирование). Вера может запустить «пор тированную копию» своего JSON-конфига в виртуальной среде (например, в связке с SUMO), чтобы увидеть, как изменения параметров зазора или режима recall влияют на движение виртуальных машин в «песочнице», не рискуя безопасностью на реальном перекрестке [20-22].

Для глубокого понимания того, за что отвечает конкретный параметр, стоит обратиться к классическим руководствам по алгоритмам NTCIP 1202 или HCM2010, так как JSON «Спектра» является их современной унифицированной реализацией [23, 24].

Этот блокнот представляет собой комплексную базу знаний по проектированию, внедрению и эксплуатации интеллектуальных транспортных систем (ИТС) нового поколения. В его основе лежит концепция перехода от субъективного управления к доказательной инженерной аналитике на базе математически точного пополосного цифрового двойника (lane-level) [1, 2].

Вариант краткого описания:

«Экосистема ИТС: от цифрового двойника до адаптивного управления и V2X»

Данный ресурс объединяет техническую документацию, методические пособия и стратегические материалы по ключевым компонентам современной цифровой дорожной инфраструктуры:

• Аналитика и мониторинг: Методология работы с сервисом AveVide для измерения реальных параметров потоков на основе треков ТС и расчета KPI [3-5].
• Моделирование и оптимизация: Инструкции по использованию Avenue 2.0 для расчета светофорных циклов и создания «зеленых волн», а также инструмента OSMPIE для высокоточного краудмаппинга дорожной сети [6-8].
• Управляющее оборудование: Технические характеристики и сценарии применения контроллеров «СПЕКТР-II» и МФУ, обеспечивающих адаптивность по направлениям и интеграцию стороннего оборудования через протокол «Сигнал-2» [9-11].
• Стандарты и compliance: Полное соответствие и классификация решений согласно актуальным национальным стандартам ГОСТ Р 71096—2023 и ПНСТ 894-2023 [12-14].
• Стратегическое развитие: Подходы к построению открытых платформ с расширяемым API, внедрению V2X-сервисов и реализации приоритета для транспорта в сложных условиях (РЭБ, RFID, BLE) [15-17].

Блокнот предназначен для инженеров АСУДД, транспортных аналитиков и ЛПР, стремящихся внедрять измеримые и эффективные решения в сфере организации дорожного движения.

Для того чтобы транспортный инженер мог полноценно освоить конфигурирование дорожных контроллеров серии «СПЕКТР» (в частности, «Спектр-II») и интеграцию их в современные ИТС, рекомендуется изучить следующие материалы.

Логика конфигурирования «Спектра» в формате JSON базируется на открытых международных стандартах (NTCIP 1202, HCM), немецких методиках (RiLSA) и новых российских стандартах (ПНСТ 894-2023, ГОСТ Р 71096—2023), что делает систему аппаратно-независимой и расширяемой [1-3].

Источники для освоения конфигурирования ДК «СПЕКТР»

С чего начать («Roadmap»):

1. Просмотреть презентацию «Спектр-II» [23], чтобы понять архитектуру (Linux, JavaScript-скрипты, многокольцевое управление) [1, 24].
2. Изучить пример JSON-файла [4], сопоставляя его блоки с параметрами из FHWA Signal Timing Manual (Главы 5 и 6) [25, 26].
3. Освоить логику матриц межзеленых (IGM) по ПНСТ 894-2023 [27] или RiLSA [12], так как это фундамент безопасности в контроллере.
4. Попробовать технологию SITL/HITL (виртуальный контроллер) для отладки своего JSON-конфига в «песочнице» SUMO перед выездом на объект [28, 29].

Для реализации приоритетного проезда в АСУДД «Спектр» используются унифицированные программные сущности, что позволяет системе работать одновременно по разным архитектурным принципам.

Сущности, отвечающие за вызов и продление приоритета

В зависимости от выбранной архитектуры, за логику принятия решения отвечают следующие компоненты:

1. Децентрализованный принцип (Локальный приоритет):

   • Бортовое устройство (OBU): Выступает в роли генератора запросов (Request Generator), передавая данные о местоположении и статусе ТС [1, 2].
   • Придорожный блок (RSU) или контроллер: Выступают в роли сервера запросов (Request Server) [2, 3].
   • Дорожный контроллер (ДК) или МФУ: Непосредственно принимают решение о вызове (call) или продлении (extend) фазы на основе «активирующего события» (actuation) [4, 5]. В этой схеме ДК «Спектр-II» (или МФУ, выступающее как «мозг» для старого контроллера) самостоятельно обрабатывает запрос в режиме реального времени [6-8].

2. Централизованный принцип:

   • Управляющий центр (Сервис приоритета АСУДД): Получает телематику от транспорта (например, через LTE/ГЛОНАСС), сопоставляет её с цифровым двойником УДС (lane-level) и определяет момент пересечения виртуального детектора [9-11].
   • Центральное ПО: Формирует и передает прямую команду на включение или удержание конкретной фазы/направления в дорожный контроллер [10, 12].

Изменения в конфигурации для работы по LTE и V2X

Согласно технической документации, логика работы самого ДК однотипна вне зависимости от канала связи [13]. Архитектура «Спектра» построена на унифицированных сущностях, что позволяет реализовать гибридные сценарии [14, 15].

Необходимость изменений: Прямой необходимости переписывать алгоритм нет, так как параметры приоритета в JSON-конфигурации (блок priorityRequests) являются аппаратно-независимым стандартом [15, 16]. Однако для обеспечения работы через LTE (через центр) необходимо выполнить следующие настройки в конфигурационном файле:

• Блок sensors: Должны быть описаны идентификаторы датчиков (например, prio.442), которые будут служить «триггерами» для системы [17, 18]. При работе по LTE центр управления будет программно активировать эти сенсоры через API.
• Блок MultiRing -> priorityRequests: Здесь прописывается связь между конкретным сенсором и действиями контроллера (какие фазы вызвать, какие отменить — omits, и временные параметры — timeSvcDes, timeEstDep) [18, 19].
• Блок Priority: Если используется внешний сервер приоритета, в конфигурации указывается его URL и соответствующие каналы (например, tcp://192.168.9.31:9337) [20].

Итог: Для системы «Спектр» переход с V2X на LTE (или их совместное использование) требует лишь правильной привязки внешнего источника данных к внутренним логическим сенсорам в JSON-конфигурации. Это позволяет ДК получать команды от центра (по LTE) точно так же, как он получает их от RSU (по V2X), сохраняя единый алгоритм обработки приоритета [13, 21, 22].

На основе представленных документов («РО АСУДД 2026.pdf», «СПРАВКА (7).docx») и методического разбора аналогичных текстов, можно сделать вывод, что предлагаемая система «КОМПАС» на текущий момент представляет собой классическую проприетарную АСУДД «коробочного» типа, во многом опирающуюся на академические описания, в то время как решения компании РИПАС (платформа «СПЕКТР», МФУ, цифровой двойник) предлагают переход к открытой экосистеме ИТС, основанной на измеримых данных и унификации.

Ниже представлена рецензия-сравнение и ответы на вопросы, которые остались без внимания со стороны поставщиков «КОМПАС».

Рецензия: АСУДД «КОМПАС» vs Экосистема «СПЕКТР»

1. Методологический разрыв: «Учебник» против «Инженерии»

Описание алгоритмов «КОМПАС» (MPC, Reinforcement Learning (RL), MAXBAND) выглядит как компиляция из научных статей без привязки к архитектуре реализации [1, 2]. Например, заявленное использование глубокого обучения с подкреплением (RL) является типичным «маркетинговым слоем»: в документах отсутствует схема обучения, источники данных и сценарии безопасного применения [3, 4].

• Альтернатива РИПАС: Вместо «черного ящика» RL предлагается доказательная инженерия. Использование AveVide позволяет перейти от субъективного «кажется, пробка» к точным метрикам (задержки, LoS, очереди) на основе реальных треков ТС [5, 6].

2. Закрытость против Открытости (API и Интеграция)

Документация «КОМПАС» маркирована как «для ограниченного пользования» [7], что характерно для закрытых систем. В руководстве оператора отсутствуют упоминания о структурированном API для внешних разработчиков.

• Альтернатива РИПАС: Платформа «СПЕКТР» изначально строится как «ЛЕГО для ИТС» [8]. Внедрен механизм открытого API (OpenAPI/Swagger) и единая аутентификация на JWT-токенах [9]. Это позволяет региону не зависеть от одного вендора и строить над ядром любые прикладные сервисы [8, 10].

3. Модель данных: Статика против Цифрового двойника

В «КОМПАС» управление описывается через выбор планов и зон [11]. Нет упоминания о пополосной модели УДС.

• Альтернатива РИПАС: Фундаментом системы является Lane-level цифровой двойник (инструменты OSMPIE, Net329Edit) [9, 12]. Это не просто карта, а математически точная модель, которая используется и для генерации V2X сообщений (MAPEM), и для микромоделирования в виртуальной среде (SITL/HITL) [13-15].

Ответы на вопросы к АСУДД (сравнение возможностей)

Резюме для ЛПР

Система «КОМПАС» на основе представленных документов выглядит как АСУДД прошлого поколения (2.0) [30]. Она предлагает набор жестких инструментов в закрытой оболочке.

Решение компании РИПАС — это устойчивая основа ИТС (4.0), которая:

1. Унифицирует «зоопарк» через МФУ и протокол «Сигнал-2» [29, 31].
2. Гарантирует безопасность через динамический расчет матриц InterGreen (согласно ГОСТ Р 71096—2023) [32, 33].
3. Обеспечивает масштабируемость за счет открытых API и lane-level моделирования [8, 34].

Выбор «КОМПАС» несет риск попадания в зависимость от одного поставщика без возможности объективной проверки эффективности внедряемых алгоритмов.

Преимущества унификации алгоритмов, использования многокольцевого управления и матриц межзеленых интервалов (IGM) по сравнению с контроллерами интервального типа (которые лежат в основе системы «Компас») заключаются в переходе от жесткой, предопределенной логики к динамическому адаптивному регулированию, ориентированному на реальную безопасность и пропускную способность.

Согласно современным национальным стандартам (ГОСТ Р 71096-2023 и ПНСТ 894-2023), использование контроллеров интервального типа для реализации адаптивного управления (АУ) не рекомендуется [1, 2].

1. Эффективность: Многокольцевое управление vs Интервальный тип

• Контроллеры интервального типа (КОМПАС): Реализуют цикл как «предопределенную последовательность дискретных шагов» [3]. Это ограничивает гибкость: для изменения логики нужно перекраивать всю последовательность интервалов.
• Многокольцевое управление (РИПАС/СПЕКТР): Позволяет управлять каждым направлением (подфазой) независимо в рамках параллельных «колец» [4, 5].
  • Преимущество: Система может продлевать «зеленый» только для тех направлений, где есть спрос, и мгновенно переходить к обслуживанию других вызовов, не дожидаясь окончания фиксированного «шага» всего перекрестка [6, 7]. Это исключает «пустое» время (slack time) и максимизирует пропускную способность [8].

2. Безопасность: Матрицы Intergreen vs Фиксированные такты

• Интервальный тип: Промежуточные такты (промтакты) задаются жестко в сигнальном плане [9]. Если система пропускает какой-то интервал в адаптивном режиме, возникает риск нарушения безопасности переходов.
• Матрицы переходов (IGM): Описывают задержки включения для каждой пары сигнальных групп на основе их реальной геометрии (методика RiLSA) [10, 11].
  • Преимущество: Контроллер рассчитывает безопасный промтакт «на лету» для любой комбинации переключаемых групп [12, 13]. Это гарантирует, что конфликтные потоки никогда не встретятся, даже при самых сложных и непредсказуемых сменах фаз в адаптивном режиме [14, 15].

3. Унификация и открытость vs Проприетарность

• Система КОМПАС: Оперирует конфигурациями интервального типа, что характерно для АСУДД прошлого поколения (2.0) [16]. Такие системы часто закрыты и сложны в интеграции с внешними сервисами [17].
• Унифицированный подход (РИПАС): Использование JSON-конфигураций и протокола «Сигнал-2» позволяет отделить логику управления от «железа» [17, 18].
  • Преимущество: Благодаря МФУ (многофункциональному устройству), даже старый или «слабый» контроллер интервального типа (включая продукцию, используемую в «Компас») может быть наделен системными свойствами современного АДК: адаптивностью по направлениям, V2X-сервисами и активным приоритетом [17, 19, 20].

4. Готовность к инновациям (V2X и Приоритет)

• Для работы сервисов подключенного транспорта (V2X) контроллер должен генерировать сообщения SPaT (прогнозы сигналов) и MAP (топология) [21, 22].
• Преимущество унификации: Интервальные контроллеры не могут эффективно транслировать пополосную топологию, так как их логика не оперирует направлениями [2]. Многокольцевые системы изначально построены на пополосном представлении УДС (lane-level), что делает их фундаментом для беспилотного транспорта [23, 24].

Сводная таблица сравнения:

Итог: Унификация и переход к многокольцевому управлению позволяют создать «ЛЕГО для ИТС» — открытую систему, где эффективность подтверждается не маркетинговыми заявлениями, а точными инженерными метриками (AveVide) и математически обоснованной безопасностью [29, 30].

Ниже представлен перечень из 18 контрольных вопросов, разработанный для лиц, принимающих решения (ЛПР), при выборе технологического стека ИТС. Вопросы составлены на стыке архитектурных требований документа «Платформа vs. Монолит», национальных стандартов (ГОСТ Р 71096—2023, ПНСТ 894-2023) и практического опыта внедрения систем «СПЕКТР» и «AveVide».

I. Архитектура и интеграционный потенциал (Борьба с монолитом)

1. Наличие открытой спецификации API: Предоставляет ли система единую спецификацию Swagger/OpenAPI для всех функций управления, доступную внешним разработчикам для создания прикладных сервисов? [1, 2]
2. Механизм аутентификации: Поддерживает ли платформа единую систему авторизации на базе JWT-токенов или OAuth2, позволяющую безопасно подключать сторонние микросервисы к ядру ИТС? [3, 4]
3. Событийная модель (Pub/Sub): Позволяет ли система подписываться на события (webhooks, WebSocket) в реальном времени (например, срабатывание детектора или смена фазы), или данные доступны только через ресурсозатратный «ручной» опрос (REST-polling)? [1, 5]
4. Модульность и контейнеризация: Можно ли разворачивать отдельные подсистемы (адаптивка, мониторинг, V2X) независимо от ядра (например, в Docker-контейнерах), или система представляет собой неделимый программный «монолит»? [3, 6]

II. Уровень полевого оборудования и логики управления

1. Тип организации цикла: Соответствует ли логика дорожного контроллера (ДК) критерию О3 (активное многокольцевое управление по направлениям), или она ограничена устаревшим интервальным/фазным типом (О1/О2)? [7-9]
2. Безопасность промежуточных тактов: Реализует ли ДК динамическое формирование промтактов на основе полных матриц переходов (Intergreen Matrix) по методике RiLSA «на лету», что исключает ошибки проектировщика при сложных сменах фаз? [10-12]
3. Унификация «зоопарка» вендоров: Позволяет ли система интегрировать ДК сторонних производителей через МФУ-адаптеры и открытый протокол «Сигнал-2», наделяя их единой логикой адаптивного управления без физического демонтажа? [11, 13, 14]
4. Пользовательская логика (скрипты): Имеет ли инженер возможность задать произвольный сценарий управления на объекте (критерий Л2) с помощью общеприменимого языка (например, JavaScript), не обращаясь к вендору за перепрошивкой? [15-17]

III. Данные и цифровой двойник

1. Детализация модели УДС: Базируется ли система на пополосном цифровом двойнике (lane-level) с топологической связностью, или используется упрощенная «навигационная» карта? [4, 18, 19]
2. Доказательная аналитика потоков: Использует ли система для оценки эффективности реальные треки транспортных средств (мапмэтчинг ГЛОНАСС/GPS к полосам), позволяя измерять задержки и LoS по каждому направлению, а не только «среднюю скорость»? [18, 20, 21]
3. Историзированные реестры: Ведется ли в системе история изменений параметров оборудования и ОДД (версионирование), позволяющая провести аудит состояния ИТС на любую дату в прошлом? [22]
4. Экспорт в открытых стандартах: Можно ли выгрузить модель УДС и данные о потоках в стандартных форматах (GeoJSON, CSV, Net329), пригодных для использования в стороннем ПО для моделирования (Avenue, SUMO)? [3, 23]

IV. Перспективные технологии и надежность

1. Виртуальное моделирование (SITL/HITL): Позволяет ли система запустить точную алгоритмическую копию ДК в виртуальной среде имитационного моделирования для безопасной отладки адаптивных планов перед их внедрением в «железе»? [24-26]
2. Готовность к V2X: Способен ли контроллер нативно генерировать машиночитаемые сообщения MAPEM (топология) и SPATEM (прогнозы сигналов) для подключенного и беспилотного транспорта? [27, 28]
3. Устойчивость к подавлению сигнала (РЭБ): Как реализован приоритетный проезд спецтранспорта в условиях отсутствия спутникового сигнала — поддерживает ли система технологии RFID или BLE-маяков? [29, 30]
4. Активный приоритет: Реализована ли логика активного приоритета (вызов/продление фазы на основе запроса ТС), или система ограничивается лишь «пассивными» зелеными волнами? [31-33]
5. Диагностика и Fallback: Предусмотрено ли автоматическое переключение ДК в безопасный фиксированный режим при отказе тактических детекторов в адаптивном цикле? [34, 35]
6. Экосистема сторонних решений: Сколько внешних интеграторов реально разработали и внедрили свои модули на базе API данной платформы? [36, 37]

Критерий оценки для ЛПР: Если на 50% и более вопросов получен ответ «нет» или «это закрытая информация», значит, вам предлагают проприетарный монолит, который создаст технологическую зависимость региона от одного поставщика на годы вперед. [37, 38]

Экономические последствия выбора закрытого монолита вместо открытой ИТС-платформы проявляются в росте совокупной стоимости владения, снижении эффективности транспортной сети и потере ценности накопленных данных.

1. Технологическая зависимость и стоимость интеграции (Vendor Lock-in)

• Монополия вендора: Выбор закрытой системы создает «жёсткую зависимость» от аппаратного обеспечения конкретного производителя [1, 2].
• Скрытые расходы на доработки: В монолитах отсутствие открытых спецификаций API (Swagger/OpenAPI) и SDK превращает систему в «черную дыру» для данных, что делает любую последующую интеграцию с внешними сервисами крайне дорогой или технически невозможной [3, 4].
• Отсутствие модульности: В отличие от платформенного подхода («ЛЕГО для ИТС»), где можно докупать только нужные модули, в монолите для добавления одной функции (например, приоритета или V2X) часто требуется полная переработка или замена всей системы [5].

2. Снижение операционной эффективности и пропускной способности

• Потери времени: Закрытые системы часто используют устаревшую логику интервального управления, которая не позволяет перераспределять неиспользуемое зеленое время между направлениями [6, 7].
• Экономический ущерб от пробок: Неэффективная координация («зеленая волна») ведет к росту задержек, что напрямую конвертируется в макроэкономические потери, измеряемые миллионами человеко-часов [8, 9].
• Затраты на перенастройку: Стоимость оптимизации одного перекрестка вручную составляет от 2500 до 3100 долларов за каждое обновление; закрытые системы, лишенные автоматизированной аналитики потоков (как AveVide), требуют этих затрат регулярно [10].

3. Социально-экономические издержки и безопасность

• Риски ДТП: Неправильно настроенные переходные интервалы в закрытых системах (без использования динамических матриц Intergreen) повышают вероятность аварий [11, 12].
• Стоимость аварийности: Экономические потери от одного серьезного ДТП могут значительно превышать всю сомнительную экономию на покупке дешевого «закрытого» контроллера [11].
• Баланс эффективности и безопасности: В современных платформах соотношение «безопасность/эффективность» оценивается в денежном эквиваленте как «общественные выгоды/затраты», что невозможно реализовать в закрытом монолите [13].

4. Деградация «цифрового актива»

• Потеря данных: Закрытые системы скрывают накопленные данные внутри себя, не позволяя использовать их для научного анализа, планирования ОДД или создания цифровых двойников региона [3, 14].
• Отсутствие будущего: Устаревшие системы не обеспечивают «строительных блоков» для внедрения беспилотного транспорта и V2X, что потребует полной замены инфраструктуры в ближайшем будущем [15, 16].
• Ценность модели: Открытая платформа формирует высокоточный цифровой двойник (lane-level), который сам по себе является ценным активом для города, позволяя, например, автоматизировать оформление ДТП через Госуслуги [17, 18].

Итог: Экономия на начальном этапе при покупке закрытого монолита оборачивается кратным ростом затрат на эксплуатацию, невозможностью развития и прямыми убытками для экономики города из-за пробок и аварийности [3, 11, 19].

Переход от проприетарной монолитной АСУДД к открытой платформе предоставляет городу и оператору ИТС ряд стратегических, технологических и экономических преимуществ, превращая систему из «черного ящика» в гибкую экосистему.

1. Устранение зависимости от вендора (Vendor Lock-in)

Монолитные системы создают жесткую зависимость от конкретного производителя аппаратного обеспечения, что ограничивает развитие ИТС темпами и бюджетами одного поставщика [1]. Открытая платформа использует унифицированные протоколы (например, «Сигнал-2») и многофункциональные устройства-адаптеры (МФУ), что позволяет объединять в единую сеть «зоопарк» контроллеров разных вендоров без их демонтажа [2-4]. Это обеспечивает мультивенодорность и позволяет выбирать лучшее оборудование под конкретные задачи [4, 5].

2. Модульность и масштабируемость («ЛЕГО для ИТС»)

В отличие от монолита, где любая доработка требует переписывания всей системы, платформа строится по принципу модульности [3].

• Гибкое расширение: Новые функции (адаптивка, приоритет, V2X) добавляются как независимые блоки без вмешательства в ядро [5, 6].
• Микросервисная архитектура: Платформа поддерживает развертывание подсистем в контейнерах и использование единых механизмов аутентификации на базе JWT-токенов [7-9].

3. Открытость данных и API

Открытая платформа предоставляет документированные OpenAPI (Swagger), позволяя сторонним разработчикам создавать прикладные сервисы («для людей» и «для систем») над общим ядром [7, 8, 10, 11].

• Единый источник правды: Все подсистемы работают с общим пополосным цифровым двойником (lane-level), что гарантирует консистентность данных для навигации, моделирования и управления [5, 8, 12].
• Обмен данными: Информация не уходит в «черную дыру» монолита, а доступна для научных исследований и интеграции с внешними системами (РНИС, Госуслуги) [7, 9, 13].

4. Переход к доказательной инженерной аналитике

Монолитные системы часто оперируют субъективными понятиями, в то время как платформа внедряет измеримые метрики эффективности:

• Аналитика по трекам: Использование сервиса AveVide позволяет перейти от догадок к точным цифрам задержек, очередей и уровня обслуживания (LoS) на основе реальных данных ГЛОНАСС/GPS [14-17].
• Обратная связь: Инструменты вроде ATSPM (диаграммы Purdue) дают инженерам объективную картину того, как светофорные циклы соответствуют реальному трафику [2, 18].

5. Безопасность и инновации (V2X, БАС)

Открытые платформы изначально проектируются с учетом требований будущего:

• Поддержка V2X: Контроллеры платформы нативно генерируют сообщения MAPEM (топология) и SPATEM (прогнозы сигналов) для подключенного и беспилотного транспорта [19-21].
• Виртуальное моделирование (SITL/HITL): Платформа позволяет запустить точную алгоритмическую копию контроллера в симуляторе (SUMO) для безопасной отладки адаптивных алгоритмов в «песочнице» перед их внедрением на реальных улицах [22-25].
• Математическая безопасность: Использование матриц межзеленых интервалов (Intergreen Matrix) и динамический расчет промтактов «на лету» исключают человеческую ошибку проектировщика [18, 26-28].

Итог: Переход к открытой платформе превращает ИТС из набора разрозненных светофоров в устойчивый цифровой актив региона, который легко масштабируется, поддается объективному контролю и готов к внедрению технологий автономного транспорта [29-31].

Этот блокнот представляет собой всеобъемлющую базу знаний по интеллектуальным транспортным системам (ИТС), охватывающую теорию, нормативную базу и практические инструменты проектирования цифровой дорожной инфраструктуры.

Основные темы и разделы

• Аналитика и мониторинг потоков: Методология работы с сервисом AveVide для измерения задержек, очередей и уровней обслуживания (LoS) на основе реальных треков ТС [1-4].
• Моделирование и оптимизация ОДД: Инструменты Avenue 2.0 для расчета светофорных циклов и создания «зеленых волн», а также OSMPIE для высокоточного пополосного картирования (lane-level) [5-8].
• Управляющее оборудование и алгоритмы: Технические характеристики контроллеров «СПЕКТР-II» и многофункциональных устройств (МФУ), описание многокольцевого адаптивного управления и матриц межзеленых интервалов (IGM) [9-13].
• Стандарты и Compliance: Национальные стандарты России (ГОСТ Р 71096—2023, ПНСТ 894-2023) и международные руководства (RiLSA, HCM, FHWA) [14-18].
• Архитектурная стратегия: Чек-листы для выбора между открытыми платформами и закрытыми монолитами, требования к OpenAPI (Swagger) и интеграции систем [19-21].
• Инновационные сервисы: Реализация V2X (сообщения MAPEM/SPATEM), приоритетного проезда (проект «Чижик») и работа в условиях подавления спутникового сигнала (РЭБ) [22-25].

Загруженные источники

1. Методические и учебные пособия: Разбор инструментов AveVide, Avenue 2.0 и OSMPIE [1, 5, 6].
2. Государственные стандарты (ГОСТ/ПНСТ): Официальные требования РФ к подсистемам светофорного управления и адаптивным ДК [17, 18].
3. Международные отраслевые руководства: Немецкие правила RiLSA и американские руководства FHWA/NCHRP по проектированию сигнальных планов [14, 26-28].
4. Техническая документация и примеры: Конфигурационные JSON-файлы контроллера Спектр-2, руководства операторов АСУДД («Компас», «Спектр») [29-31].
5. Стратегические и аналитические материалы: Презентации по развитию ИТС, чек-лист «Платформа vs. Монолит» и инженерный разбор качества алгоритмов различных систем [20, 32, 33].

Язык материалов

Материалы в блокноте представлены на двух основных языках:

• Русский: Государственные стандарты РФ, презентации по развитию ИТС МО, руководства пользователя и методики AveVide [1, 17, 18, 32].
• Английский: Международные стандарты (FHWA, NTCIP), перевод немецких правил RiLSA, руководства к ПО (VisVAP) и документация OSMPIE [14, 27, 28, 34-36].
• Встречаются также фрагменты на немецком (оригинальные названия RiLSA и статьи в Wikipedia) [37-39].

Для принятия обоснованного решения при выборе технологического фундамента ИТС Московской области ниже представлено прямое сопоставление открытой платформы СПЕКТР (РИПАС) и проприетарной системы КОМПАС. Сравнение базируется на архитектурных требованиях ГОСТ Р 71096—2023, ПНСТ 894-2023 и чек-листе «Платформа vs. Монолит».

1. Архитектурная философия: Экосистема vs. Монолит

• СПЕКТР (РИПАС): Построен как открытая ИТС-платформа (Lego-подход) [1]. Система отделяет логику управления от «железа», предоставляя документированный OpenAPI (Swagger) и единую аутентификацию на базе JWT-токенов [2-4]. Это позволяет бесшовно интегрировать сторонние модули, навигационные сервисы и внешние системы (РНИС, Госуслуги) [1, 5].
• КОМПАС: Классическая АСУДД 2.0 (Монолит) [6]. Система закрыта, документация имеет гриф «для ограниченного пользования» [7]. Программный интерфейс (API) для внешних разработчиков не описан, что создает риск «вендор-лока» (полной зависимости от одного поставщика) [8, 9].

2. Логика управления: Многокольцевое АУ vs. Интервальный тип

• СПЕКТР (РИПАС): Реализует активное многокольцевое управление (criteria О3) [10, 11]. Контроллер оперирует направлениями движения (подфазами), а не жесткими интервалами. Это позволяет системе мгновенно реагировать на разрывы в потоке, перераспределяя «зеленый» в реальном времени [12, 13]. Промтакты рассчитываются динамически на основе матриц Intergreen (IGM) по методике RiLSA, что гарантирует математически обоснованную безопасность [14-16].
• КОМПАС: Оперирует интервальной логикой (criteria О1), характерной для технологий 1980-х [17, 18]. Цикл — это жесткая последовательность шагов [19]. Согласно ПНСТ 894-2023, контроллеры интервального типа не рекомендуются для адаптивного управления, так как они не обладают гибкостью современной адаптивки [20, 21]. Безопасность переходов зависит от ручного ввода проектировщика, а не от динамического расчета [15].

3. Инновации и V2X: Реальность vs. Маркетинг

• СПЕКТР (РИПАС): Нативно поддерживает сервисы V2X (Vehicle-to-Everything) [22, 23]. Контроллер генерирует машиночитаемые сообщения MAPEM (пополосная топология) и SPATEM (прогнозы сигналов) [24-26]. Система проверена интеграторами в реальных проектах (например, «Чижик»), обеспечивая активный приоритет через RFID, V2X и BLE-маяки (защита от РЭБ) [27-29].
• КОМПАС: Заявляет об использовании Глубокого обучения с подкреплением (RL) и Model Predictive Control (MPC) [30, 31]. Однако инженерный разбор показывает отсутствие архитектуры внедрения ИИ, данных для обучения и сценариев безопасности [32, 33]. Поддержка V2X и генерация MAP/SPaT в документации детально не описаны [8].

4. Модель данных и аналитика эффективности

• СПЕКТР (РИПАС): Базируется на цифровом двойнике УДС (lane-level) [34, 35]. Для оценки эффективности используется комплекс AveVide, который на основе реальных треков ТС (ГЛОНАСС/GPS) измеряет задержки, очереди и уровень обслуживания (LoS) по каждому направлению [36-38]. Это переход к доказательной инженерии [39, 40].
• КОМПАС: Оперирует упрощенными зонами и планами [41, 42]. В документации отсутствуют инструменты анализа трековой микро-аналитики и калибровки потоков насыщения [6, 43]. Эффективность работы алгоритмов остается «черным ящиком» для заказчика.

5. Интеграция «зоопарка» оборудования

• СПЕКТР (РИПАС): Решает проблему разнородного оборудования через МФУ (многофункциональное устройство) и открытый протокол «Сигнал-2» [11, 44, 45]. Это позволяет наделить старые или «слабые» контроллеры (в т.ч. «Сигнал», «Синтез») интеллектом современной адаптивки и V2X без их физического демонтажа [44, 45].
• КОМПАС: Подключение сторонних ДК в документации не раскрыто. Прямые вопросы о совместимости с другими вендорами остались без ответа поставщика [вопрос №7]. Вероятнее всего, интеграция ограничена базовой телемеханикой [8, 18].

Сводная таблица сравнения

Резюме для ЛПР: Система СПЕКТР — это промышленный стандарт ИТС нового поколения, обеспечивающий региону независимость от вендора и измеримый результат. КОМПАС — классическая АСУДД прошлого, скрывающая технологическое отставание за академическими терминами без конкретики реализации.

Формирование матрицы межзеленых интервалов (IGM — Intergreen Matrix) основывается на требованиях безопасности, изложенных в немецком руководстве RiLSA (редакции 1992/2003), и переносится в конфигурацию дорожного контроллера в виде структурированного набора данных для расчета безопасных переходов между конфликтующими потоками.

1. Формирование IGM по методике RiLSA

Согласно RiLSA, межзеленый интервал ($t_z$) — это время между окончанием зеленого сигнала для одного потока и началом зеленого сигнала для следующего, конфликтующего с ним потока [1]. Кратчайший необходимый интервал рассчитывается по формуле:

$t_z = t_ü + t_r - t_e$ [2], где:

• $t_ü$ (Crossing time / Время пересечения): интервал между концом зеленого сигнала и началом времени очистки [3]. Для легковых автомобилей при движении прямо принимается равным 3 секундам, для поворачивающих — 2 секундам, для велосипедистов — 1 секунде, для пешеходов — 0 секунд [4-7].
• $t_r$ (Clearance time / Время очистки): время, необходимое участнику движения для прохождения пути очистки ($s_r$) с расчетной скоростью ($v_r$) [4].
  • Путь очистки ($s_r$) включает расстояние от стоп-линии до конфликтной точки ($s_o$) и фиктивную длину транспортного средства ($l_{Fz}$) [8].
  • Фиктивная длина: для автомобилей — 6 м, для трамваев — 15 м, для велосипедов и пешеходов — 0 м [8-10].
  • Расчетная скорость очистки: для авто прямо — 10 м/с, для поворотов — 7 м/с (или 5 м/с при малом радиусе), для пешеходов — 1,2 м/с [4, 5, 7].
• $t_e$ (Entering time / Время входа): время, необходимое вступающему в конфликтную зону потоку для достижения точки столкновения [1]. Если конфликтная зона начинается непосредственно у стоп-линии, время входа принимается равным нулю [9, 11].

Все рассчитанные значения для всех комбинаций конфликтующих потоков сводятся в единую матрицу межзеленых интервалов [2, 12].

2. Задание IGM в конфигурации дорожного контроллера

В современных контроллерах (например, «СПЕКТР-II») матрица IGM задается в формате JSON, что позволяет системе рассчитывать безопасные промежуточные такты (промтакты) «на лету» для любой комбинации переключаемых сигнальных групп [13-15].

В конфигурационном файле матрица описывается в блоке "IGM" и состоит из массива объектов "items" [16, 17]:

• clearing: ID сигнальной группы, которая заканчивает движение [16].
• entering: ID сигнальной группы, которая начинает движение [16].
• time: расчетное значение межзеленого интервала в секундах (например, 4.00, 8.00 или 10.00) [16-18].

Пример структуры в JSON:

{
  "clearing": 1,
  "entering": 5,
  "time": 8.00
}

В данном примере контроллер обеспечит задержку включения группы 5 на 8 секунд после выключения группы 1 [17].

Особенности задания в ПО:

1. Несколько матриц: В одной конфигурации может быть задано несколько матриц (например, для разных режимов разъезда или экспериментальные варианты) [16, 19].
2. Флаг безопасности: Одна из матриц может иметь атрибут "safety": true, что делает её приоритетной для контроля безопасности переключений [17].
3. Динамический расчет: Контроллер использует эти данные для автоматического формирования оптимальных переходных интервалов, что исключает ошибки «человеческого фактора» при ручном создании фаз и соответствует требованиям ПНСТ 894-2023 и ГОСТ Р 71096—2023 [14, 15, 20].

В контексте организации дорожного движения и светофорного регулирования, термин GAP (интервал) имеет несколько взаимосвязанных значений, касающихся времени или расстояния между транспортными средствами.

1. Основное определение

Gap (Интервал) — это временная или дистанционная сепарация между транспортными средствами [1, 2]. Технически это время, необходимое переднему бамперу второго из двух идущих друг за другом автомобилей, чтобы достичь заднего бампера первого автомобиля [1]. Важно отметить, что интервал (gap) всегда меньше, чем временная дистанция (headway), которая измеряется между одними и теми же точками автомобилей (например, между передними осями) [1, 3].

2. Применение в светофорном управлении

В работе дорожных контроллеров и алгоритмов АСУДД понятие «интервал» используется в следующих параметрах:

• Passage Time (Gap Time): Параметр, называемый также «временем проезда» или «временем расширения фазы» [4-6]. Он определяет максимальную допустимую длительность отсутствия вызовов от детекторов, в течение которой фаза будет оставаться зеленой [7, 8].
• Gap Out (Сброс по разрыву): Ситуация, когда фаза светофора завершается досрочно (до достижения максимума) из-за того, что временной разрыв между автомобилями в потоке превысил установленный порог (passage time) [1, 9, 10]. Это указывает на то, что поток стал разреженным и фазу можно эффективно завершить для обслуживания других направлений [4, 5].
• Gap Reduction (Снижение порога разрыва): Функция «плотности потока», которая постепенно уменьшает допустимый временной разрыв с течением времени действия зеленого сигнала [11-13]. Это позволяет системе становиться более «агрессивной» в поиске возможности для завершения фазы по мере роста задержек на конфликтующих направлениях [13, 14].
• Minimum Gap: Минимальное значение, до которого может быть уменьшен допустимый разрыв при использовании функции gap reduction [15-17]. Обычно оно устанавливается на уровне среднего интервала насыщения (около 2 секунд) [18, 19].

3. Применение в анализе и моделировании

• Gap Acceptance (Принятие интервала): Теория, на которой основан расчет пропускной способности нерегулируемых перекрестков и колец [20, 21]. Она описывает поведение водителя, который оценивает разрыв в конфликтующем потоке и решает, достаточно ли он велик для безопасного маневра [21, 22].
• Critical Gap (Критический интервал): Минимальный временной интервал в основном потоке, который позволяет транспортному средству с второстепенной дороги выехать на перекресток [22]. Более высокие значения этого фактора характерны для более консервативных водителей [23].

4. Оценка безопасности

• Gap time: Один из показателей тяжести конфликта [24]. Это промежуток времени между моментом, когда поворачивающее транспортное средство покидает зону конфликта, и моментом прибытия туда пересекающего его путь автомобиля (при условии сохранения их скоростей и траекторий) [24].

В одно кольцо (ring) включают направления движения, которые конфликтуют друг с другом и должны обслуживаться последовательно [1-3]. Основные правила формирования кольца включают следующие аспекты:

Основной принцип формирования

• Последовательность конфликтов: Кольцо представляет собой установленный порядок следующих друг за другом конфликтных фаз [1, 3]. Фазы внутри одного кольца не могут работать одновременно [2, 4, 5].
• Использование подфаз: Согласно российским стандартам (ГОСТ Р 71096-2023), кольцо — это заданная в сигнальном плане последовательность подфаз, каждая из которых управляет набором не конфликтующих между собой сигнальных групп [6-9].

Распределение направлений в стандартной схеме (8-фазный контроллер)

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

• Кольцо 1: Обычно включает в себя левый поворот с главной дороги, за которым следует встречное прямое направление, а затем аналогичная последовательность для второстепенной дороги (например, фазы 1, 2, 3 и 4) [10-12].
• Кольцо 2: Включает в себя комплементарные (совместимые) направления, которые могут работать одновременно с направлениями из первого кольца, но сами по себе также конфликтуют между собой (например, фазы 5, 6, 7 и 8) [10-12].

Ограничения и совместимость

• Стороны барьера: Направления с одной улицы (например, все движения по главной дороге) должны быть назначены на одну и ту же сторону барьера (линии совместимости) в обоих кольцах [11, 12]. Это гарантирует, что движения по пересекающимся улицам никогда не будут разрешены одновременно [13, 14].
• Совместимые движения: Направления, которые могут двигаться одновременно без конфликтов (например, попутный прямой поток и левый поворот встречного направления в определенных схемах), должны быть разнесены по разным кольцам, чтобы контроллер мог включать их параллельно [4, 10, 11, 15].
• Группировка в фазы: Неконфликтные потоки (например, прямой ход и правый поворот из той же или соседней полосы) могут быть объединены в одну фазу или сигнальную группу внутри кольца [16-18].

Специальные случаи

• Пофазный разъезд (Sequential Phasing): Если используется однокольцевая структура, то абсолютно все разрешенные движения на перекрестке включаются в это единственное кольцо и работают строго по очереди [5, 19].
• Многокольцевое управление: Современные контроллеры (например, «СПЕКТР») позволяют использовать более двух колец для гибкого управления сложными пересечениями, где направления распределяются по кольцам так, чтобы максимизировать количество одновременно работающих неконфликтных групп [20, 21].

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

1. [1]–[2] AveVide — методический документ: представляет собой логически связанную транскрибацию видеоуроков по работе с сервисом аналитики транспортных потоков, предназначенную для инженеров и аналитиков ИТС [1, 2].
2. [3]–[4] Alabama Traffic Signal Manual: официальное руководство штата Алабама, регламентирующее структуру планов светофорного регулирования, состав проектной документации и требования к оформлению чертежей [3-5].
3. [6]–[7] Balancing Safety and Capacity... (FHWA): отчет об исследовании (Фаза 1), посвященном поиску баланса между безопасностью и пропускной способностью в адаптивных системах управления [6, 8].
4. [9]–[8] DLR: Design of Signal Timing Plan...: технические публикации в Journal of Advanced Transportation, описывающие матрицы межзеленых интервалов и политику приоритета левых поворотов [8, 9].
5. [10]–[11] FGSV RiLSA (2003): немецкие рекомендации по светофорным объектам, содержащие примеры фазировки, расчеты циклов и перечень необходимых эксплуатационных документов [10-12].
6. [13]–[14] FGSV Translations Catalog: официальный каталог доступных английских переводов немецких стандартов и директив в области проектирования и эксплуатации дорог [13, 15].
7. [16] FHWA-HRT-24-121: документ, описывающий инструменты с открытым исходным кодом для обеспечения взаимодействия и связности систем на базе протоколов NTCIP и SAE [16].
8. [17]–[18] FHWA Adaptive Signal Control Performance Measures: руководство по оценке эффективности и валидации технологий адаптивного регулирования с детальным описанием метрик и полевых испытаний [17, 19].
9. [20]–[21] FHWA Regional Traffic Signal Operations Programs: обзорный документ по организации региональных программ эксплуатации светофоров и созданию совместных концепций управления (RCTO) [20-22].
10. [23]–[24], [25]–[26] FHWA Traffic Signal Program Handbook (2023): современное комплексное руководство по управлению светофорными программами, фокусирующееся на интеграции людей, процессов и технологий [27-29].
11. [30]–[31] FHWA Signal Timing Under Saturated Conditions (2008): исследовательский отчет, посвященный методам настройки светофорных циклов в условиях предельного насыщения транспортных потоков [30, 31].
12. [32]–[33] FHWA Traffic Signal Change and Clearance Interval (2023): синтетический отчет, обобщающий методы расчета желтого и красного интервалов, а также влияние законов на поведение водителей [32, 34].
13. [35]–[36] FHWA Traffic Signal Operations and Maintenance Staffing Guidelines: практические рекомендации по штатному расписанию и компетенциям персонала, необходимого для обслуживания светофорных систем [35, 37].
14. [38]–[39], [40]–[41] FHWA Traffic Signal Timing Manual (2008): классическое базовое руководство по принципам и процедурам настройки параметров светофорного регулирования [42, 43].
15. [44]–[45] German HBS Road Capacity Document: материалы и ссылки на немецкое руководство по пропускной способности дорог и оценке качества движения [44, 46].
16. [47]–[48] HCM Edition 7.1 Replacement Chapters: обновленные главы Highway Capacity Manual, содержащие методики анализа зон переплетения, слияния и разделения потоков на магистралях [47, 49].
17. [50]–[51] MUTCD Official Page: выдержки из официального американского стандарта по техническим средствам организации движения (знаки, разметка, сигналы) [50, 52].
18. [53]–[54] MnDOT Signals 101 Manual: учебное пособие штата Миннесота, вводящее в основы проектирования, обслуживания и заключения соглашений по светофорным объектам [53, 55].
19. [56]–[57] NCHRP Report 812 (STM2): второе издание руководства по настройке светофоров, акцентирующее внимание на результативном управлении и учете интересов всех участников движения [56, 58].
20. [59]–[60] RiLSA 1992: более раннее издание немецких норм (перевод 2003 года), содержащее фундаментальные принципы проектирования логики управления и требования к оборудованию [59, 61, 62].
21. [63]–[64] TEOPS Chapter 16 - Wisconsin DOT: раздел руководства штата Висконсин по анализу, операциям и безопасности движения, включая методики валидации моделей [63, 65].
22. [66]–[67] Traffic Signal Timing Guide (MnDOT/Scribd): методические материалы штата Миннесота по сбору данных и разработке планов координации [66, 68].
23. [69]–[70] FHWA Traffic Signal Timing Manual (Chapters 4, 6): отдельные разделы руководства FHWA, посвященные проектированию и параметрам тайминга [69, 70].
24. [71]–[72] VAP 216 User Manual (PTV AG): техническое руководство по языку программирования VAP, используемому для моделирования гибкой логики светофорного управления в среде Vissim [71, 73].
25. [74]–[75] Вставленный текст (Конфигурация JSON): пример реальной конфигурации дорожного контроллера для объекта в Санкт-Петербурге (пр. Наставников — пр. Энтузиастов) с описанием групп, фаз и детекторов [74, 76, 77].
26. [78]–[79] ГОСТ Р 71096-2023 — ПСУ: действующий российский стандарт, устанавливающий терминологию, классификацию и функциональные требования к подсистемам светофорного управления в рамках ИТС [78, 80].
27. [81]–[82] Дорожный контроллер — решения для V2X: презентация технических характеристик и веб-интерфейса контроллера «СПЕКТР-II», поддерживающего современные сервисы V2X и API [83-85].
28. [86]–[87] ПНСТ 894-2023 — АДК: предварительный российский стандарт на средства адаптивного управления, определяющий критерии масштабируемости, безопасности и поддержки языков программирования [86, 88, 89].
29. [90]–[91] План презентации «Развитие АСУДД МО»: стратегический документ, описывающий концепцию перехода к единой цифровой экосистеме управления транспортом Московской области на базе открытых API [90, 92].
30. [93]–[94] Практика приоритета трамвая «Чижик»: материалы по реализации адаптивного приоритета в Санкт-Петербурге, включая описание децентрализованной архитектуры и использования RFID [95-97].
31. [98]–[99] Развитие АСУДД МО 2026-2027: презентационные слайды, раскрывающие преимущества модульной архитектуры «СПЕКТР», интеграцию с V2X и цифровыми двойниками УДС [98, 100, 101].
32. [102]–[103] Чек-лист «Платформа vs Монолит»: методический инструмент для оценки степени открытости, масштабируемости и зрелости архитектуры ИТС-платформ [102, 104].

На основе представленных источников ниже приведены определения указанных параметров настройки светофорного регулирования:

• Мин Зелёный (Minimum Green) — это параметр, определяющий наименьшее время, в течение которого для данной фазы будет отображаться зеленый сигнал [1, 2]. Он устанавливается для того, чтобы водители успели среагировать на включение сигнала, а также чтобы стоящие между детектором и стоп-линией транспортные средства успели начать движение и частично пересечь перекресток [2, 3].
• Recall (Вызов) — функция контроллера, которая автоматически размещает запрос на обслуживание фазы в каждом цикле, независимо от того, обнаружен ли детектором транспорт или пешеход [4, 5].

В зависимости от выбранного режима вызова (recall) контроллер ведет себя следующим образом:

• Recall Min (Минимальный вызов) — контроллер автоматически включает фазу в каждом цикле и отрабатывает как минимум установленное время минимального зеленого [6, 7]. После истечения этого времени фаза может быть продлена при наличии реальных вызовов от детекторов или завершена, если есть запрос от конфликтующей фазы [6, 8]. Этот режим часто используется для главных направлений, чтобы гарантировать им зеленый свет в каждом цикле [4, 9].
• Recall Max (Максимальный вызов) — контроллер автоматически включает фазу в каждом цикле и удерживает зеленый сигнал в течение максимально допустимого времени (Maximum Green), даже если транспорт отсутствует [6, 10]. Этот режим фактически переводит светофор в режим жесткого (фиксированного) регулирования для данной фазы [9, 10]. Обычно применяется при неисправности детекторов или когда необходимо гарантированное максимальное время обслуживания [10, 11].
• None (Нет вызова) — автоматический вызов фазы отсутствует. Фаза будет включена только в том случае, если детектор обнаружит транспортное средство или пешеход нажмет кнопку вызова [12, 13]. Если запросов на обслуживание нет, такая фаза в текущем цикле будет пропущена [12].

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

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

1. Источник данных и логика работы

• Жёсткое расписание (Pretimed Control): Работает на основе исторических данных о транспортных потоках [1, 4]. Сигналы переключаются по заранее запрограммированному времени, которое не меняется в зависимости от того, есть на перекрёстке машины или нет [5, 6]. Как правило, такие программы сменяются по времени суток (например, «утренний пик», «ночь»), но внутри периода остаются неизменными [7, 8].
• Адаптивное управление (Adaptive Control): Основано на данных реального времени, получаемых от детекторов транспорта (датчиков, камер, телематики) [2, 9]. Система непрерывно анализирует текущий спрос и использует математические алгоритмы или прогностические модели для поиска оптимального решения «на лету» [10-12].

2. Гибкость параметров

• Жёсткое расписание: Имеет фиксированную длительность цикла, фаз и постоянные «сдвиги» (offsets) для координации с соседними светофорами [1, 13].
• Адаптивное управление: Может динамически изменять [12, 14]:
  • Длительность цикла (увеличивать его при росте нагрузки) [15, 16];
  • Расщепление (splits) — перераспределять зелёное время между направлениями в зависимости от очереди [17-19];
  • Смещение (offsets) — корректировать время начала «зелёной волны» для лучшего прохождения платонов машин [20, 21];
  • Последовательность фаз — пропускать фазы, на которых нет заявок, или менять их порядок для уменьшения задержек [17, 22].

3. Эффективность и использование ресурсов

• Жёсткое расписание: Часто приводит к «пустому» горению зелёного света, когда на одном направлении нет машин, а на другом стоят очереди [23, 24]. Однако оно дешевле в установке, так как не требует сложной системы детекторов [24-26].
• Адаптивное управление: Позволяет минимизировать задержки, сократить количество остановок и быстрее восстанавливать движение после инцидентов [10, 27, 28]. Оно эффективно распределяет «запас» пропускной способности перекрёстка, но требует значительных затрат на поддержание работоспособности датчиков и сложную настройку моделей [27, 29, 30].

4. Реакция на непредвиденные ситуации

• Жёсткое расписание: Не способно реагировать на кратковременные колебания трафика, ДТП или спецмероприятия, продолжая работать по шаблону [24, 31].
• Адаптивное управление: Может распознать всплеск задержек или падение скорости и оперативно скорректировать работу светофора, чтобы предотвратить образование затора [32-34].

Сводная таблица различий

Существует также промежуточный вариант — транспортно-зависимое (активное) управление, которое может продлевать фазу при наличии машин («gap-out logic»), но делает это в рамках жестко заданных рамок без полной системной оптимизации, характерной для «настоящего» адаптивного управления [37-39].

Многокольцевая (multi-ring) структура управления светофорными объектами является современным стандартом для обеспечения гибкости и эффективности регулирования, особенно в условиях адаптивного управления [1-3].

Когда стоит использовать многокольцевую структуру

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

• Сложные пересечения: Для перекрестков с пятью и более подходами или при необходимости использования более 9 фаз регулирования [4].
• Максимизация эффективности (устранение «slack time»): В отличие от однокольцевых (последовательных) систем, многокольцевая структура позволяет совместимым фазам в разных кольцах работать одновременно и завершаться независимо друг от друга в зависимости от спроса [2, 5]. Это исключает простои, когда одно направление уже пустое, а другое еще требует зеленого сигнала.
• Гибкое левоповоротное регулирование: При необходимости реализации схем с ведущими (leading), ведомыми (lagging) или ведуще-ведомыми (lead-lag) левыми поворотами [6-8]. Кольца позволяют независимо управлять каждой парой конфликтующих направлений.
• Адаптивное и транспортно-зависимое управление: Многокольцевая логика является основой для полностью актуализируемого управления (Full Actuated), где контроллер принимает решение о продлении или пропуске подфаз (phases) в реальном времени на основе данных детекторов [9-11].
• Групповое управление (один контроллер на несколько узлов): Для управления близко расположенными перекрестками (например, алмазные развязки) или сложными системами, где требуется жесткая синхронизация движений без использования классического механизма смещения (offset) [4, 12, 13]. Это позволяет избежать проблем «раннего выхода в зеленый» (early return to green) [13].
• Повторное обслуживание фаз (Phase Re-Service): Когда высокая интенсивность левого поворота требует его включения дважды за один цикл (например, в начале и в конце), что реализуется через перекрытия (overlaps) и многокольцевую логику [14, 15].

Когда использование нецелесообразно

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

• Простые перекрестки: Стандартные объекты с 2–4 фазами и простым пофазным разъездом [4, 16].
• Жесткие последовательные ограничения: Когда технология требует строгого чередования фаз без возможности их совмещения (однокольцевой режим) [17, 18].
• Стационарное (жесткое) регулирование: Если транспортные потоки стабильны и не требуют адаптации, использование многокольцевой логики не даст значимых преимуществ перед классическим фазным управлением [19, 20].
• Ограничения оборудования: Устаревшие контроллеры могут физически не поддерживать более двух колец или сложную логику барьеров [21, 22].

Метрики для определения целесообразности

Для выбора структуры управления инженеры используют следующий набор метрик и критериев:

1. Геометрические критерии:
   • Количество подходов (более 4) [4].
   • Наличие выделенных левоповоротных полос и допсекций [5, 16].
2. Операционные метрики (KPI):
   • Уровень обслуживания (LoS): Сравнение задержек при разных схемах фазирования [23, 24].
   • Степень насыщения (Utilization): Если направления имеют сильно различающуюся загрузку, кольца позволяют более эффективно перераспределять время [25, 26].
   • Доля остановившихся ТС и количество очередей: Метрики, указывающие на неэффективность текущего жесткого цикла [27, 28].
3. Пространственные критерии:
   • Расстояние между узлами: Если перекрестки находятся менее чем в 10 секундах пути (около 150 метров) друг от друга, рекомендуется их объединение под управление одного многокольцевого контроллера [29, 30].
4. Метрики безопасности:
   • Количество конфликтных точек: Анализ вероятности столкновений при совмещении фаз [31, 32].
   • Частота проездов на запрещающий сигнал: Косвенный признак раздражения водителей из-за избыточных задержек при неэффективном фазировании [33, 34].

Многокольцевое управление (часто реализуемое в логике Dual Ring) превосходит традиционное пофазное регулирование по нескольким ключевым параметрам, связанным с гибкостью и эффективностью использования пропускной способности перекрестка.

Основные преимущества многокольцевого управления:

• Максимальная эффективность и устранение «пустого» времени: В традиционном пофазном управлении все направления внутри фазы начинают и заканчивают движение одновременно. Многокольцевая структура позволяет независимо завершать и начинать неконфликтующие потоки [1, 2]. Это исключает ситуацию, когда одна полоса уже пуста, но зеленый свет продолжает гореть, потому что в той же фазе еще движутся машины на другом направлении [1].
• Гибкое совмещение совместимых потоков: Использование системы колец и барьеров позволяет любым неконфликтующим движениям (например, прямому направлению и встречному левому повороту) работать одновременно [3, 4]. Если в одном из колец спрос на движение исчерпан, контроллер может перейти к следующей подфазе в этом кольце, не прерывая совместимое движение в другом кольце [5, 6].
• Оптимальная работа с детекторами (активное управление): Многокольцевой метод является основой для полностью активного управления (Full Actuated) [7]. Контроллер в реальном времени реагирует на «разрывы» в потоке (gap-out), позволяя моментально передавать освободившееся время тем направлениям, где скопилась очередь [8, 9].
• Эффективность на сложных узлах: Пофазное управление рекомендуется только для простых объектов (Т-образные перекрестки, переходы без допсекций) [10]. Для перекрестков любой сложности многокольцевое управление позволяет реализовать такие эффективные схемы, как Lead-Lag (опережающий/задерживающий левый поворот), которые значительно расширяют пропускную способность магистральных «зеленых волн» [11-13].
• Соответствие современным стандартам ИТС: Согласно актуальным российским нормативам (ГОСТ Р 71096-2023 и ПНСТ 894-2023), использование многокольцевого принципа является предпочтительным для унификации алгоритмов адаптивного управления [14, 15]. Пофазное управление рассматривается в них лишь как частный случай многокольцевого (с одним кольцом) [15].

Резюме: Многокольцевое управление позволяет «выжимать» из геометрии перекрестка максимум, сокращая задержки за счет более точного распределения зеленого времени между конкретными полосами движения, а не общими фазами [2, 10].

Дорожный контроллер СПЕКТР (в частности, версия «СПЕКТР-II») обладает широкими возможностями для реализации многокольцевого управления, основанного на современных международных стандартах и открытой архитектуре [1, 2].

Возможности ДК СПЕКТР для многокольцевого управления

1. Активное управление по направлениям: В отличие от традиционных контроллеров, работающих строго по фазам (этапам), СПЕКТР реализует алгоритм управления отдельными регулируемыми направлениями [1, 3]. Это позволяет каждой подфазе (движению по конкретному направлению) иметь собственные временные параметры и активироваться по запросу от детекторов или кнопок независимо от других, если нет конфликтов [4, 5].
2. Гибкая структура колец и барьеров:
   • Алгоритм полностью соответствует концепциям HCM2010 и NTCIP [2].
   • Система позволяет настраивать произвольное количество колец (например, 3 кольца для сложных сценариев с приоритетом трамвая или пешеходных переходов) [6].
   • В частном случае многокольцевой алгоритм может быть сведен к традиционному фазному режиму при установке числа колец, равного единице [2, 7].
3. Динамическое формирование промежуточных тактов (IGM): Использование матрицы межзеленых интервалов (InterGreen Matrix) позволяет контроллеру рассчитывать безопасные переходы между любыми комбинациями подфаз «на лету» [1, 2, 8]. Это исключает необходимость жестко прописывать каждый переход вручную и повышает безопасность при динамической смене последовательности движений [9, 10].
4. Программная реализация и конфигурация:
   • Управление описывается в формате JSON, что является открытым стандартом и позволяет гибко задавать параметры: минимальный/максимальный зеленый, время дотяжки (passage time), режимы recall и параметры снижения зазора (gap reduction) [11, 12].
   • Поддерживается пользовательская логика на языках сценариев (JavaScript/ECMA-262), что позволяет реализовывать нестандартные алгоритмы многокольцевого управления поверх базового ядра [2, 13, 14].

Сравнение ДК СПЕКТР и ASC/3 (Econolite)

Контроллеры серии ASC (например, ASC/3) являются классическими представителями американских NEMA-контроллеров. Ниже приведено сравнение их возможностей в контексте многокольцевого управления:

Итог: ДК СПЕКТР представляет собой более гибкую систему за счет перехода от жесткой «фазной» логики к управлению по направлениям и использования современных программных стандартов (Linux, JSON, JS), в то время как ASC/3 является надежным, но более консервативным решением, строго привязанным к стандартам NEMA и проприетарной среде разработки [1, 2, 15, 26].