Разбор модели: техобслуживание самолётов

Моделирование системы технического обслуживания и ремонта самолетов

Привет читателям блога!

Мы продолжаем разбирать примеры моделей из AnyLogic. Цель таких технических постов – улучшить ваши навыки в разработке и анализе моделей, научить продвинутым возможностям AnyLogic, а также рассказать, как имитационное моделирование применяется в разных областях бизнеса. Ссылки на предыдущие разборы – в конце поста.

Сегодня рассмотрим Airlines Fleet – модель-игру, в которой вы будете ответственным за состояние пассажирских самолётов с тысячами лётных часов. В этой модели, как и в реальности, самолёты изнашиваются, требуют плановых проверок запчастей, а также экстренных замен оборудования. Обслуживание напрямую влияет на вероятность задержки рейсов. При значительных задержках уровень сервиса снижается, и компания может потерять деньги и репутацию.

На примере этой модели мы посмотрим, как агентное моделирование помогает анализировать и планировать сервисное обслуживание. Вы найдёте модель в списке примеров в AnyLogic Professional или University Researcher, а также в AnyLogic Cloud. Полетели!


Как работает модель: агентный подход к моделированию

Общий вид модели Airlines Fleet

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

Модель построена с помощью агентного подхода, поэтому схема её работы не задаётся диаграммами процесса, а формируется из поведения отдельных агентов:

  • регулярных рейсов из аэропорта Хитроу (Лондон) в 50 аэропортов по всему миру (тип агента – Flight);
  • самолётов, выполняющих эти рейсы и проходящих сервисное обслуживание (тип агента – Plane);
  • деталей самолётов, которые нужно ремонтировать или менять в процессе использования (тип агента – Equipment).

Диаграмма состояния агента Equipment

Диаграмма состояния агента Equipment

Диаграмма состояния агента Plane

Диаграмма состояния агента Plane

Агентный подход выбран неслучайно. В моделях, созданных с помощью него, у каждого типа агента – независимая структура, свойства и поведение, которые задаются диаграммами состояний, набором параметров и действий. Хотя агенты одного типа имеют одинаковую структуру, они независимы друг от друга. Это позволяет отразить их индивидуальные свойства. Например, в нашей модели время замены или ремонта зависит от вида детали.

У самолётов также есть индивидуальные характеристики и требования к запчастям. В модели учитывается 16 видов запчастей для 6 видов самолётов. Таким образом, общее количество запчастей составляет 96. Информация о каждой из них хранится во встроенной базе данных и используется для создания агентов.

Внешний вид базы данных в модели

Внешний вид базы данных в модели

Создание пользовательских объектов в модели

Агентный подход также будет полезен, если вы не нашли нужный объект на палитре AnyLogic, и вам нужно создать собственный. Например, для задания прибытия агентов в AnyLogic используется объект Schedule. В нашей модели он бы подошёл для моделирования расписания рейсов, однако он не позволяет менять график полётов динамически. Кроме того, информация о времени вылета уже задана в параметрах агента типа Flight. Поэтому в модели используется набор этих агентов, отсортированных по дате отправления.

Репликация объектов

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

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

Таблица для задания плана закупок на Main

Таблица для задания плана закупок на Main

Таблица во время выполнения модели

Таблица во время выполнения модели

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

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

  • местоположение и размеры объекта;
  • связь элемента интерфейса с переменной;
  • пользовательские параметры агентов;
  • тип-дженерик у Java-классов и типов агентов;

Посмотрим, как задаётся репликация, на примере ячейки Monthly Order (элемент enterAmount2) в таблице плана закупок.

В свойствах элемента код monthlyOrderSize[2*index + 1] определяет, с какой переменной в массиве monthlyOrderSize будет связано текстовое поле. Локальная переменная index указывает на индекс реплицированного объекта. Так как всего текстовых полей 8, то их индексы – от 0 до 7. 0-е поле позволяет менять значение переменной на 0-м месте в массиве, и т.д.

С помощью репликации удобно создавать большие объекты, например, таблицы, интерфейсы управления, а также сложные анимационные фигуры. В нашей модели репликация применяется для создания табло с расписанием полётов.

Табло с расписание полётов

Табло с расписание полётов

Динамическое моделирование

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

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

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

Эти задачи не имеют аналитического решения и могут быть решены только с помощью динамической модели системы.

Панель управления моделью и окно статистики

Панель управления моделью и окно статистики

Моделирование случайных событий

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

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

AnyLogic поддерживает выбор случайных распределений из готового списка или путём загрузки распределения из программ Stat::Fit или ExpertFit. Если вы не знаете, какое распределение подойдёт для вашего набора данных, используйте эмпирическое распределение: загрузите данные в модель, а AnyLogic рассчитает и графически покажет, как они распределены. Как это сделать (видео) >>

Оптимизационный эксперимент

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

Интерфейс оптимизационного эксперимента

Интерфейс оптимизационного эксперимента

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

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

Результаты оптимизации можно использовать в эксперименте Simulation для более глубокого анализа работы системы, например, настроить сценарий “что если” и оценить возможные риски.



Надеюсь, этот разбор модели был полезным. А вот ссылки на другие посты, где мы разбираем модели:

Разборы каких моделей вы бы хотели увидеть в блоге? Напишите в комментариях, а мы возьмём на заметку 😉

Похожие материалы