Имитационное моделирование примеры программ

Использование имитационного моделирования для оптимизации бизнеса является своего рода палочкой-выручалочкой для менеджмента. Данный инструмент дает возможность определить, как изменения повлияют на компанию при эксперименте на модели, а не на «живой» фирме. Остановимся более подробно на инструкции.

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

Имитационное моделирование. Лекция 1

Так каким же образом построить правильный бизнес, не ставя эксперименты над фирмой и сотрудниками? Как связана оптимизация бизнеса и имитационное моделирование? В данной статье мы постараемся ответить на все эти вопросы.

Разработка имитационных моделей бизнес-процессов в AnyLogic

Интеграция со всеми популярными IT-системами: 1C/SAP/ORACLE/MES/POWER BI и т.д.

• Создание цифровой копии реальной бизнес-системы;
• Глубокий анализ, поиск «узких мест», оптимизация процессов;
• Оперативное планирование.

Что такое имитационное моделирование

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

В первую очередь оптимизации подвергаются такие показатели, как:

• затраты процесса;
• длительность процесса;
• объем произведенного продукта или количество обслуженных клиентов.

Нерезультативные значения этих параметров снижают эффективность процессов, что в свою очередь приведет к потере финансового актива организации и недовольству руководителя. Почему данные параметры выделяются как ключевые? Высокая цена бизнеса-процесса напрямую повышает затраты фирмы. Длительное выполнение процесса зачастую приводит к запоздалому получению результатов, когда они уже будут не актуальны. Недостаточное количество продукта организации — показатель даже не требует комментариев.

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

Имитационное моделирование систем массового обслуживания в AnyLogic. Урок 1.

Чтобы определить стоимость процесса вместе с имитационным моделированием, целесообразно выполнить функционально-стоимостный анализ (сокращенно — ФСА). Это способ расчета себестоимости товара, который отличается от классического тем, что акцент ставится на подсчете стоимости процессов, требуемых для производства продукта и осуществления услуги, а не на детальном разделении затрат на прямые и косвенные с группировкой трат по статьям калькуляции. ФСА основывается на положении о том, что для производства товара следует выполнить ряд процессов, на осуществление которых затрачиваются ресурсы. Стоимость бизнес-процесса определяется методом переноса цены ресурсов на стоимость каждого этапа процесса. Непосредственно сумма расходов на выполнение включительно всех этапов составляет себестоимость товара.

Проведение имитационного моделирования

Проведение имитационного моделирования подразумевает выполнение 4 ключевых этапов:

1. Построение модели процессов, осуществление которых нужно оптимизировать.
2. Старт имитации выполнения процессов утвержденной модели.
3. Анализ полученных данных.
4. Повторение трех вышеперечисленных пунктов для альтернативных сценариев осуществления процесса и выбор максимально подходящего.

Более подробней процесс выглядит так:

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

Имитационное моделирование на реальных примерах

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

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

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

Чтобы смоделировать все разнообразия подобных ситуаций, следует учитывать некоторые факторы:

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

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

Алгоритм подготовки бизнес-процесса к проведению имитационного моделирования

Первое, что следует сделать, это обозначить событие, которое будет сигналом для запуска выполнения процесса — стартовое событие. Допустим, сигналом для запуска выполнения процесса под названием «Подготовка коммерческого предложения» будет событие «От заказчика поступил запрос на предложение». Любое стартовое событие может появляться с разной периодичностью и интенсивностью, например, звонки от заказчиков поступают в среднем каждые 10 минут, проводить плановую проверку оборудования и оснащения нужно раз в несколько месяцев, а совещание у руководителя проводится раз в неделю ровно в 10 утра по вторникам. Очевидно, что группа событий появляется в определенные моменты, а другая часть — через некоторые интервалы. При этом и момент времени, и интервалы между повторениями событий могут быть случайными параметрами, для которых прописываются законы их возникновения.

Для любого шага процесса нужно задать длительность, которая по определению может являться константой или случайной величиной. Допустим, длительность этапа «Шлифовка детали», осуществляемая станком ЧПУ, равна точно 3 минутам. Но если станок делает шаг за фиксированное время, то в отношении людей это не всегда работает, поскольку их поведение сложное и непредсказуемое.

На выполнение такого простого этапа, как «Внесение данных о заявке клиента в систему» у одного исполнителя уходит 5 минут, а у другого работника — 15. Также время выполнения этапа может стать случайной величиной по объективным обстоятельствам. Процесс «Ответ клиенту на звонок» может занимать от 1 до 40 минут, в зависимости от заказчика и цели его телефонного обращения.

При описании бизнес-процесса крайне важно обращать внимание на тот факт, что не во всех случаях возможна линейная последовательность шагов. Довольно часто выбор следующего этапа зависит от некоторых условий, например, «Текущая дата», «Объем уже обработанных заготовок». Иногда выбор дальнейшего шага будет иметь вероятностную специфику, например, вероятность того, что договор будет согласован с клиентом составит 0,8, а вероятность, что заказчик пришлет замечания и комментарии к тексту договора — 0,4.

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

• трудовые;
• материальные.

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

Например, для осуществления шага «Сборка автомобиля» требуется трудовой ресурс «Рабочий» и материальный «Комплектующее изделие». Цена изделия составляет 2000 рублей, цена рабочего — 200 рублей (дневная смена) или 250 рублей (ночная смена). Если сборка автомобиля выполняется за 4 часа, причем два из них — в дневное время, а два — в ночное, то цена использования трудового ресурса «Рабочий» будет 900 рублей. Соответственно, итоговая стоимость ресурсов в переносе на стоимость шага процесса составит 2900 рублей.

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

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

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

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

• распознать «бутылочные горлышки» среди всех трудовых ресурсов — так называемые перегруженные ресурсы, к которым всегда выстраивается очередь задач (этапов, шагов процессов), вследствие чего они тормозят выполнение процессов;
• идентифицировать трудовые ресурсы с неполной загрузкой;
• провести анализ производства и потребления материальных ресурсов и выявить наличие проблем дефицита или перепроизводства. Недостаток приводит к увеличению продолжительности выполнения процесса, а излишки или закупка ресурсов в повышенном количестве, превосходящем текущие потребности — к издержкам на запасы.

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

Плюсы имитационного моделирования

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

На все данные вопросы можно получить ответ ДО момента, когда фирма начнет свою деятельность и выяснит, что материальных ресурс все время не хватает, а трудовые — перегружены.

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

Недостатки имитационного моделирования

Однако наравне со многими преимуществами имитационного моделирования, существует и ряд недостатков.

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

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

Хотите получать подобные статьи по четвергам?
Быть в курсе изменений в законодательстве?
Подпишитесь на рассылку

Источник: www.1cbit.ru

3.2. Инструментальные средства имитационного моделирования

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

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

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

Предположим, пиктограмма представляет устройство обслуживания в какой-либо системе, в этом случае диалоговое окно позволяет уточнить информацию о числе параллельных устройств обслуживания, распределении времени обслуживания для каждого из них, о том, может ли устройство прийти в неисправное состояние (если да, то каким образом). В то же время разработчики предметно-ориентированных программ моделирования сделали свои программные средства более гибкими, обеспечив в некоторых местах модели возможность программировать с использованием внутреннего языка программирования. По крайней мере, в одной программе моделирования сейчас можно изменять существующие моделирующие конструкции и создавать новые. Все это, по мнению Аверилла Лоу и Дэвида Кельтона [2], привело к тому, что отличия между языками имитационного моделирования и программами моделирования стали менее заметными.

Таким образом, существует два типа пакетов имитационного моделирования. Универсальные пакеты имитационного моделирования предназначены для различных целей, но они могут иметь специальные функции для решения одного конкретного вида задач (например, моделирования производственных систем, систем связи или модернизации технологий производства). Популярными универсальными пакетами имитационного моделирования являются, например, Arena (разработчик System Modeling Corporation, Севикли, Пенсильвания, США), Extend (разработчик Imagine That., Inc., Сан-Хосе, Калифорния, США), AnyLogic (разработчик XJ Technologies, Санкт-Петербург, Россия) и другие. Предметно-ориентированные пакеты имитационного моделирования служат для решения специальных задач, таких как моделирование работы производственных систем, медицинских учреждений, центров выполнения заказов. Список предметно-ориентированных пакетов имитационного моделирования достаточно обширен, как правило, компании разработчики программных средств имитационного моделирования предлагают на рынок как универсальные, так и предметно-ориентированные пакеты.

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

• обеспечение визуального конструирования (программирования) моделей с использованием стандартных графических компонентов на основе технологии drag and drop (идеографическое моделирование);
• совмещение средств и систем имитационного моделирования с интеллектуальными системами поддержки принятия решений (экспертные системы, САПР и т.п.);
• обеспечение возможности анимации при отображении процессов функционирования моделируемых систем;
• интеграция с CASE-технологиями, конструирование многоуровневых моделей систем в рамках методологии структурного анализа.

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

Современные инструментальные средства ИМ

Класс реализуемых моделей

Источник: studfile.net

Простая система имитационного моделирования на Go

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

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

Уже порядка полувека при имитационном моделировании используются компьютерные модели. Для их разработки создано огромное множество различных программ и фреймворков, среди которых, на мой взгляд, наибольшее развитие получили средства для моделирования систем массового обслуживания (СМО). Одна из наиболее известных и простых программ для имитационного моделирования СМО – GPSS World (General Purpose Simulation System – система моделирования общего назначения), более подробно можно ознакомится по ссылкам [1], [2].

Концепция этой программы и была положена в основу фреймворка имитационного моделирования на Go.

Моделирование в GPSS

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

Основных блоков порядка десяти: GENERATE, TERMINATE, ASSIGN, SEIZE, RELEASE, QUEUE, ADVANCE, DEPART, START. Всего блоков порядка трёх десятков. Блоки имеют параметры, в качестве которых могут выступать числа, имена функций, метки в программе моделирования, имена переменных. Более подробно с блоками можно ознакомиться, например, здесь.

Объекты в GPSS имеют набор стандартных числовых атрибутов (СЧА) и стандартных логических атрибутов (СЛА). Например, для очереди, один из СЧА это текущая длина, а примером СЛА для некоего оборудования будет свободно (TRUE) или занято оно (FALSE).
В отдельных версиях GPSS присутствует визуализация процесса моделирования, но чаще всего она отсутствует. По результатам моделирования в GPSS формируется отчёт, с указанием СЧА и СЛА по всем объектам.

Реализация в Go

Реализация в Go представляет собой разработку набора объектов схожих по функциям с блоками GPSS. Первым был создан Pipeline – объект, в рамках которого выполняется симуляция.

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

После добавления всех компонентов, можно запустить моделирование с помощью метода Start . Внутри неё реализован циклический обход всех компонентов в течение заданного времени моделирования. По окончания моделирования можно напечатать отчёт, содержащий СЧА и СЛА.

Второй важный элемент это собственно компоненты для описания моделирования. Были реализованы: Generator – генерирует транзакты, Advance – создаёт задержки на пути транзакта, Queue – очереди транзактов, Facility – некое устройство, монопольно захватываемое транзактом на некоторое время, Hole – «дыра» в которую проваливаются транзакты в конце пути. Разумеется, такого набора недостаточно для создания сложных имитационных моделей, но для отработки решения и сравнения с результатами GPSS вполне хватает. Все компоненты реализуют интерфейс IBaseObj, который охватывает минимально необходимый функционал.

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

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

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

Так как при моделировании одновременно могут существовать множество транзактов, перемещающихся между различными компонентами, то возникла идея использовать внутри компонентов goroutines. Pipeline, проходя по компонентам, запускает для каждого из них обработчик HandleTransacts , внутри которого создаётся goroutine. После того как все goroutines отработают, увеличивается счётчик модельного времени и повторно вызывается HandleTransacts .

Последний ключевой объект это собственно сам транзакт. У него есть идентификатор, время рождения и смерти, владелец (в каком компоненте он сейчас), ряд параметров для вычисления СЧА и СЧЛ.

На рис. 1 приведена структурная схема взаимодействия основных объектов фреймворка при моделировании.

Рис. 1. Обобщённая структурная схема взаимодействия основных объектов при моделировании

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

Допустим надо смоделировать работу парикмахерской. Это известный пример из GPSS. Посетители идут хаотично, с периодичностью 18±6 минут, их количество заранее не известно. Парикмахер у нас один, на стрижку он тратит 16±4 минуты. Итак, сколько всего человек он пострижёт за рабочий день?

Сколько будет людей в очереди? Сколько в среднем уйдёт времени на стрижку и сколько времени просидят люди в очереди? Много вопросов и простая симуляция. Структурная схема на рис. 2.

Рис. 2. Структурная схема моделирования парикмахерской

Код для построения модели будет следующий.

barbershop := NewPipeline(«Barbershop», true) // Наша симуляция clients := NewGenerator(«Clients», 18, 6, 0, 0, nil) // Генератор клиентов chairs := NewQueue(«Chairs») // Очередь master := NewFacility(«Master», 16, 4) // Парикмахер hole := NewHole(«Out») // Выход barbershop.Append(clients, chairs) // От генератора транзакты идут в очередь barbershop.Append(chairs, master) // Из очереди идут в устройство barbershop.Append(master, hole) // Из устройства в дыру barbershop.Append(hole) // А из дыры транзакты никуда не уходят barbershop.Start(480) // Моделируем рабочий день
Результаты моделирования можно посмотреть здесь.

Pipeline name » Barbershop »
Simulation time 480
Object name » Chairs »
Max content 1
Total entries 26
Zero entries 11
Persent zero entries 42.31%
In queue 0
Average time/trans 2.58
Average time/trans without zero entries 4.47

Object name » Clients »
Generated 26

Object name » Master »
Average advance 16.46
Average utilization 89.17
Number entries 26.00
Transact 26 in facility

Object name » Out »
Killed 25
Average advance 16.56
Average life 19.44

Обслужили 25 клиентов, 26-ой на момент завершения моделирования был ещё в кресле мастера. В очереди было не более 1 человека, 11 человек не ждали (нулевой проход) и сразу проходили на стрижку. В среднем в очереди люди провели 2,58 минуты, а из тех, кто ждал (не нулевой проход) 4,47 минуты. 89,17% своего времени парикмахер усиленно стриг.

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

Другой пример. Есть офис, в нём 10 сотрудников и один туалет. Люди желают пойти в туалет каждые 90±60 минут, идти до туалета 5±3 минуты, занимают туалет 15±10 минут, поход обратно в офис 5±3 минуты. Проведём симуляцию в течении 9 часов (8 часов работы + 1 час обед), на рис. 3 приведена структурная схема.

Рис. 3. Структурная схема модели занятости туалета: слева с одним туалетом, справа с двумя

Слева модель с одним туалетом, справа с двумя. Далее приведён код модели.

waterclosetsim := NewPipeline(«Water Closet Simulation», false) office := NewGenerator(«Office», 0, 0, 0, 10, nil) wantToToilet:= NewAdvance(«Wanted to use the toilet», 90, 60) pathToWC := NewAdvance(«Path to WC», 5, 3) queue := NewQueue(«Queue to the WC») pathFromWC := NewAdvance(«Path from WC», 5, 3) wc := NewFacility(«WC», 15, 10) pathToOffice:= NewAdvance(«Path from WC», 5, 3) waterclosetsim.Append(office, wantToToilet) waterclosetsim.Append(wantToToilet, pathToWC) waterclosetsim.Append(pathToWC, queue) waterclosetsim.Append(queue, wc) waterclosetsim.Append(wc, pathFromWC) waterclosetsim.Append(pathFromWC, wantToToilet) waterclosetsim.Start(540)
Результаты моделирования следующие.

Pipeline name » Water Closet Simulation »
Simulation time 540
Object name » Office »
Generated 10

Object name » Path from WC »
Average advance 5.77

Object name » Path to WC »
Average advance 5.22

Object name » Queue to the WC »
Max content 4
Total entries 36
Zero entries 8
Persent zero entries 22.22%
Current contents 4
Average content 1.78
Average time/trans 24.11
Average time/trans without zero entries 31.00

Object name » WC »
Average advance 14.69
Average utilization 87.04
Number entries 32.00
Transact 2 in facility

Object name » Wanted to use the toilet »
Average advance 95.85

В очереди было до 4 человек, 8 раз человек сразу попал в туалет, в течении рабочего дня туалет используют на 87,04%. Самое существенное, на мой взгляд, это то, что люди ждут порядка получаса (31 минута) в очереди в туалет. Возможно, это связано с тем, туалет один, а возможно, с тем, что в среднем люди сидят в нём 14,69 минут.

Добавив ещё один туалет, я увидел, что очередь сократилась до 3 человек, 29 раз люди сразу попали в туалет. Но самое главное, почти в три раза уменьшилось ожидание.

Заключение

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

Источник: habr.com