Построение модели предоставления технической поддержки пользователей на языке моделирования AnyLogic

Тип работы:
Реферат
Предмет:
Информатика


Узнать стоимость новой

Детальная информация о работе

Выдержка из работы

УДК: 004. 942 ГРНТИ: 20. 23. 17
ПОСТРОЕНИЕ МОДЕЛИ ПРЕДОСТАВЛЕНИЯ ТЕХНИЧЕСКОЙ ПОДДЕРЖКИ ПОЛЬЗОВАТЕЛЕЙ НА ЯЗЫКЕ МОДЕЛИРОВАНИЯ ANYLOGIC
А. Р. Срульдинов, С. А. Варламова*
Пермский национальный исследовательский университет Россия, 618 404, г. Березники, ул. Тельмана, 7 * email: varlamovasa@mail. ru
Описаны основные принципы разработки агентной модели на языке AnyLogic. Обоснованы преимущества имитационного моделирования для широкого круга задач. Разработаны структурная и агентная модели технической поддержки пользователей. Описаны элементы модели и значения ее параметров. Произведен анализ результатов моделирования.
Ключевые слова: агентная модель, техническая поддержка, AnyLogic.
DESIGN OF TECHNICAL SUPPORT MODEL BY ANYLOGIC LANGUAGE A. R. Sruldinov, S. A. Varlamova*
Perm national polytechnic research university 7 Telmana St., 618 404, Berezniki, Russia * email: varlamovasa@mail. ru
Basic principles of agent model design by AnyLogic are described. Features of queue modeling for wide specter of tasks are shown. A structural and queue models of technical support service are designed. All elements of queue model are circumscribed, parameters of the model are based on a real object observing. An analysis of modeling results is given.
Keywords: agent model, support service, AnyLogic.
Современный этап развития человечества отличается тем, что на смену века энергетики приходит век информатики. Происходит интенсивное внедрение новых информационных технологий во все сферы человеческой деятельности.
Появление новейших информационных технологий увеличивает не только возможности моделирующих систем, но и позволяет применять большее многообразие моделей и способов их реализации.
В настоящее время подготовка управленческих решений требует принятия во внимание большого числа различных факторов, влияющих на динамику исследуемых систем. Лицам, принимающим решения, необходимо анализировать сотни различных сценариев (вариантов решений), что обуславливает необходимость разработки имитационных моделей различного типа, интеграции этих моделей с базами и хранилищами данных, создания оптимизационных модулей для имитационных моделей.
Суть имитационного моделирования заключается в компьютерной реализации математической модели изучаемой системы для использования в целях симуляции (имитации) поведения реальной системы.
В настоящее время сфера применения имитационного моделирования практически не ограничена. Имитационные модели разрабатываются для изучения поведения отдельных предприятий и корпораций, исследования рыночного равновесия, оценки последствий государственного регулирования в экономике, оптимального управления логистическими системами, изучения эпидемиологии (прогнозирования динамики распространения заболеваний) и решения других практических задач.
В данной статье попробуем с помощью компьютерной имитационной модели описать процесс предоставления
технической поддержки пользователям.
В отдел технической поддержки пользователей поступают заявки n типов с вероятностями р1, р2, …, рп соответственно. Интервалы времени Тп между двумя очередными поступлениями одного типа заявок случайные. Каждый любой тип заявки может требовать одного из а1, а2, …, ак видов работ с вероятностями рal, рa2, …, рak соответственно.
В отделе работают ni, п2, …, пп специалистов для выполнения заявок каждого типа соответственно. Специалист n1 выполняет заявки первого типа, если таких заявок нет и остальные специалисты заняты, то специалист n1 выполняет заявки остальных типов, при этом поступающие заявки первого типа ожидают его освобождения. Аналогичные обязанности и у остальных специалистов, кроме специалиста пп, он выполняет заявки одного n-го типа, в нашем случае это разработчик.
Время выполнения заявки случайное, не зависит от специалиста, а зависит только от поставленной задачи: Т11,…, Т1п — для заявок первого типа, Т21,…, Т2п — для заявок второго типа, Тп1,…, Тпп — для заявок п-го типа.
Прием и распределение заявок между специалистами осуществляется d диспетчерами. Время, затрачиваемое одним диспетчером на одну заявку, Ti, случайное. Диспетчерами не принимаются к ремонту q заявок всех типов.
Интервалы времени между поступлениями заявок, и время выполнения заявок распределены по экспоненциальному закону.
Представим отдел технической поддержки как СМО (рис. 1).
Отдел технической поддержки представляет собой многофазную многоканальную систему массового обслуживания разомкнутого типа с отказами.
«Переменная». Она предназначена для моделирования изменяющихся характеристик агента или для хранения результатов работы модели (Рис. 2).
Рис. 1. Отдел технической поддержки как СМО
Заявки должны иметь следующие параметры (поля):
• типЗ — код типа заявки-
• видР — вид работы-
• времяР — время выполнения одного вида работы- Как говорилось выше, интервалы между соседними
заявками подчинены экспоненциальному закону. Принято, что за время Тр от каждого источника поступает одна заявка, тогда средний интервал поступления заявок равен Тр/п, поэтому вместо п объектов имитации источников заявок будем использовать один.
Код типа заявки определяется в виде чисел 1, 2, 3, 4, так как п=4. Код вида работы определяется также числами 1…3 соответственно. Для этого используются следующие исходные данные:
р1 … р4 — вероятности поступления заявок 1.4 типов соответственно-
р11 … Р43 — вероятности поступления заявок 1.4 типов с видами 1.3 работ соответственно.
Коды типа заявки и вида работ записываются в поля типЗ и видР соответственно. По этим кодам определяется среднее время вида работы и заносится в поле времяР.
В процессе выполнения модели накапливаются следующие статистические данные:
постЗаявТип1 … постЗаявТип4, постЗаявТип — количество поступивших заявок 1.4 типов и заявок всех типов-
выпЗаявТип1 … выпЗаявТип4, выпЗаявТип — количество выполненных заявок 1.4 типов и заявок всех типов-
выпРабВида11 … выпРабВида43 — количество выполненных заявок 1.4 типов с видами 1.3 работ соответственно.
Поскольку эти данные накапливаются за все прогоны модели, то для получения средних значений они делятся на количество прогонов колПрог. Например, выпЗаяв-Тип1=выпЗаявТип1/ колПрог.
По этим же статистическим данным рассчитываются: верВыпЗаяв1 … верВыпЗаяв4, верВыпЗаяв — вероятности выполнения заявок 1.4 типов и заявок всех типов. Например, верВыпЗаяв1=выпЗаявТип1/постЗаявТип1.
Модель в AnyLogic Ввод исходных данных и вывод результатов
Для ввода исходных данных нам понадобятся несколько элементов «Параметр». «Параметр» используется для задания статических характеристик агента.
Для вывода результатов будет использоваться элемент
Исходные данные
0тр
0П 0 ри 0 р31 (3 колПрог
О& quot- 0 Т21 0 Р12 0 Р32 (3 колДисп
15 0 То1 ж 20 0 Т22 0 ТЗЗ 0. 7S 0Р13. 0. 75 (3 рзз (3 колСпец1
С? til 0 Т23 0 Т41 0 Р21 (3 И1 (3 колСпец2
0Т12 0 Т31 0 Т42 0Р22 (3 Р42 (3 колСпецЗ
0пз 50 15 0 Т32 25 25 0 Т43 45. 0 75 0Р23 0. 75 О р43 (3 колСпец4
Результаты моделирования
Q постЗаявТип 1 0 © выпЗаявТип1 0 Л верВыпЗаяв 1 0
О постЗаявТип2 0 С выпЗаявТип2 0 © верВыпЗаяв2 0
О постЗаявТипЗ 0 С выпЗаявТипЗ 0 С верВыпЗаявЗ 0
© постЗаявТип4 0 О выпЗаявТип4 0 Q верВыпЗаяв4 0
Q постЗаявТип 0 С выпЗаявТип 0 С верВыпЗаяв 0
© выпРабВида11 0 © выпРабВида12 0 © выпРабВида13 0
Q выпРабВида21 0 С выпРабВида22 0 © выпРабВида23 0
© выпРабВида31 0 Д выпРабВида32 0 Д выпРабВидаЗЗ 0
Q выпРабВида41 © ВЫпРабВида42 (J выпРабВида43
Q коИспСпец1 Я коИспСпец2 © коИспСпецЗ i^i коИспСпец4 Л коИспДисп
п п — п п г,
Рис. 2. Размещение элементов Параметр и Переменная
Таблица 1
Элементы и их свойства
Параметр Параметр
Имя Значение по умолчанию Имя Значение по умолчанию
Tp 30 T1 15
n 4 T01 2
T11 30 p11 0. 50
T12 40 p12 0. 75
T13 50 p13 1. 00
T21 20 p21 0. 50
T22 30 Р22 0. 75
T23 40 Р23 1. 00
T31 15 p31 0. 50
T32 25 Р32 0. 75
T33 35 Р33 1. 00
T41 25 p41 0. 50
T42 35 Р42 0. 75
T43 45 Р43 1. 00
колПрог 1000 колДисп 2
колСпец1 1 колСпец3 1
колСпец2 1 колСпец4 1
В таблице (Табл. 1) указаны значения параметров элементов, полученные по результатам наблюдений за реальным объектом и путем анализа его работы.
Вся модель будет разбита на 4 сегмента:
• источник заявок-
• диспетчеры-
• специалисты-
• учёт выполненных заявок.
Далее остановимся конкретнее на каждом из сегментов.
Сегмент Источник заявок состоит из одного элемента Source, который создает агентов и используется в качестве начальной точки потока агентов.
Так же в этом сегменте присутствует Java класс с названием Заявка. Он содержит следующие поля Java класса: типЗ, видР, времяР.
Java-кодом в поля entity/гипЗ и епШу. видР заносятся равномерно распределённые случайные числа. Они нужны далее для розыгрыша кодов типов заявок и кодов видов ремонта.
Сегмент Диспетчеры предназначен для распределения по специалистам заявок согласно их типам и видам работ в зависимости от занятости мастеров в текущий момент времени.
Данный сегмент содержит следующие объекты:
SelectOutput5 — объект направляет входящих агентов в один из пяти выходных портов в зависимости от выполнения заданных (детерминистических или заданных с помощью вероятностей) условий.
SelectOutput — направляет входящих агентов в один из двух выходных портов в зависимости от выполнения заданного (детерминистического или заданного с помощью вероятностей) условия.
Queue — моделирует очередь агентов, ожидающих приема объектами, следующими за данным в потоковой диаграмме, или же хранилище агентов общего назначения.
Delay — задерживает агентов на заданный период времени. Время задержки вычисляется динамически, может быть случайным, зависеть от текущего агента или от каких-то других условий.
Sink — используется в качестве конечной точки потока агентов.
Объектом типЗаявки (SelectOutput5) разыгрывается код типа заявки. Например, в поступившей заявке agent. типЗ=o. 723. Проверяется условие о: agent. типЗ=о. 723<-=р1=о.5. Условие о не выполняется. Тогда проверяется условие 1: agent. типЗ= 0. 723 & lt-=р2=о. 75. Условие i выполняется. Заявка пропускается на выход 1.
С выходов 0…3 объекта типЗаявки заявки поступают в очДисп (queue) с максимальной вместимостью, а затем в объект дисп (delay), имитирующий время работы одного из диспетчеров с одной заявкой.
Объект отказ (selectOutput) предназначен для розыгрыша отказа в принятии заявки с вероятностью q = 2%. Заявки, получившие отказ, уничтожаются объектом sink.
Принятые к выполнению заявки распределяются по типам объектом поТипамЗаяв (SelectOutput5), с выходов 0.3 этого объекта заявки поступают на объекты видРабЗаяв1… видРабЗаяв4 соответственно. Аналогичным образом как объектом типЗаявки этими объектами разыгрываются для заявок 1.4 типов коды видов 1.3 ремонтов.
Сегмент Специалисты предназначен для имитации ожидания освобождения специалистов, непосредственно времени выполнения соответствующего вида работ и отправки выполненной заявки в сегмент учёта.
Данный сегмент содержит объекты queue и delay, которые были описаны выше.
С выходов 1.3 объекта видРабЗаяв1 заявки сразу поступают в объект очСпец1 (queue).
С выходов объектов видРабЗаяв2… видРабЗаяв4 заявки поступают на объекты свобСпец12, свобСпец1_з, своб-Спец14 соответственно. В принятых именах первая цифра означает группу мастеров, а вторая — тип заявки. Этими объектами проверяются условия. Например, объектом свобМастер1_з проверяется условие:
(очСпецl. size ()==o)&-&-
(спецl. size ()<-колСпецl)&-&-(спецз. size ()≠o)
Пуста ли очередь специалиста 1? И свободен ли специалист 1? И занят ли специалист 3 группы? Если сложное условие, состоящее из трёх простых условий, выполняется, заявка с выхода true объекта свобСпец1_з на объект спец1.
Аналогичные проверки осуществляются в объектах свобСпец13, свобСпец14.
Если условие не выполняется, то заявка с выходов false поступает в очередь очСпец2… очСпец4 соответственно.
Объекты свобСпец2_з, свобСпец24 проверяют возможности в текущий момент времени выполнения заявок з и 4 типов специалистом 2.
Объект свобСпецз4 проверяет возможность выполнения заявок 4 типа специалистом з.
Сегмент Учёт выполненных заявок предназначен для учёта количества выполненных заявок по типам и видам работ, а также для определения вероятности выполнения заявок в целом.
Сегмент построен на объектах selectOutput5 и объекте smk.
Объект поТипамЗаяв1 осуществляет разделение и учёт выполненных заявок по типам, а также рассчитывает вероятности выполнения заявок каждого типа. В количество поступивших заявок, а, следовательно, и в расчёт вероятностей входят и те заявки, которым отказано в обслуживании.
Объекты выпРабЗаяв1… выпРабЗаяв4 учитывают количество видов ремонтов, выполненных по заявкам каждого типа.
Объект smk1 уничтожает поступающие заявки. Введён-
Рис. з Вид готовой модели на AnyLogic
ный в поле Действие при входе код рассчитывает вероятность выполнения всех заявок.
После проведения выше описанных действий готовая модель выглядит следующим образом (Рис. 3).
В результате исследования работы модели получили следующие данные, заявок 1 типа выполнено 9853, с вероятностью выполнения 0,789, всего выполнено заявок всех типов 46 300 с вероятностью 0,927. Остальные данные работы модели приведены в таблице (Табл. 2).
Таблица 2
Показатели
Выполнено заявок типа 1 985з
работ вида 11 4958
работ вида 12 2481
работ вида 13 2414
Выполнено заявок типа 2 12 089
работ вида 21 6028
работ вида 22 з0бз
работ вида 23 2998
Выполнено заявок типа 3 122з0
работ вида 31 6078
работ вида 32 з074
работ вида 33 з078
Выполнено заявок типа 4 12 128
работ вида 41 5954
работ вида 42 зиз
работ вида 43 з061
Выполнено заявок всех типов 46з00
Вероятность выполнения всех заявок 0,927
Коэффициенты использования специалистов 1 1
Коэффициенты использования специалистов 2 0,954
Коэффициенты использования специалистов 3 0,8з
Коэффициенты использования специалистов 4 0,796
Коэффициент использования диспетчеров 0,998
ЛИТЕРАТУРА
1. Карпов Ю. Г. Имитационное моделирование систем. Введение в модели-рование с AriyLogic 5. СПб.: БХВ Петербург, 2006. 400 с.
2. AmyLogic User'-s Mai^al. XJ Technologies: [электрон. ресурс]. Режим дос-тупа: http: //www. xjtek. com
3. AnyLogic Tutorial. XJ Technologies: [электрон. ресурс]. Режим доступа: http: //www. xjtek. com
4. Многоподходное имитационное моделирование в ArnyLogic. XJ Technologies: [электрон. ресурс]. Режим доступа: http: //www. xjtek. ru
5. Иванова Е. В., Затонский А. В. Оценка и моделирование науч-но-исследвовательской работы студентов как многоагентной системы // Современные наукоемкие технологии. 2009. № 7. С. 75−78.
6. Затонский А. В. Выбор вида модели для прогнозирования развития экономических систем // Новый университет. Серия: Технические науки. 2012. № 1 (7). С. з7−41.
7. Затонский А. В. Теоретический подход к управлению социально-техническими системами // Программные продукты и системы. 2008. № 1. С. 29-з2.
Поступила в редакцию 09. 0з. 201б

ПоказатьСвернуть
Заполнить форму текущей работой