Имитационное моделирование логистических процессов организации в среде Arena

Курсовая работа

Имитационное моделирование логистических процессов организации в среде Arena

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

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

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

Моделирование — это замещение одного объекта (оригинала) другим (моделью), фиксация и изучение свойств модели. Замещение производится с целью упрощения, удешевления и ускорения изучения свойств оригинала.

В курсовой работе представлен процесс разработки имитационной модели работы сети передачи данных в среде Arena.

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

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

Произведен анализ результатов имитационного моделирования. Описаны основные направления оптимизации работы системы.

1. Построение моделей в Arena

Одним из наиболее эффективных инструментов имитационного моделирования является система Arena.

Arena, разработанное компанией Systems Modeling Corporation программное обеспечение для имитационного моделирования, позволяет создавать подвижные компьютерные модели, используя которые можно адекватно представить очень многие реальные системы.

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

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

Имитационная модель в Arena включает следующие основные элементы: источники и стоки (Create и Dispose), процессы (Process) и очереди (Queue).

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

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

Процессы — это аналог работ в функциональной модели. В имитационной модели может быть задана производительность процессов. На рис. 1 приведен рисунок простейшей имитационной модели, созданная в Arena.

Рисунок 1. Простейшая имитационная модель, созданная в Arena

Для построения моделей Arena имеет набор средств, которые включают палитру инструментов, набор гидов и др. Для создания модели сначала нужно щелкнуть по кнопке New на панели инструментов. Слева появляется палитра инструментов (рис. 2), которая содержит два типа модулей.

§ Модули типа «Flowchart» (в том числе Create, Dispose и Process) служат для отображения потоков объектов и могут быть перенесены на рабочее пространство модели drag&drop. Модули типа «Data» (например Queue) не могут быть размещены в рабочее пространство модели и служат для настройки параметров модели. Окно редактирования параметров появляется в нижней части модели, когда фокус установлен на модуле типа «Data».

§ Из панели инструментов в рабочее пространство модели можно перенести по одному модулю Create, Dispose и Process. Связи между модулями устанавливаются автоматически (хотя могут быть переопределены вручную). Модуль Create является источником сущностей в системе. Так, например, если описывается изготовление изделий, то модуль Create может описывать поступление заготовок на конвейер. Модуль Process отвечает за обработку сущностей. Например, он может имитировать станок, обрабатывающий заготовки. Модуль Dispose является стоком сущностей из системы. Он может моделировать снятие готовых изделий с конвейера.

§ Для проигрывания модели (имитации реалного процесса) необходимо перейти в меню Run/Go. После проигрывания модели автоматически генерируются отчеты.

§ Модель в Arena может быть гораздо более сложной, чем представленная на рисунке 1. Она может включать сотни модулей различных типов. Модули, обрабатывающие сущности (подобные модулю Server из примера) могут иметь различные состояния, например «ожидание» или «работа». Каждому состоянию можно поставить в соответствие определенное изображение и, тем самым, анимировать имитационную модель.

Объектами оптимизации структурно-функциональных моделей могут быть:

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

2. Оптимизация параметров готовой модели (структура модели не изменяется, меняется значения переменных)

§ имеющиеся ресурсы;

§ затраты времени на какие-либо действия;

§ денежные затраты;

§ и другие переменные.

Средства оптимизации структурно-функциональных моделей:

1. Среда имитационного моделирования Arena:

§ отчеты, статистику и основные анимационные объекты для просмотра полученных результатов;

§ VBA and Visual Basic для изменения пределов параметров с целью определения наилучшего результата.

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

3. Дополнительное средство оптимизации OptQuest. Изменяя пределы значений переменных, запуская модель несколько раз, система определяет наилучшее решение. Оптимизировать можно только одно значение, при этом можно определять параметры ограничений для других переменных. Т. е. это однокритериальная оптимизация. Модель должна быть исследована, ее разработка, и корректировка должны быть завершены. Т. е., таким образом, можно найти необходимое оптимальное число ресурсов, требуемых данной системой.

2. Задание

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

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

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

Все линии модемной связи абонентов с провайдером имеют одинаковую скорость передачи — 33 600 бит/сек.

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

Сканирование дискового пространства прокси-сервера, занимает, примерно 2ё8 сек.

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

Пусть скорость обмена информацией в сети, на данный момент, составляет всего 1,5 Кбайт/сек.

Клиент в ответ на свою заявку получает по сети нужный ему пакет (от 10 до 100 Кбайт) или в случае сбоя — отказ. Вероятность возникновения отказа — 10%. Необходимо учесть тот факт, что клиент не может послать новую заявку, не получив запрашиваемых данных или признак отказа по предыдущей заявке.

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

Смоделировать работу магистрали передачи данных в течение 10 часов.

Определить при имеющихся в задании исходных данных:

— количество переданных пакетов по общему каналу передачи;

— объём принятой информации каждым из клиентов.

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

3. Построение модели сети

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

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

Три пользователя посылают запросы провайдеру, запросы моделируются модулями User request 1, User request 2, User request 3. Запросы от пользователей исходят случайным образом, но, так как система провайдера может обслуживать единовременно только один запрос от каждого пользователя, организуется отсеивание запросов модулями Line 1 unused, Line 2 unused, Line 3 unused, типа Decide. На входе системы провайдера установлены блоки UnFlag 1, UnFlag 2, UnFlag 3 регистрирующие приход запроса от пользователя, болоки Flag 1, Flag 2, Flag 3 установлены на выходе и регистрируют доставку пакета клиенту. Таким образом, когда количество запросов вошедших в систему равно количеству запросов вышедших из системы, модуль типа Decide, впускает на обработку один запрос от соответствующего пользователя. Окно параметров настройки блока Line1 unused показано на рисунке 3. Далее запрос пользователя поступает на прокси-сервер, который выполняет поиск информации на своих носителях информации (Процесс Check on proxy). Процесс поиска информации занимает от 2 до 8 секунд. Прокси-сервер многозадачный и может обрабатывать одновременно до трех запросов. Окно параметров блока Check on proxy приведено на рисунке 6.

При возникновении ошибки, модулем Report Failure генерируется отчет, который возвращается пользователю. Если ошибка не возникла и информация найдена на прокси-сервере, в модуле User package моделируется пакет данных для передачи пользователю. Далее пакет передается клиенту по линии связи. Блок Out Line delay моделирует задержку при передаче данных пользователю по модемной линии, параметр времени формируется делением размера пользовательского пакета данных на скорость передачи по линии (см. рисунок 11).

Если пакета, запрошенного пользователем, нет на прокси-сервере, данные доставляются пользователю из сети интернет, скорость передачи данных в которой составляет 1500 байт/с. Задержку, связанную со скоростью передачи данных в сети интернет, моделирует блок Net speed изображенный на рисунке 12. После того как сформированы пакеты данных или отчет об ошибке, они поступают на маршрутизатор, определяющий какому пользователю предназначается данная информация. Считается, что пользователь получил пакет данных, если сущность вышла из соответствующего блока Flag.

Рис. 1. Модель сети

4. Описание блоков модели

Сущности, представляющие запросы клиентов создаются в модулях типа Create, такой модуль имитирующий запросы от первого пользователя изображен на рисунке 2. Блок создает сущности типа Us1 случайным образом.

Рис. 2 Модуль User1 request

Блоки User2 request и User3 request имеют такие же параметры как блок User1 request за исключением типа создаваемой сущности.

Блок типа Decide с именем Line1 unused отвечает за ввод запросов пользователей в систему провайдера. Если выполняется условие (Flag1. NumberOut — UnFlag1. NumberIn) == 0 || Entity. CreateTime == 0.0, то есть пришла первая сущность или количество запросов данного пользователя в обработке равно 0, то блок пропускает один запрос. Если условие не выполняется, запрос уничтожается. Окно параметров блока Line1 unused изображено на рисунке 3.

Рис. 3 Окно параметров настройки блока Line1 unused

Для остальных каналов блоки имеют аналогичные настройки, за исключением имен тригирующих блоков Flag и Unflag.

Блоки Flag и Unflag, окно параметров которых изображено на рисунке 4, определяют количество запросов от каждого пользователя, находящихся в системе. Данные блоки не создают задержки.

Рис. 4 окно параметров блока Unflag1

Блок InLine delay моделирует задержку линии модемной связи. Окно параметров данного блока изображено на рисунке 5. Запрос пользователя имеет размер 100 бит, тогда, учитывая, что скорость передачи данных равна 33 600 бит/с, задержка линии передачи данных будет равна 0.003 секунды. Блок Failure delay имеет аналогичные настройки.

Рис. 5 Окно параметров блока InLine delay

Блок Check on proxy моделирует проверку наличия требуемой информации на сервере, этот процесс занимает от 2 до 8 секунд. Время распределяется равномерно функцией UNIF (2,8). Работа блока Internet server response аналогична, за исключением параметров функции UNIF (0,1).

Рис. 6 Окно параметров блока Check on proxy

Блок Failure (см. рисунок 7) определяет процент ошибок системы, в соответствии с заданием эта величина равна 10%.

Рис. 7 Окно параметров блока Failure

Блок Inf on Proxy определяет была ли найдена информация на прокси-сервере. По умолчанию значение вероятности нахождения информации равно 30% (рисунок 8).

Рис. 8 Окно параметров блока Inf on proxy

Блок типа Assign, изображенный на рисунке 9 изменяет картинку сущности на шар красного цвета.

Рис. 9 Окно параметров блока Report failure

Блок типа Assign с названием UserP package отвечает за определение размера пакета данных, который необходимо передать пользователю. По условию задания размер пакета от 10 до 100 Кбайт.

Рис. 10 Окно параметров блока UserP package

Блок OutLine delay моделирует задержку, связанную с пропускной способностью модемной линии передачи данных. Скорость передачи данных по условию задания равна 33 600 бит/с (4200 байт/с). Время задержки изменяется в зависимости от размера пакета t=Users pack / 4200 (см. Рисунок 11).

Рис. 11 Окно параметров блока OutLine delay

Блок Net speed моделирует задержку, связанную с пропускной способностью общей линии передачи данных. Скорость передачи данных по условию задания равна 1500 байт/с. Время задержки изменяется в зависимости от размера пакета t=Users pack / 1500 (см. Рисунок 12).

Рис. 12 Окно параметров блока Net speed

Блоки Inf For Us1 и Inf For Us2 выполняют функции маршрутизации пакетов пользователей. Окно параметров данных блоков изображено на рисунке 13.

Рис. 13 Окно параметров блока Inf For Us1

Заключение

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

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

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