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

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

Меня зовут Олег Плотников, я продакт вертикали «Промышленность». И сегодня я буду вашим экскурсоводом. 

Для начала немного теории. Термин «цифровой двойник» — определение довольно расплывчатое. Несмотря на чёткое определение ГОСТ Р 57700.37–2021, в сети можно встретить самые удивительные толкования этого термина. И чем дальше авторы толкования от практики, тем более необычные вещи они приписывают двойнику. Давайте определимся: 

Цифровой двойник — это цифровая модель изделия или процесса, имеющая двусторонние связи с этим изделием или процессом.

Не пугайтесь определения, на примере будет понятнее. 

Допустим, у нас есть станок по производству ЭВМ «Тамагочи». Станок, по ходу своей работы, генерирует метрики. Это может быть потребляемая мощность, скорость вращения двигателя, температура привода, количество изделий в минуту или авария по застреванию батареек в устройстве подачи. 

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

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

Зачем это нужно на практике?

Пример 1. Резко подскочил уровень вибраций двигателя. Он не укладывается в нормативы, определённые производителем. Это повод провести внеочередное ТО и выяснить, что у нас проблема с подшипником. Поскольку мы отловили проблему на ранней стадии, мы обойдёмся временной остановкой станка и заменой подшипника. Двигатель не разорвёт и не заклинит.

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

Пример 3. Вводим элементы высшего пилотажа. Допустим, станок делает два вида «Тамагочи»: для взрослых и для детей. Тамагочи для взрослых больше и требует бо́льшего расхода электричества на единицу продукции. Наша модель, помимо текущих параметров, умеет оценивать ресурсы на производство и делает ещё много других важных выводов. Мы наглядно видим, что взрослые Тамагочи дороже не только по материалам, но и по затратам на электричество. И можем скорректировать техпроцесс: производить взрослые Тамагочи по ночам, когда электроэнергия дешевле. Это уже элементы энергомониторинга, двойники производств отлично с ним справляются.

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

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

• У проектного отдела на нём будут отмечены новые постройки и даже часть тех, что ещё не построили. 

• У эксплуатации в плане окажутся уже снесённые объекты. 

• У КИПиА будет актуальная карта линий связи и реестр приборов учёта, а вот серверная — не в том месте. 

• У админов серверная на месте, а вот линии связи — образца десятилетней давности.

Разумеется, я утрирую, но общая идея понятна. Точной и полной картины не будет ни у кого. Цифровой двойник всего предприятия обязательно имеет условную подложку — цифровой макет. Это тот самый ситуационный план, где нанесены все линии связи, строения, коммуникации и прочее. Макет — не двойник, у него нет двусторонней связи с объектами. Но он часть единой информационной системы предприятия. И если после его внедрения грамотно приучить всех его использовать, то порядка станет больше.

С чем будем работать?

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

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

Полевая шина — это довольно абстрактное понятие, сильно размытое в наших реалиях. Имеется в виду канал связи между устройством и ПЛК. Если брать промышленные решения, то самыми популярными интерфейсами окажутся RS-485 и 4-20 мА, а протоколами — ModBus RTU, HART и семейство ProfiBUS. 

ПЛК — программируемый логический контроллер. Это устройство, на котором реализована логика работы и сценарии. Например, он получает сигнал с датчика о росте температуры в цехе и включает охлаждение. Или останавливает конвейер в случае аварии по станку. Конструктивно это миниПК в промышленном исполнении. От контроллера выходит уже более верхнеуровневый протокол, что-то вроде Ethernet или ProfiNET. Сигнал расходится на компьютер или рабочую панель оператора. И, наконец, сигнал уходит на…

А вот тут нас резко выбрасывает из теории и возвращает в наши реалии. 

По идее, сигнал с контроллера должен уходить в систему управления и сбора данных (SCADA). А информация из SCADA потом уйдёт в инфосистему цехового уровня (MES) и дальше в систему управления всем предприятием (ERP). 

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

Почему это происходит? Потому что предприятие редко строится с нуля и целиком. Цеха вводят в строй постепенно. Оснащают тем, что есть на рынке и что выигрывает по соотношению цена/качество. Как итог — дичайший зоопарк. Этот цех конца 90-х, этот вчера сдали, этот, кажется, в 2010-м. А там вообще советское наследие, но пока живое. Разное оборудование, разные производители, разные поколения, разные протоколы. 

С такими вводными и работаем. 

Как создают цифровой двойник?

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

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

Второй этап — монтаж оборудования, подключение к контроллерам и внешним датчикам. В нашей архитектуре для этого используется AIoT-Hub — наш программно-аппаратный комплекс. По сути, это обычный компьютер на Linux в промышленном исполнении. На нём крутится часть нашей платформы SberMobile AIoT, которая отвечает за сбор и нормализацию данных. Все метрики с контроллеров и датчиков должны быть собраны в одном месте. AIoT-Hub имеет множество физических интерфейсов и дополнительных адаптеров, таких как RS-485/232, RJ-45 или KNX. По этим интерфейсам мы получаем наши метрики. 

Для того, чтобы понимать различные протоколы, платформа на AIoT-Hub имеет набор необходимых драйверов. Этот процесс настройки — самая нетривиальная часть работы. Хорошо, если у нас все метрики приходят через какой-нибудь понятный протокол (ModBus RTU, здоровья тебе!) и грамотно задокументированы. А если перед нами более специфичный и менее понятный ProfiNET имени Siemens? И значения метрик нигде не описаны? Задача кратно усложняется, а на AIoT-Hub появляется дополнительное ПО. 

После того, как метрики добыты всеми правдами и неправдами, AIoT-Hub делает ещё одну важную вещь: нормализует данные. То есть приводит всё, что он получил, в единый, понятный для следующих узлов вид. 

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

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

Четвёртый этап — собственно двойник, то есть аватар, обогащенный матмоделью на основе физических или иных свойств. Важно понимать, что во многих проектах полноценный двойник избыточен. Вполне можно остановиться на аватаре или ЕЦС (единой цифровой среде, комплекса аватаров и иерархических связей между ними). 

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

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

Наш заказчик, производитель растительного масла ГК «Благо», оказался готов рассказать о своём проекте. Шаг это довольно смелый. Большинство наших проектов скрыто под NDA, и иногда даже обидно, что нельзя рассказать про потрясающий опыт. Но с «Благо» мы это сделать можем. Потому — делаем.

Обследование для меня — это самая интересная часть работы. Очень надеюсь, что получится выпустить про это отдельную статью, ибо именно во время обследования происходят главные приключения. Но, NDA есть NDA. 

Начинаем мы всегда с постановки задачи, запроса документации и обследования. В идеале — именно в таком порядке. Мы должны понять, какую задачу решаем, подготовиться к выезду (чтобы знать, на что смотреть и чего нам не хватает) и, наконец, рвануть на объект к заказчику, окончательно заполнив все пробелы.

На практике это почти не работает. 

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

• Поговорить с заказчиком и понять, что он хочет.

• Запросить максимальный объём документации, отдавая себе отчёт, что если дадут половину, то это уже победа.

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

• Переговоры с заказчиком на месте. Именно в этот момент верхнеуровневое ТЗ уточняется и обретает конкретику.

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

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

Именно по такой схеме мы действовали с «Благо». После того, как коммерсанты обговорили начальные договорённости, начался масштабный подготовительный процесс. Наш AIoT-архитектор запросил у завода проектную документацию, ситуационный план, схему локальных сетей, паспорта на оборудование, расположение АРМ-ов и ещё много всего. К работе привлекли сервисную компанию, обслуживающую завод. 

Через некоторое время картина начала складываться. Но в ней пока хватало белых пятен. Когда уровень подготовки посчитали достаточным, архитектор выехал в Верхнюю Хаву. Несколько дней он тщательно записывал всё, что видел. Общался с ответственными, собирал недостающую документацию, вникал в тонкости техпроцессов. А по возвращении написал отчёт. И сообщил, что нам придётся тяжело.

Продолжение следует.