Добавление пунктов досмотра
Теперь мы дополняем картину пунктами досмотра. Это снова сервис с очередями. Нам нужно поместить точки обслуживания в
металлодетектор (металлорамку), который находится на схеме. Мы разворачиваем объект сервиса и размещаем его в центре металлодетектора.
Затем отрисовываем очередь к этому сервису. Очередь одна, идет змейкой. Немного укорачиваем выход из нее, чтобы пешеходы могли нормально перемещаться. Металлодетектор и рентгеновский сканер добавляем как объекты анимации, которые будут визуализировать процесс досмотра.
Теперь нужно настроить обслуживание на втором уровне. Переименовываем очередь в
Security Check Queue. После нее добавляем новый сервис с названием
Security Check Service. Время обслуживания задаем равномерным распределением (
uniform) от 15 до 120 секунд. В минутах это составляет диапазон от 0.25 до 2, что мы и указываем в свойствах.
Запускаем модель в 3D, чтобы проверить работу. Видно, как персонажи выстраиваются в очередь, проходят через металлодетектор и двигаются дальше. Очередь формируется корректно, модель работает.
Создание зоны ожидания у гейта
Это предпоследняя фаза. Мы нарисуем область ожидания возле выхода на посадку (гейта). Для этого используем элемент
«Многоугольная область» (Polygonal Area). Это геометрический объект, который моделирует место, где люди ждут объявления посадки на рейс. Расположим его слева от колонны, так как выход у нас левый.
После того как пассажир прошел все проверки, он должен попасть в эту зону. Добавляем в процесс элемент
«Ожидание» (Wait). В свойстве «Область» указываем нашу созданную зону area. Время задержки ставим конкретным значением —
2 часа (например, из-за задержки рейса).
Запускаем модель, чтобы увидеть, как люди собираются в зоне ожидания. Поскольку время задержки 2 часа, а время моделирования ограничено, мы уменьшаем его до 30 минут для теста. При этом важно помнить, что если мы меняем время ожидания, то при дальнейших настройках (например, инкубационного периода инфекции) это нужно будет синхронизировать.
Моделирование распространения инфекции
Это последняя фаза. Мы зададим логику заражения.
1. Создание переменной для заражения
В классе агента
Passenger создаем переменную
Infection. Тип значения —
double (дробное число). Инициализируем ее случайным распределением:
randomTrue(0.05). Это значит, что с вероятностью 5% агент получит значение 1 (инфицирован), в остальных случаях —
0 (здоров).
2. Настройка отображения агента
В свойствах фигуры агента разделяем отображение для 2D и 3D.
• В 3D будет отображаться фигурка человека.
• В 2D мы рисуем овал (кружок) в начале координат с радиусом 3.
Цвет заливки овала в 2D делаем динамическим в зависимости от статуса заражения. Используем функцию
lerpColor, которая возвращает цвет на основе линейной интерполяции. Если
Infection == 0, цвет будет
голубым. Если
Infection == 1, цвет будет
красным. Так как у нас только два значения, промежуточных цветов не будет, но функция удобна для связи цвета и состояния.
3. Создание стейтчарта агента (Statechart)
Возвращаемся к агенту Passenger и рисуем его
стейтчарт (диаграмму состояний). Добавляем два основных состояния и переход между ними.
• Первое состояние: Susceptible (Восприимчивый). Это начальное состояние для всех неинфицированных.
• Второе состояние: Infected (Зараженный).
• Переход: между состояниями срабатывает
по условию (Condition). Условие:
Infection > 0.5. Пока значение Infection меньше или равно 0.5, агент считается восприимчивым, как только превышает — становится зараженным.
4. Логика заражения других агентов
К состоянию «Зараженный» добавляем
внутренний переход (Internal Transition). Называем его
Infect Others.
• Срабатывает по
тайм-ауту (Timeout) каждую
1 секунду.
• В действии пишем
Java-код. Мы используем цикл for, чтобы пробежаться по всем агентам в радиусе 30 от текущего зараженного агента. Для этого используем функцию
getNeighbors(30). Каждому агенту p, попавшему в этот радиус, отправляется сообщение с текстом
"infection".
Фактически, зараженный агент каждую секунду «облучает» всех окружающих его пассажиров, отправляя им сообщения.
5. Обработка полученного сообщения
В свойствах агента переходим в раздел
«Соединения» (Connections) и настраиваем
«Действия при получении сообщения» (On message received). Здесь мы пишем код, который увеличивает значение переменной
Infection на
0.001 за каждое полученное сообщение.
Таким образом, если рядом с зараженным агентом кто-то стоит, он будет получать дозу инфекции каждую секунду. Постепенно его значение Infection накопится, превысит порог 0.5, и он сам перейдет в состояние «Зараженный», начав заражать других.
Проверка и результат
Запускаем модель. Изначально все агенты синие. Постепенно появляются первые красные (5%). Мы наблюдаем, как красные точки начинают влиять на синих вокруг себя. Цвета агентов меняются, и красный цвет начинает распространяться по зоне ожидания. Инфекция визуализируется в реальном времени.
Важный нюанс: сильное масштабирование (приближение) в 3D-окне вызывает серьезную нагрузку на рендеринг и оперативную память. Модель начинает тормозить, сборщику мусора требуется время для высвобождения ресурсов. Поэтому для наблюдения за динамикой лучше использовать вид без значительного приближения.
Краткие итоги
Построение имитационной модели в данной работе демонстрирует восходящий принцип разработки: от статичного размещения объектов к программированию сложного, эмерджентного поведения системы. Ключевая ценность изложенного подхода заключается в связывании физического пространства и логики агентов. Сначала решается инженерная задача по организации потоков — корректное расположение зон обслуживания и очередей задает топологию процесса, которая сама по себе может выявить «узкие горлышки» в пропускной способности аэропорта.
Однако качественный скачок в аналитических возможностях происходит при внедрении агентной логики на примере распространения инфекции. Здесь демонстрируется техника, превращающая модель из дискретно-событийной в агентную. Использование стейтчартов и механизма обмена сообщениями между агентами в заданном радиусе позволяет моделировать нелинейные процессы, где поведение толпы не задано извне, а является результатом множества локальных взаимодействий. Важен сам принцип накопления воздействия: переменная агента меняется не скачкообразно, а инкрементально, под влиянием длительного контакта, что гораздо ближе к реальной эпидемиологии, чем мгновенная передача состояния.
С практической точки зрения, такая модель является инструментом для сценарного анализа. Изменяя время ожидания в зоне посадки, радиус взаимодействия или интенсивность «облучения», можно количественно оценить, как архитектурные и операционные решения влияют на эпидемиологическую безопасность. Это показывает, что ценность модели — не в финальной анимации, а в способности стать «цифровым полигоном» для проверки гипотез, которые невозможно или неэтично тестировать в реальности. Наконец, затронута и инженерная проблема визуализации: разделение 2D- и 3D-графики с помощью функции lerpColor — это не просто эстетика, а способ создавать эффективные и информативные панели мониторинга, которые не перегружают вычислительные ресурсы при масштабировании модели.
1. Очереди в сервисах типа «металлодетектор» моделируются с помощью стандартных блоков библиотеки моделирования процессов.
2. Время обслуживания задается вероятностным распределением, например равномерным (uniform), отражая вариативность реальных операций.
3. Зона ожидания пассажиров перед гейтом моделируется с помощью элемента «Многоугольная область» и блока «Ожидание» (Wait).
4. Задание конкретного времени задержки в блоке Wait имитирует фиксированные события, такие как ожидание посадки.
5. Свойства агентов, например склонность к инфекции, задаются через переменные с вероятностной инициализацией (randomTrue).
6. Разделение анимации агента на 2D (схема) и 3D (реалистичный вид) оптимизирует восприятие и производительность модели.
7. Функция lerpColor позволяет динамически менять цвет фигуры агента в зависимости от значения любой его непрерывной переменной.
8. Стейтчарт (диаграмма состояний) является основным инструментом для моделирования смены состояний агента под воздействием условий.
9. Логика заражения реализуется через отправку сообщений соседним агентам, что запускает у них процесс накопления «дозы» инфекции.
10. Инкрементальное изменение внутренней переменной при получении множества сообщений симулирует эффект накопления при длительном контакте.
11. Интенсивный рендеринг графики, особенно в 3D, напрямую влияет на скорость симуляции и потребление памяти.
12. Сочетание процессного моделирования и агентной логики позволяет создавать многоуровневые модели сложных социотехнических систем.
1. Какой тип распределения и с какими параметрами используется для моделирования времени прохождения пункта досмотра?
2. Для чего в модели нужен элемент «Многоугольная область» и с каким блоком процесса он взаимодействует?
3. Каким образом задается и инициализируется переменная, определяющая статус заражения пассажира?
4. В чем преимущество разделения 2D- и 3D-графики для одного агента?
5. Какую функцию и с какими аргументами используют для динамической смены цвета заливки в зависимости от статуса агента?
6. Какие состояния предусмотрены в стейтчарте агента для моделирования заражения и как осуществляется переход между ними?
7. Каким образом зараженный агент циклически воздействует на окружающих?
8. Какую операцию выполняет здоровый агент при получении сообщения от зараженного?
9. Почему для изменения состояния агента используется условие Infection > 0.5, а не проверка на точное равенство единице?
10. Почему агент становится зараженным не мгновенно после контакта, а с задержкой?
11. Какие негативные последствия для производительности модели возникают при сильном масштабировании 3D-вида?
12. Зачем может понадобиться корректировать время инкубационного периода при изменении времени ожидания в модели?
