Проект адаптивной системы
управления движением транспортных средств и пешеходов
на перекрестке по
технологии MDD/MDA
В.В. Макаров,
с.н.с, к.т.н., makarov@ipu.ru
ИПУ РАН, г. Москва
Анализируются
возможности проектирования системы управления по технологии MDD/MDA для
контроллера, регулирующего движение транспортных средств и пешеходов на
перекрестке. За основу проекта был взят опыт передовых зарубежных стран по
созданию адаптивных систем управления на перекрестке. По сложности создания
такую систему управления можно отнести к сложным проектам малого масштаба.
Используя средства быстрого создания прототипов, визуальной отладки и
выполнения модели, с помощью IBM Rational Rhapsody
удалось получить конечные продукты, соответствующие заявленным требованиям. По
визуальным UML-моделям был сгенерирован готовый к исполнению на
контроллере светофора программный код на языке Java 2.
Possibilities of designing of a control system
on technology MDD/MDA for the controller regulating movement of vehicles and
pedestrians at a crossroads are analyzed. The project is based on experience of
the advanced foreign countries on creation of adaptive control systems at a
crossroads. The control system is enough complex projects of small scale. Using
means of fast creation of prototypes, visual debugging and model performance,
by means of IBM Rational Rhapsody it was possible to receive the end-products
corresponding to declared requirements. On visual UML-models the program code
in language Java 2 has been generated ready to execution on the traffic light
controller.
Введение
Транспортная проблема является «бичом» крупных
городов. В особенно тяжёлом положении в последнее время оказалась Москва. Не
будем касаться всех причин, приведших чуть ли не коллапсу уличное движение в г. Москве. Одна из причин транспортного коллапса в столице –
отсутствие адекватной системы управления движением. Нельзя сказать, что
управлению движением в Москве не уделялось внимания. Долгие годы в это
направление вкладывались немалые деньги – это и система СТАРТ, и другие системы
работавшие и работающие сейчас. Однако недавно принято решение мэром города
выделить несколько миллиардов рублей на приобретение и внедрение к 2013 году
(затраты на внедрение оцениваются в 17,75 млрд. руб.) немецкой централизованной
системы управления движением SITRAFFIC Scala фирмы Siemens. Эту систему называют
комплексной интеллектуальной. Она будет использовать и каналы Интернет, и
спутниковые системы глобального позиционирования, будет иметь единый центр
управления и т.д. Будем надеяться, что деньги потрачены не зря.
Задачей настоящей работы является не предложение
альтернативной системы управления всем городским движением, а демонстрация
разработки локальной адаптивной системы управления на основе моделей для
контроллера светофора. При таком подходе контроллеры могут быть реализованы на
любых аппаратных платформах, т.е. представлять собой гетерогенную систему, где
возможна установка JVM – виртуальной Java-машины, обеспечивающей кросс-платформенность приложений – разработанной системы
управления. Говоря математическим языком, предлагается к реализации
распределенная адаптивная система управления с решением задач локального
управления, как альтернативы задачи глобального мониторинга и управления
движения мегаполиса. Единственное, что можно с уверенностью утверждать, такая
система заведомо окажется более надёжной и более дешёвой. Внедрение проекта
системы управления улучшит движение транспортных средств специальных
служб и транспортных средств с преимуществом движения (пассажирских автобусов,
троллейбусов и пр.), оборудованных системами взаимодействия с контроллером
светофора. Используемая система разработки для встраиваемых систем гарантирует
получение программного продукта заданного качества для системы жесткого
реального времени.
1. Общее описание системы управления
Описание одной из возможных систем управления на
перекрестке приведено в книге Douglass B. P. [1].
Каждый перекресток управляется отдельным
контроллером. Каждый контроллер управляет движением шириной до 6 полос (по три
полосы в каждом направлении, включая поворотные полосы), на которых
устанавливаются пассивные индукционные датчики движения (размещаемые под
дорожным полотном), а также наземные инфракрасные и радарные датчики.
Пешеходные светофоры и кнопки сигнализации для пешеходов могут устанавливаться
на обеих дорогах. Задание установленных датчиков должно производиться при
начальной конфигурации контроллера перекрестка. Каждый контроллер перекрестка
имеет лицевую панель управления, позволяющую локально конфигурировать и изменять
режимы работы устройства.
В дополнение к обычным режимам работы, контроллер
перекрестка должен иметь возможность реагировать на передатчики, установленные
на транспортных средствах специальных служб и транспортных средствах с
преимуществом движения. Передатчики, дающие преимущества движения, в основном
устанавливаются на транспортные средства, осуществляющие массовые перевозки
людей (например, автобусы), что позволяет оптимизировать расписание их
движения. Передатчики на транспортных средствах специальных служб позволяют
детектировать приближение автомобилей скорой помощи, пожарных машин и
автомобилей полиции. Такие передатчики должны быть строго направленными, чтобы
иметь возможность точно определять, по какой дороге – главной или
второстепенной – и по какой полосе движется транспортное средство (ТС).
Специальные режимы управления перекрестком могут быть задействованы только при
наличии установленных на дорогах инфракрасных и радарных датчиков.
Когда на транспортном
средстве с преимуществом движения включен передатчик, и для параметра
«Реагировать на ТС с Преимуществом Движения» установлено значение ДА, при его
приближении к перекрестку контроллер либо увеличивает на 10 секунд длительность
включения ЗЕЛЕНОГО сигнала светофора для направления его движения, либо, если
для данного направления горит КРАСНЫЙ сигнал, сокращает на 10 секунд
длительность включения зеленого сигнала для перпендикулярной дороги. Это позволяет ускорить
проезд перекрестка для транспортных средств, имеющих преимущество на дороге.
При приближении к перекрестку транспортных средств специальных служб с
включенными передатчиками, при параметре «Реагировать на ТС Специальных Служб»
установленном значении ДА, светофор для перпендикулярной дороги немедленно
переключается в КРАСНЫЙ, светофор для направления его движения переключается в
ЗЕЛЕНЫЙ; при этом для всех поворотных полоc
включается КРАСНЫЙ сигнал. Если же в направлении, в котором движется
транспортное средство специальных служб, уже включен ЗЕЛЕНЫЙ сигнал светофора,
то его длительность должна быть увеличена. Сигналы светофора должны оставаться
в данном состоянии (ЗЕЛЕНЫЙ сигнал для направления движения транспортного
средства специальных служб и КРАСНЫЙ сигнал для перпендикулярной дороги) еще в
течение 5 секунд после того, как транспортное средство с передатчиком пересечет
перекресток, либо передатчик будет выключен.
Детальное рассмотрение всех требований к
разрабатываемой системе управления не входит в задачу этой работы. Полную
спецификацию требований можно найти в книге [1].
На основе вербального описания системы управления,
на языке UML создадим спецификацию требований к системе.
2. Спецификация требований
Одной из наиболее важных задач в работе инженеров
является определение требований к разрабатываемой системе. Ошибки в требованиях
– это один из наиболее серьезных видов стратегических ошибок в системах и
наиболее дорогой в исправлении, поскольку вносятся эти ошибки на ранних
стадиях, а обнаруживаются, как правило, на поздних стадиях проекта, оказывая
влияние на многие компоненты системы.
В UML отсутствует отдельная
сущность с названием «требование». Хотя варианты использования, диаграммы
последовательности, конечные автоматы, диаграммы деятельности и ограничения
разных видов могут использоваться для моделирования свойств
требований, отдельная сущность с названием требование отсутствует. По
этой причине данная сущность была добавлена в языке SysML (Systems Modeling Language
– Язык Моделирования Систем), а IBM Rational
Rhapsody (использовались версии 7.5.3 и 7.6) позволяет нам
добавлять элементы требований в моделях.
Начнем с создания проекта системы управления
перекрестком в Rhapsody – Roadrunner. Модель будет содержать в
себе несколько пакетов, первым будет создан пакет «_System», который будет содержать
всю информацию уровня системы, кроме интерфейсов подсистем (рис.1).
рис.1 Обозреватель модели, пакет _System
В данном пакете создадим еще 3 пакета: Arсhitecture_of_System, который будет содержать
набор подсистем и диаграмм, отображающих, как они взаимосвязаны; Model_of_requirement (рис.2),
который будет содержать соответственно модель требований; Testing_scenario,
который будет содержать диаграммы последовательности и диаграммы деятельности,
определяющие тесты уровня системы.
Создадим в Rhapsody еще одну диаграмму
(рис.3). Поместим данную диаграмму использования в пакете _System->Model_of_requirement->Operation_requirement.
На рис. 3 изображены варианты использования для
системы управления дорожным перекрестком. Два основных варианта использования
системы: «Конфигурирование системы» и «Управление движением». В варианте
использования «Конфигурирование системы» система взаимодействуют либо с
оператором лицевой панели, либо с удаленным монитором. Независимо от того, как
система конфигурируется, она также выполняет свое основное назначение –
управляет движением.
Можно было бы определить единственный вариант
использования «Управление движением», конечный автомат которого определял бы
различные режимы в виде высокоуровневых вложенных состояний для данного
варианта
рис. 2 Диаграмма «Обзор основных требований» – Model_of_requirement
использования.
Результирующий конечный автомат был бы очень сложным. Поэтому лучше создать
несколько разновидностей режимов управления движением, определив для каждого из
них более простой конечный автомат. В данном случае перекресток может
переключаться из режима в режим. Однако с точки зрения операционного
представления системы эти режимы независимы друг от друга и, поэтому,
моделируются с помощью различных вариантов использования системы.
рис. 3 Диаграмма вариантов использования системы
управления дорожным перекрестком
3. Определение сценариев для дорожного перекрестка
Рассмотрим вариант использования «Режим
реагирования на сигналы датчика» (рис. 3). Можно придумать несколько десятков
различных сценариев, определяющих различные варианты взаимодействия между
системой и действующими лицами, которые будут входить в данный вариант
использования. Для решения поставленной задачи будет достаточно определить
всего три сценария:
·
Движение отсутствует (система функционирует в режиме с фиксированной
длительностью цикла);
·
Транспортное средство приближается к перекрестку по дороге В, в то время как для дороги А горит зеленый свет
транспортного светофора и горит зеленый сигнал пешеходного светофора;
·
Пешеход приближается к перекрестку по дороге В,
в то время как для дороги А горит зеленый свет транспортного светофора.
В качестве примера приведем
первый вариант сценария – «Режим с фиксированной длительностью цикла.
рис. 4 Первый сценарий управления дорожным
перекрестком – «Режим с фиксированной длительностью цикла»
4. Системная архитектура. Определение модели системы
Для небольших систем рекомендуется использовать
следующую организацию модели [1]:
·
Системная область
o Системные требования
§ Операционные требования
(варианты использования)
§ Неоперационные требования
§ Тестовые сценарии для
системы
o Системная архитектура
(включая размещение)
·
Область сборки системы (для поэтапной сборки системы)
o Сборка х
(отдельный пакет для каждой сборки)
·
Общая область (для совместно используемых типов и классов)
·
Кооперация х (отдельный пакет для каждого
варианта использования)
Построим диаграмму пакетов, отображающую набор
пакетов, используемых для организации модели всей системы (рис. 5). Назначение
каждого пакета указано в коротком комментарии.
рис. 5 Общая организация модели
На следующем рисунке (рис.
6) изображена модель в иерархическом виде в обозревателе модели Rhapsody.
рис. 6 Представление организации модели в
обозревателе
Для отображения системной архитектуры воспользуемся
структурной диаграммой UML. Для пояснения назначения отдельных элементов модели
используем стереотипы «Система» и «Подсистема» (рис. 7). Порты между
подсистемами системы еще пока не типизированы соответствующими интерфейсами.
Эти интерфейсы будут определены позднее.
На диаграмме (рис. 7) определены отдельные
подсистемы для транспортного светофора на основной дороге (Гл.Транспортный
светофор) и транспортного светофора на второстепенной дороге (Вт.Транспортный
светофор). В представленной на рисунке модели для каждой из подсистем
используется множественность 1. Другой альтернативой является использование
одного блока подсистемы с названием «Транспортный светофор» и множественностью
2. Был выбран первый вариант, поскольку роли двух этих подсистем для их клиента
(контроллера управления перекрестком) различны, и использование отдельных
связей делает это различие более наглядным.
Заключение
Проектирование системы управления перекрестком реализовано
по следующим этапам. На этапе спецификаций требований была сформирована
техническая спецификация. Были построены модели требований с помощью диаграмм
вариантов использования на языке SysML. Были реализованы варианты
использования и выполнена группировка требований по полученным вариантам
использования. Определена часть сценариев для системы управления дорожным
перекрестком.
На этапе системной архитектуры была определена
организация модели системы, определены подсистемы. Для отображения подсистем и
их взаимодействия была построена соответствующая структурная диаграмма. Далее
был построен ряд диаграмм последовательностей, чтобы определить операционные
контакты и их привязку к подсистемам.
На этапе объектного анализа
были определены основные объекты и классы, необходимые для реализации вариантов
использования, определены отношения между основными объектами и классами,
определены атрибуты и операции, которые привязаны к классам. Специфицировано
поведение реактивных классов при помощи конечных автоматов, реализовано
исполнение операций, проверена правильность модели путем ее исполнения.
рис. 7 Диаграмма с системной архитектурой для модели
перекрестка
Изучать поведение системы позволяет
динамический анализ и верификация системы [2, 3]. В среде разработки Rational Rhapsody (использовались
версии 7.5.3 и 7.6) поддерживается уникальный механизм анимации UML-моделей
и реальное выполнение сгенерированной программы с графическим интерфейсом.
Механизм анимации для UML-диаграмм реализуется
следующим образом. При генерации кода указывается необходимость создания
анимированной версии приложения, а так же параметры для связи с
инструментальной средой разработки по TCP/IP. В этом случае
поведенческий код, реализующий диаграммы конечных автоматов (State Machine Diagram) и диаграммы
последовательностей (Sequence Diagram),
вставляются соответствующие инструкции. При запуске программы она устанавливает
TCP-соединение с Rhapsody и во время выполнения
сообщает среде разработки своё текущее состояние. Среда разработки отражает
изменение состояния приложения на соответствующей диаграмме. Исполнение UML-моделей
в режиме анимации называют динамической отладкой.
Были рассмотрены
анимационные модели, основанные на диаграммах состояний и диаграммах
последовательности. Рассмотрена анимационная модель, основанная на диаграммах
состояний. Плюс этой анимационной модели в том, что мы можем четко проследить
жизнь, поведение экземпляров любого класса системы в различных условиях во
время работы системы. Относительным минусом данной анимационной модели можно
назвать то, что существует она только во время выполнения программы.
Далее были рассмотрены
анимационные модели, основанные на диаграммах последовательности. Необходимо
отметить плюс данных анимационных моделей, что полученные анимационные модели в
результате работы системы сохраняются, и их можно просматривать и
анализировать уже после работы системы,
они сохраняются в проекте разработки, в отличие от анимационных моделей,
основанных на диаграмме состояний. Еще одним плюсом данной анимационной модели
является то, что на ней отображаются помимо всех действий, предписанных
диаграммой последовательности, все состояния экземпляров классов, которые
принимают они во время работы, а также методы, которые выполняют экземпляры,
генерируемые ими события и сообщения, предписанные диаграммой состояний, во
время перехода в различные состояния. Анимационные модели обоих видов являются
еще одним средством, облегчающим процесс
создания качественного и надёжного ПО. Код с анимацией
разработчик использует только на этапе отладки и верификации программного
обеспечения, а не для использования в целевой системе.
На основе построенной
модели системы управления дорожным перекрестком был сгенерирован
работоспособный Java-код.
Литература
1.
Douglass B. P. Real-Time
UML Workshop for Embedded Systems. – Oxford, UK, Elsevier Inc., 2007. p.408.
2. Новичков А., Костиков А.
Автоматизация процесса тестирования при помощи методологии и инструментальных
средств IBM Rational. (Электронный ресурс)/ Новичков
А., Костиков А. Автоматизация процесса тестирования при помощи методологии и
инструментальных средств IBM Rational.-Режим доступа: http://citforum.ru/SE/testing/automation_1/index.shtml
,свободный.
3. Зыль С.Н. Проектирование,
разработка и анализ программного обеспечения систем реального времени. – СПб.: БХВ-Петербург, 2010. 336с.