Система моделирования «Транспортная инфраструктура города» Текст научной статьи по специальности «Компьютерные и информационные науки»

8. Kozlov D.I., Anshakov G.P., Antonov Yu.G., Makarov V.P., Somov Ye.I. Precision flight control systems of Russian remote sensing spacecraft // Space Technology. 1999. Vol. 19. No. 3&4. P. 149-163.

Статья поступила в редакцию 7 марта 2008 г.

УДК 004.652.5

Т.И. Михеева, И.А. Рудаков, И.А. Чугунов

СИСТЕМА МОДЕЛИРОВАНИЯ «ТРАНСПОРТНАЯ ИНФРАСТРУКТУРА ГОРОДА»

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

Введение

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

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

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

Назначение системы

Система моделирования управления ТП предназначена для исследования поведения ТП при различных стратегиях управления с использованием расширенной модели УДС [1] и обеспечивает:

- обработку результатов измерения интенсивности ТП на улично-дорожной сети города, хранящихся в базе данных ИТС;

- сохранение обработанных результатов в базе данных и экспорта в формате С^К-файла;

- проведение имитационного моделирования;

- отображение карт распределения характеристик ТП в ГИС Мар1п/о по результатам моделирования либо обработки результатов измерения интенсивности ТП на УДС города.

Кроме построения непосредственно модели движения ТП, в системе решен ряд вспомогательных задач. Разработаны математические модели [2, 3]:

- генерации транспортного потока — введения транспортных средств (ТС) в моделируемую УДС;

- выбора цели — определения конечных пунктов следования ТС;

- перераспределения транспортных потоков - выбора одного из возможных путей следования ТС;

- управления - модель ТСОДД с формальным описанием их воздействия на поток транспорта в целом и на каждое транспортное средство в отдельности.

Определены некоторые параметры сети:

- пропускная способность отдельных участков сети - пропускная способность входит в модель перераспределения транспортных потоков как обязательный параметр;

- транспортный спрос - на основании транспортного спроса строятся модели генерации транспортного потока и выбора цели;

- интенсивность транспортного потока.

Предметно-ориентированная среда моделирования и поддержки принятия решений для работы с транспортной инфраструктурой города использует объектные геоинформационные модели уличнодорожной сети, ТСОДД и транспортных потоков. Определены значения параметров, входящих в уравнения движения транспортного потока [4].

Моделирование может инициироваться как Экспертом в организации дорожного движения, так и некоторой Внешней системой. В первом случае система предоставляет пользователю графический интерфейс пользователя, и результаты моделирования представляются в виде тематического слоя карты в ГИС MapInfo. Во втором случае система предоставляет программный интерфейс приложения, и посредством обратных вызовов (callbacks) внешняя система получает сведения о координатах транспортных средств в модели, их скорости, затратах времени и пр., а также запрашивает распределения интенсивности, скорости, транспортной задержки.

Форматы представления данных, внешних по отношению к системе

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

Патч структуры УДС содержит в себе:

- список узлов и дуг графа УДС, которые должны быть добавлены или удалены из модели транспортной инфраструктуры перед началом процесса моделирования;

- список ТСОДД, которые должны быть добавлены или удалены из модели;

- альтернативные значения транспортного спроса по транспортным районам.

Патч хранится в текстовом XML-файле.

Перед началом процесса моделирования необходимо указать ряд параметров:

- шаг дискретизации по времени;

- имя используемого

снимка со значениями интенсивностей и

транспортного спроса;

- используемый патч.

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

Наиболее удобным форма- том

такого файла является CSV (Сomma-Separated Values), хранящий отображение множества идентификаторов объектов УДС (узлов, дуг) на множество значений (интенсивности или транспортной задержки).

Компоненты системы

Снимок

(сущность В БД

------------------

I

._____I_______

| I | АИС построения модели УДЗ

*

Импорт модели УДЗ

| I | Инструмент работы со снимсаыи

1 I 1 ГИС MaDlnfo

1=Ъ

<1ййл с 1 ' 1

распределением | MapBasic-скрипты

погрешности | 1

Получение данных для

я^изображени

| I | Модуль отображения результатов моделирования

Р и с. 1. Компоненты, участвующие в импорте модели УДС, обработке результатов измерений интенсивностей и построении карт распределения погрешности

гут

при

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

Прецеденты «Импортировать модель УДС», «Сформировать снимок», «Показать карту интенсивностей». Интерфейс пользователя предоставляется компонентами «Инструмент работы со снимком» и «ГИС MapInfo». Инструмент работы со снимками производит импорт данных из автоматизированной информационной системы (АИС) построения модели УДС, формирует снимок в БД, производит процедуру восстановления пропущенных значений интенсивностей и формирует файл со значениями абсолютной погрешности восстановления интенсивностей. Данные из этого файла могут быть представлены в виде карты в ГИС MapInfo. В прецеденте «Показать карту интенсивностей» участвуют те же компоненты, но формируется не файл со значениями абсолютной погрешности, а файл со значениями интенсивностей.

Прецедент «Имитационное моделирование в составе внешней системы». Система моделирования управления ТП предоставляет программный интерфейс приложения для работы в составе внешней системы (рис. 2). Для этого модуль имитационного моделирования должен быть оформлен в виде библиотеки или сборки .NET, а сам интерфейс (API) должен быть документирован.

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

Интерфейс прикладного программиста

При разработке API-модуля имитационного моделирования основным требованием является независимость от какого-то конкретного представления графа УДС. Для этого разработан набор интерфейсов, реализовав которые, прикладной программист делает свое собственное представление графа УДС «понятным» для модуля имитационного моделирования (рис. 4). Основу API-модуля имитационного моделирования составляют классы «Модель города», «Параметры моделирования» и «Ре-

При создании экземпляра класса «Модель города» в его конструктор передается ссылка на экземпляр класса «Параметры моделирования». Затем вызывается метод Загрузитьмодель, в качестве аргумента методу передается экземпляр класса «Загрузчик графа УДС», поддерживающий интерфейс «Загрузчик графа»: вызовы методов список_дуг(), список_узлов() и т.п. должны возвращать однонаправленный итератор, поддерживающий интерфейс «Загрузчик объектов». Через этот итератор экземпляр класса «Модель города» сможет загрузить соответствующие объекты графа УДС.

Методы Запустить_моделирование() и Остановить_моделирование() служат для управления модельным временем. В любой момент текущее состояние модели может быть получено в виде структуры «Результаты моделирования» вызовом метода Получить__результаты().

зультаты моделирования».

GUI системы моделирования

>) I Modelling

Модуль имитационного моделирования

Файл с

результатами

моделирования

(распределениями

интенсивности,

средней скорости...)

ГИС MapInfo

MapBasic-скрипты

' I ' Модуль отображения результатов моделирования

Р и с. 3. Компоненты, используемые при имитационном моделировании средствами разрабатываемой системы

Р и с. 2. Использование модуля имитационного моделирования в составе внешней системы

Пользовательский интерфейс системы имитационного моделирования

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

- диалоговое окно, позволяющее пользователю заполнить структуру «Параметры моделирования»;

- класс «Загрузчик графа УДС» (рис. 4) - экземпляр этого класса реализован паттерном «Адаптер», загружающим граф УДС и представляющим его в виде, понятном модулю имитационного моделирования, ссылка на этот класс будет передана в модуль имитационного моделирования;

- окно, информирующее пользователя о ходе процесса моделирования (окно, изображающее граф УДС с положением транспортных средств в модели);

- элементы управления процессом моделирования - кнопки «Остановить» / «Продолжить», индикатор хода модельного времени;

- диалоговое окно, позволяющее сохранить результаты моделирования в файле.

Р и с. 4. АР-системы имитационного моделирования

Логическая модель базы данных

Система моделирования использует БД для доступа к следующей информации.

- Транспортная инфраструктура города. Структура УДС города меняется медленно, и в БД необходимо хранить только текущее состояние УДС: структуру графа УДС, расположение и характеристики ТСОДД. Для моделирования каких-либо изменений в структуре УДС используются патчи. Структура УДС редактируется с помощью подсистемы построения модели УДС.

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

- Снимки интенсивностей и транспортного спроса. Снимки формируются по значениям интенсивностей, сохраненных в БД.

Каждый подсчет интенсивности на УДС представлен в базе данных экземпляром сущности Значение интенсивности. Подсчет интенсивности уникально идентифицируется датой / временем подсчета и первичным ключом дуги графа УДС. В неключевых атрибутах зафиксирована интенсивность ТС различного типа (количество ТС/час).

Снимки интенсивности и транспортного спроса представлены в базе данных сущностями Снимок, Снимок интенсивности, Снимокспроса, Транспортный_район.

Сущность Снимок — это контрольная точка, состояние УДС, зафиксированное в базе данных. Все

экземпляры сущностей Снимокинтенсивности и Снимокспроса, состоящие в ассоциации с одним и тем же Снимком, описывают УДС в одном и том же состоянии (например, 08.03.2007 в 9:00).

Снимок интенсивности - это значение интенсивности и пропускной способности соответствующей дуги, зафиксированное в соответствующем снимке. Если при формировании снимка для некоторой дуги найден подходящий результат значения интенсивности, то он будет включен в снимок. Если подходящий результат интенсивности не найден, то снимок интенсивности помечается как вычисляемый. Кроме ключевых атрибутов, Снимок_интенсивности характеризуется значениями приведенной интенсивности (авт/час), пропускной способности (авт/час), флагом «вычисляемое» и абсолютной погрешностью, которая является мерой противоречивости имеющихся данных об интенсивности на дуге.

Транспортный_район - это область города с относительно однородным спросом.

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

Объектно-ориентированное проектирование системы моделирования

Система моделирования ТП представляет собой набор классов, помещенных в сборку .NET [5]. «Точкой входа» для прикладного программиста является класс Модель города. Создание экземпляра этого класса в пользовательском приложении дает пользователю доступ к услугам системы имитационного моделирования. Основные компоненты системы - планировщик событий; структуры, хранящие модель УДС и состояние транзактов; структуры, собирающие статистику в ходе процесса моделирования, являются частями класса Модель города, т.е. состоят с ним в отношении композиции и вне этого отношения не существуют.

Класс «Модель_Города»

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

Модель Города изображена на рис. 5 и образована следующими компонентами. ТаймерМодели - это планировщик, отвечающий за ход времени внутри модели. В обязанности планировщика входит пересчет модельного времени по методу «Літ» и отправка уведомлений активным объектам модели о том, что прошел очередной квант времени. Получив уведомление, объекты смогут изменить свое состояние и состояние пассивных объектов модели (например, элементов графа УДС).

Автопарк - это список ТС, осуществляющих движение по УДС. Когда в модели создается новое ТС, оно добавляется в автопарк. ТС, двигаясь по УДС и достигая пункта своего назначения, удаляется из автопарка.

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

рат УДС |Сп nr^mnpi пд група

|ЬБ~^к'СДНЛЬ

Р и с. 5. Структура класса «МодельГорода»

Класс «Карта»

На рис. 6 изображена статическая диаграмма классов, реализующих модель УДС. Серым цветом на диаграмме выделены классы, образующие структуру УДС: Транспортный_район, Узел, Дуга. Экземпляры этих классов предназначены для хранения в процессе моделирования соответствующих сущностей из БД в оперативной памяти. К вспомогательным классам относятся Генератор_СП (генератор случайного потока), Дорожный знак, Светофор, Светофорнаягруппа, Датчик_на_дуге, Источник автомобилей.

Карта

■Загрузить_карту() + Квант_времени()

|Светофорная_группа |

—|Т ранспортный_район~|—

Генератор_СП |

Граф_УДС

+Загрузить_граф() +квант_времени() 1-----------

1

Светофор

Источник автомобилей!

1

начинается в

1Ц

заканчива* тся в узле

Дуга

|Дорожный_зна1Т

_|Датчик_на _дуге~|

Р и с. 6. Структура класса «Карта»

Классы Генератор СП и

Источник автомобилей. ,__, ТГ С

каждым объектом класса Транспортный_район ассоциирован генератор случайного потока

событий и несколько источников ТС. Каждый экземпляр класса

ГенераторСП соответствует случайному потоку

автомобилей, зарождающихся в выбранном транспортном районе.

Промежуток времени т между моментами

генерации двух последовательных

автомобилей в одном транспортном районе определяется как

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

Источники автомобилей располагаются на дугах графа УДС. Учитывая небольшую протяженность дуг графа УДС в городе и небольшое значение потока, вливающегося в УДС в точках-источниках, по сравнению с потоком, движущимся по дугам УДС, несколько источников,

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

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

Классы Светофор и Светофорная_Группа. Светофоры не могут быть целиком отнесены ни к

Р и с. 7. Расположение источников автомобилей

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

- класс СветофорнаяГруппа описывает группу светофоров на перекрестке, работающих совместно по одной программе (класс инкапсулирует динамические свойства светофора);

- класс Светофор описывает светофор как объект, установленный на дороге (класс инкапсулирует статические характеристики светофора).

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

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

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

Класс «Модель_ Транспортного_Средства»

Транспортное Средство в разрабатываемой системе моделирования - сложный (составной) объект. ТС характеризуется:

- постоянными характеристиками: номинальной скоростью, ускорением, замедлением;

- постоянными характеристиками конкретного ТС (маршрутом следования, который не меняется на протяжении всего времени жизни автомобиля в модели);

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

Эти характеристики представлены различными программными классами, связанными с классом

и Каждый экземпляр класса Транспорт-ноеСредство включает в себя экземпляры классов (рис. 8).

Маршрут - хранит последовательность дуг графа УДС, по которым должно проехать ТС, и текущую дугу в этой последовательности; маршрут определяется при внедрении автомобиля в модель.

Динамика - содержит в себе скорость, ускорение и расстояние от ТС до начала текущей дуги графа УДС.

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

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

Транспортное Средство отношением композиц

Смотрит вдоль

0-1 1

|,Рэтчик_на_автомобиле

иле|—і

1

1

Автомобиль

Маршрут |

Перемещает автомобиль по І

ІДінам

1

1

-| Обстановка!

71^

Анализирует

I

I

-|Блок_принятия_решений|

Определяет

I

Тактика 1 I 1 I

Р и с. 8. Модель автомобиля

характеристикам УДС, ТСОДД и других ТС).

Блок_принятия_решения - формализует зависимость тактики движения ТС от текущей обстановки; алгоритм [6] определения тактики ТС показан на рис. 9.

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

(Начало)

перекрестке, ожидая «зеленый» сигнал светофора или пропуская другой автомобиль

Р и с. 9. Алгоритм работы блока принятия решений

Динамика процесса моделирования

Для управления динамикой процесса моделирования служит таймер системы моделирования, или планировщик. Планировщик реализован в виде класса ТаймерМодели - один экземпляр на модель. В обязанности планировщика входит пересчет модельного времени и отправка сообщений (или выделение квантов времени) активным компонентам модели. Сообщения от планировщика достигают цели по связям, совпадающим с ассоциациями, которые изображены на рис. 5 и рис. 6; активация составного объекта также влечет за собой активацию составляющих его компонентов. Например, выделение квантов времени всем объектам класса Транспортное Средство происходит путем активации объектов-синглтонов классов Модель города и Автопарк (рис. 5). На рис. 10 изображены три последовательности сообщений, формирующих жизненный цикл экземпляра класса Транспорт-ноеСредство. Каждая из них начинается со срабатывания таймера модели.

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

Р и с. 10. Жизненный цикл объекта «Транспортное средство»

При этом процесс создания нового экземпляра, добавление его в список ТС модели и внедрение автомобиля в УДС ложится на один из экземпляров класса Источникавтомобилей того транспортного района, в котором сработал генератор. Третья последовательность соответствует движению ТС по графу УДС и возможному уничтожению экземпляра класса Транспортное Средство по прибытии в пункт назначения (рис. 11). Кроме передвижения ТС по графу УДС таймер модели управляет обновлением состояния объектов УДС: дуг графа УДС и светофорных групп. Каждая дуга графа УДС содержит в себе список ТС, находящихся на дуге, в той последовательности, в которой ТС расположены на дороге. В каждом цикле системного таймера происходит сортировка списков ТС на дугах графа УДС. Другими объектами, требующими активации в процессе моделирования являются светофорные группы. Объекты класса Светофорная группа должны получать управление для того, чтобы обновить свое состояние - переключить ассоциированные с ними светофоры в соответствии с заданной программой управления ТП.

таймер карта граф УДС

Квант_времени() | |

квант_времени() I

дуга

светофорная группа

сортировать_автомобили()

обновить_состояние()

Р и с. 11. Обновление статической части модели УДС

Модуль отображения результатов в ГИС

Импорт данных в MapInfo - процедура достаточно трудоемкая. В первую очередь это обусловлено особенностью работы MapInfo с внешними данными - связь с внешними данными, обычно реализуемая в современных СУБД операцией JOIN, в MapInfo осуществляется добавлением к существующим таблицам дополнительных временных полей. Для облегчения импорта данных в MapInfo разработан специальный модуль, основное назначение которого - связать различные форматы хранения

данных (база данных, CSV-файл) с элементами графа УДС, хранящегося в виде карты в MapInfo (с дугами и узлами графа УДС).

Основные операции, которые поддерживаются модулем:

- импорт из файла снимка значений интенсивностей ТП на дугах графа и величины транспортного спроса (отдельно входящего, исходящего либо суммарного);

- добавление внешних по отношению к MapInfo данных (распределения скорости, транспортной задержки, уровня шума) в виде временных столбцов к элементам графа УДС, хранящимся в таблицах MapInfo ;

- импорт из БД из выбранного пользователем снимка значений интенсивностей ТП на дугах графа и величины транспортного спроса, значений абсолютной погрешности процедуры восстановления интенсивностей и меры достоверности.

Импортируемые данные добавляются в соответствующие таблицы MapInfo и становятся атрибутами сущностей графа УДС (узлов и дуг). Это позволяет проводить анализ импортированных данных средствами MapInfo - производить выборки, строить тематические карты и т.п. Модуль отображения результатов моделирования реализован в виде динамической библиотеки (DLL) и использующей ее программы на языке MapBasic. MapBasic позволяет расширять возможности MapInfo - добавлять пользовательские панели инструментов, выполнять SQL-запросы, манипулировать объектами на карте. Программный код из DLL содержит диалоговые окна, позволяющие пользователю указать имя файла или название снимка в БД для импорта.

Проверка адекватности модели

Для проверки адекватности модели проведена серия имитационных экспериментов на тестовой модели. Граф УДС тестовой модели состоял из 30 узлов и 70 дуг (рис. 12). В эксперименте при различных значениях транспортного спроса фиксировались значения средней скорости и интенсивности ТП на одной из наиболее загруженных дуг модели. Плотность ТП оценивалась исходя из основного уравнения потока. Неопределенность значения интенсивности возле точки максимума (точки насыщения потока) обусловлена возникновением затора в моделируемой сети при приближении к точке насыщения. При возникновении затора ТП на УДС скачком переходит из одного устойчивого состояния (свободный поток) в другое устойчивое состояние (насыщенный поток) [У]. В разных экспериментах зафиксированы различные состояния ТП.

В разработанной модели воспроизвелись следующие известные свойства ТП:

- основная диаграмма транспортного потока;

- возникновение заторов при увеличении транспортного спроса и медленное смещение затора против направления движения транспортного потока;

- наличие области неустойчивости на основной диаграмме ТП в области насыщения.

По результатам анализа аварийности за 3 лет (2002-2006 гг.) выбраны 30 наиболее аварийных перекрестков (на их долю приходится около 13% всех ДТП города). На выбранных перекрестках проведены подсчеты интенсивности ТП. Подсчеты проводились дважды в день, в утренний и вечерний часы «пик», поскольку наибольший интерес представляет моделирование УДС в состоянии максимальной загруженности.

Средства разработки и среда выполнения

Разработанная система спроектирована таким образом, чтобы максимально упростить повторное использование кода без ущерба производительности. С точки зрения возможности повторного использования кода, все программное обеспечение системы можно условно разделить на две составные части: программные модули, представляющие собой законченные инструменты и не допускающие интеграции с другими программами, и модули (паттерны), которые могут быть использованы по-

ПдаеШШРЕ |

ИАҐ МйвМртММ* НСйеЛаиМ Bptnfl. . £1 31

Р и с. 12. Граф УДС тестовой модели. Образование затора

вторно в составе других программ.

Основной средой разработки выбран Visual Studio.NET, все модули, допускающие повторное использование, представляют собой сборки .NET и предоставляют программный интерфейс приложения (API). Для реализации этих компонентов выбран язык C#.

БИБЛИОГРАФИЧЕСКИЙ СПИСОК

1. Михеева Т.И. Построение математических моделей объектов улично-дорожной сети города с использованием геоин-формационных технологий // Информационные технологии. 2006. №1. С.69-75.

2. Михеева Т.И., Михеев С.В. Модели наследования в системе управления дорожным движением // Информационные технологии. 2001. № 7. С. 50-54.

3. Михеева Т.И. Моделирование движения в интеллектуальной транспортной системе / Вестник Самарского гос. аэрокосм. ун-та. 2004. С. 118-126.

4. Клинковштейн Г.И., Афанасьев М.Б. Организация дорожного движения: Учеб. для вузов. 5-е изд., перераб. и доп. М. : Транспорт, 2001. 247 с.

5. Рихтер Дж. CLR via C#. Программирование на платформе Microsoft . NET Framework 2.0 на языке C#. Мастер-класс: Пер. с англ. М.: Изд-во «Русская Редакция», 2007. 656 с.

6. Кормен Т., Лейзерсон Ч., РивестР. Алгоритмы: построение и анализ. М.: МЦНМО, 2001. 960 с.

7. Михеева Т.И. Управление транспортными потоками. Учет ДТП. Самара: Самар. гос. тех. ун-т, 2006. 125 с.

Статья поступила в редакцию 30 января 2008 г.

УДК 681.3 Г.Н. Рогачев

ПРОГНОЗИРОВАНИЕ ВЕРХНЕЙ ГРАНИЦЫ КРИТЕРИЯ КАЧЕСТВА В ЗАДАЧЕ ОПТИМАЛЬНОГО ПО БЫСТРОДЕЙСТВИЮ УПРАВЛЕНИЯ ПРОЦЕССОМ ИНДУКЦИОННОГО НАГРЕВА*

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

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

Понятие области достижимости предоставляет удобный язык, на котором могут быть описаны различные задачи теории управления. Если известны области достижимости, то можно легко оценить возможности управления. Например, часто возникает такой вопрос: можно ли перевести систему в некоторое предписанное состояние x * в предписанный момент T > s ? Для ответа на этот вопрос достаточно проверить, принадлежит ли вектор x * области достижимости. Предположим, что решается более общая задача о приведении системы в заданное терминальное многообразие N в момент T. Ясно, что решение этой задачи эквивалентно выяснению того, пересекается ли многообразие N с множеством достижимости. Зная области достижимости, мы можем проанализировать, как решение этих задач зависит от момента времени T и множества N . Пусть, наконец, необходимо решить задачу оптимального быстродействия. Эта задача состоит в приведении системы на заданное множество за кратчайшее время, что имеет и теоретическое значение, и практический интерес. С точки зрения областей достижимости вопрос состоит в следующем: требуется найти такое минимальное время T *, чтобы область достижимости в этот момент пересекалась с заданным множеством.

Эти примеры подчеркивают полезность использования областей достижимости в теории и практике управления. К сожалению, за исключением очень узкого класса систем, точное вычисление областей достижимости невозможно. Приближенные численные методы построения множеств дости-

* Работа поддержана грантом РФФИ (проект 08-08-00383-а)