В этом посте я хочу рассказать о своем опыте разработки технологии, которая управляет интеллектуальными решениями, используемыми в  промышленности, чтобы сделать их работу эффективнее и обнаружить скрытые выгоды для бизнеса. Для начала приведу пример системы, которыми управляют классы продуктов, описываемых в статье. Некоторое время назад я столкнулся с задачей оптимизации расхода ферросплавов (далее ФС). При производстве стали сталевары добавляют специальные вещества, ферросплавы, чтоб получить нужную марку с определенным химическим составом (см. схему с этапами ниже). Например, чтобы содержание Si в полученной стали было не менее 0.2 % (в технологической инструкции обычно указан диапазон, допустим от 0.2 до 0.3, но мы для простоты будем говорить только о нижней границе) Суть проблемы: сталевары добавляют ФС с запасом, чтобы точно получилось Si не меньше 0.2%, отсюда идет лишний расход. Решение: цифровой советчик, который на основе алгоритмов машинного обучения рассчитывает, сколько минимально следует добавить ФС и дает рекомендацию сталевару, что позволяет сэкономить. Упрощенно, структура этого советчика, как и многих других, выглядит следующим образом: Данные поступают в советчик через адаптер или API, мат.модель рассчитывает рекомендацию, и она отображается на UI. Поступающие данные включают марку стали, нужный для нее хим.состав, температуру, окисленность, текущий хим.состав и др. В рекомендации отображается, сколько какого материала добавить: Когда я присоединился к команде, моей первой большой задачей было превратить решение в продукт, который можно будет поставлять разным заказчикам со своей спецификой. Для этого мы добавили пару фичей - гибкую, изменяемую структуру данных и возможность настройки момента, когда запрашивать рекомендацию. Далее произошла смена стратегического курса для команды продуктовой разработки и нас переключили на область более сложных задач - сквозную оптимизацию, которой мы продолжаем заниматься на момент написания статьи. Я бы описал понятие сквозной оптимизации так: это когда мы ищем выгоду не на одном узле предприятия, а на производственной цепочке из нескольких узлов. Цифровые советчики, установленные на разных узлах, работают независимо, и, например, максимальная экономия ресурса 1 на агрегате 1 ограничит возможность экономии ресурса 2 на агрегате 2. “Цепочки” далее в контесте - это представление технологического процесса. И за счет такого моделирования можно высвободить эмерджентные выгоды. Пример группы цифровых советчиков в металлургии и их взаимозависимостей: Итак, была поставлена задача спроектировать и разработать такой продукт, который: позволит подключать несколько цифровых советчиков, работа которых может влиять друг на друга будет управлять работой этих цифровых советчиков в реальном времени даст возможность имитировать такой процесс в реальном времени и считать общий экономический эффект позволит получать дополнительный экономический эффект от интеллектуального управления советчиками там, где это возможно В первую очередь хотелось изучить, как такие продукты делают в других странах. Наш главный стратег в компании сказал, что самыми крутыми и технологически развитыми металлургами являются японцы и корейцы. 1) Французская компания "Fives" использует мегамозг, загадочную "Мастер-модель", объединяющую и балансирующую другие модели. Как именно - узнать не получилось. Картинка с их сайта: 2) Немецко-американская "Smart Steel Technologies" предлагает "Экономить выбросы CO2, улучшать качество и повышать эффективность на всех этапах производства стали" с помощью группы своих цифровых советчиков, которые учитывают влияние друг на друга. То есть логика "мастер-модели" распределена между моделями самих советчиков. Что-то вроде "роя дронов", в котором нет главного управляющего объекта. 3) Корейцы Posco заявляют, что они "think of railway platforms", используют концепцию цепочечного производства, что позволяет увеличивать производительность, сокращать издержки и повышать качество. Но как именно работает их продукт PosFrame, я найти не смог. 4) Про японцев, Nippon Steel, информации было совсем мало. Только про пару советчиков, но ничего про сквозную оптимизацию, а она у них есть. Ключевым, на мой взгляд, был вопрос, по какому пути идти - "французскому" с мастер моделью или "немецкому", где сами модели советчиков знают друг про друга. Одним из требований к продукту было: "Позволит подключать несколько цифровых советчиков, работа которых может влиять друг на друга". Мы раскрыли его так, что: во-первых, он будет платформой, на базе которой можно разрабатывать цифровые советчики, и они будут изначально встроены в общее решение во-вторых, будет возможность подключать "внешних" советчиков через API и управлять ими, т.к. на многих предприятиях уже стоят советчики от других вендоров И для второго пункта "немецкий" подход не годился, так как внешние модели ничего не будут знать о наших моделях и не смогут сами синхронизироваться для достижения общих выгод. Таким образом, при проектировании взаимодействия с советчиками мы ориентировались на схему, в которой был бы один компонент, управляющий работой группы моделей: Разберемся теперь со стрелками, как "Логика /модель сквозной оптимизации" должна управлять советчиками на примере описанных выше ФС. Советчики, в разработке которых я участвовал, на самом деле стараются рекомендовать отдачу не так чтобы попасть идеально в требования, а тоже немного с запасом. Например, не 0.2% Si, а 0.21. Чем больше запас, тем надежнее будет попадание в требования к марке стали, но и тем меньше экономия. Итого у советчиков есть главная настройка - в какой химический состав целиться, с каким запасом. Далее будем обозначать ее как "цель" по химии. При производстве стали ФС добавляют 2 раза - на этапе выплавки и на этапе доводки, где формируется финальный химический состав. Например, можно получить 0.15% Si на выплавке и далее 0.21% на доводке. В зависимости от этого баланса можно получить разный экономический эффект от экономии ФС. Итого наш компонент "логика / модель сквозной оптимизации" рассчитывает цели перед тем, как советчики выдают рекомендации, и, таким образом, управляет их работой в процессе производства стали. Параллельно с общей логикой работы мы описали 3 основных пользовательских сценария, реализацию которых в UI покажем позже: настройка цепочки советчиков и того, какие цели они будут получать запуск работы цепочки в симуляционном режиме и работа в продакшен среде просмотр результатов работы цепочки и того, какой получается эконом.эффект Когда концептуальные вопросы по тому, как будет работать продукт были решены, можно было перейти к следующему шагу и придумать его архитектуру. Продукт реализован на микросервисной архитектуре, Kafka, Kubernetes - тут все стандартно. Компонентная архитектура выглядит так: 1) На UI настраивается, какие советчики будут работать в цепочке и как формировать для них цели - простыми алгоритмами, для которых задаются параметры вручную или специальной моделью сквозной оптимизации, которая сама подбирает эти параметры. 2) Через API поступают данные с завода в реальном времени, либо импортируется специальный файл с данными производства, в случае режима симуляции.  3) В компоненте сквозной оптимизации рассчитываются цели и передаются в советчики. 4) Советчики рассчитывают рекомендации, показывают их сталеварам, а также отправляют рекомендации в компонент "Бизнес-мониторинг". 5) Компонент "Бизнес-мониторинг" по рекомендациям, данным производства и историческим данным рассчитывает: последовал ли сталевар рекомендации если последовал, то сколько ФС это позволило сэкономить, относительно того, сколько раньше отдавали сталевары, когда советчиков не было если не последовал, считаем упущенную выгоду 6) В "Бизнес-мониторинге" формируются отчеты, содержащие в т.ч. экономический эффект как для каждого советчика, так и для всей цепочки. Позволяет нам измерить и показать эмерджентный эффект, который дает использование модели-оптимизатора. В зависимости от настроек, цели для советчиков могут рассчитываться: Простым алгоритмом. Например, по Si взять из требований к марке стали (0.2) и прибавить "запас" - 0.01. Указывается величина запаса Моделью-оптимизатором, которая сама подбирает цели для советчиков, при которых будет достигаться наибольший экономический эффект. Для разработки таких моделей использовался метод дифференциальной эволюции, обучение на лучших подобранных целях, полученных по историческим данным и пр. В качестве формата данных, которые загружаются вручную в режиме симуляции, мы используем ... коллекции “Postman”. Плюсы: есть стандарт формирования коллекций на сайте разработчика. По работе с “Postman” присутствует множество информации.  имеется консольный клиент (“Newman”) для прогона коллекций. возможность использовать скрипты JS прямо внутри коллекции. Можно реализовать часть логики импорта прямо в скрипте, например, задержку между отправкой событий о плавке не меняя кода решения. Минусы:  вручную редактировать коллекцию сложнее, чем, например, данные в csv при импорте больших коллекций могут возникать разного рода проблемы, связанные с утечкой памяти в “Newman”. Что получили в итоге: работающий компонент системы, который эмулирует заводские системы и отправляет через Rest API данные о производстве в систему. Из-за проблемы с утечкой памяти пришлось ограничить размер коллекции, а в остальном проблем с таким решением больше не обнаружили В UI платформы на данный момент заложены далеко не все возможности настройки и использования советчиков, но общий концепт продукта там продемонстрирован.  Визуально все это выглядит следующим образом: В левой части выбираются советчики, которые будут использоваться на предприятии. Те советчики, которые могут влиять друг на друга "собираются" в цепочку и загорается индикатор цепочки. В правой части заполняются настройки советчиков. Интерфейс динамический и без программирования позволяет добавлять новые советчики и новые настройки. На скрине видна главная настройка - каким алгоритмом подбирать цели для советчика по ФС на выплавке. Выбран простой алгоритм "Отступом от НТД" где вручную настроено, сколько должно получиться  Si и Mn, относительно требований к марке стали. Для Si указано min НТД (требования к минимальному содержанию элемента) +0.01. То есть, компонент сквозной оптимизации будет рассчитывать цель для советчика на выплавке следующим образом: брать число, сколько минимум Si должно быть у этой марки стали и прибавлять к нему 0.01, например 0.2 + 0.01 = 0.21. Также можно выбрать модель-оптимизатор. Сравнение ее эффективности с простым алгоритмом будет описано ниже. Итак, советчики включены и механизм управления ими настроен. Чтобы запустить работу продукта в продакшен больше ничего делать не нужно - начнут приходить данные с производства, по ним будут рассчитываться цели и передаваться советчикам, советчики - выдавать рекомендации. Чтобы запустить работу в имитационном режиме надо загрузить файл с пакетом производственных данных вручную и Shopfloor начнет работать с ними. Пакет может включать много плавок, по каждой из них будет рассчитаны цели и рекомендации. После загрузки пакета видно прогресс - % плавок из всего пакета, по которым рассчитаны цели и выданы рекомендации советчиками.  В режиме симуляции и режиме работы на продакшен среде используются одни и те же отчеты по советчикам, показывающие итоговую эффективность работы продукта с текущей версией настроек как по советчику, так по цепочке в целом. Пример отчета при симуляции на 149 плавках, получили эффект - экономия 127.2. На заводах есть технологические ограничения, например, этапе доводки нельзя отдать ФС больше, чем 800 кг. Цифра 6.7% показывает, сколько раз при таких настройках цели были рассчитаны так, и советчики выдали такие рекомендации, что это ограничение было нарушено. Кстати, без советчиков сталевары судя по данным сами часто нарушают ограничение в 800 кг, примерно в 18% случаев Соответственно, в случае ФС нужно подбирать настройки и искать баланс так, чтоб экономический эффект был максимальным, а % плавок с нарушением технологий - минимальным. После проведения множества экспериментов у простых алгоритмов с самыми разными настройками показатели были такие: советчики дали экономию 263 рубля на тонну стали и 4.1% нарушений ограничений технологии Модель-оптимизатор с автоподбором целей дала: 269 рублей на тонну и 3.7 % нарушений ограничений Прирост в 6 рублей может выглядеть незначительным на 1й взгляд, но если учесть, что крупные предприятия могут производить до нескольких млн тонн стали в год, то использование не только решения, управляющего работой нескольких советчиков, но и моделей сквозной оптимизации внутри него должно быть весьма актуально. В настоящий моменты мы адаптируем наши платформу под химическую и нефтехимическую отрасли - системы оптимизации в реальном времени (RTO). Примеры таких продуктов: Aspen GDOT (Dynamic RTO), Aspen Online (RTO), Honeywell Plant-Wide Optimizer, Yokogawa Dynamic Real Time Optimizer (RT-OP). Там больше физ.хим. моделей, чем математики: система верхнего уровня (RTO) подбирает оптимальные управляемые переменные (Manipulated values) для систем нижнего уровня. На нижнем уровне с помощью физ.хим. моделей рассчитываются значения и передаются в качестве установочных параметров на агрегаты. Модели и процессы разные, но суть сквозной оптимизации похожа, так что мы работаем и под эту доменную область. В этой статье я старался написать не сухой технический, или сочный продажный текст, а рассказать историю и результат создания продукта со стороны функционального архитектора. Полагаю, что такие системы рано или поздно появятся у всех больших металлургических предприятий, как один из нераскрытых источников сокращения издержек.