Построение модели предоставления технической поддержки пользователей на языке моделирования anylogic
Автор: Срульдинов А.Р., Варламова С.А.
Журнал: Juvenis scientia @jscientia
Рубрика: Информатика
Статья в выпуске: 3, 2016 года.
Бесплатный доступ
Описаны основные принципы разработки агентной модели на языке AnyLogic. Обоснованы преимущества имитационного моделирования для широкого круга задач. Разработаны структурная и агентная модели технической поддержки пользователей. Описаны элементы модели и значения ее параметров. Произведен анализ результатов моделирования
Агентная модель, техническая поддержка
Короткий адрес: https://sciup.org/14110106
IDR: 14110106
Текст научной статьи Построение модели предоставления технической поддержки пользователей на языке моделирования anylogic
Современный этап развития человечества отличается тем, что на смену века энергетики приходит век информатики. Происходит интенсивное внедрение новых информационных технологий во все сферы человеческой деятельности.
Появление новейших информационных технологий увеличивает не только возможности моделирующих систем, но и позволяет применять большее многообразие моделей и способов их реализации.
В настоящее время подготовка управленческих решений требует принятия во внимание большого числа различных факторов, влияющих на динамику исследуемых систем. Лицам, принимающим решения, необходимо анализировать сотни различных сценариев (вариантов решений), что обуславливает необходимость разработки имитационных моделей различного типа, интеграции этих моделей с базами и хранилищами данных, создания оптимизационных модулей для имитационных моделей.
Суть имитационного моделирования заключается в компьютерной реализации математической модели изучаемой системы для использования в целях симуляции (имитации) поведения реальной системы.
В настоящее время сфера применения имитационного моделирования практически не ограничена. Имитационные модели разрабатываются для изучения поведения отдельных предприятий и корпораций, исследования рыночного равновесия, оценки последствий государственного регулирования в экономике, оптимального управления логистическими системами, изучения эпидемиологии (прогнозирования динамики распространения заболеваний) и решения других практических задач.
В данной статье попробуем с помощью компьютерной имитационной модели описать процесс предоставления технической поддержки пользователям.
В отдел технической поддержки пользователей поступают заявки n типов с вероятностями р1, р2, …, рn соответственно. Интервалы времени Тп между двумя очередными поступлениями одного типа заявок случайные. Каждый любой тип заявки может требовать одного из а1, а2, …, аk видов работ с вероятностями рa1, рa2, …, рak соответственно.
В отделе работают n1, n2, …, nn специалистов для выполнения заявок каждого типа соответственно. Специалист n1 выполняет заявки первого типа, если таких заявок нет и остальные специалисты заняты, то специалист n1 выполняет заявки остальных типов, при этом поступающие заявки первого типа ожидают его освобождения. Аналогичные обязанности и у остальных специалистов, кроме специалиста nn, он выполняет заявки одного n-го типа, в нашем случае это разработчик.
Время выполнения заявки случайное, не зависит от специалиста, а зависит только от поставленной задачи: Т11,…, Т1n – для заявок первого типа, Т21,…, Т2n – для заявок второго типа, Tn1,…, Tnn – для заявок n-го типа.
Прием и распределение заявок между специалистами осуществляется d диспетчерами. Время, затрачиваемое одним диспетчером на одну заявку, Т1, случайное. Диспетчерами не принимаются к ремонту q заявок всех типов.
Интервалы времени между поступлениями заявок, и время выполнения заявок распределены по экспоненциальному закону.
Представим отдел технической поддержки как СМО (рис. 1).
Отдел технической поддержки представляет собой многофазную многоканальную систему массового обслуживания разомкнутого типа с отказами.

Рис. 1. Отдел технической поддержки как СМО
Заявки должны иметь следующие параметры (поля):
-
• типЗ — код типа заявки;
-
• видР — вид работы;
-
• времяР — время выполнения одного вида работы;
Как говорилось выше, интервалы между соседними заявками подчинены экспоненциальному закону. Принято, что за время Tp от каждого источника поступает одна заявка, тогда средний интервал поступления заявок равен Tp/n, поэтому вместо n объектов имитации источников заявок будем использовать один.
Код типа заявки определяется в виде чисел 1, 2, 3, 4, так как n=4. Код вида работы определяется также числами 1…3 соответственно. Для этого используются следующие исходные данные:
p1 … p4 — вероятности поступления заявок 1…4 типов соответственно;
p11 … p43 — вероятности поступления заявок 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Ввод исходных данных и вывод результатов
Для ввода исходных данных нам понадобятся несколько элементов «Параметр». «Параметр» используется для задания статических характеристик агента.
Для вывода результатов будет использоваться элемент
«Переменная». Она предназначена для моделирования изменяющихся характеристик агента или для хранения результатов работы модели (Рис. 2).
Исходные данные |
||||
0тР |
||||
3 n° |
3 ри |
3 р31 3 колПрог |
||
3 Т1 3 Т21 |
0Р12 |
(3 р32 (3 колДисп |
||
(3 Tol (3 Т22 |
3 тзз |
(Зр1з |
3 рЗЗ 3 колСпец! |
|
ЗТП ЗТ23 |
3 Т41 |
0Р21 |
3 Р41 3 колСпец2 |
|
ЗП2 3™ |
3 Т42 |
0Р22 |
3 Р42 3 колСпецЗ |
|
ЗТ13 3 Т32 |
ЗТ43 |
(?Р23 |
3 р43 3 колСпец4 |
|
50 25 |
45 |
|||
Результаты моделирования |
||||
0 постЗаявТип 1 |
0 выпЗаявТип1 |
0 верВыпЗаяв! |
||
О постЗаявТип2 |
0 выпЗаявТип2 |
0 верВыпЗаяв2 |
||
0 постЗаявТипЗ |
0 выпЗаявТипЗ |
0 верВыпЗаявЗ |
||
О постЗаявТип4 |
0 выпЗаявТип4 |
0 верВыпЗаяв4 |
||
О постЗаявТип |
0 выпЗаявТип |
0 верВыпЗаяв |
||
0 выпРабВидаИ |
0 выпРабВида12 |
0 выпРабВида13 |
||
0 выпРабВида21 |
0 выпРабВида22 |
0 выпРабВида23 |
||
О выпРабВидаЗ! |
0 выпРабВида32 |
0 выпРабВидаЗЗ |
||
О выпРабВида41 |
0 выпРабВида42 |
0 выпРабБида43 |
||
0 коИспСпец! ( коИспСпец2 0 коИспСпецЗ 0 коИспСпец4 0 коИспДисп 0 0 0 0 0 |
||||
Рис. 2. Размещение элементов Параметр и Переменная
Таблица 1
Элементы и их свойства |
|||
Параметр |
Параметр |
||
Имя |
Значение по умолчанию |
Имя |
Значение по умолчанию |
Tp |
30 |
T1 |
15 |
n |
4 |
To1 |
2 |
T11 |
30 |
p11 |
0.50 |
T12 |
40 |
p12 |
0.75 |
T13 |
50 |
p13 |
1.00 |
T21 |
20 |
p21 |
0.50 |
T22 |
30 |
p22 |
0.75 |
T23 |
40 |
p23 |
1.00 |
T31 |
15 |
p31 |
0.50 |
T32 |
25 |
p32 |
0.75 |
T33 |
35 |
p33 |
1.00 |
T41 |
25 |
p41 |
0.50 |
T42 |
35 |
p42 |
0.75 |
T43 |
45 |
p43 |
1.00 |
колПрог |
1000 |
колДисп |
2 |
колСпец1 |
1 |
колСпец3 |
1 |
колСпец2 |
1 |
колСпец4 |
1 |
В таблице (Табл. 1) указаны значения параметров элементов, полученные по результатам наблюдений за реальным объектом и путем анализа его работы.
Вся модель будет разбита на 4 сегмента:
-
• источник заявок;
-
• диспетчеры;
-
• специалисты;
-
• учёт выполненных заявок.
Далее остановимся конкретнее на каждом из сегментов.
Сегмент Источник заявок состоит из одного элемента Source, который создает агентов и используется в качестве начальной точки потока агентов.
Так же в этом сегменте присутствует Java класс с названием Заявка. Он содержит следующие поля Java класса: типЗ, видР, времяР.
Java-кодом в поля entity.типЗ и entity.видР заносятся равномерно распределённые случайные числа. Они нужны далее для розыгрыша кодов типов заявок и кодов видов ремонта.
Сегмент Диспетчеры предназначен для распределения по специалистам заявок согласно их типам и видам работ в зависимости от занятости мастеров в текущий момент времени.
Данный сегмент содержит следующие объекты:
SelectOutput5 – объект направляет входящих агентов в один из пяти выходных портов в зависимости от выполнения заданных (детерминистических или заданных с помощью вероятностей) условий.
SelectOutput – направляет входящих агентов в один из двух выходных портов в зависимости от выполнения заданного (детерминистического или заданного с помощью вероятностей) условия.
Queue – моделирует очередь агентов, ожидающих приема объектами, следующими за данным в потоковой диаграмме, или же хранилище агентов общего назначения.
Delay – задерживает агентов на заданный период времени. Время задержки вычисляется динамически, может быть случайным, зависеть от текущего агента или от каких-то других условий.
Sink – используется в качестве конечной точки потока агентов.
Объектом типЗаявки (SelectOutput5) разыгрывается код типа заявки. Например, в поступившей заявке agent.типЗ=0.723. Проверяется условие 0: agent. типЗ=0.723<=p1=0.5. Условие 0 не выполняется. Тогда проверяется условие 1: agent.типЗ= 0.723 <=p2=0.75. Условие 1 выполняется. Заявка пропускается на выход 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 заявки поступают на объекты свобСпец1_2, свобСпец1_3, своб-Спец1_4 соответственно. В принятых именах первая цифра означает группу мастеров, а вторая — тип заявки. Этими объектами проверяются условия. Например, объектом свобМастер1_3 проверяется условие:
Пуста ли очередь специалиста 1? И свободен ли специалист 1? И занят ли специалист 3 группы? Если сложное условие, состоящее из трёх простых условий, выполняется, заявка с выхода true объекта свобСпец1_3 на объект спец1.
Аналогичные проверки осуществляются в объектах свобСпец1_3, свобСпец1_4.
Если условие не выполняется, то заявка с выходов false поступает в очередь очСпец2…очСпец4 соответственно.
Объекты свобСпец2_3, свобСпец2_4 проверяют возможности в текущий момент времени выполнения заявок 3 и 4 типов специалистом 2.
Объект свобСпец3_4 проверяет возможность выполнения заявок 4 типа специалистом 3.
Сегмент Учёт выполненных заявок предназначен для учёта количества выполненных заявок по типам и видам работ, а также для определения вероятности выполнения заявок в целом.
Сегмент построен на объектах selectOutput5 и объекте sink.
Объект поТипамЗаяв1 осуществляет разделение и учёт выполненных заявок по типам, а также рассчитывает вероятности выполнения заявок каждого типа. В количество поступивших заявок, а, следовательно, и в расчёт вероятностей входят и те заявки, которым отказано в обслуживании.
Объекты выпРабЗаяв1…выпРабЗаяв4 учитывают количество видов ремонтов, выполненных по заявкам каждого типа.
Объект sink1 уничтожает поступающие заявки. Введён-

Рис. 3 Вид готовой модели на AnyLogic
ный в поле Действие при входе код рассчитывает вероятность выполнения всех заявок.
После проведения выше описанных действий готовая модель выглядит следующим образом (Рис. 3).
В результате исследования работы модели получили следующие данные, заявок 1 типа выполнено 9853, с вероятностью выполнения 0,789, всего выполнено заявок всех типов 46300 с вероятностью 0,927. Остальные данные работы модели приведены в таблице (Табл. 2).
Таблица 2
Показатели |
|
Выполнено заявок типа 1 |
9853 |
работ вида 11 |
4958 |
работ вида 12 |
2481 |
работ вида 13 |
2414 |
Выполнено заявок типа 2 |
12089 |
работ вида 21 |
6028 |
работ вида 22 |
3063 |
работ вида 23 |
2998 |
Выполнено заявок типа 3 |
12230 |
работ вида 31 |
6078 |
работ вида 32 |
3074 |
работ вида 33 |
3078 |
Выполнено заявок типа 4 |
12128 |
работ вида 41 |
5954 |
работ вида 42 |
3113 |
работ вида 43 |
3061 |
Выполнено заявок всех типов |
46300 |
Вероятность выполнения всех заявок |
0,927 |
Коэффициенты использования специалистов 1 |
1 |
Коэффициенты использования специалистов 2 |
0,954 |
Коэффициенты использования специалистов 3 |
0,83 |
Коэффициенты использования специалистов 4 |
0,796 |
Коэффициент использования диспетчеров |
0,998 |
Список литературы Построение модели предоставления технической поддержки пользователей на языке моделирования anylogic
- Карпов Ю. Г. Имитационное моделирование систем. Введение в модели-рование с AnyLogic 5. СПб.: БХВ Петербург, 2006. 400 с
- AnyLogic User’s Manual. XJ Technologies: . Режим дос-тупа: http://www.xjtek.com
- AnyLogic Tutorial. XJ Technologies: . Режим доступа: http://www.xjtek.com
- Многоподходное имитационное моделирование в AnyLogic. XJ Technologies: . Режим доступа: http://www.xjtek.ru
- Иванова Е.В., Затонский А.В. Оценка и моделирование научно-исследвовательской работы студентов как многоагентной системы//Современные наукоемкие технологии. 2009. № 7. С. 75-78
- Затонский А.В. Выбор вида модели для прогнозирования развития экономических систем//Новый университет. Серия: Технические науки. 2012. № 1 (7). С. 37-41
- Затонский А.В. Теоретический подход к управлению социально-техническими системами//Программные продукты и системы. 2008. № 1. С. 29-32