Практика показывает, что обычным сценарием внедрения АСУДД в российских городах является поэтапное оснащение отдельных районов и поэтапная замена существующего управляющего периферийного оборудования - дорожных контроллеров (ДК). При этом оказывается, что эффективность внедрения системы на первых этапах может быть низкой из-за отсутствия должного охвата системы. Например, в ряде случаев, координированное управление работой светофорных объектов должно действовать не только на группе перекрестков основной магистрали, но и охватывать прилегающие улицы. Вместе с тем, в большинстве предлагаемых системных решений, возможности включения существующего парка дорожных контроллеров весьма ограничены. Использование же и расширение существующих во многих городах традиционных отечественных управляющих систем сдерживается физическим износом медных линий, ориентированностью на использование в этих системах узкоспециализированных средств связи, например, средства связи на базе софтфон, заложенной функциональной ограниченностью. Для традиционных отечественных систем, характерна передача управляющих сигналов по узкоспециализированным линиям связи в реальном времени. Отказ от этих принципов в пользу применения унифицированных и доступных средств физической передачи данных и ориентирование решений на повсеместно применимые транспортные протоколы TCP/IP во многом облегчает положение, но при этом остается основная преграда - отсутствие стандартизованных способов сопряжения оконечного оборудования и единых требований по системной функциональности этого оборудования. И если на физическом уровне задача сопряжения с каналами связи довольно просто решается доступными на современном рынке преобразователями поточных интерфейсов в IP-пакеты и конвертерами физической среды передачи (на оптические линии, радиоканал и т. п.), то на уровне совместимости прикладных протоколов управления контроллерами все гораздо сложнее. Большинство отечественных дорожных контроллеров имеют либо свой собственный управляющий поточный интерфейс для «внутрифирменного» использования (интерфейс инженерного пульта, собственной управляющей системы центра, интерфейс ведущего контроллера и т.п.), либо модуль сопряжения с линиями системы АСС УД «СИГНАЛ» с поддержкой протокола этой системы. Также ряд контроллеров уже имеют собственную реализацию управляющего интерфейса для IP сетей..
Рассмотрим более подробно эти варианты.
В первом случае, проблема состоит в закрытости внутрифирменного протокола для других разработчиков и в его нестабильности от одной версии контроллера к другой. Также этот интерфейс в большинстве случаев нельзя использовать просто «удлинив» до управляющего центра т. к. он зависим от времени передачи по каналу связи и не пригоден или не оптимизирован для передачи пакетами в IP сетях. Для второго случая - хотя протокол системы АСС УД и является де-факто стандартом для большинства отечественных инсталляций, моральное устаревание уже не позволяет ориентироваться на него при создании современных решений. Этот протокол реализует низкоскоростную (100 бит/сек) передачу по выделенным линиям синхронного сигнала, что делает невозможным использование IP сетей для его мультиплексирования и передачи. Кроме того, заложенная функциональность протокола весьма ограничена. Для третьего случая - большинство готовых IP реализаций управляющего протокола носят закрытый, нестабильный внутрифирменный характер. Также, отсутствует единый стандарт по функциональной насыщенности протокола для управляющего центра.
Пути решения. Для последнего описанного варианта - существует необходимость создания единого стандарта и протокола взаимодействия периферийного контроллера и управляющего центра при совместном участии заинтересованных отечественных разработчиков. Обычной практикой является создание специального комитета - с государственной поддержкой или при поддержке лидирующих фирм. Как показывает практический опыт, эффективным решением для первых двух случаев является использование системных адаптеров. Эти устройства сопрягают внутренний управляющий интерфейс дорожных контроллеров с интерфейсом передачи IP пакетов и преобразуют внутренний протокол произвольного ДК в принятый в системе единый протокол взаимодействия управляющего центра с периферийным устройством. Ряд системных функций, расширяющих возможности контроллера, реализуется в самом адаптере - в своем роде это вынесенный на периферию фрагмент управляющего центра. Реализуются функции координированного и адаптивного управления, функции сбора данных от детекторов транспорта (ДТ) в формате, необходимом системе и др. Это позволяет приблизить системные свойства несущего адаптер ДК к свойствам контролера, изначально предназначенного для использования в данной АСУДД. На сегодняшний день есть успешные отечественные реализации указанной схемы, использующие базовый интерфейс АСС УД и набор драйверов для использования с контроллерами, имеющими хоть и внутрифирменный, но открытый и стабильный интерфейс управления. Аналогичный опыт применения адаптеров есть и в зарубежных реализациях, в частности, в системе UTOPIA (Urban Traffic Optimisation by Integrated Automation, Италия) и SCATS (Sydney Coordinated Adaptive Traffic System, Австралия). [4,7] Для успешного развития такого пути построения систем, необходимо открытие разработчиками отечественных ДК документации на существующие низкоуровневые управляющие интерфейсы и создание в будущем единого стандарта взаимодействия связки адаптер-контроллер, рекомендованного для новых разработок. Стандарт должен описывать необходимый набор и формат сообщений в низкоуровневом протоколе реального времени на базе последовательного интерфейса, включая данные о неисправностях силовых нагрузок, данные детекторов, управляющие воздействия на уровне фаз и отдельных сигнальных групп.