Анализируй это. Кейсы по внедрению платформы для промышленной аналитики от КРОК

Руководитель проектов Big Data в промышленности ИТ-компании КРОК Павел Егоров поделился опытом, как компания пришла к идее создания платформы промышленной аналитики и какие задачи решала команда в процессе реализации проектов для производственных компаний.

Как появилась идея по созданию вашей платформы промышленной аналитики? Она родилась у потенциальных заказчиков или ее у кого-то позаимствовали?

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

Начинали мы с проекта для управляющей компании нескольких нефтеперерабатывающих заводов в 2017 году. Задача была отслеживать критичные отклонения в технологическом процессе, которые могут повлиять на качество готовой продукции и привести к авариям и/или другим негативным последствиям на производственном участке.

Наша команда тогда первый раз узнала, что в производстве есть специализированные протоколы передачи промышленной информации, есть специфика ведения НСИ информации по сбору телеметрии, по интеграции, по спецификам проведения расчетов.

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

Объектная модель производственной площадки - это вообще первая необходимость, если вы занимаетесь выстраиванием любых аналитических процессов на производстве. Данных в производстве очень много, например, на одной площадке может быть более 100 тысяч только показателей с датчиков, которые приходят в режиме, близком к реальному. К этому нужно добавить данные из систем LIMS (Laboratory Information Management System - система управления лабораторной информацией) о качестве сырья, полуфабрикатов, готовой продукции, данные с IoT-датчиков, MES- и ERP-систем, и масштабировать на другие производственные площадки, которых на предприятии может быть несколько десятков.

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

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

После того как мы обкатали модули фреймворков, заказчикам требуется всего 5 минут вместо двух дней, как это было раньше, чтобы внести 50 расчетных показателей. Time-to-market обработки новых запросов на онлайн-аналитику производственных показателей рекордно сократился.

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

Также важно забирать данные из реляционных систем - в рамках платформы у нас для этого есть так называемый фреймворк ELT (Extract Load). Им мы начали заниматься еще до промышленных проектов, с момента внедрения корпоративных хранилищ данных. С использованием ELT-фреймворка можем грузить данные из различных реляционных систем в платформу и гибко управлять процессами загрузки - настраивать расписание, методы забора инкремента и др.).

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

Отдельно нужно остановиться на архитектурных аспектах.

Мы создавали наши решения исходя из стека технологий Big Data на базе двух вендоров - Аrenadata и Cloudera. На текущий момент мы полностью переориентировались на российскую Arenadata, так как решение входит в реестр ПО. Ее отличие от Cloudera состояло в модуле для создания ML-моделей, но мы в рамках наших проектов можем предложить решения, разработанные на базе CI/CD процессов на Gitlab и Kubernates непосредственно под требования заказчиков.

С точки зрения выбора компонентов мы ориентировались на то, что одни из наших целевых заказчиков - это Data scientist и BI-разработчики аналитических панелей и дэшбордов. Поэтому, в отличие от производственных систем, решение должно предоставлять данные через sql-запросы к большим объемам данных и максимально быстро.

Для этого расчеты мы сделали на spark, интеграцию потоковых данных - на kafka, с точки зрения механизма доступа к данным мы сначала использовали apache phoenix, но со временем перешли на Greenplum. Если нужен быстрый отклик - то используем Clickhouse. Проблема с phoenix в том, что язык sql имеет большое количество ограничений и мало коннекторов из BI-систем. С Greenplum тут все совершенно иначе, коннекторы есть в любой BI-системе.

Платформа промышленной аналитики тиражируема, то есть ее можно применять и в других отраслях. Кто является пользователем данного решения?

Платформу можно применять в любой производственной компании, которая работает с большим количеством данных. Например, фреймворк по загрузке и обработке данных из реляционных источников, который входит в нашу платформу, может применяться на каждом предприятии, где требуется аналитика. У промышленных компаний мы обычно забираем данные из LIMS и MES с помощью этого фреймворка, а у других - реляционные данные. А вот с точки зрения решения объектной модели, наш фреймворк инженерных расчетов (near real time расчеты) на базе spark заточен все же непосредственно под промышленные компании, так как там есть определенная специфика.

Непосредственными пользователями платформы являются Data scientist, BI разработчики аналитических панелей и дэшбордов, а также Data Engineer. Они первыми получают аналитические данные, работают с архитектурой системы, разрабатывают отчеты и пр.

Далее разработанными отчетами пользуются руководители производственных подразделений, которые сфокусированы на получении бизнес-эффектов и принимают управленческие решения на основе аналитической проработки исторических данных о производстве.

Еще одним сегментом потребителей являются сотрудники производственно-технических отделов и\или технологи, которые могут исследовать данные в BI платформе самостоятельно (с использованием компонентов self service BI) для выявления скрытых закономерностей и повышения эффективности производственных процессов.

Обычно проекты по промышленной аналитике мы реализуем совместно с группой экспертов на предприятии. Это и команда ИТ-директора, и директора по производству, плюс - в ряде компаний есть отдельные специалисты, которые отвечают за цифровизацию производства, за работу с Big Data.

Сколько времени обычно занимает внедрение аналитической платформы? Можно ли провести его своими силами?

За счет того, что у нас все процессы, занимающие большое количество времени, автоматизированы на базе наших фреймоврков (настройка, загрузка из источников, расчет показателей в режиме NRT, расчет технологический отклонений, контроль качества производственных данных), мы можем сделать MVP за 6 месяцев – на одном цеху порядка 3-5 тысяч тегов и 1-2 реляционных источника. Но тут тоже нужно понимать, что многое зависит от уровня зрелости и уровня подготовленности предприятия. Для того, чтобы определить уровень готовности компании, нужно ответить на следующие вопросы:

Существует ли описание текущих собираемых показателей?

Насколько быстро технологи, специалисты КИПиА могут сформулировать методики расчета показателей?

Насколько качественные данные поступают? Здесь отдельная специфика – мы очень часто сталкиваемся, что с некоторых датчиков данные вообще не поступают, другие датчики не откалиброваны, некоторые датчики выдают "пилу". У нас для этого теперь есть отдельный модуль. Потому что мы поняли, что из-за качества исходных данных мы тратим очень много времени в момент внедрения.

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

Возможный переход на отечественные вычислительные платформы. Насколько это трудоемкий процесс?

У нас сейчас это решение на базе Arenadata (входит в реестр рос ПО). Основные задачи большинства предприятий платформа решает.

Какие бизнес-эффекты после внедрения платформы отмечают предприятия, работающие с онлайн аналитикой?

Эффекты разные в зависимости от сценариев использования платформы. Базовый -- это аналитика 360 по производственным процессам. Компании, которые работают с этим решением, отмечают значительное сокращение времени подготовки аналитических отчетов (с 2 дней до 5 минут), повышение достоверности этих отчетов. Особенно это важно для производственных процессов, где нужно быстро оценить поступающее сырье и сделать выводы о его качестве.

Следующий сценарий – это анализ качества производственных данных. Мы позволяем выявлять данные, которые потенциально могут быть некорректными. Как я уже говорил у нас в платформе для этого предусмотрен отдельный модуль. То есть эта информация полезна будет и для Data Scientists, которые строят модели, и для Data Engineer, которые строят аналитику, но также и для руководителей производственных цехов и сотрудников КИПиА, которые могут использовать данную аналитику в своей повседневной работе. Ряд компаний отмечают, что время обнаружения некорректных показателей сократилось на 30%.

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

Кто обычно занимается развитием платформы после внедрения, вы или заказчик?

Это двусторонняя работа. Обычно у заказчиков запущена комплексная программа по цифровизации предприятия или группы предприятий. Часто бывает так, что мы запускаем один сценарий, а потом компания обращается за помощью по другим процессом. Например, на одном из металлургических комбинатов мы внедрили наш интеграционный фреймворк, и он уже больше года работает в промышленной эксплуатации. Далее для этого заказчика мы разработали в одном из цехов онлайн мониторинг качества производственных данных, который включает в себя модуль инженерных расчетов и объектную модель производства. А сейчас добавляем новый функционал, связанный с подключением к платформе IoT устройств. В результате ожидается полноценная реализация модуля управления IoT через нашу объектную модель производственной площадки. Но, подробнее об этом, я думаю, мы расскажем уже ближе к концу года.

Появляются ли новые сферы применения решения, например, в области ТОиР, охраны окружающей среды, контроля техпроцессов и энергоэффективности?

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

В части ТОИР - это старые кейсы про прогнозирование внепланового отказа оборудования. Я считаю, что эти проекты на текущем уровне готовности компаний не будут давать значимого эффекта по нескольким причинам.

Доступность, наличие и качество технологических данных – очень мало на текущий момент производственных площадок, где данные действительно качественные. А на некоторых площадках и вовсе не хватает данных в целом для полноценной аналитики, поэтому история с IoT развивается в первую очередь. IoT значительно сокращает скорость установки и получения информации с датчиков.

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

Запчасти, ремонты – при ремонте оборудования могут меняться его свойства, особенно если ремонтные работы ведутся с помощью комплектующих аналогов. Естественно, модель нужно доубучать в таких случаях.

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

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

Каковы направления развития продукта на ближайшую перспективу?

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

В наших ближайших планах – включение нового полезного функционала для пользователей: подключаем платформу к IoT-устройствам, работаем над упрощением процесса заполнения типовых показателей, пилотируем дашборды российских BI-систем для того, чтобы пользователи могли быстро получать ad-hoc отчеты и не зависели от лицензионных проволочек, связанных с уходом иностранных вендоров. Также мы расширяем протоколы получения промышленных данных, подключаем нашу платформу к IoT устройствам.

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

Мы планируем пропилотировать ряд решений российского BI для того, чтобы предоставить пользователям системы полноценные отчеты ad-hoc по производственным данным прям для сотрудников производственных подразделений.

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