Создание модели

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

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

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

Чтобы оптимизировать модель

1.Создайте оптимизационный эксперимент;

2.Задайте целевой функционал;

3.Задайте оптимизационные параметры;

4.Задайте ограничения, которые будут наложены на значения параметров и переменных (опционально);

5.Задайте условия остановки прогона;

6.Задайте условия остановки оптимизации;

7.Запустите оптимизационный эксперимент;

Процесс оптимизации представляет собой итеративный процесс, который состоит в том, что:

•Оптимизатор OptQuest выбирает допустимые значения оптимизационных параметров и запускает модель с этими значениями;

•Завершив "прогон" модели, OptQuest вычисляет значение целевой функции на момент завершения;

•Оптимизатор анализирует полученное значение, изменяет значения оптимизационных параметров в соответствии с алгоритмом оптимизации и процесс повторяется заново.

Теперь перейдем к разработке модели.

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

В работе будет использоваться блоки такие, как:

Source (см. рис. 4)

Рисунок 4 –Блок Source

Создает заявки. Обычно используется в качестве начальной точки потока заявок.

Заявки могут быть либо базового для заявок класса Entity, либо любого класса пользователя, унаследованного от этого базового класса. Можно сконфигурировать объект так, чтобы он создавал заявки других типов, указав конструктор нужного класса в параметре Новая заявка, а также задать действие, которое должно выполняться перед тем, как новая заявка покинет объект, и связать с заявкой определенную фигуру анимации.

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

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

SelectOutput (см. рис. 5)

Рисунок 5 –Блок SelectOutput

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

Может использоваться для сортировки заявок согласно заданному критерию, для случайного разделения потока заявок на части и т.д..

Queue (см. рис. 6)

Рисунок 6 –Блок Queue

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

Заявка может покинуть объект Queue различными способами:

•“обычным способом” через порт out, когда объект, следующий в блок-схеме за этим объектом, готов принять заявку;

•через порт outTimeout, если заявка проведет в очереди заданное количество времени (если включен режим таймаута);

•через порт outPreempted, будучи вытесненной другой поступившей заявкой при заполненной очереди (если включен режим вытеснения);

•“вручную”, путем вызова функции remove() или removeFirst().

Поступающие заявки помещаются в очередь в определенном порядке: либо согласно правилу FIFO (в порядке поступления в очередь), либо согласно приоритетам заявок. Приоритет может быть либо явно храниться в заявке, либо вычисляться согласно свойствам заявки и каким-то внешним условиям. Очередь с приоритетами всегда примет новую входящую заявку, вычислит ее приоритет и поместит ее в очередь в позицию, соответствующую ее приоритету. Если очередь будет заполнена, то приход новой заявки вынудит последнюю хранящуюся в очереди заявку покинуть объект через порт outPreempted (но если приоритет новой заявки не будет превышать приоритет последней заявки, то тогда вместо нее будет вытеснена именно эта новая заявка).

Delay (см. рис. 7)

Рисунок 7 –Блок Delay

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

Одновременно могут быть задержаны сразу несколько заявок (не более заданной вместимости объекта capacity). Заявки задерживаются независимо друг от друга – время задержки вычисляется отдельно для каждой заявки. Как только время задержки истекает, заявка тут же покидает объект. Если объект Delay заполнен полностью, то новую заявку он не примет, и в этом случае Вам нужно будет поместить перед ним специальный объект буферизации, например, Queue.

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

Service (см. рис. 8)

Рисунок 8 –Блок Service

Захватывает для заявки заданное количество ресурсов, задерживает заявку, а затем освобождает захваченные ею ресурсы (заданных указанным объектом ResourcePool). Объект ResourcePool может быть задан как графически, путем соединения его порта с портом access этого объекта Service, так и с помощью параметра Объект ResourcePool (в случае одновременого использования обоих способов будут захватываться ресурсы объекта, указанного в параметре).

Эквивалентен последовательности объектов Seize, Delay, Release (и сам реализован именно таким способом) и должен использоваться в тех случаях, когда все, что требуется - это задержать захваченные ресурсы на заданное время, а затем их отпустить. Большинство параметров этих вложенных объектов вынесены в интерфейс объекта Service.

Вместимость вложенного объекта delay установлена максимально допустимой (поскольку она фактически все равно будет ограничена количеством ресурсов заданного типа).

ResourcePool (см. рис. 9)

Рисунок 9 –Блок ResourcePool

Задает набор ресурсов, которые могут захватываться и освобождаться заявками с помощью объектов Seize, Release и Service. Есть два способа моделирования ресурсов: они могут быть заданы в модели как индивидуальные объекты, а могут просто как их количество. Если ресурсы заданы в модели как индивидуальные объекты, то каждый такой ресурс может иметь отличные от других ресурсов свойства, отображаться на презентации, хранить статистику своего использования и т.д. Базовым классом для таких ресурсов является ResourceUnit, Вы можете создать свои собственные подклассы этого класса. Но если таких ресурсов будет достаточно много, и на моделирование каждого отдельного ресурса будет тратиться определенное время и память. И если все такие ресурсы будут идентичными, то имеет смысл не моделировать каждый такой ресурс отдельно, а рассматривать их в целом, то есть, захватывать и освобождать просто определенное количество такого агрегированного ресурса. Примером ресурсов такого типа могут быть деньги, компьютерная память, складская площадь и т.д.

Если запросы от объектов Seize и Service не могут быть удовлетворены в текущий момент времени, эти запросы помещаются в очередь объекта ResourcePool. Эта очередь может быть либо обычной очередью FIFO, либо учитывать приоритеты запросов.

При выборе ресурса (если ресурсы моделируются как индивидуальные объекты) по запросу заявки объект NetworkResourcePool выбирает тот свободный ресурс, который оставался свободным на протяжении наибольшего времени. Такой подход со временем приведет к равномерному использованию всех ресурсов.

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

Sink (см. рис. 10)

Рисунок 10 –Блок Sink

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

Для успешного уничтожения заявки необходимо выполнение трех условий:

1.Если заявка находится в сети, то она должна быть удалена из этой сети с помощью объекта NetworkExit.

2.Заявка не должна обладать ни одним ресурсом или сетевым ресурсом.

3.Если заявка содержит другие заявки, то они тоже должны удовлетворять вышеуказанным условиям.

Если какое-то из этих условий не выполняется, объект Sink выдает ошибку.

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

Рисунок 11 – Диаграмма состояний

Модель отделения банка, построенная в AnyLogic см. рис. 12.

Рисунок 12- Модель отделения банка

Также мной создано меню подбора параметров для данной модели, позволяющая при запуске быстро найти наилучшее варианты работы отдела банка. (см. рис. 13)

Рисунок 13 – Меню выбора параметров

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

Дата добавления: 2015-08-31