Определение процесса обслуживания в системе

Теперь приступим к описанию непосредственнно процесса обслуживания. Процесс обслуживания будет описываться блочной диаграммой, собранной из блоков библиотеки Enterprise Library. Соответствующая модель называет­ся Emergency department Phase 3.

В качестве источника заявок будем использовать блок source. Выходящие из source заявки ничего не знают о сети, поэтому в блок-схему необходимо добавить блок, после которого заявка будет помещаться в конкретный узел определенной сети. Это блок NetworkEnter со следующими параметра­ми: узел сети, в который необходимо добавить заявку (параметр des: animation.entrance, см. рис. 14.3) и имя сети (сетей в сложной системе может быть несколько). В нашей модели есть единственная сеть с именем network.

Первый шаг в движении пациентов по нашему госпиталю состоит в том, что они подходят к регистратуре и проходят регистрацию. Для перемещения заявок по сети используется блок NetworkMoveTo с параметром узел назна­чения. На рис. 14.3 ЭТОТ узел МЫ обзначили rectRegistration.

Очевидно, что при случайном интервале времени между прибытиями паци­ентов у регистрации может собраться очередь. Поэтому до самой процедуры регистрации необходимо поставить уже знакомый нам блок Queue и уже по­сле него вставить в диаграмму блок Delay, моделирующий прохождение ре­гистрации. Начальный фрагмент блочной диаграммы процесса обслужива-

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

Вместимость задержки у регистрации (параметр capacity) оставим равной единице — пусть только один пациент может выполнять регистрацию. Фактически, каждому элементарному шагу этого процесса соответствует свой блок, и обратно, любой блок имеет ясный смысл шага процесса об­служивания.

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

Продолжим разработку диаграммы процесса обслуживания пациентов в гос­питале. После регистрации используем блок NetworkMoveTo для перемеще­ния пациента в комнату ожидания. Задержка на заполнение формы модели­руется с помощью блока Delay. Вместимость блока (параметр capacity) выставим сообразно площади этой комнаты, пусть будет 100. Это означает, что в комнате ожидания может находиться одновременно до 100 пациентов, заполняющих формы.

Перейдем теперь к самой важной части — работе с ресурсами. После запол­нения формы пациент ждет, пока не освободится комната первичного ос­мотра (у нас этот ресурс моделируется классом TriageRoom, от термина triage — первичный осмотр). В терминах модели это интерпретируется так: заявка захватывает ресурс. Для работы со статическими (неперемещаемыми) ресурсами используется блок NetworkseizeQ, в который также встроена оче­редь. В этой очереди заявки ожидают, если нет свободных ресурсов.

В соответствии с описанным ранее процессом обслуживания, после того как пациент захватил ресурс (комнату первичного осмотра), он перемешается в эту комнату в сопровождении медсестры. Такой вариант использования ре­сурсов типа "персонал" (staff) является достаточно частым, поэтому в биб­лиотеку встроен специальный блок NetworkMoveTowithQ. Это аналог блока NetworkMoveTo, но для данного типа блока можно указать, в сопровождении какого ресурса типа staff пациент перемещается в указанный узел сети. Кроме того, можно указать, отпустить персонал после перемещения или нет. Поскольку в соответствии с правилами этого госпиталя та же медсестра, которая сопровождала пациента, выполняет и первичный осмотр, параметр reieaseEscortAfterMove изменен. Он установлен в false: ресурс не осво­бождать. В качестве узла назначения здесь используется предустановленное значение параметра "location of last seized static resource". Это оз­начает, что пациент переместится в тот узел сети, в котором располагается последний захваченный статический ресурс, т. е. комната первичного ос­мотра.

Фрагмент блочной диаграммы процесса обслуживания пациентов в госпита­ле до данного момента рассмотрения будет иметь вид рис. 14.7.

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

Окончание процесса обслуживания (рис. 14.8) моделируется тоже просто.
После того как первичный осмотр выполнен, пациент отпускает медсестру
(блок freeNurse типа NetworkFree). Теперь, находясь в комнате первичного
осмотра, пациент должен дождаться, пока освободится процедурная комна­
та. Поэтому блок releaseTriageRoom, в котором освобождается ресурс
(комната первичного осмотра) помещен после блока захвата процедурной
комнаты seizeProcRoom.                                                                         \

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

 

ции, в частности, множества данных. Но даже и при простом визуальном анализе анимированного процесса (рис. 14.9) ясно, что ресурсы здесь рас­пределены неравномерно: процедурные комнаты почти не используются, а комнаты первичного осмотра перегружены, медсестер не хватает, пациен­ты должны ожидать в комнате ожидания длительное время.

Отметим, что вся модель построена с помощью только блоков библиотеки Enterprise Library, фактически, без единой строки программного кода.

Заключение

Дискретно-событийное моделирование имеет огромную сферу приложе­ний — от логистики и систем массового обслуживания до транспортных и производственных систем. Некоторые авторы считают, что парадигма моде­лирования, основанная на блок-схемах обработки потоков транзакций, яв­ляется единственным представителем имитационного моделирования: боль­шое число монографий с названием "Имитационное моделирование" посвящены изложению исключительно этого стиля моделирования.

Удачно выбранные базовые принципы, лежащие в основе AnyLogic, позво­ляют строить на этой платформе дискретно-событийные модели в стиле, традиционном для этой области моделирования: стиле блочных структурных диаграмм. Библиотека Enterprise Library позволяет создавать модели весьма сложных систем без использования программного кода. Как и другие биб­лиотеки, она открыта для пополнения. AnyLogic содержит мощные базовые средства разработки дискретно-событийных систем (таймеры, порты, сооб­щения, события, стейтчарты и т. п.), с помощью которых можно построить повторно используемые блоки для высокоуровневого моделирования в лю­бой прикладной области, в которой дискретно-событийная парадигма ими­тационного моделирования является удобной и адекватной.

Отметим однако, что модели, процессы в которых удобно представлять в дискретном времени, не исчерпываются только системами обслуживания. Модель пешеходного перехода, построенная в главе 6, не относится к этому классу, хотя для ее разработки используются дискретное представление вре­мени, события, системы переходов и другие средства событийного модели­рования. Другим примером дискретных систем, не относящихся к классу систем массового обслуживания, являются протоколы коммуникации. Со­стояния и системы переходов, таймеры, события и сообщения являются традиционными средствами для спецификации протоколов уже почти 40 лет. Для быстрого моделирования протоколов и распределенных алго­ритмов в AnyLogic может быть разработана библиотека повторно используе­мых объектов в этой области, аналогичная Enterprise Library.

 

Глава 15

■

Многоагентные системы

Существует множество определений понятия агента. Общим во всех этих определениях является то, что агент — это некоторая сущность, которая обладает активностью, автономным поведением, может принимать решения в соответствии с некоторым набором правил, может взаимодействовать с окружением и другими агентами, а также может изменяться (эволюциони­ровать). Многоагентные (или просто агентные) модели используются для исследования децентрализованных систем, динамика функционирования которых определяется не глобальными правилами и законами, а наоборот, эти глобальные правила и законы являются результатом индивидуальной активности членов группы. Цель агентных моделей — получить представле­ние об этих глобальных правилах, общем поведении системы, исходя из предположений об индивидуальном, частном поведении ее отдельных ак­тивных объектов и взаимодействии этих объектов в системе. Рост произво­дительности компьютеров и достижения в информационных технологиях, использованные в AnyLogic, сделали возможным реализацию агентных мо­делей, содержащих десятки и даже сотни тысяч активных агентов.

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

При создании агентной модели логика поведения агентов и их взаимодейст­вие не всегда могут быть выражены чисто графическими средствами, здесь часто приходится использовать программный код. Это не является особен­ностью только AnyLogic: например, пакеты Swarm и RePast для разработки агентных моделей используют только программный код на языке Java.

В отличие от них, AnyLogic предоставляет для разработки агентных моделей всю мощь визуальной графической разработки: стейтчарты, события, тайме­ры, синхронное и асинхронное планирование событий, библиотеки ранее определенных активных объектов — все это оказывается удобным и естест­венным при разработке агентных моделей. Однако разработчик обычно должен включать в агентную модель фрагменты кода на языке Java.

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

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

Агенты в AnyLogic

Агент естественно реализовать с помощью базового объекта AnyLogic — актив­ного объекта. В модели на AnyLogic можно создавать классы активных объектов и далее использовать в модели любое число экземпляров этих классов. Активный объект имеет параметры, которые можно менять извне, переменные, которые можно считать памятью агента, а также поведение (рис. 15.1).

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

Поведение агентов

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

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

На рис. 15.2 представлен стейтчарт, выражающий переход агента из одной возрастной группы в другую, что было необходимо в модели изменения по­пуляции в главе 13. Наряду со стейтчартами, для спецификации поведения агентов могут использоваться таймеры, функции — весь арсенал средств, доступный в Any Logic, в любых их комбинациях.

Интерфейс агентов

Все средства взаимодействия объектов, доступные в AnyLogic, могут исполь­зоваться для построения агентных моделей. Рисунок 15.3 показывает эти возможности.

Во-первых, это явно определенные интерфейсные объекты: порты и интер­фейсные переменные. На рис. 15.3 агенту с именем agent в порт с именем port можно послать из среды, в которой этот агент определен, сообщение message, вызвав функцию receive этого порта. Изменение интерфейсной переменной можно выполнить простым присваиванием, однако для того, чтобы изменение переменной было учтено в условиях, влияющих на пове­дение агента, следует вслед за оператором присваивания вызвать функцию setModif ied этого агента (как это было объяснено в главе 7).