Как стать автором
Обновить

Разбор архитектуры автоматизированной системы управления дорожным движением из стандарта U.S. DoT ITS

Время на прочтение 9 мин
Количество просмотров 9.5K
Американский стандарт интеллектуальных транспортных систем U.S. Dot ITS описывает весь комплекс автоматизированных систем управления транспортом. Стандарт настолько масштабен, что втиснуть его описание в один или даже два поста нереально. Так как большинство описанных в нем систем для нас недостижимое светлое будущее, то и делать этого не стоит. А вот что стоит сделать — это рассмотреть то, как он устроен изнутри, какие находки сделали неизвестные американские (ой ли?) ИТ-специалисты, проделавшие весьма значительный объем работы за счет налогоплательщиков.

Чтобы было проще, предлагаю рассмотреть более подробно одну из систем стандарта, а именно АСУДД (автоматизированную систему управления дорожным движением). Тем более, что это сейчас крайне модная тема в нашей стране, где еще сильны иллюзии того, что компьютеры смогут заменить нормальный асфальт, а, может быть, вообще позволят обойтись без дорог.

Основные понятия архитектуры


Требования

На следующей картинке изображены основные элементы архитектуры и связи между ними. Зеленым покрашены сущности, которые мы рассмотрим сегодня.



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

Я насчитал более 1400 уникальных требований. Из них около 120 относится к АСУДД, из них только 60-70 можно предъявить к гипотетическим российским системам. Остальные требования относятся к совершеннейшей экзотике (например, автоматические полосы на магистралях или передача дорожных знаков внутрь автомобиля) или связаны с американской спецификой, реализовать которую у нас вообще нереально (интеграция железнодорожных расписаний и планов координации светофоров на городских улицах, чтобы переезды не создавали пробок).

Вот, например, как выглядят требования к подсистеме управления светофорами:
  • Система должна обеспечивать удаленное управление дорожными контроллерами
  • Система должна принимать запросы на проход перекрестка от пешеходов
  • Система должна обеспечивать централизованный сбор и верификацию информации об оперативном статусе дорожных контроллеров
  • Система должна обеспечивать сбор информации о сбоях дорожных контроллеров
  • Система должна позволять применение планов координации светофоров на оборудованных перекрестках под контролем персонала ЦУД, основываясь на данных от детекторов, информации о транспортных потоках, инцидентах, запросах на приоритетный проезд спецтранспорта, данных о грузовых ТС с избыточной нагрузкой, информации об отказах оборудования, запросов на переход от пешеходов и т.д.

Все кажется вполне логичным, и даже есть стандартный «косяк» в виде «etc», который является любимым лакомством корпоративных троллей, стремящихся упихать в это самое «etc» слона с бегемотом, лишь бы развалить проект или отжать еще немного денег у подрядчика. Как бы то ни было, требования составляли живые люди, и эти требования похожи на «боевые», взятые из реальных техзаданий.

Подсистемы

В оригинале американцы используют термин «Equipment Packages», некие группировки элементов оборудования, к которым предъявляются функциональные требования. Я же предлагаю использовать понятие «Подсистемы», которое нам ближе и родней, а также максимально близко по смыслу.

Подсистемы физически реализуют функциональные требования при помощи оборудования, ПО и каналов связи. В архитектуре существует реестр всех перечисленных элементов и таблица связей между всеми подсистемами и элементами оборудования/ПО/сетей. Чтобы излишне не загромождать картинку, я эту связь рисовать не стал.

Далее перечислены основные подсистемы с комментариями, которые я бы рекомендовал к реализации в нашей стране. Некоторую «экзотику» перечислю ниже для общего развития.

  1. Подсистема управления шлагбаумами. Осуществляет удаленное управление шлагбаумами и другими преграждающими устройствами
  2. Подсистема сбора информации о дорожном движении. Осуществляет удаленный сбор информации с камер видеонаблюдения, детекторов транспортного потока, обработку и хранение этой информации, а также информации о дорожном движении, получаемой из внешних источников. Также осуществляет предоставление собранной информации во внешние системы и другие АСУДД.
  3. Подсистема мониторинга окружающей среды. Контролирует погодные условия, используя информацию АДМС, метеоцентров и соседних АСУДД. Предоставляет информацию другим подсистемам для информирования участников дорожного движения и принятия решений.
  4. Подсистема управления магистралями. Обеспечивает централизованный мониторинг и управление движением на автомагистралях, включая регулирование доступа на магистраль, промежуточный контроль скорости, управление развязками, полосами движения и т.п.
  5. Подсистема управления выделенными полосами для АТОП. (Я тут выбрал термин «автотранспорт общественного пользования», хотя американцы используют HOV — High Occupancy Vehicle. Под этот термин могут попасть и легковые автомобили, перевозящие нескольких человек). Осуществляет управление движением транспорта по выделенным полосам, приоритезацию движения АТОП на перекрестках, фиксацию нарушений в использовании выделенной полосы.
  6. Подсистема обнаружения инцидентов. Осуществляет идентификацию инцидентов и оповещает персонал ЦУД (центр управления движением). Удаленно контролирует дорожные детекторы, систему сбора параметров дорожного движения, которая обеспечивает обнаружение инцидентов. Также предусматривает получение и обработку информации об инцидентах на грузовых перевалочных пунктах, пунктах пересечения границ и т.п.
  7. Подсистема интеграции со смежными АСУДД. Осуществляет интеграцию и координацию мероприятий по управлению дорожным движением между региональными и локальными АСУДД, например координацию светофоров в городской черте и светофоров на областной магистрали.
  8. Подсистема управления полосами реверсивного движения. Осуществляет удаленный мониторинг и управление реверсивными полосами посредством управления реверсивными светофорами, шлагбаумами и другими средствами ограничения въезда на полосу.
  9. Подсистема управления светофорами. Обеспечивает возможность мониторинга и управления транспортными потоками на пересечениях, оборудованных светофорами. Эта возможность включает анализ и обработку данных детекторов, разработку и применение планов координации на нескольких перекрестках, входящих в один домен управления.
  10. Подсистема контроля скоростных режимов. Обеспечивает удаленный мониторинг скорости и управление системой предупреждения превышения скорости. Осуществляет измерение скорости ТС и передачу этой информации в ЦУД. Также обеспечивает уведомление контрольно-надзорных органов о фактах значительного превышения скорости.
  11. Подсистема распространения информации о дорожном движении. Обеспечивает распространение информации о трафике, дорожных условиях, перекрытиях и рекомендуемых путях объезда. Предоставляет информацию об инцидентах, объявлениях и прочую транспортную информацию в другие подсистемы, центры, СМИ и т.п. Обеспечивает отображение информации на ТПИ (табло переменной информации), передачу информации по радиоканалу и т.п.
  12. Подсистема поддержки принятия решений. Рекомендует оператору последовательность действий на основе текущих и прогнозируемых дорожных условий и состояния трафика. Осуществляет контроль за транспортными происшествиями, специальными мероприятиями, техническим обслуживанием и другими событиями, влияющими на транспортный спрос. Для оценки последствий действий оператора и выработки рекомендаций используются исторические данные. Рекомендуемые действия могут включать переопределение планов реагирования на инциденты, пересчет планов координации, применение различных стратегий управления, ограничение въезда на магистрали, перенаправление транзитного трафика и рекомендации путей объезда для автомобилистов. После того, как оператор согласует рекомендации, система применяет сценарий и оборудование ЦУД осуществляет необходимые действия.
  13. Подсистема оценки производительности дорожной сети. Измеряет параметры производительности транспортной сети и предсказывает изменение транспортного спроса для обеспечения оптимизации транспортного потока, управления транспортным спросом, и дорожными инцидентами. Собирает как информацию с детекторов транспорта, так и информацию других АСУДД и смежных систем, центров экологического мониторинга, логистических центров, организаторов массовых мероприятий и использует эту информацию для измерения параметров производительности транспортных потоков. Также подсистема собирает информацию о плановых маршрутах для того, чтобы предсказать развитие транспортной ситуации. Стратегии планирования могут быть переданы в подсистему информирования пользователей, а также могут быть использованы для будущего планирования маршрутов.
  14. Подсистема сбора информации о состоянии дорожной сети. Обеспечивает сбор в режиме реального времени информации о состоянии транспортной сети в масштабах региона. Сюда входят коммуникации и определение возможности обработки данных ЛАСУДД в реальном режиме времени. При помощи запросов в локальные СУБД подсистема осуществляет сбор информации ЛАСУДД, после чего распространяет эту информацию между другими системами ЦУД и внешними системами.
  15. Подсистема управления ремонтными работами. Координирует планы работ по обслуживанию дорожной сети с целью минимизации влияния работ по ремонту и обслуживанию на транспортную ситуацию. Информирует участников дорожного движения о проводимых ремонтных работах посредством вывода объявлений на ТПИ.
  16. Подсистема сбора и хранения информации о дорожном движении. Обеспечивает хранение информации о дорожном движении для последующего ее использования персоналом и для архивирования на федеральном уровне.
  17. Подсистема поддержки эксплуатации оборудования обеспечивает мониторинг работоспособности оборудования и обнаружение сбоев. Информирует персонал эксплуатации и передает информацию в подсистему управления ремонтными работами. Отслеживается работоспособность всего спектра установленного оборудования.

А теперь немного экзотики.

TMC Automated Vehicle Operations (Управление автоматическим транспортом). Осуществляет удаленное управление автоматизированными магистралями (по которым движется автоматизированный транспорт, «автопилот»).

А вот тут возникли трудности перевода. В русском адекватного термина нет.
TMC In-Vehicle Signing Management (Управление информированием водителя посредством бортовой системы отображения дорожных знаков об условиях движения). Осуществляет мониторинг и управление оборудованием, осуществляющим передачу сигнала на переключение знака в бортовой системе предупреждения водителя, пересекающего зону действия знака.

TMC Demand Management Coordination (Управление спросом на парковки). Контролирует спрос на парковки и другие платные элементы инфраструктуры для регулирования цены на эти услуги.

TMC Evacuation Support (Поддержка эвакуации). Поддерживает разработку, координацию и выполнение сценариев и стратегий управления движением в ходе эвакуации во время стихийных бедствий. Стратегия разрабатывается на основе моделирования возможного транспортного спроса. Подсистема работает в тесной связке с центром по ЧС (отдельная подсистема, не входящая в АСУДД)

Перечень можно бы и продолжить, но, боюсь, того, что уже перечислено, более чем достаточно, чтобы заставить задремать даже самых стойких читателей. Может быть, небольшим утешением будет то, что я перечислил только 21 подсистему, а всего в стандарт ИТС входит 219 разнообразных подсистем! Одно только высокоуровневое описание информационных потоков между этими подсистемами занимает 3 толстых тома мелким шрифтом, неизвестно зачем выпущенных американцами. Ведь понять эту систему, глядя на паутину связей на бумаге, невозможно в принципе. Все связи есть в прилагаемой к стандарту базе данных в формате Access, которая и использовалась при подготовке данной статьи.

Процессы

На самом деле в оригинале они называются Market Packages, и я всю голову сломал, пытаясь подобрать верный перевод. В итоге решил остановиться на слове «процесс», так как в этих сущностях группируется динамическая составляющая ИТС, а именно, то, что она делает для достижения поставленных целей.

Не буду утомлять вас перечислением процессов АСУДД, так как это не добавит представленному материалу дополнительной ценности, а только нагонит никому не нужный листаж. Приведу для примера пару процессов, чтобы вы представили, как выглядят остальные.

Управление магистралями. Обеспечение управления движением на магистралях. Включает различные стратегии управления, такие как ограничение доступа на магистрали, управление скоростью потока, управление полосами, въездами и съездами и т.п. Включает весь необходимый комплекс оборудования и программного обеспечения.

Управление выделенными полосами для АТОП. Обеспечение управления полосами для движения АТОП. Включает оборудование светофорных объектов, а также транспортных средств для обеспечения приоритетного проезда для ТС, отстающих от графика движения. Бортовые системы включают GPS оборудование, датчик открытия дверей и маршрутный компьютер.

С процессами непосредственно связаны спецификации процессов — документы, формально описывающие каждый процесс с детальностью, достаточной для дальнейшей проработки постановок на ПО или формирование требований к поставщикам.

Спецификации процессов в свою очередь связаны с «терминаторами» (terminators). Терминаторы — это или конечные пользователи, или другие (внешние) системы, с которыми взаимодействует процесс. Для простоты я перевел этот термин как «пользователи АСУДД», понимая под этим бизнес-роли, которые исполняют люди, ответственные за какие-либо параметры или части системы.

Резюме

Итак, архитектура АСУДД полностью описывает:
  • Функциональные требования к системе
  • Используемое оборудование
  • Подсистемы
  • Процессы
  • Процессные роли
  • Внутренние и внешние информационные потоки


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

По-моему, очень красиво.
Теги:
Хабы:
+19
Комментарии 8
Комментарии Комментарии 8

Публикации

Истории

Работа

Ближайшие события

Московский туристический хакатон
Дата 23 марта – 7 апреля
Место
Москва Онлайн
Геймтон «DatsEdenSpace» от DatsTeam
Дата 5 – 6 апреля
Время 17:00 – 20:00
Место
Онлайн