Разработка имитационной модели автомобильного сервисного центра в среде AnyLogic
Обзор предметной области (автомобильный сервис). Основные виды компьютерного моделирования. Характеристика инструмента многоподходного имитационного моделирования AnyLogic. Разработка имитационной модели автомобильного сервисного центра в среде AnyLogic.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | дипломная работа |
| Язык | русский |
| Дата добавления | 07.08.2018 |
| Размер файла | 1,2 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Система AnyLogic основывается на инновациях в области информационных технологий и применяет на практике теории параллельных взаимодействующих процессов и гибридных (смешанных) систем, вследствие чего процесс имитации значительно упрощается. Продукт опирается на концепцию объектно-ориентированности, причем объекты в AnyLogic являются активными, то есть взаимодействующими с окружением. Имитационная модель, реализованная в этой системе, напоминает интерактивную игру с графическим интерфейсом, анимацией и 3D, так что можно наглядно увидеть динамику моделируемой системы. AnyLogic осуществляет многоподходное моделирование, совмещая несколько классических подходов имитационного моделирования (по возрастанию уровня абстракции): дискретно-событийное (Discrete Event Modeling), агентное (Agent Based) и системную динамику (System Dynamics). Допускается переключение между подходами и интегрирование нескольких подходов в одной модели. Интерфейс программы изображен на рис.2.3.
Рис.2.3 - Интерфейс системы имитационного моделирования AnyLogic
К сожалению, только самые простые модели можно построить графически, перетаскивая на холст редактора элементы и соединяя их друг с другом. Стремясь как можно более точно отразить в модели объекты реального мира, разработчик неизбежно столкнется с необходимостью использовать функции вероятностных распределений, вычисления выражений и проверки условий, задания нестандартных структур данных и разработки соответствующих алгоритмов. Для описания логики поведения моделируемой системы и специальных вычислений AnyLogic позволяет использовать современный язык объектно-ориентированного программирования Java. Кроме того, Java-платформа предоставляет практически безграничную возможность расширения создаваемых моделей. По словам разработчиков среды, Java во многом вдохновил их на ее создание [15]. Модель AnyLogic может использоваться как отдельное Java-приложение, независимое от среды разработки. Это обеспечивается за счет того, что создаваемая модель автоматически переводится в Java-код и связана с исполняющим модулем (также написанным на Java) и опционально с оптимизатором Java. Это делает среду AnyLogic кроссплатформенной: модели могут воспроизводиться в любой Java-совместимой оболочке и даже в веб-браузере в качестве апплетов. Классы активных объектов, о которых говорилось несколько ранее, среда интерпретирует в Java-классы, что является еще одним примером тесной связи AnyLogic c Java. Сама AnyLogic, к слову, также написана на Java в среде разработки Eclipse. С одной стороны, Java - достаточно высокоуровневый язык, который избавляет от необходимости заботиться о выделении памяти, различать объекты и ссылки и т.д. С другой стороны, это очень мощный язык ООП с высокой эффективностью. В Java можно определять структуры данных любой сложности и управлять ими, разрабатывать эффективные алгоритмы, использовать многочисленные пакеты классов компаний SunТМ, OracleТМ и других разработчиков. Напрашивается правомерный вопрос: насколько хорошо нужно владеть Java, чтобы успешно конструировать модели в AnyLogic? Для этого совершенно необязательно знать объектно-ориентированное программирование. В типичной модели Java-код присутствует в небольшом количестве, главным образом в описании различных свойств графических объектов. Это могут быть выражения, вызовы функций или пара операторов. Поэтому достаточно знаний основных типов данных в Java и языкового синтаксиса, а также понимания, что для того чтобы выполнить некоторое действие с объектом модели, необходимо вызвать его функцию.
AnyLogic представляет пользователю возможность проведения трех типов экспериментов над построенной моделью. "Простой эксперимент" решает так называемую прямую задачу имитационного моделирования - анализ "что - если" - и создается автоматически при создании проекта. Далее среда позволяет провести анализ чувствительности модели (эксперимент с варьированием параметров). Обратная задача имитационного моделирования - поиск оптимального решения - осуществляется с помощью эксперимента оптимизации. Для этого многократно решается прямая задача, а затем альтернативные решения сравниваются между собой или, если это невозможно, используется метод направленного перебора с применением эвристических методов (эвристик). Поддержку оптимизации реализует упомянутый ранее пакет оптимизации OptQuest.
2.4 Платформа дискретно-событийного моделирования Enterprise Dynamics
Enterprise Dynamics (ED) - комплексная программная платформа имитационного моделирования, предлагающая настраиваемую, масштабируемую и удобную в использовании среду моделирования. Среда применима для проектирования широкого спектра инфраструктур: складского хранения, производства, сферы услуг и т.д. ED представляет собой модульную объектно-ориентированную систему, созданную для решения задач, связанных с людьми, процессами, технологиями и инфраструктурой, для большинства коммерческих, правительственных, образовательных, производственных приложений. Имитационная среда ED обеспечивает полноценный анализ, визуализацию моделируемых процессов и управление ими. Разработчик программного продукта - INCONTROL Simulation Solutions (Нидерланды).
Парадигма моделирования ED основана на создании пользовательских объектов, называемых атомами (atoms), с помощью встроенных библиотек среды. Атом может представлять собой как материальную сущность (прибор, счетчик, продукт), так и нематериальную, например, граф. Существует несколько основных атомов, идентичных элементам СМО и схемы перемещения транзактов: продукт (product), источник (source), уничтожитель заявок (sink), сервер (server) и очередь (queue). Кроме того, в систему интегрированы некоторые транспортные атомы (например, конвейеры и перевозчики), атомы для представления результатов и т.д. Благодаря открытой структуре, пользователь ED может создавать собственные типы атомов, например, для моделирования агрегатов с очень специфическими характеристиками, а также собственные библиотеки, структуры меню и макеты [16]. Таким образом, атомы есть не что иное как предопределенные объекты моделирования, используемые для быстрого создания моделей и проведения исследований. Интерфейс программной платформы и примеры атомов представлены на рис.2.4.
Рис.2.4 - Интерфейс платформы моделирования Enterprise Dynamics
ED располагает встроенным языком программирования 4DScript, который может применяться для задания определенных условий и ограничений модели. Интегрированный оптимизатор позволяет производить экономические расчеты и прогнозировать результаты изменения входных параметров моделируемых процессов. ED поддерживает двумерную и трехмерную презентацию моделей.
2.5 Сравнительный обзор программных средств имитационного моделирования
Чтобы выбрать программное обеспечение для разработки имитационной модели автомобильного сервисного центра, необходимо произвести сравнительный анализ рассмотренных ранее программных продуктов. Сравнение выполнено по следующим группам критериев: требования операционной системы и поддержка аппаратного обеспечения, построение модели, в том числе поддерживаемые подходы, анимация и презентация процесса и результатов моделирования [17]. Итоги анализа представлены в таблицах 2.1 - 2.3.
Таблица 2.1. Требования операционной системы и поддержка аппаратного обеспечения
|
Программный продукт |
Операционная система |
Совместимое ПО |
Управление и выполнение сторонним ПО |
Поддержка CPU мультипроцессора |
|
|
GPSS World |
Windows; Mac OS X 10.10 и более поздние версии |
Proof Animation (Wolverine Software) |
|||
|
ArenaTM |
Microsoft Windows |
OptQuest |
Visual Studio |
||
|
AnyLogic |
Windows, Mac, Linux |
Excel, Access, OptQuest, Stat:: Fit, DLL Java |
Java-апплеты |
||
|
Enterprise Dynamics |
Microsoft Windows |
Различное |
Различное |
Таблица 2.2. Построение модели и поддерживаемые подходы
|
Программный продукт |
Поддерживаемые подходы моделирования |
Поддержка методологии drag-and-drop |
Необходимость программирования |
Повторное использование кода |
|
|
GPSS World |
Дискретно-событийное |
||||
|
ArenaTM |
Дискретно-событийное |
||||
|
AnyLogic |
Многоподходное |
||||
|
Enterprise Dynamics |
Дискретно-событийное |
||||
|
Программный продукт |
Поддержка оптимизации |
Отладка |
Дискретное и непрерывное моделирование |
Просмотр в реальном времени |
|
|
GPSS World |
|||||
|
ArenaTM |
OptQuest для Arena |
||||
|
AnyLogic |
OptQuest, пользовательские алгоритмы |
||||
|
Enterprise Dynamics |
Встроенные ссылки на оптимизаторы |
Таблица 2.3. Анимация и презентация модели
|
Программный продукт |
Экспорт анимации |
Совместимое ПО анимации |
Поддержка 3D-анимации |
Импорт CAD |
|
|
GPSS World |
|||||
|
ArenaTM |
|||||
|
AnyLogic |
|||||
|
Enterprise Dynamics |
Итак, сравнение систем имитационного моделирования по группам критериев позволило оценить их на предмет функциональной полноты и выявить программное обеспечение, удовлетворяющее требованиям разработчика наилучшим образом. Таким средством представляется среда многоподходного имитационного моделирования AnyLogic, позволяющая реализовать все необходимые аспекты модели в рамках единого проекта.
3. Разработка имитационной модели автомобильного сервисного центра в среде AnyLogic
3.1 Описание диаграммы процессов
Имитационная модель выполнена в среде AnyLogic 7.3.7 Personal Learning Edition с использованием обширного инструментария Библиотеки моделирования процессов, нескольких классов агентов, диаграммы состояний и элементов системной динамики. Структурная схема, представленная на рис.1.1, принимает вид иерархичной объектно-ориентированной потоковой диаграммы (приложение А). Разноцветными прямоугольниками выделены субдиаграммы (подпроцессы) процессов, соответствующие определенным в главе 1 функциональным подразделениям сервисного центра. Логически они идентичны друг другу и содержат одинаковые блоки, поэтому подробно рассматривать каждую субдиаграмму нецелесообразно. Рассмотрим диаграмму процессов станции технического обслуживания (рис.3.1), прочие диаграммы действуют аналогичным ей образом. В роли генератора заявок выступает блок source (источник), который создает заявки, выражаемые активными объектами (агентами) типа Auto (Автомобиль), с заданной интенсивностью прибытия. Имеет смысл разделить общий поток прибытия автомобилей на несколько частных потоков, поскольку интенсивность прибытия не одинакова для выделенных подсистем. Интенсивность прибытия соответствует экспоненциальному распределению времени между соседними прибытиями и численно равна переменной, определяемой параметром intensity. Перед воспроизведением модели экспериментатор с помощью элемента управления "Бегунок" (slider) задает пиковое значение этого параметра (интерфейс эксперимента Simulation представлен на рис.3.2), которое остается неизменным в течение всего эксперимента, что соответствует максимальной интенсивности данного потока в конкретном прогоне. Далее вычисляются значения параметра intensity в различные периоды суточного времени, которые смоделированы диаграммой состояний. Вследствие изменения интенсивности с течением времени система массового обслуживания, лежащая в основе дискретно-событийной модели, перестает быть сугубо марковской: средства имитационного компьютерного моделирования позволяют рассматривать более сложные стохастические процессы, близкие к реальным.
Рис.3.1 - Потоковая диаграмма станции технического обслуживания
Рис.3.2 - Интерфейс стандартного эксперимента Simulation
Как видно из рис.3.1, диаграмма потоков повторяет семантику структурной схемы модели типичной СМО и в то же время содержит вспомогательные блоки, поясняющие логику процесса. Блок ветвления по условию selectOutput реализует описанный ранее механизм выбора свободного канала обслуживания: состояния "занят" и "свободен" соответствуют значениям переменной булевского типа - true и false соответственно. При входе заявки в канал обслуживания этой переменной присваивается значение true, и движение следующей заявки к данному каналу невозможно до тех пор, пока переменная не будет инициализирована значением false. Блок moveTo моделирует перемещение объекта от одного узла сети физического пространства к другому и успешно применяется для визуализации маршрутов транспортных средств. В контексте разрабатываемой модели moveTo позволяет имитировать движение автомобилей по территории сервисного центра. Блок split создает копии каждого поступающего в этот блок агента и направляет их в собственный участок диаграммы процессов, а затем выходят из системы вместе с "агентом-оригиналом". Копиями агентов класса Auto в модели являются агенты класса Customer (Клиент), которые во время обслуживания автомобилей на станциях используют сервисы "Магазин", "Оплата услуг" и т.д. Следующие функциональные блоки - захват (seize) и освобождение (release) ресурсов, а также связанный с ними элемент диаграммы resourcePool (источник ресурса).
В данной модели основным занимаемым ресурсом является специалист того или иного цеха: как только агент-автомобиль достигает пункта обслуживания, к нему пересылается агент-мастер, то есть происходит его захват. После определенной временной задержки (delay), имитирующей обслуживание, захваченный ресурс освобождается и становится доступным для следующего агента. Канал обслуживания (последовательность функциональных блоков seize-delay-release) является областью с ограниченным количеством единовременного пребывания заявок. Вход в эту область обозначен с помощью блока restrictedAreaStart, а выход - restrictedAreaEnd. Вместимость данного участка - один агент, что удовлетворяет условию обслуживания одним мастером только одного клиента в текущий момент времени. Если область содержит максимально допустимое количество объектов, поток агентов блокируется до тех пор, пока хотя бы один объект не закончит обработку. Схожим по функциям блоком является блокировщик hold. Более того, restrictedAreaStart реализован именно на основе блока hold, который на определенном участке схемы служит своего рода семафором. В отличие от остальных блоков Библиотеки моделирования процессов, hold и пара restrictedArea не хранят внутри себя агентов, то есть не задерживают их ни на какое время [15]. В некоторых субдиаграммах последовательность блоков seize-delay-release заменена на один блок service, который программно реализован как последовательность указанных объектов, в данном контексте являющихся вложенными. Необходимо отметить, что все элементы диаграммы жестко связаны друг с другом: если агент по какой-либо причине не может покинуть выходной порт промежуточного блока, возникает ошибка и дальнейшее выполнение модели прекращается. Список и краткое описание на естественном языке всех агентов модели представлены в табл.3.1 Описание агента подразумевает указание его типа и родительского класса (при наличии), а также основных функций и ключевых особенностей каждого конкретного класса агентов. Далее агенты, заслуживающие особого внимания, будут рассмотрены подробнее.
Таблица 3.1. Описание агентов модели автомобильного сервисного центра
|
Агент |
Описание агента |
|
|
Main (Главный агент) |
Корневой агент модели, представляющий собой среду для всех остальных (вложенных) агентов и их популяций. |
|
|
Auto (Автомобиль) |
Подтип базового типа агентов Agent, описывающий поведение агентов-автомобилей. Имеет собственную анимацию и ряд параметров, необходимых для фиксирования значений эффективности. |
|
|
Customer (Клиент) |
Подтип базового типа Agent. Агенты этого класса создаются как копии агентов класса Auto. Имеют собственную анимацию. |
|
|
Агент |
Описание агента |
|
|
Master (Мастер) |
Подтипы базового типа Agent, моделирующие различные должности сотрудников сервисного центра. Являются ресурсами, захватываемыми в момент обслуживания заявки. |
|
|
Journeyman (Младший мастер) |
||
|
Manager (Менеджер) |
||
|
Cashier (Кассир) |
||
|
Basket (Корзина) |
Подтип базового типа Agent, который имитирует неодушевленный ресурс - корзину для покупок. Относится к типу переносных ресурсов. |
|
|
Bus (Автобус) |
Подтип базового типа Agent, используется для описания поведения агентов-автобусов. |
|
|
Refuel (АЗК) |
Агент, вложенный в класс Main. Описывает функционирование АЗК, включается в общую процессную диаграмму с помощью создаваемого разработчиком значка. |
Особым образом в общей потоковой диаграмме реализована субдиаграмма процесса обслуживания автомобилей на АЗК. Потоковая диаграмма построена в редакторе отдельного агента Refuel (рис.3.3) и интегрирована в диаграмму агента верхнего уровня Main в качестве значка активного объекта класса Refuel. Значок изображается с помощью элементов палитр "Презентация" и "Картинки", но при этом не является объектом анимации, а используется как блок с собственными портами входа и выхода.
Подход, состоящий в выделении отдельного класса агентов и замещении субдиаграммы ее значком, рационален с точки зрения восприятия потоковой диаграммы - она становится менее громоздкой и, вследствие упрощения, более понятной. Таким образом достигается иерархичность архитектуры модели: корневой агент класса Main представляет собой своего рода контейнер для агентов иных классов, которые, в свою очередь, также могут содержать вложенные объекты.
Рис.3.3 - Потоковая диаграмма и значок класса Refuel
Помимо собственно станции технического сервисного обслуживания автомобилей в модели присутствуют элементы некоторой инфраструктуры и топографии: смоделировано движение транспортных средств по автодороге в двух направлениях, маршрутного автобуса с остановкой и высадкой пассажиров, которые следуют в парк (рис.3.4).
Рис.3.4 - Потоковая диаграмма маршрута автобуса с остановкой и высадкой пассажиров
Таким образом, дискретно-событийный, или "процессный", подход имитационного моделирования может успешно применятся для моделирования систем разнообразной природы, если в основе их логической структуры лежат понятия события, операции и состояния системы, а изменение состояний происходит в дискретные моменты времени. Благодаря этому, метод получил обширное распространение и успешно применяется для моделирования сложных систем разнообразной природы.
3.2 Описание диаграммы состояний (statechart)
В качестве основного фактора определения пространства состояний моделируемой системы выбраны периоды времени, в течение которых интенсивность прибытия транспортных средств на обслуживание изменяется в соответствии с некоторыми правилами. Такое поведение системы во времени явным образом задано в модели с помощью диаграммы состояний (или стейтчарт - statechart), представленной на рис.3.5 Диаграммы состояний AnyLogic строятся в графической нотации UML в соответствии со стандартом [15]. Основными элементами диаграммы являются простые состояния, изображаемые поименованными прямоугольниками со скругленными углами, и переходы между состояниями - поименованные стрелки со значком причины перехода (таймаут, условие, сообщение и т.д.). Начало диаграммы обозначается специальным элементом и указывает стрелкой на начальное состояние. Важно, что у отдельной диаграммы состояний может быть только одно начало. Стейтчарт содержит псевдосостояние-ветвление (branch), обозначенное соответствующим блоком, которое делает возможным выбор альтернативного состояния для перехода при выполнении условия.
В рассматриваемом случае состояния представляют собой времена суток, а все переходы между ними происходят по таймауту - через явно определенный промежуток модельного времени с момента передачи управления текущему состоянию. По выходу из состояния Night управление получает ветвление: по умолчанию срабатывает переход к начальному состоянию (на диаграмме изображается пунктирной стрелкой), но при истинности условия getDayOfWeek () == FRIDAY управление сообщается состоянию FridayMorning. Переход из последнего состояния SundayNight возвращает управление начальному состоянию Morning. Таким образом, переход между состояниями в диаграмме осуществляется последовательными итерациями в цикле от состояния Morning до состояния SundayNight с вложенным циклом, моделирующим дни недели с понедельника по четверг, от Morning до Night.
Рис.3.5 - Диаграмма состояний
При достижении состоянием активности выполняется программный код на языке Java, указанный в поле "Действие при входе" окна свойств данного состояния. Поскольку действие выполняется мгновенно (за нулевое время), программные операции не должны требовать выполнения временных задержек. Все состояния построенной диаграммы изменяют значения параметров и вспомогательных переменных, содержащих числовые значения текущей и пиковой интенсивностей, которые сообщаются блокам потоковой диаграммы. Пример программного кода, выполняемого при входе в состояние Afternoon:
intensity=carIntensity- (carIntensity*0.3);
varIntensity=intensity;
intensityFuel=refuelIntensity- (refuelIntensity*0.5);
varIntensityFuel=intensityFuel;
intensityWashTire=WTintensity- (WTintensity*0.6);
varIntensityWashTire=intensityWashTire;
Здесь интенсивность прибытия автомобилей на СТОА (параметр intensity) рассчитывается как 70% от пикового значения, на АЗК (параметр intensityFuel) - 50% от соответствующего максимального значения, а интенсивность прибытия на шиномонтаж и автомойку (параметр intensityWashTire) - 40%. При выходе из состояния всем параметрам присваиваются значения по умолчанию (заданные при запуске модели на выполнение), и при входе в следующее состояние снова происходит выполнение программного кода нового состояния.
Динамика интенсивности в течение суток и недели отображается с помощью временной цветовой диаграммы (см. рис.3.5), где разноцветными горизонтальными полосами визуализируются временные тренды соответствующих наборов данных. Светло-бежевый цвет соответствует диапазону интенсивности от 0 до 10 ТC/час, зеленый - от 10 до 20 ТС/час, бордовый - наиболее близкому к пиковому значению интервалу, от 20 до 30 ТC/час. Три набора данных изображают соответственно интенсивность трех отдельных потоков прибытия заявок - прибытия на СТОА, на АЗК и станции шиномонтажа и автомобильной мойки. Данные временной диаграммы обновляются в автоматическом режиме.
3.3 Презентация и анимация имитационной модели
Система имитационного моделирования AnyLogic имеет встроенный двумерный графический редактор, позволяющий в одном окне строить логические диаграммы процессов и создавать их графические презентации с помощью элементов соответствующих палитр. AnyLogic поддерживает 2D и 3D пространства в имитационных моделях, позволяя разрабатывать высококачественную трехмерную анимацию в дополнение к более "технической" двумерной анимации [18, с.539]. Трехмерные фигуры могут быть импортированы в модель в формате X3D и VRML или составлены из встроенных графических примитивов. Кроме того, система обладает достаточно обширной палитрой наиболее часто используемых 3D объектов - людей, зданий, автомобилей, станков и т.д. Чтобы графический объект представлял собой динамическую презентацию моделируемого процесса, его необходимо ассоциировать с соответствующим агентом, под которым подразумевается элемент модели, обладающий поведением и интерфейсом для связи с другими элементами. Особенность создания 3D анимации состоит в том, что для создания трехмерной модели достаточно настроить так называемые Z-свойства 2D фигур. Это значение координаты Z и высота фигуры в трехмерном пространстве в пикселах, задаваемая параметром Z-высота. Следует отметить, что значения этих свойств могут быть как константными, так и динамическими.
Имитационная модель, созданная в AnyLogic, есть не что иное как самостоятельное Java-приложение, сгенерированное отображением в программный код на языке Java всех элементов, размещенных в редакторе модели. Это означает, что абстрактные сущности "модель" и "графика" существуют в едином пространстве и программно взаимосвязаны. Модель (набор семантических элементов) и графика (набор элементов презентации) связываются друг с другом с помощью динамических свойств фигур [18, с.468]. Так, с инструментами презентации и анимации тесно связана применяемая в разработке модели Библиотека моделирования процессов. Функциональные блоки, например, queue и delay, обладают свойством "Место агентов" для указания фигуры презентации (в частности, элемента сети разметки пространства), где располагаются агенты, обрабатываемые данным блоком. Совокупность путей (path), по которым движутся агенты, и узлов (point), представляющих собой целевые пункты назначения, образуют сеть (network), формирующую определенную топологию поверх плана здания, дорожной разметки и т.д. На рис.3.6 изображена двумерная презентация и разметка пространства имитационной модели автомобильного сервисного центра, представляющая собой маршрутную сеть передвижения агентов в физическом пространстве. Голубыми пунктирными линиями со стрелками (в соответствии с направлением движения) обозначены пути (path) - траектории перемещения агентов-автомобилей; точки, заключенные в окружность, изображают узлы (point) - пункты назначения и места задержек на пути следования от начальной точки к конечной. Присвоив свойству "Видимость" каждого структурного элемента сети значение false, можно скрыть разметку во время выполнения модели и отрисовки ее презентации. Таким образом, на анимации воспроизводимой модели отображаются только те фигуры и объекты, свойству "Видимость" которых сообщено логическое значение true. Кроме того, с помощью специфических свойств элементов презентации можно настроить отображение только в двумерном модельном пространстве, только трехмерном или и в 2D, и в 3D проекциях одновременно.
Рис.3.6 - Элементы презентации и разметка пространства
Последовательное движение агентов по сети задается структурными блоками moveTo, направляющими агента по кратчайшему пути к заданному узлу. Пункты обслуживания, реализованные блоками delay, обозначены узлами или прямоугольной областью с аттракторами, задающими точное расположение объекта внутри области и его ориентацию. Чтобы при воспроизведении модели разметка пространства не мешала восприятию, опция "Видимость" каждой ее фигуры отключается. Планы зданий и элементы топографии изображены прямоугольниками с различной текстурной заливкой; дорожная разметка есть не что иное как графический объект Библиотеки дорожного движения road. Все двумерные объекты (рис.3.7) транслируются в трехмерную анимацию модели автоматически при добавлении на диаграмму агента верхнего уровня Main элемента презентации "3D Окно".
Рис.3.7 - Двумерная анимация модели
Во время воспроизведения модели пользователь с помощью команд мыши может перемещаться по 3D сцене, приближать и отдалять точку обзора и, тем самым, регулировать глубину отрисовки. Для определения предустановленных точки и угла обзора применяется объект "Камера", который имитирует расположение виртуальной камеры видеонаблюдения, обращенной на 3D сцену. Трехмерная анимация разработанной модели представлена на рис.3.8 Кроме объектов, преобразуемых из двумерных в трехмерные, на анимации присутствуют элементы палитры трехмерных объектов - готовых фигур, по уровню сложности и реалистичности превосходящие простейшие геометрические примитивы. Анимация в AnyLogic, как двумерная, так и трехмерная, иерархична: 3D презентация вложенного активного объекта (агента) возникает на 3D-сцене объекта-контейнера [18]. В рассматриваемом примере активный объект Main является объектом-контейнером и имеет собственную презентацию, а агент Auto - вложенный. Анимация агентов класса Auto представляет собой изображение легкового автомобиля из палитры "3D Объекты".
Рис.3.8 - Трехмерная анимация модели
По умолчанию все создаваемые блоком source агенты имеют одну и ту же анимацию, однако для достижения более качественного визуального эффекта заданы различные цвета для вновь генерируемых объектов. Значение свойства "Видимость" выбрано динамическим и связанным с целочисленным параметром animationType (тип анимации), значения которого распределены по равномерному дискретному закону на отрезке [1,7]. Каждому числу из этого диапазона поставлено в соответствие изображение автомобиля определенного цвета. Графическое представление модели обеспечивает ее реалистичность и наглядность, оставляя "за кадром" трудную для восприятия структурную логическую схему моделируемого процесса, и повышает качество имитации. При необходимости пользователь может переключаться между областями видимости - 3D-презентацией, 2D-презентацией, логической потоковой диаграммой, диаграммами статистики и т.д.
3.4 Описание средств сбора и отображения результатов моделирования
В соответствии с целью моделирования в модели предусмотрен сбор статистики по следующим показателям: время нахождения в очереди на обслуживание в каждом функциональном подразделении, средняя длина очереди, среднее время обслуживания, коэффициент загрузки работников, вероятность ожидания обслуживания, количество обслуженных и необслуженных автомобилей, среднее время между поступлениями АТС на обслуживание. Впоследствии возможно проведение эксперимента оптимизации этих параметров. Программная среда моделирования AnyLogic располагает достаточно обширным интегрированным инструментарием сбора статистики по каждому блоку Библиотеки моделирования процессов и визуализации результатов. В разработанной модели рационально использовать элементы палитры "Статистика" "Данные гистограммы", "Гистограмма" и "Столбиковая диаграмма" (рис.3.9).
Рис.3.9 - Результаты моделирования в виде гистограмм и диаграмм
Объект "Данные гистограммы" осуществляет стандартный статистический анализ аккумулируемых им значений, вычисляя основные числовые и вероятностные характеристики (среднее, минимум и максимум, дисперсию и т.д.). В модели автомобильного сервисного центра этот объект используется для вычисления распределения времени нахождения ТС в каждом из цехов. Для этого в свойствах, определяющих действия при входе агента в блок delay и выходе из него, необходимо обозначить выражения, фиксирующие время входа и выхода, и в массив объекта "Данные гистограммы" добавить значение, равное разности этих двух времен. Время входа в блок присваивается параметру агента класса Auto entered. Пример сбора статистических данных для блока serviceTO (метод time () возвращает текущее модельное время):
agent. enteredTO=time ();
Распределение_времени_нахождения_ТС_на_ТО. add (time () - agent. enteredTO);
При выполнении модели под наименованием каждого объекта выводится текстовая строка с отображением количества произведенных измерений и средним значением, по которым можно судить об эффективности соответствующего канала обслуживания. Щелчок мыши по значку объекта в окне презентации открывает во всплывающем окне инспекта (рис.3.10) подробную информацию о вычисленных вероятностных характеристиках объекта (например, максимальное, минимальное и среднее значения, СКО, доверительный интервал для среднего и т.д.), которую можно скопировать в буфер обмена и исследовать с помощью внешних приложений (например, MS Office Excel).
Рис.3.10 - Окно инспекта объекта "Данные гистограммы"
Для наглядности полученные данные визуализируются объектом "Гистограмма", который представляет собой столбчатый график определенного цвета. Вертикальные прямоугольные столбцы соответствуют интервалам функции распределения вероятностей; поверх них накладываются графики функции распределения и среднего значения. Графики автоматически масштабируются и обновляются с течением модельного времени. Гистограмму можно скопировать в виде набора данных или изображения для более глубокого анализа и представления результатов моделирования во внешних файлах.
Для визуально удобного отображения количественных показателей технической эффективности применяется столбиковая диаграмма. Показатели изображаются в виде вертикальных прямоугольников, высота которых пропорциональна соответствующему значению, вычисляемому согласно выражению в поле свойств диаграммы "Данные". Рассмотрим Java-методы для вычисления значений показателей эффективности станции технического обслуживания. Коэффициент загрузки работников вычисляется встроенной функцией utilization () блока resourcePool: mastersTO. utilization () и равен среднему значению загруженности каждого ресурса данного блока. Средняя и максимальная длина очереди выражены переменной statsSize с вызовом соответствующего метода - mean () или max () (необходимо включить опцию сбора статистики в свойствах очереди): queueToServiceTO. statsSize. mean () и queueToServiceTO. statsSize. max (). Количество обслуженных автомобилей, количество отказов по времени ожидания обслуживания и длине очереди возвращаются функцией count () блоков sinkTO, sinkUnservedTimeout и sinkUnservedDisplace соответственно.
Распределение времени между соседними прибытиями ТС на обслуживание рассчитывается с помощью объекта "Данные гистограммы" следующим образом:
agent. intervalTO=time () - agent. requestTOTime;
Распределение_времени_между_поступлением_ТС_на_ТО. add (agent. intervalTO);
agent. requestTOTime=time ();.
Вероятность ожидания обслуживания вычисляется по формуле классической вероятности как отношение числа заявок, пребывающих в очереди, к общему числу заявок: queueToServiceTO. size () /agent. requestTO. Все упомянутые показатели эффективности станции технического обслуживания отображены на рис.3.11, аналогично рассчитываются технические параметры остальных цехов и функциональных подразделений.
Интегрированные средства сбора и отображения статистики по отдельным блокам диаграммы процессов позволяют наглядно представить результаты моделирования и отследить динамику изменения тех или иных параметров во время выполнения простого эксперимента. Детальный анализ полученных данных можно произвести, скопировав их в стороннее приложение. Кроме того, значение переменных и параметров, определенных в модели, можно интерактивно изменять прямо в окне презентации с помощью команд окна инспекта.
Рис.3.11 - Числовые и вероятностные характеристики СТО
3.5 Применение подхода системной динамики
Анализ и оптимизация показателей технической эффективности тех или иных функциональных цехов автомобильного сервисного центра - важная задача оценки качества его работы, однако, чтобы адекватно рассуждать о совокупной продуктивности, необходимо принять во внимание динамику экономических параметров при изменении условий. AnyLogic предоставляет удобный механизм экономического анализа функционирования системы - моделирование методом системной динамики (рис.3.12). Системная динамика представляет собой методологию моделирования, направленную на изучение структуры любых сложных систем с помощью представления причинно-следственных связей между их элементами и эволюции с течением времени [19, с.104].
Рис.3.12 - Диаграмма потоков и накопителей
Следует отметить, что в терминологическом контексте под системной динамикой понимают описанную методологию научного исследования, основанный на ней подход имитационного моделирования и одноименный графический язык, используемый для представления модели. В нотации системной динамики объекты системы изображаются в виде накопителей, потоков, вспомогательных переменных и параметров, а также петель обратной связи. Совокупность обозначенных элементов называется диаграммой потоков и накопителей.
В системно-динамической модели, представленной на рис.3.12, накопитель Revenue (Доход) аккумулирует доход предприятия технического сервисного обслуживания автомобилей и может в дальнейшем применяться для расчета чистой экономической прибыли. Параллельно вычисляется значение потенциальной упущенной прибыли (динамическая переменная missedRevenue), обусловленной отказами в обслуживании по причине длительности ожидания и вместимости очереди. Количество обслуженных автомобилей и автомобилей, покинувших СТОА без обслуживания, сообщается переменным served и unserved соответственно при входе агентов в блоки sink диаграммы процессов (рис.3.1). Переменным avrgCost присваиваются значения средней стоимости выполнения операций определенного типа, которые выражены треугольным распределением (Симпсона) вида triangular (100, 500, 250), где первый аргумент функции соответствует минимальной величине, второй - максимальной, третий - наиболее вероятной (моде). Треугольное распределение позволяет приблизительно оценить величину, точный закон распределения которой неизвестен, но может быть получен с помощью экспертной оценки. Аналогичным образом в модели заданы переменные price, которые хранят значения цен на различные виды услуг.
Динамические переменные cost и revenue связывают количество обслуженных автомобилей, затраты на осуществление обслуживания определенного типа и доход от обслуживания единицы транспортного средства.
Затем значения этих переменных суммируются динамическими переменными repairCost и revenueFromRepair, которые, в свою очередь, присутствуют в выражении накопителя Revenue: d (Revenue) /dt= revenueFromRepair- (fixedExpenses+repairCosts). Параметром fixedExpenses обозначены некоторые постоянные расходы.
Достоинство интегративного подхода - совмещения в рамках одной модели дискретно-событийного принципа и метода системной динамики - в возможности одновременного исследования влияния определенных факторов как на перерабатывающую способность сервисного центра, так и на его экономическую эффективность.
3.6 Результаты моделирования
Компьютерное имитационное моделирование - достаточно сложный итеративный процесс, состоящий из последовательности взаимосвязанных технологических этапов (рис.3.13).
Все этапы можно классифицировать на две группы - проектирование собственно имитационной модели и анализ результатов ее выполнения.
Рис.3.13 - Итеративный процесс имитационного моделирования [20]
Немаловажную роль в оценке результатов и, как следствие, принятии решения в соответствии с обозначенной целью, играет правильное планирование, проведение и интерпретация эксперимента. В связи с этим необходимо обеспечить грамотное решение следующих задач:
· Разработка тактического плана имитационного вычислительного эксперимента;
· Определение условий и факторов серии прогонов, входящих в эксперимент;
· Реализация эксперимента и фиксирование результатов каждого прогона серии;
· Сравнительный анализ результатов и сопоставление их с предварительно аналитически рассчитанными или эмпирическими данными;
· Интерпретация полученных результатов и прогнозирование (анализ "что-если").
Поскольку разрабатываемая модель автомобильного сервисного центра является гипотетической, входные данные и параметры эксперимента приближены к реальным и могут быть откалиброваны для конкретного предприятия. Итоги простого эксперимента, который заключается в последовательном воспроизведении построенной модели с различными входными параметрами, целесообразно оптимизировать для поиска наилучшего решения. В связи с этим актуальной задачей становится проведение оптимизационного эксперимента (Optimization). В математике, информатике и исследовании операций термин "математическая оптимизация" (математическое программирование или просто оптимизация) представляет собой выбор наилучшего значения (в соответствии с некоторым критерием) из альтернативного набора значений. В простейшем случае это означает максимизацию или минимизацию конкретной функции с помощью систематического подбора входных данных из набора допустимых значений и вычисления соответствующего значения этой функции. С точки зрения AnyLogic, оптимизация осуществляется итеративным воспроизведением реализации модели при различных значениях параметров и поиском такого набора значений, при котором решение поставленной задачи будет оптимальным. Пакет AnyLogic имеет в своем составе исполняющий модуль OptQuest (OptTek Systems, Inc) - метаэвристический оптимизатор, позволяющий перейти от классического анализа "что-если" к подходу "что лучше", комбинируя эвристический метод, метод нейронных сетей и математическое программирование [19].
Проведем серию прогонов модели при различных значениях пиковой интенсивности прибытия ТС на обслуживание для каждого потока, создаваемого блоками source. Для получения наиболее достоверных результатов, пригодных для сравнения, имеет смысл выбрать фиксированное модельное время воспроизведения. Будем изменять интенсивность от минимального значения (1 ТС/час) до максимального (11 ТС/час) с шагом 2 и фиксировать изменение показателей технической и экономической эффективности подразделений сервисного центра. Результаты серии прогонов эксперимента приведены в таблице 3.2 Следующим этапом может быть произведен оптимизационный эксперимент и даны рекомендации по оптимальным параметрам автосервиса, таким как вместимость очереди, количество пунктов обслуживания и численность бригад механиков функциональных подразделений, однако решение этой задачи находится за пределами данной работы.
Таблица 3.2. Результаты серии прогонов модели при различных значениях параметра
|
Показатели эффективности |
Пиковое значение интенсивности, ТС/час |
|||||||
|
1 |
3 |
5 |
7 |
9 |
11 |
|||
|
Станция технического обслуживания |
||||||||
|
Технические |
Распределение времени обслуживания (среднее) |
0.554 |
0.582 |
0.542 |
0.566 |
0.548 |
0.539 |
|
|
Распределение времени ожидания (среднее) |
0 |
0.111 |
0.193 |
0.209 |
0.214 |
0.221 |
||
|
Коэффициент загрузки работников |
0.072 |
0.277 |
0.388 |
0.470 |
0.600 |
0.610 |
||
|
Средняя длина очереди |
0 |
0.045 |
0.106 |
0.176 |
0.398 |
0.380 |
||
|
Технические |
Максимальная длина очереди |
0 |
3 |
4 |
4 |
5 |
5 |
|
|
Количество обслуженных автомобилей |
25 |
91 |
137 |
159 |
209 |
215 |
||
|
Количество отказов по таймауту |
0 |
10 |
25 |
38 |
95 |
87 |
||
|
Количество отказов по длине очереди |
0 |
0 |
0 |
0 |
0 |
0 |
||
|
Экономические |
Доход (тыс. ден. ед.) |
45.003 |
94.733 |
219.741 |
143.298 |
228.56 |
215.89 |
|
|
Упущенная прибыль (тыс. ден. ед.) |
0 |
10.410 |
40.100 |
34.238 |
103.93 |
86.954 |
||
|
Пункт диагностики |
||||||||
|
Технические |
Распределение времени обслуживания (среднее) |
0.591 |
0.766 |
0.963 |
0.814 |
0.972 |
1.170 |
|
|
Распределение времени ожидания (среднее) |
0 |
0.189 |
0.178 |
0.173 |
0.162 |
0.201 |
||
|
Коэффициент загрузки работников |
0.077 |
0.338 |
0.620 |
0.624 |
0.725 |
0.858 |
||
|
Средняя длина очереди |
0 |
0.038 |
0.205 |
0.338 |
0.525 |
0.904 |
||
|
Максимальная длина очереди |
0 |
2 |
3 |
3 |
3 |
3 |
||
|
Количество обслуженных автомобилей |
25 |
80 |
120 |
143 |
136 |
136 |
||
|
Количество отказов по таймауту |
0 |
9 |
47 |
84 |
135 |
234 |
||
|
Количество отказов по длине очереди |
0 |
0 |
0 |
0 |
0 |
0 |
||
|
Экономические |
Доход (тыс. ден. ед.) |
16.289 |
61.162 |
167.85 |
132.04 |
138.91 |
103.8 |
|
|
Упущенная прибыль (тыс. ден. ед.) |
0 |
6.632 |
64.108 |
75.448 |
133.98 |
173.7 |
||
|
Цеха автомобильного сервиса |
||||||||
|
Технические |
Распределение времени кузовного ремонта (среднее) |
4.476 |
4.169 |
4.385 |
4.342 |
4.487 |
4.476 |
|
|
Распределение времени ремонта ходовой (среднее) |
1.992 |
1.935 |
1.734 |
1.839 |
1.873 |
1.990 |
||
|
Распределение времени ремонта электроники (среднее) |
2.472 |
2.482 |
2.279 |
2.512 |
2.471 |
2.413 |
||
|
Коэффициент загрузки мастеров кузовного ремонта |
0.14 |
0.435 |
0.818 |
0.749 |
0.840 |
0.866 |
||
|
Коэффициент загрузки мастеров ремонта двигателя |
0.166 |
0.450 |
0.505 |
0.702 |
0.620 |
0.624 |
||
|
Коэффициент загрузки мастеров ремонта электроники |
0.026 |
0.186 |
0.309 |
0.377 |
0.456 |
0.390 |
||
|
Количество обслуженных ТС в цехе кузовного ремонта |
6 |
20 |
35 |
33 |
35 |
37 |
||
|
Количество обслуженных ТС в цехе ремонта ходовой |
16 |
43 |
55 |
72 |
63 |
60 |
||
|
Количество обслуженных ТС в цехе ремонта автоэлектроники |
2 |
14 |
26 |
28 |
34 |
31 |
||
|
Количество автомобилей, покинувших автосервис |
1 |
3 |
4 |
10 |
4 |
8 |
||
|
Экономические |
Доход (тыс. ден. ед.) |
89.416 |
322.301 |
640.040 |
560.02 |
408.17 |
468.69 |
|
|
Упущенная прибыль (тыс. ден. ед.) |
3.616 |
11.904 |
21.043 |
41.833 |
19.706 |
27.413 |
||
|
Автомобильная мойка и шиномонтаж |
||||||||
|
Технические |
Распределение времени обслуживания на автоматической мойке (среднее) |
0.151 |
0.231 |
0.230 |
0.231 |
0.231 |
0.230 |
|
|
Распределение времени обслуживания на ручной мойке (среднее) |
0.559 |
0.717 |
0.715 |
0.728 |
0.709 |
0.711 |
||
|
Распределение времени ожидания ручной мойки (среднее) |
0 |
0.122 |
0.148 |
0.167 |
0.178 |
0.183 |
||
|
Распределение времени обслуживания на станции шиномонтажа (среднее) |
1.045 |
1.012 |
1.052 |
1.064 |
1.036 |
1.032 |
||
|
Коэффициент загрузки работников автомойки |
0.153 |
0.374 |
0.538 |
0.621 |
0.724 |
0.780 |
||
|
Коэффициент загрузки работников шиномонтажа |
0.158 |
0.457 |
0.658 |
0.789 |
0.819 |
0.865 |
Из табл.3.1 видно, что тенденция изменения показателей эффективности работы подразделений автомобильного сервисного центра следующая. С ростом интенсивности прибытия ТС на обслуживание растет вероятность ожидания, среднее время нахождения автомобиля в очереди, длина очереди и количество отказов по длительности ожидания (таймауту). Вместе с тем до определенного момента доход и упущенная прибыль находятся в балансе, а при достижении максимальной интенсивности 7 ТС/час количество отказов становится соизмеримым с числом обслуженных автомобилей, и упущенная прибыль практически выравнивается с доходом. Загруженность работников, очевидно, возрастает с увеличением интенсивности. Распределение времени обслуживания не зависит от параметров и определяется выявленным законом распределения случайной величины, поэтому в серии испытаний средние значения времени нахождения на обслуживании отличаются незначительно.
В обозначенном контексте важной задачей становится поиск оптимальных параметров сервисного центра для обеспечения удовлетворительной перерабатывающей способности и извлечения максимальной прибыли.
Заключение
Прогрессирующее развитие транспортного комплекса России требует соответствующих темпов обновления научно-технологической и материальной базы, а также активного внедрения в различные сегменты инновационных разработок и новейших информационных систем. Многоподходное имитационное моделирование представляется перспективным инструментом исследования состояния транспортной системы страны в целом и ее регионов в частности, прогнозирования тенденций дальнейшей эволюции процессов, характерных для данного сегмента, оптимизации системообразующих параметров и показателей для достижения наилучшей эффективности в техническом, экономическом и, что немаловажно, экологическом аспектах. В бакалаврской работе в качестве сегмента обширного транспортного комплекса был рассмотрен автомобильный сервис, разработана его имитационная модель с применением методов дискретно-событийного, агентного и системно-динамического моделирования в программной среде AnyLogic. В процессе выполнения работы достигнуты следующие результаты:
· Исследована предметная область и обоснована целесообразность применения компьютерного имитационного моделирования в данном контексте;
· Рассмотрены основные подходы имитационного моделирования - дискретно-событийный, агентный и системно-динамический, аргументирована необходимость комбинирования нескольких подходов в рамках одной модели для полноценного и всестороннего исследования;
· Выполнен сравнительный обзор по нескольким группам критериев четырех программных средств имитационного моделирования - продуктов GPSS World, Arena, AnyLogic и Enterprise Dynamics, в результате которого наиболее соответствующим требованиям разработки модели инструментом оказалась среда AnyLogic;
· Разработана имитационная модель Car Service автомобильного сервисного центра в среде AnyLogic;
· Произведен простой имитационный эксперимент, состоящий в серии "прогонов" модели при различных входных данных, и последующий анализ результатов.
В дальнейшем рекомендованы настройка и проведение эксперимента оптимизации с целью определения таких параметров автомобильного сервисного центра, при которых его функционирование будет наиболее эффективно в широком смысле. Параметры построенной в рамках данной бакалаврской работы модели могут быть уточнены и откалиброваны для определенного предприятия. Таким образом, результаты работы представляют собой методологическую и технологическую основу исследования и оптимизации деятельности любого предприятия автомобильного сервиса, поскольку разработанная модель обладает свойством гибкости и может быть легко адаптирована в соответствии с особенностями конкретной организации.
Размещено на Allbest.ru
...Подобные документы
Теоретические основы моделирования систем в среде имитационного моделирования AnyLogic. Средства описания поведения объектов. Анимация поведения модели, пользовательский интерфейс. Модель системы обработки информации в среде компьютерного моделирования.
курсовая работа [1,5 M], добавлен 15.05.2014Оптимальное время для обслуживания пользователей как основная цель работы компьютерного зала библиотеки. Построение модели деятельности подписного отдела с помощью средства имитационного моделирования AnyLogic. Описание процессов и построение сценария.
курсовая работа [1,9 M], добавлен 19.06.2015Специфика работы терапевтического отделения. Разработка имитационной модели в среде AnyLogic. Выбор средств моделирования. Описание схемы моделирующего алгоритма. Организация вычислительного эксперимента над математической моделью, анализ его результатов.
курсовая работа [1,2 M], добавлен 10.06.2015AnyLogic как инструмент компьютерного моделирования нового поколения. Процесс разработки моделей и реализация имитационных моделей для распространения эпидемического заболевания. Разработка систем обратной связи (диаграммы потоков и накопителей).
контрольная работа [1,8 M], добавлен 21.07.2014Концептуальная модель процесса обслуживания покупателей в магазине. Описание системы моделирования GPSS. Разработка моделирующей программы на специализированном языке имитационного моделирования в среде AnyLogic. Результаты вычислительных экспериментов.
курсовая работа [906,9 K], добавлен 12.07.2012Обзор средств компьютерного имитационного моделирования по созданию веб-приложения для визуализации имитационных моделей. Система имитационного моделирования AnyLogic, Arena, SimuLab. Серверная, клиентская часть. Модель работы отдела банка и участка цеха.
дипломная работа [3,3 M], добавлен 25.05.2015Описание программного обеспечения AnyLogic, поддерживающего три метода имитационного моделирования (системная динамика, дискретно-событийное и агентное моделирование). Разработка модели процесса перехода пассажиров на монорельсы через кассы и турникеты.
контрольная работа [524,9 K], добавлен 21.05.2015Разработка имитационной модели "Перекресток" для анализа бизнес-процессов предприятия и принятия решения в сложных условиях. Алгоритм построения имитационной модели на основе CASE-средств. Обзор программного обеспечения для имитационного моделирования.
дипломная работа [2,6 M], добавлен 22.11.2015Создание систем имитационного моделирования AnyLogic, Arena, SimuLab, Simbigraph и Forio. Серверная и клиентская часть. Разработка модели работы отдела банка, участка цеха, движения автобуса по маршруту и социальной сети. Описание web-приложения.
дипломная работа [3,4 M], добавлен 25.05.2015Сущность концептуального и физического моделирования. Описание графической среды AnyLogic как единственного инструмента имитационного моделирования. Основные этапы создания модели, позволяющей наглядно проанализировать влияние рекламы на покупателей.
курсовая работа [690,2 K], добавлен 30.05.2014Концептуальное, физическое, структурно-функциональное, математическое (логико-математическое), имитационное (программное) и компьютерное моделирование. Построение имитационной модели в среде AnyLogic. Дискретные и непрерывно изменяющиеся модели.
курсовая работа [1,6 M], добавлен 21.11.2013Построение схемы модели процесса и разработка анимации; определение характеристики модели с использованием AnyLogic. Сеть Петри для процесса работы порта. Описание программного продукта. Объекты библиотеки Enterprise Library. Результаты работы модели.
курсовая работа [334,1 K], добавлен 25.04.2015Разработка имитационной модели функционирования кладовой на промышленном предприятии с использованием имитационного метода в среде GPSS World. Экспериментальное исследование результатов моделирования. Выработка предложений по оптимизации работы системы.
курсовая работа [183,1 K], добавлен 27.08.2012Методы прогнозирования, их классификация. Использование рекламы в социологии. Пооперационная разработка, реализация и конфигурирование модели в пакете Anylogic. Создание анимации. Описание имитационных вычислительных экспериментов, анализ результатов.
курсовая работа [1,7 M], добавлен 03.06.2012Особенности моделирования биологических систем с использованием программы "AnyLogic". Влияние различных факторов на популяции жертв и хищников. Принципы имитационного моделирования и его общий алгоритм с помощью ЭВМ. Анализ результатов моделирования.
курсовая работа [922,2 K], добавлен 30.01.2016Процесс моделирования имитационной модели функционирования класса персональных компьютеров на языке GPSS World. Поиск линейной зависимости и оценка полученного уравнения. Отчет по результатам работы имитационной модели. Листинг разработанной программы.
курсовая работа [49,2 K], добавлен 07.09.2012Основы технологии моделирования Arena. Построение простой имитационной модели. Моделирование работы системы обслуживания покупателей на кассе супермаркета. Построение модели IDEF3. Анализ результатов имитационного моделирования и аналитического решения.
курсовая работа [659,1 K], добавлен 24.03.2012Анализ работы станции скорой помощи: прием вызовов, обслуживание пациентов, движение автомобилей. Формализация имитационной модели, ее программирование с помощью системы моделирования AnyLogic. Использование программы для расчета времени оказания помощи.
контрольная работа [1004,2 K], добавлен 25.07.2013Основные понятия теории моделирования. Виды и принципы моделирования. Создание и проведение исследований одной из моделей систем массового обслуживания (СМО) – модели D/D/2 в среде SimEvents, являющейся одним из компонентов системы MATLab+SimuLink.
реферат [1,2 M], добавлен 02.05.2012Анализ и формализация задачи моделирования: построение концептуальной модели, ее формализация в виде Q-схемы. Построение имитационной модели: создание блок-схемы, представление базовой исходной имитационной модели. Исследование экономических процессов.
контрольная работа [156,0 K], добавлен 21.11.2010
