3.2.6. Модель пополнения запасов

Представим себе киоск, торгующий пивом и квасом на разлив. Будем считать, что 60 % покупателей берут пиво, а 40 % – квас. Количество напитка, взятого одним покупателем, будем считать случайной величиной, имеющей треугольную функцию распределения. В случае покупки пива минимальное, наиболее вероятное, и максимальное значения этой функции 0, 2 и 15 литров соответственно. При покупке кваса те же параметры принимают значения 0, 0.5 и 3 литра. Конечно, в реальности минимальное количество купленного напитка − это один стакан, затем идут значения 0.5, 1, 2, 3, 5 и т. д. литров в соответствии со стандартными ёмкостями используемой посуды. Однако, в целях упрощения модели, мы будем использовать непрерывную функцию распределения с указанными параметрами.

Далее допустим, что пиво и квас хранятся в ёмкостях объёмом 300 и 100 литров соответственно. Пусть заказ пива делается в тот момент, когда его остаётся 20 литров, а заказ кваса − при остатке10 литров. Время выполнения заказа имеет треугольную функцию распределения с параметрами 0.5, 1 и 2 часа в обоих случаях. Ещё одним параметром, влияющим на нашу систему, является поток клиентов. Будем считать, к примеру, что он описывается экспоненциальной функцией распределения с характерным временем 5 минут.

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

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

Полная формулировка задачи является весьма непростым делом, поэтому мы здесь не будем ставить такую цель, ограничимся пока лишь построением грубой модели. Тем не менее, ясное понимание ограничений модели является необходимым условием её успешного использования. Поэтому эти ограничения надо в каждом случае чётко обозначать. На данном примере мы продемонстрируем использование субмоделей, анимации, блоков панели Advanced Transfer (Улучшенное перемещение) и управление объёмом ресурсов при помощи системной функции mr.

Очевидно, наша модель должна начинаться с блока Create, в который мы занесём параметры функции распределения, описывающей прибытие клиентов. Далее надо поставить блок Decide, в котором клиенты будут разделяться на потребителей пива и кваса. Наверное, найдутся люди, приобретающие одновременно и пиво, и квас, но мы пока не будем брать их в расчет в целях упрощения модели. Очевидно, что после блока Decide должны находиться две однотипных ветви модели, описывающие процессы обслуживания клиентов, приобретающих пиво и квас. Обе этих ветви должны оканчиваться блоком Exit, в котором клиенты покидают систему. Назовём нашу модель BeerAndKvass1.

Представим две однотипные ветви модели в качестве субмоделей, как это изображено на рис. 3.59. Для этого мы здесь воспользовались блоками Create, указав в них в графе Type – параметр Submodel. В результате блок, обозначающий субмодель, выглядит так же, как обычный блок Create за исключением того, что в его правом верхнем углу появляется небольшая стрелка. Субмодели, создаваемые другими способами, имеют вид незакрашенных прямоугольников разного размера.

Рис. 3.59. Модель пополнения запасов

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

Чтобы начать создание субмодели, надо навести на неё курсор и сделать щелчок правой клавишей мыши. Из появившегося меню надо выбрать команду Edit Submodel (Редактировать субмодель), после чего на экране появится пустое окно субмодели с точками входа (слева) и выхода (справа). Готовая субмодель, описывающая процессы продажи и пополнения запасов пива, представлена на рис. 3.60.

В блоке Beer Ordering (Заказ пива) определяется количество пива, которое собирается приобрести покупатель. На рис. 3.61 представлен образец заполнения диалогового окна этого блока. Здесь значение случайной величины BeerAm (от словосочетания Beer Amount – количество пива) задаёт объём покупки. Это значение определяется при помощи функции tria, задающей в Arena треугольное распределение случайных величин. В силу того, что для каждого клиента должна быть определена своя величина BeerAm, она не может иметь тип Variable (Переменная), так как присвоение значения переменной может быть инициировано любым объёктом, находящимся в системе. Для этого лучше подходит тип Attribute (Атрибут).

Рис. 3.60. Субмодель продажи и пополнения запасов пива

Блок Beer Checking предназначен для удвоения объекта (покупателя). Сам покупатель отправляется за пивом, а его двойник одновременно идёт проверять уровень пива в баке. Пройдём сначала путь покупателя по верхней цепочке блоков. В первом из них Start Beer Pouring (Начать наливать пиво) захватывается один из двух необходимых ресурсов – пивной кран (Beer Tap). Образцы заполнения диалоговых окон приведены на рис. 3.62 и 3.63.

Рис. 3.63. Заполнение диалогового окна блока Start Beer Pouring

В следующем блоке Beer Pouring (Налить пиво) происходит захват другого ресурса – пива (Beer) в нужном количестве BeerAm. Пример заполнения диалогового окна дан на рис. 3.64. Обратите внимание на то, что время обслуживания в блоке Beer Pouring задаётся установкой в графе Delay Type значения Expression (Выражение). В графе Units (Единицы измерения времени) устанавливается значение Minutes. В графе Expression установлено BeerAm. Это означает, что время обслуживания клиента в минутах равно количеству наливаемого пива в литрах. Идея заключается в том, что должна соблюдаться пропорциональная зависимость между временем и количеством отпускаемого напитка. Это кажется разумным предположением.

Рис. 3.64. Заполнение диалогового окна блока Beer Pouring

Рис. 3.65. Заполнение диалогового окна блока Beer Level Change

Блок Beer Level Change (Изменение уровня пива) предназначен, как следует из названия, для уменьшения количества пива в баке. Образец заполне­ния   диалогового окна представлен на рис. 3.65. Здесь используется системная функция mr, показывающая объём ресурса, имя которого (Beer) указано в качестве аргумента. Заметим, что тип функции mr надо указывать, как Other (Иной). В данном случае мы сталкиваемся с необходимостью использования ресурса переменного объёма.

В блоке End Beer Pouring (Закончить наливать пиво) происходит освобождение захваченных ресурсов. Возникает вопрос: Почему нельзя объединить блоки Start Beer Pouring, Beer Pouring и End Beer Pouring или хотя бы первые два из них в один? Вы можете поэкспериментировать и убедиться, что в этом случае модель не будет работать. Причиной, по-видимому, является то, что при наличии нескольких ресурсов, которые надо захватить одновременно, возникает патовая ситуация, когда один объект захватывает один ресурс, а другой объёкт захватывает другой ресурс, в результате этого они блокируют возможность дальнейших действий друг для друга. Чтобы избежать такого положения, приходится организовывать последовательности из нескольких блоков. Здесь представлен обычный способ разрешения указанного конфликта.

Обратимся теперь к процессу пополнения запасов пива. Начинается этот процесс в блоке Decision to Start Beer Refilling (Решение о начале процесса пополнения запаса пива), образец заполнения которого представлен на рис. 3.66. Здесь выбор одного из двух направлений движения объекта происходит по условию (Type: 2-way by Condition). Условием является одновременное равенство нулю значения переменной BeerSignal и снижение уровня пива в баке ниже критического уровня. Последнее выражение можно записать при помощи неравенства:

mr(Beer)<=BeerCriticalLevel. (3.5)

Рис. 3.66. Содержимое блока Decision to Start Beer Refilling

Обратите внимание, что вместо обычного знака =, который обозначает присвоение значения для записи логических функций, используется знак ==, который обозначает сравнение. Одновременное выполнение двух условий проверяется при помощи логического оператора .and. (левая и правая точки входят в состав оператора, их писать обязательно). Выражение, содержащее этот оператор, принимает значение 1 (True – Истина), если оба условия, стоящие справа и слева от оператора .and., удовлетворяются и значение 0 (False – Ложь) − в ином случае. Посредством выражений, содержащих несколько операторов .and., можно проверять одновременно выполнение и более чем двух условий. Параметр BeerCriticalLevel (Критический уровень пива) задаёт, как это следует из названия, тот уровень пива, при котором инициируется процесс пополнения его запаса. Переменная BeerSignal служит в качестве флага, значение которого устанавливается, равным 1, если заказ на пополнение запаса пива инициирован, и сбрасывается на 0 после его выполнения. Эти действия предотвращают многократное инициирование одного и того же заказа.

Чтобы меньше загромождать модель, сама последовательность действий при пополнении запаса пива может быть организована в виде субпроцесса (рис. 3.60). Если открыть блок субпроцесса Beer Refilling (Пополнение запасов пива), то внутри него мы найдём цепочку, изображённую на рис. 3.67. Здесь, в блоке Start Beer Refilling (Начало процесса пополнения запаса пива), значение флага BeerSignal устанавливается равным 1.

Рис. 3.67. Схема субмодели Beer Refilling

В блоке Continue Beer Refilling (Продолжить пополнение запаса пива) производится задержка выполнения заказа на пополнение запаса пива в соответствии с условиями задачи (рис. 3.68).

Рис. 3.68. Заполнение диалогового окна блока Continue Beer Refilling

В

Рис. 3.69. Пример заполнения окна блока End Beer Refilling

На этом разбор логики процесса покупки и восполнения запасов пива можно считать завершённым. Теперь можно вернуться к рассмотрению всей системы в целом (рис. 3.59). Субмодель Getting Beer (Покупка пива) мы наполнили содержанием, а субмодель Getting Kvass (Покупка кваса) мы для начала замкнём накоротко, т.е. соединим напрямую вход и выход субмодели (внутри блока). После этого можно начать отладку модели.

Д

Рис. 3.70. Заполнение диалогового окна вывода значения функции mr

Таблицы Resource и Variable должны выглядеть так, как это показано на рис. 3.71 и 3.72. Необходимо явным образом указать в таблицах начальные значения переменных BeerCriticalLevel, FullTankBeer и BeerSignal, а также объём ресурса Beer. В настройках процесса вычислений укажем одну репликацию продолжительностью, к примеру, 30 часов. Если нигде не допущено ошибок, то модель должна заработать при выполнении команды Go (Счёт). При этом можно наблюдать, как объекты движутся от входа к выходу, возле блока Start Beer Pouring иногда возникает очередь, уровень в баке уменьшается, и пиво заканчивается. После этого очередь начинает быстро расти до тех пор, пока не прибудет новая партия пива и резервуар будет полностью наполнен. Тогда очередь начнёт рассасываться. На рис. 3.73 представлена субмодель в процессе работы.

Рис. 3.71. Заполнение таблицы Resource

Рис. 3.72. Заполнение таблицы Variable

Убедившись в том, что субмодель Getting Beer работает нормально, скопируем её в блок субмодели Getting Kvass. Сделаем необходимые изменения имён и значений параметров. Изначально мы старались называть элементы модели так, чтобы их легко было переименовать, заменяя слова Beer на Kvass (как легко догадаться, квас по-английски Kvass). Стоит попутно заметить, что всем блокам мы пытались дать содержательные имена, отражающие функциональное назначение блоков. Однако это является нелёгким делом, даже в случае такой простой задачи. Поэтому на практике большинство блоков остаётся с их оригинальными именами (типа Assign 3 и т.д.), которые мало что могут сказать о том, для чего эти блоки предназначены.

Рис.3.73. Работа субмодели

Возвращаясь к нашей модели, заметим, что, после копирования и изменения имён компонентов, не все они автоматически добавляются в соответствующие таблицы. Так, открыв таблицу Variable, мы обнаружим, что в ней появилась новая переменная KvassSignal, но нет переменных KvassCriticalLevel и FullTankKvass, которые необходимо занести вручную (рис. 3.74). В таблице Resource необходимо указать объём нового ресурса Kvass. Если все изменения проделаны правильно, модель должна заработать по команде Go. Предоставим вам самим добиться корректной работы модели.

Рис. 3.74. Вид таблицы Variable