Платформенная агентная модель производственного кластера

Автор: Сергей Лукьянчиков, InterSystems

Фоновое фото баннера статьи: Pavel Danilyuk

1. Цель

В данной публикации мы описываем прототип и исследуем оркестровку нескольких агентных моделей связанных друг с другом роботизированных фабрик (представленных каждая своей моделью) с применением универсальной платформы данных – добиваясь симуляции наблюдаемых и прогнозных свойств группы фабрик (производственного кластера). В прототипе были задействованы программный комплекс NetLogo для агентных моделей фабрик (с моделью «Robotic Factory» [1] в качестве основы) и платформа данных InterSystems IRIS для оркестровки NetLogo и сквозной симуляции системы «фабрики-кластер».

Существенный эффект от симуляции межфабричных связей в контексте интегрированного производства был доказан уже давно в ходе множественных научно-практических изысканий (например, Ferdows and Carabetta, 2006 [2]). Для ознакомления с подходами к выявлению эффекта при различных конфигурациях производственных кластеров мы рекомендуем читателю обратиться к этим изысканиям. В нашей публикации мы сосредоточили внимание на функциональных преимуществах от симуляции производственного кластера средствами агентного моделирования.

Преимущества от платформенной реализации симуляции производственных кластеров начали материализовываться относительно недавно в связи с эволюцией возможностей компьютеров и программного обеспечения, сделавшей целесообразными параллельные вычисления, интеграционный обмен в приближении к реальному времени и безбарьерное использование полного спектра инструментов моделирования (например, Ng et al., 2011 [3]). Как уже упоминалось выше, для ознакомления с подходами к выявлению эффекта при платформенной реализации симуляции производственных кластеров мы предлагаем читателю обратиться к соответствующим исследованиям. В нашей публикации мы уделяем основное внимание преимуществам от оркестровки агентных моделей фабрик в составе производственного кластера на базе универсальной платформы данных.

Три взаимосвязанные NetLogo-модели фабрик, входящие в прототип, могут работать и вне платформы данных InterSystems IRIS – тогда сохраняется функционал агентной симуляции, но теряются преимущества платформенной оркестровки, кластерной дескриптивной и предиктивной аналитики.

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

2. Сущности, переменные состояния и масштабы       

В нижеприведенной таблице обобщаются сведения о сущностях, переменных состояния и масштабах:

2.1 Масштабы

Мы используем три масштаба: производственный кластер – рассматривает связанные фабрики как одно целое, фабрика – рассматривает фабрику как одно целое, и производственная операция – моделирует элементы фабрики по отдельности.

Временное измерение учитывается при помощи команд hang и wait в InterSystems IRIS и NetLogo, соответственно. Обе команды позволяют замедлять исполнение, адаптируя прототип для практически любого масштаба времени: от приближенного к фактической скорости до ускоренного исполнения (например, для симуляции в составе механизма прогнозирования и т. п.).

Пространственные измерения учитываются в NetLogo при помощи пространственных (2D) координат в сочетании с агентами, реализованными как “patches”. Пространственные координаты (плюс опция “world wrapping”) позволяют моделировать практически любую пространственную конфигурацию производственных операций фабрик.

2.2 Сущности

Сущности, функционирующие в масштабах кластера и фабрики, носят те же названия, что и масштабы: производственный кластер – набор связанных через потребление/выпуск фабрик, и фабрика – производственное предприятие, обслуживающее свой поток поступающих внешних заказов и предоставляющее свой выпуск для потребления другими фабриками.

Масштаб производственной операции содержит две сущности: агенты – роботы, производственное оборудование (далее «машины»), склады (материалов и готовой продукции); и глобальная сущность – совокупность всех глобальных переменных, используемых в NetLogo-моделях и реализующих как реальные, так и абстрактные атрибуты.

2.3 Переменные состояния

Каждый из макрокомпонентов исследуемого нами прототипа, InterSystems IRIS и NetLogo, обладает собственными переменными состояния. InterSystems IRIS содержит следующие переменные состояния: продукция (подробнее), операция (подробнее), процесс (подробнее) и шаг (подробнее). Их описания приведены выше в Таблице 1, мы лишь приведем примеры каждой переменной в действии в InterSystems IRIS:

Все операции и процессы в продукции isc.py.test.Production (см. выше Рисунок 2) опираются на пакет расширений ML Toolkit для InterSystems IRIS и, в частности, на его свободно доступный компонент Python Gateway. Одна из операций – PYTHON – реализует на уровне кластера взаимодействие с Python (установлен на том же компьютере, что и InterSystems IRIS). Остальные три – PYTHON A/B/C – реализуют взаимодействие на уровне фабрики с NetLogo через Python (используя доступ и управление задачами на уровне ОС в Python). Процесс NETLOGO.CLUSTER выполняет оркестровку сквозной симуляции на уровне кластера, процессы NETLOGO.FACTORYA/B/C – сквозной симуляции на уровне фабрики.

Переменными состояния NetLogo являются модель (подробнее), роль (подробнее), продукт (подробнее), количество (подробнее) и направление (подробнее). Их описания приведены выше в Таблице 1, мы лишь приведем примеры каждой переменной в действии в NetLogo:

Модель Robotic Factory A (см. выше Рисунок 5) реализует роли агентов (например, breed [ cutters cutter ]), типы продуктов (например, атрибут роботов product-type), количества продуктов (например, атрибуты product и supply всех ролей агентов) и направления роботов (например, атрибут роботов destination).

3. Определение и организация процесса

Наш прототип был выполнен при следующих основных допущениях, в большинстве основанных на  «Robotic Factory» [1] и адаптированных к контексту производственного кластера:

• Продукция, хранящаяся на складах каждой из фабрик (loading-docks и storages, в терминах ролей в наших NetLogo-моделях), может учитываться только как количество типа supply. Т. е., на складах не подразумевается производство готовой продукции.

• Продукция, находящаяся при роботах каждой из фабрик (robots), может учитываться только как количество типа product. Т. е., при роботах не подразумевается потребление материалов в производственном процессе.

• Продукция, находящаяся при машинах каждой из фабрик (cutters, stitchers и finishers) может учитываться как количество типа supply или product в зависимости от того, ожидается ли списание этой продукции в производственный процесс машины или ее поступление из производственного процесса машины.

• В каждом такте симуляции для каждой из фабрик возможно пополнение набора внешних заказов (роль агента orders) в соответствии с равномерным законом (т. е. новые заказы появляются в случайных тактах, пропорция которых в общем потоке тактов фиксирована) с линейно-стохастическим нарастанием количеств новых заказов. Каждый заказ содержит потребность в одной единице готовой продукции (т. е. либо в одном стандартном, либо в одном люксовом продукте).

• В каждом такте симуляции каждая фабрика обслуживает внешние заказы в пределах запаса продукции (products), выпущенной ее сшивными машинами (stitchers – на которых происходит распределение полуготовых продуктов по внешним заказам). Любой внешний заказ, обслуженный фабрикой, приносит ей единицу денежных средств (глобальная переменная cash), уменьшает ее запас готовой продукции, а также ее пул внешних заказов.

• Та часть выпуска фабрики за такт, которая не была востребована, становится доступной для потенциальной отгрузки (глобальная переменная dispatch) другим фабрикам кластера. Если за тот же такт после обслуживания внешних заказов остается достаточный запас готовой продукции для выполнения отгрузки другим фабрикам, то отгрузка происходит (уменьшается запас готовой продукции, количество отгрузки отражается в .csv-файле, и становится возможным его потребление другими фабриками кластера).

• Фабрики формируют потребление производственных материалов, покупая их за денежные средства или получая в их качестве выпуска других фабрик. Потребление происходит каждый такт, его объем ограничен суммой доступного остатка денежных средств и отгрузок выпуска фабрик-поставщиков (подробнее о конфигурации обсуждаемого кластера см. в сл. разделе).

• Маршрутизация роботов среди производственных машин, управление погрузкой на них и разгрузкой с них продукции, управление уровнем заряда их батарей  реализованы почти так же, как и в «Robotic Factory» [1] – единственное отличие нашего прототипа состоит в том, что роботы могут перемещать более одной единицы продукции между машинами (позволяя, таким образом, всему прототипу справляться с нарастанием количеств внешних заказов).

На нижеприведенной диаграмме мы видим три процесса InterSystems IRIS (NETLOGO.FACTORYA, NETLOGO.FACTORYB и NETLOGO.FACTORYC), реализующие в продукции InterSystems IRIS фабрики A, B и C, а также три соответствующие NetLogo-модели:

Каждый процесс InterSystems IRIS запускает NetLogo-эксперимент с использованием соответствующей NetLogo-модели – и начинает циклически выполнять мониторинг динамики эксперимента путем считывания метрик уровня фабрики (на каждом такте симуляции метрики экспортируются NetLogo-моделями в .csv-файлы с заданными именами, находящиеся в заданной рабочей директории). В дополнение к процессам уровня фабрики мы создали процесс InterSystems IRIS уровня кластера: NETLOGO.CLUSTER. Этот процесс запускает процессы уровня фабрики и выполняет циклическое вычисление метрик уровня кластера:

Метрики уровня кластера и уровня фабрики сохраняются в таблицах InterSystems IRIS, становясь фактами для OLAP-кубов InterSystems IRIS, на которых работают различные визуальные компоненты – см. ниже скриншот индикаторной панели уровня кластера (cockpit):

Ход исполнения процессов InterSystems IRIS отображается в визуальной трассировке (см. ниже Рисунок 9). Мы можем отследить точную последовательность, продолжительность и результат активностей, исполняемых во всех процессах и операциях InterSystems IRIS:

Мы можем контролировать статус всех очередей сообщений, возникающих в связи с работой процессов и операций InterSystems IRIS, используя монитор очередей сообщений:

Как было упомянуто выше в разделе «Сущности, переменные состояния и масштабы» (подраздел «Масштабы»), прототип не подразумевает явной организации во времени или заданной длительности такта. Варьируя продолжительностью паузы в исполнении процессов InterSystems IRIS и NetLogo-моделей, мы можем добиваться любого необходимого темпа. Отсутствие предопределенной последовательности исполнения среди как процессов InterSystems IRIS, так и NetLogo-моделей является базисом для концепций спонтанности и стохастичности прототипа (подробнее см. в сл. разделе).

4. Концепции дизайна

4.1 Базовые принципы

Агентная симуляция при помощи NetLogo-моделей уровня фабрики позволяет довольно точно смоделировать динамику основных метрик уровня фабрики: потребление материалов, запасы, выпуск продукции, загрузку роботов и т. п. Тем не менее, для метрик уровня кластера простого агрегирования метрик, считываемых с уровня отдельных фабрик, недостаточно – нам нужно моделировать связи между фабриками. И именно в этот момент InterSystems IRIS начинает играть роль «дирижёра», моделируя потоки и зависимости между фабриками. Например, в нашем прототипе выпуск фабрики C может потребляться фабрикой A. Фабрика C блокирует рабочую директорию и (заново) создает файл OutputC.csv, содержащий (помимо прочих метрик) отгрузку ее текущего такта симуляции, например, 10 единиц. Фабрика A циклически (с частотой, регулируемой моделью фабрики A) предпринимает попытку прочитать OutputC.csv и добавить выпуск фабрики C из этого файла к своему потреблению – при условии, что рабочая директория не заблокирована другими моделями или процессами. Процесс InterSystems IRIS NETLOGO.CLUSTER циклически (с определенной в нем самом частотой) предпринимает попытку прочитать таблицы OUTPUTA, OUTPUTB и OUTPUTC – при условии, что рабочая директория не заблокирована другими моделями или процессами. Таким образом, InterSystems IRIS позволяет NetLogo-моделям конкурировать за доступ к рабочей директории, тем самым имитируя «исполнительский ажиотаж», возникающий в реальной жизни в любом интегрированном производственном кластере. С другой стороны, InterSystems IRIS заставляет свой процесс-супервайзер NETLOGO.CLUSTER участвовать в конкуренции за доступ к рабочей директории (вместе с NetLogo-моделями уровня фабрики), чтобы гарантировать, что консолидируемые им выходные данные не подвергаются изменению в ходе консолидации. Прочие концепции дизайна нашего прототипа будут изложены далее в этом разделе.

4.2 Спонтанность

Ранее уже упоминалось, что NetLogo-модели и процессы InterSystems IRIS (и уровня фабрики, и уровня кластера) конкурируют за доступ к рабочей директории. Т. е., помимо спонтанности, реализованной в каждой из NetLogo-моделей (в т. ч., стохастичности количеств во взаимодействиях и направлений роботов, подробнее см. в подразделе «Стохастичность»), возникает дополнительный слой спонтанности, основанный на процессах InterSystems IRIS:

Взятые вместе, NetLogo и InterSystems IRIS моделируют конкуренцию за доступ к ресурсам и информации, неизбежную в условиях производственного кластера.

4.3 Адаптация

Адаптация на уровне кластера реализована в NetLogo-моделях: по мере того, как увеличивается пул внешних заказов самой фабрики и ее фабрики-потребителя (например, фабрика B может потреблять выпуск фабрики A), спрос на уровне фабрики (глобальные переменные demand0 и demand1, соответствующие спросу на стандартную и люксовую продукцию) учитывает необслуженные заказы как самой фабрики, так и фабрики-потребителя (глобальные переменные req0 и req1, соответствующие спросу фабрики-потребителя на стандартную и люксовую продукцию):

Текущий объем пула внешних заказов записывается на каждом такте каждой из фабрик в ее файл OutputA/B/C.csv, делая возможным считывание фабриками-поставщиками объема пула заказов фабрик-потребителей.

На каждом такте симуляции спрос на уровне фабрики участвует в расчете списания фабрикой материалов со склада в производство:

4.4 Результаты

Конечным результатом для каждой фабрики является обслуживание нарастающего потока внешних заказов за счет выпуска стандартной и люксовой продукции. У каждой фабрики есть свой пул внешних заказов, при этом каждая фабрика отгружает фабрике-потребителю оставшийся невостребованным после обслуживания заказов выпуск отдельного такта. Как уже упоминалось выше, объем пула необслуженных внешних заказов фабрики учитывается ее фабрикой-поставщиком при оценке спроса и расчете списаний в производство. Осуществление производства на каждой фабрике зависит от эффективности парка ее роботов, которые перемещают продукцию между машинами и складами. Следовательно, критически важную роль в достижении фабрикой результатов играет работа парка ее роботов. Это объясняет, почему объем пула необслуженных заказов (по типу продукции) соседствует с показателями работы парка роботов (уровень заряда роботов и численность роботов) в кластерной секции индикаторной панели. Если теперь сформулировать суть результатов одной фразой, то получится «снижать объем пула необслуженных заказов, повышая уровень заряда батарей роботов».

4.5 Обучение

Помимо изначальной способности агентных систем к самоорганизации, в прототипе в явном виде присутствуют механизмы машинного обучения. Мы реализовали обучение линейной регрессионной модели, аппроксимирующей зависимость уровня заряда всех роботов кластера (в следующем n-ом такте симуляции: например, в непосредственно следующем такте) от суммарного объема пулов необслуженных заказов в кластере на стандартную и люксовую продукцию (наблюдаемого в течение определенного скользящего периода: например, последних 50 тактов симуляции). Данный механизм машинного обучения внедрен в процесс NETLOGO.CLUSTER при помощи расширений ML Toolkit для InterSystems IRIS и запускается в каждом такте посредством операции PYTHON, обеспечивающей взаимодействие с локальным Python:

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

4.6 Прогнозирование

Метод обученной модели, отвечающий за прогнозирование, вызывается на данных об объемах пулов необслуженных заказов при очередном считывании:

Теперь у нас есть и фактическое последнее считанное (т. е. в текущем такте) значение суммарного уровня заряда роботов в кластере, и прогнозное значение на следующий такт. Мы можем расширить приборную доску кластера за счет этой информации:

Прогноз может оказаться чрезвычайно полезен для выявления потенциальных проблем с уровнем заряда роботов:

4.7 Сенсорика

Роботы, обеспечивающие внутрифабричную логистику, проявляют базовые сенсорные способности, когда определяют возможность забрать выпущенную той или иной машиной продукцию, или необходимость выполнить зарядку своих батарей, или экстренную потребность в роботах с прерыванием процесса зарядки. Для этого они «улавливают» присутствие поблизости от себя машин или складов. База (где производится зарядка роботов) «улавливает» присутствие роботов поблизости от себя.

4.8 Взаимодействие

Роботы забирают продукцию, наличествующую у машины или склада, и перемещают ее к другой машине или складу. Или, если более формально, то агенты-роботы «взаимодействуют» с агентами-машинами и агентами-складами. Такие взаимодействия сводятся к изменению уровня запасов у передающего и у получающего агентов, а также к смене направления у робота. Взаимодействие робота с базой происходит при зарядке батареи: агент-робот должен провести некоторое количество тактов симуляции на базе (если только у фабрики не возникла неотложная потребность в роботах где-нибудь в производстве). Помимо взаимодействий уровня фабрики мы видим взаимодействия уровня кластера, реализованные в виде межфабричных отгрузок/потребления.

4.9 Стохастичность

Мы изменили исходную NetLogo-модель «Robotic Factory» [1], реализовав рандомизацию количеств во всех основных взаимодействиях:

Также, расчет количества внешних заказов, генерируемых для каждой фабрики за один такт, использует случайные величины:

А также, расчет количества продукции для отгрузки фабрике-потребителю:

Резюмируя, вышеупомянутые элементы стохастичности (в сочетании с элементами спонтанности, упомянутыми ранее, равно как и со стохастичностью выбора направления и расходования/восстановление запаса энергии роботами) обеспечивают случайность динамики всех ключевых типов количеств в прототипе и недетерминированность поведения производственного кластера.

4.10 Коллективы

Фабрики состоят из коллективов роботов, машин и складов; а из фабрик состоит кластер – коллектив, прототип которого мы изучаем. Коллективы уровня фабрики генерируются NetLogo-моделями при запуске симуляции в режиме эксперимента:

На уровне кластера конфигурация коллектива фабрик определяется пользователем и реализуется в NetLogo и в InterSystems IRIS. С учетом целей данного прототипа, как упоминалось ранее в разделе «Концепции дизайна», была применена конфигурация, основанная на круговом потоке межфабричных взаимодействий (отгрузки/потребление). Приводит в действие и выполняет оркестровку этой конфигурации процесс InterSystems IRIS NETLOGO.CLUSTER (запускает процессы NETLOGO.FACTORYA/B/C и ведет мониторинг их метрик):

Механизмы межфабричных взаимодействий в NetLogo были описаны выше в подразделе «Взаимодействие». NetLogo-модели трех фабрик содержат полную реализацию коллектива уровня кластера.

4.11 Наблюдение

Генерируемые в ходе NetLogo-эксперимента данные уровня фабрики, такие как количества разных типов и прочие метрики, циклически (на каждом такте симуляции) экспортируются в .csv-файл и становятся доступными для других NetLogo-экспериментов и процессов InterSystems IRIS:

5. Инициализация

Начальные состояния всех моделей фабрик определяются посредством процедуры setup в соответствующих NetLogo-моделях. Как мы могли уже видеть выше в подразделе «Коллективы», базовые атрибуты агентов инициализируются при генерации: x- и y-координаты (влияют на расстояния, которые предстоит преодолевать роботам), классы и статусы машин (влияют на тип выпускаемой продукции и доступность машин), уровень запасов материалов (влияет на начальную продолжительность работы без пополнения запасов машины или склада), и т. п.

Глобальные переменные инициализируются также через процедуру setup:

Ряд глобальных переменных уровня фабрики реинициализируются на каждом такте симуляции в ходе исполнения процедуры go; таким образом гарантируется, что в отсутствие доступа к .csv-файлу фабрики-поставщика или фабрики-потребителя из-за блокировки и пропуска моделью фабрики чтения .csv-файла, зависящим от этого чтения глобальным переменным присваиваются нулевые значения (некоторые из них, например, intake и dispatch, могут быть реинициализированы ненулевыми значениями вне зависимости от исхода попытки чтения .csv-файла):

6. Исходные данные

.csv-файлы (OutputA.csv, OutputB.csv и OutputC.csv), доступные при запуске процесса InterSystems IRIS NETLOGO.CLUSTER и содержащие исходные значения определенного набора метрик уровня фабрики, выступают носителями исходных данных для фабрик. В большинстве испытаний мы предпочитали указывать нулевые исходные значения в .csv-файле каждой из фабрик:

По мере того, как процессы NETLOGO.FACTORYA/B/C (будучи запущены процессом NETLOGO.CLUSTER), в свою очередь, запускают каждый свой NetLogo-эксперимент, значения метрик в .csv-файлах начинают обновляться с каждым тактом симуляции для каждой из фабрик:

Обновленные значения метрик могут быть считаны другими фабриками из .csv-файлов:

7. Подмодели

В самом начале этой публикации упоминалось, что NetLogo-модели фабрик в нашем прототипе являются адаптациями модели «Robotic Factory» [1] – мы бы посоветовали читателю изучить документацию и программный код этой исходной модели, воспользовавшись ссылкой в разделе «Источники».

Все наиболее важные новые/адаптированные элементы NetLogo-моделей, реализованных в нашем прототипе, были описаны достаточно детально в тексте публикации, и мы уверены, что это оптимальный подход к их изложению (по сравнению с цитированием всего NetLogo-кода в данном разделе).

Продолжая в той же логике: все объекты InterSystems IRIS (продукция, процессы, операции, таблицы, кубы, сводные таблицы, индикаторные панели и т. п.) хранятся в виде программного кода в платформе; и тем не менее, мы не процитировали здесь ни одной строчки их кода, т. к. считаем, что визуальный формат в нашем случае подходит гораздо лучше.

Несмотря на эти соображения, если у читателя возникнет желание поработать собственноручно с материалом нашего прототипа (полным или частичным), чтобы воссоздать описанный здесь сценарий или ускорить разработку собственного проекта – автор будет рад поделиться материалом, пожалуйста свяжитесь с ним через LinkedIn.  

Выводы

В завершение мы хотели бы сформулировать основные выводы из проделанной технической и исследовательской работы, описанной в данной публикации:

• Главным преимуществом платформенной реализации агентных симуляций являются сквозной контроль и всеуровневая прозрачность поведения результирующего решения: специализированный функционал в средах симуляции (NetLogo, в нашем случае) дополняется функционалом оркестровки в универсальной платформе данных (InterSystems IRIS), что позволяет моделировать интегрированный производственный кластер более эффективно и достоверно.

• Преимущество, которое может иметь важность для аналитика, состоит в том, что возникновение и развитие различных сценариев динамки складских запасов (как правило, одна из наиболее востребованных областей в исследовании операций) – эффектов кнута, ажиотажного спроса, дефицита запасов и т. п. – становятся значительно более прогнозируемыми, легче выявляемыми и нагляднее представимыми в масштабе всей логистической сети кластера (в этой публикации были приведены скриншоты индикаторной панели кластера с визуализацией некоторых примеров).

• Преимуществом, релевантным для ИТ-специалистов, может оказаться то, что вместо «лоскутного одеяла» отдельных компонент решения, у нас возникает масштабируемая всеобъемлющая DevOps-среда, в которой специализированные среды агентного моделирования эффективно взаимодействуют со средами математического моделирования (такими как Python в данном случае) и другими компонентами интегрированного решения – при обеспечении безбарьерных взаимодействий всех компонент и устойчивости жизненного цикла всего решения платформой данных (InterSystems IRIS).