Эпопея в двух частях. Часть вторая

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

ТЗ, проект и подготовка

Если предпроект — это очень верхнеуровневая история, то в этом месте мы переходим к конкретике:

• Пишем техническое задание — подробное описание того, что заказчик получит на выходе, вплоть до конкретных метрик и дашбордов.

• Составляем проект — тот самый документ, в котором описана реализация ТЗ. В рамках проекта можно посчитать точное количество кабеля и часов разработчиков. 

ТЗ и проект — самая ответственная часть работы. Предпроектирование — это индикатив, и там простительно немного промахнуться по затратам. А проект даёт заказчику ответ на два самых главных вопроса: «Сколько и когда». Любой промах в этом документе — удар по нашему карману и ресурсам. Помимо стоимости и состава техрешения у нас появляется подробный план, с которым все будут сверяться. 

У проектирования есть одна важная особенность, которую всегда нужно держать в голове. Мало посчитать затраты в рублях и человеко-днях. Мало заложить лаг на закупку и поставку. Самое главное — помнить, что инженеры распланированы на месяцы вперёд, и свой проект надо аккуратно впихнуть, не перекосив их планы по занятости. Либо обосновать важность проекта и сдвинуть их планы. Последнее не желательно, но иногда бывает. Особо важный заказчик с большой сумкой денег может потребовать (и получить) особое отношение. Рынок, знаете ли.

С «Благо» всё пошло по сложному сценарию. Основные агрегаты цехов были сведены в контроллеры Siemens S7 разных версий. Это означало, что нам придётся работать с ProfiNET — хоть и открытым, но довольно специфичным протоколом. На физическом уровне использовались кабели и разъёмы, аналогичные Ethernet. А вот для получения данных понадобился специальный драйвер, который взять было негде. Поэтому мы написали его сами. Чем хорош Siemens — он очень распространён по всему миру. И при всех его особенностях есть много документации по его работе. Но это оказалось меньшей из проблем. 

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

Тут отдельно отмечу, что приходится работать с разным оборудованием. Часто не первой свежести, но вполне рабочим. Рекорд наших задач — цифровизировать каменную дробилку 1932 года выпуска (!!!). Вполне себе бодрую и выполняющую свои функции. 

Отдельная история произошла с весами. У заказчика были установлены весы компании «Тензо-М». Их особенность в том, что они имеют нестандартный протокол общения со своим оборудованием. Здесь нам помог сам производитель, который пошёл навстречу и помог с интеграцией протокола в платформу. Это тоже заняло время, но кратно меньше, чем если бы мы интегрировали устройство самостоятельно.

На этом фоне подключение небольшого количества приборов учёта уже выглядело каким-то фоновым шумом. 

Создание двойника

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

Спойлер: хоть бы раз так было! Конечно, по ходу работы возникают подводные камни, которые не удалось учесть сразу. Нивелировать их помогают опыт и смекалка.  

Когда оборудование пришло, было успешно смонтировано и потекли данные, казалось, что самое страшное уже позади. Но всё только начиналось! Далее пошёл трудный и кропотливый анализ метрик. Суммарно оборудование семи цехов генерирует порядка 1000 метрик с дискретностью в 1 секунду.  Из этого нам требовалось выделить порядка 100 нужных нам метрик, на основе которых мы и собирали цифровой аватар. Все метрики свели в таблицы, расшифровали и проверили на наличие ошибок. Это действительно титаническая работа, которая заняла порядка двух месяцев. На выходе мы, наконец, получили очищенные данные.

Если честно, ни в одной статье не встречал описание этого процесса. Цифровой двойник — это всегда «подключились, получили метрики, построили модель». Если делать с нуля, то оно, возможно, так и будет. Но с оборудованием, которое запущено давно и по которому нет полной документации, такой подход не срабатывает. 

Возможно, вам интересно, куда мы дели ещё 900 метрик? Никуда не дели, аккуратно собираем. Но в формировании цифрового двойника они не участвуют. Во всяком случае, пока.

После сбора и обработки метрик нужна ещё их визуализация: графики, дашборды, элементы SCADA. 

Тут надо озвучить важную мысль о нашей работе. С одной стороны, кажется, что нам не требуется отраслевая экспертиза. То есть, не нужно вникать в тонкости каждого отдельного производства, будь это масло, молоко или щебёнка. Верхнеуровнево всё выглядит одинаково: подключиться к оборудованию, собрать метрики, сформировать модель по правилам, полученным от заказчика. Но на практике заказчик потому и заказывает у нас цифрового двойника, чтобы разобраться, что происходит на его производстве с точностью до грамма, секунды или любой другой метрики. И это подразумевает, что подробное и качественное ТЗ он нам выдать просто не в состоянии. Так что вникать в отраслевые нюансы приходится, без вариантов. Поэтому наша команда состоит не только из классических разработчиков, но и из людей с самым неожиданным опытом. И мы всегда готовы погружаться в тонкости и нюансы очередного техпроцесса. 

Тонкие настройки и подсчёт эффективности

Отлично! Мы добрались до финала. Финал же, да? 

Не совсем. 

Теперь мы переходим к главному — тому, зачем мы двойника вообще делали. Нам нужно получить от него пользу. И чем больше, тем лучше. Помните примеры из начала статьи? Вот сейчас будет пример тонких настроек оборудования из нашего опыта. Но для этого нам придётся немного погрузиться в процесс маслоэкстракции.

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

Важнейший этап — разделение этой массы. Лузга нам не нужна, она пойдёт в энергоцентр на сжигание. А вот из ядер получится сразу два продукта: то, что из них выжмут, станет подсолнечным маслом, а то, что останется — это шрот. Тоже полезная штука, идёт на корм скоту. 

Разделение массы происходит ветром с устройств, называемых вейками. У вас уже сложилась картинка, почему цех рушально-веечный, да? Так вот, от настроек веек зависит, какую долю лузги выдует. И это история про баланс. Не доберём — на отжим поедут не только ядра, но и лузга, которая забивает пресс и снижает качество шрота. Перестараемся — в энергоцентр на сжигание полетят уже ценные ядра. 

Процент выхода помогает рассчитать анализ сырья до его захода в рушально-веечный цех. Именно на этом этапе можно получить примерное соотношение ядер и лузги и определиться с ветровыми настройками. До прихода SberMobile AIoT это был ручной процесс с задержками в передаче данных и весьма условным контролем. Передать результаты анализов могли не вовремя, не всегда точно получали соотношение ядер и лузги. А теперь у нас есть информация со всей линии. К цеху подходит сырье, его анализируют. Результаты анализа загружают в модель, и она сообщает нам, что при оптимальных настройках Х выход ядра будет наибольший и составит Y %. Эта информация нигде не задерживается и поступает в цех. Там выставляют нужные параметры на вейках, процесс проходит. и мы проверяем, насколько точно модель предсказала результат. Двусторонняя связь с объектом, помните? Если результат точен, значит всё в порядке. Если находим различия, то есть какая-то проблема и её надо устранить.

Это только один, очень упрощённый пример того, как сейчас работает цифровой двойник завода «Благо». Он также собирает параметры работы оборудования, предсказывает аварии и сбои в работе, выводит ключевую информацию на дашборд руководства и многое другое. Но не буду усложнять.

Вот теперь всё. Мы сделали двойника, передали его клиенту и выполнили первые оптимизации. Дальше дело за заказчиком. Весь год он кропотливо улучшал техпроцессы с помощью нашего двойника и подсчитывал экономию. Итоги и выводы тоже его, мы в этом участия не принимали. Зачёркнутые серым числа — это целевые значения, которых пытались достигнуть.

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

Кроме того, завод получил прозрачность и управляемость. Да какую! Предмет нашей отдельной гордости проиллюстрирует следующая история.

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

Заключение

Пример ГК «Благо» — очень показательный проект. Внедрение цифрового двойника позволило повысить управляемость завода, подкрутить настройки оборудования и, в конечном счёте, сэкономить. 

В заключение отмечу важнейшее качество цифрового двойника: его целостность. Он как бы накрывает собой всю технологическую цепочку или весь завод. Нередко слышу мнение: «Ну и что в этом такого?» Подумаешь, подключились к оборудованию, добавили датчиков, всё в единое окно вывели и аналитики навесили. Что тут революционного? Но проблема большинства заводов как раз и состоит в разрозненности данных. Помните, как внезапно оборвался наш обзор типового цеха? Беда не в том, что метрики взять негде. Беда в том, что они в разных местах и у разных людей. В цехе есть SCADA, но дальше цеха она никуда не уходит. Получается, что конечной точкой SCADA становится её оператор. У станка есть контроллер, но контроллер болтается в воздухе и никак не связан с информационными системами предприятия. У счетчика есть интерфейсный выход, но он… правильно, никуда не подключён. Его интерфейс — монтёр Михалыч, который раз в неделю переписывает с него показания. 

И типовое предприятие превращается в ворох таблиц Excel, бумажных журналов и какой-нибудь информационной системы, которая внезапно заканчивается в одном цехе и так же внезапно начинается в другом. Плюс — экспертиза в головах экспертов и смесь из бумажной и электронной документации. Сведение всего этого в одно окно и с наглядным представлением, в понятном и удобочитаемом виде — уже огромный шаг вперёд. 

А ведь предприятие с единой цифровой средой этим не ограничивается. Идеальная картинка выглядит как-то так:

1. Вся информация с каждого датчика анализируется, агрегируется и в конечном счёте уходит в ERP и BI. Пусть не в чистом виде, но каждая метрика вносит свой вклад.

2. Топы предприятий видят все ключевые метрики и эскалации по всем площадкам. Что-то «затихарить» становится нереально, только чинить, устранять и улучшать. Сначала это тяжело, зато потом основные проблемы вычищаются и можно заняться экспериментами по эффективности. С каждым годом получаем всё более управляемое и производительное предприятие.

3. Руководители контролируют свои участки, наводят и поддерживают порядок.

4. Линейный персонал получает чётко выстроенные и контролируемые процессы. Теперь понятно, что и когда делать, а чего делать не надо.

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

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