Хроники цифровых заводов: как надували технологии IIoT

В прошлой статье ^[1] мы прошлись по уровням АСУТП/АСУП и вспомнили, что будет, если эти уровни неудачно смешать. В этой статье уделим время IIoT-платформам и IIoTу в целом.

Революция интернета вещей случилась примерно в 2015 году и вызвала сильнейшее недоумение у всех, кто работал в промышленной автоматизации. Было много разговоров на тему, что IoT (Internet of Things) — это наше новое будущее, были прогнозы Гартнера о миллиардах датчиков уже совсем скоро, и всем казалось, что начинается какая-то новая эра. Но сотрудники на заводах никак не могли взять в толк, что происходит. Что такого необычного и революционного привнёс IoT? Датчик, который через сеть сливает с себя информацию в какое-то ПО? А ничего, что промавтоматизация существует уже более полувека? 

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

Как ни странно, IoT (и его промышленное воплощение IIoT) оказался не простым маркетинговым ходом. Всё-таки до 2015 года цена среднего датчика была больше чуть ли не на порядок. «Революция» IoT создала целые классы доступных устройств, работающих как на периферии, так и в сердце техпроцесса. Появилась новая тенденция: начали обвязывать и брать под контроль буквально всё. Началась эра накопления данных.

Самый главный вопрос промышленных конференций тех лет: «Мы целое озеро уже залили, делать-то что с ним будем?». Это было действительно странно, но деньги вкладывали почти бездумно. Сейчас всё датчиками обвесим, историю накопим, а потом посмотрим. Тем не менее, такой подход помог собрать те самые Data Lake. Вопрос лишь в том, где всё это хранить и чем всё это анализировать.

IIoT-платформа

Под эти задачи стал рождаться новый класс программных продуктов. Новый он с большой натяжкой, как и весь IoT, тут разговор, скорее, о концептуальном подходе. IIoT-платформа — это не замена АСУ ТП. Это новый пласт над классической автоматизацией и рядом с ней.

Выглядит это примерно так: у нас есть некий базовый минимум информации, который помогает нам безопасно и гарантированно вести техпроцесс, её мы собирали всегда, она и составляет тот самый базовый контур АСУ ТП/АСУП; а есть данные, которые прямо на техпроцесс не влияют, но из которых можно кое-чего выжать:

• Оптимальность работы. Внимательно посмотрев на продукцию и, к примеру, увязав её с энергопотреблением, можно прикинуть, как нам сэкономить. Допустим, перенести выпуск самой энергоёмкой продукции на ночь, когда электричество дешевле.

• Предиктивная аналитика. По отклонениям группы метрик можно понять, что скоро этот конкретный двигатель заклинит. Важно нам знать такое? Важно.

• Качество продукции. Опять же, по группе метрик можно предсказать, что техпроцесс скоро деградирует. Формально он останется в допустимых рамках, но болванки на выходе будут уже не такие болванистые. Однако, если совсем чуть-чуть подкрутить ряд параметров…

И так далее. Получилось что-то вроде «роскошного максимума» данных, из которых можно выжать много полезного. У таких данных несколько бед: их надо как-то получать, правильно хранить и быстро анализировать.

Собирай, храни, анализируй!

Что ж, пройдёмся по бедам. Начнём с главного. Данные надо получить и быть готовым к тому, что выдавать нам их могут абсолютно разные источники: ПЛК, SCADA, счётчики и системы учёта ресурсов, частотные преобразователи, релейная защита, приводы, анализаторы, шкафная автоматика, MES, LIMS или ERP, внешняя система вроде видеонаблюдения или системы контроля транспорта.

По сути, для получения метрик нужно решить три проблемы:

• Физическое подключение к оборудованию и сигналам. Если у вас есть 4–20 мА, дискретные сигналы, импульсный выход, последовательная связь по RS-232/485, то платформа сама по себе к ним напрямую не подключается. Нет в популярных сетевых картах серверов таких интерфейсов. Для этого нужны модули ввода-вывода, шлюзы, промышленные компьютеры, edge-устройства и прочая промежуточная инфраструктура.

• Протоколы обмена. Тут уже появляются Modbus RTU/TCP, OPC UA, Profibus/Profinet, MQTT, REST API и прочие способы передать данные в промышленном контуре. Платформа должна эти протоколы знать или иметь какой-то способ работы с ними. Набор коннекторов прямо на борту — большое преимущество, но сгодится и какая-нибудь типовая схема вроде промышленного шлюза и связки по OPC UA. Главное, чтобы это была отработанная история прямо из коробки. Если платформа работает через шлюз, то рекомендованные шлюзы (с которыми гарантированно заведётся) нужно явно прописывать в документации, а то и продавать в связке с ПО.

• Встраивание (или API) в чужую систему или сервис. Например, забрать данные из MES, выгрузку из учётной системы, телеметрию из видеосервера или результат работы аналитического модуля. Нужен стык нашей IIoT-платформы с чужими системами. 

Но собрать метрики — только полдела. Их ещё надо хранить так, чтобы потом с ними можно было работать. Помните, в первой статье я приводил пример со SCADA, когда можно дёрнуть посекундные данные за квартал и нагрузка процессора упрётся в полку? Эта проблема остаётся, нам по-прежнему надо анализировать большой объём метрик за большие промежутки времени. И если SCADA от такой задачи зависнет и будет права, то IIoT-платформа обязана с этим справиться. А для этого у неё должна быть выбрана оптимальная БД и способ хранения.

Ну и, наконец, сами аналитики. Инструменты, линейная и нелинейная (с помощью ML) логика ^[2] и многое другое. Это всё очень сложные и нетиповые задачи. Они требуют довольно свежих подходов, новых специалистов, парка непривычного оборудования (например, сервер с видеокартами). С таким на заводах ранее не сталкивались. 

В общем, сложно это всё. 

Однако. 

Однако, выхлоп от этого оказался существенный. 

Минутка рекламы.

SberMobile AIoT — это классическая платформа новой формации. Более 50 коннекторов, возможность интеграции видеосервера, возможность использовать ML на борту. Подробнее пример её внедрения я описывал тут ^[3]. Вкратце напомню, что её внедрение сходу помогло одному из заводов сэкономить 52 млн в год при затратах на внедрение в 37 млн.

По итогу мы все оказались вынуждены признать: появился новый класс ПО, который в стандартную пирамидку АСУ ТП/АСУП не укладывался, но который позволил вывести контроль процессов на качественно иной уровень. 

Мрачный цифровой двойник 

Повсеместное внедрение IIoT-платформ внезапно подготовило почву, для следующего этапа новой промышленной революции (или, как любят говорить на конференциях, Индустрии 4.0). Всё чаще зазвучала фраза «цифровой двойник». Это трёхмерная модель изделия, которую можно покрутить и потыкать мышкой в разные места, получив информацию о том, что в этих точках происходит. Именно так многие представляют себе ЦД. Видимо, картинки с wireframe из презентаций создали устойчивую связь. 

То, как многие представляют себе цифровой двойник. Куда ж тут без 3D-модели? На самом деле, цифровой двойник — это всего лишь модель (информационная, математическая, статистическая, имитационная, гибридная и пр.) реального процесса или устройства, связанная ним двусторонними связями и синхронизированная с ним. Эта модель умеет прогнозировать, что произойдёт с процессом или устройством на основе уже имеющихся данных.

В этом определении важно, что модель умеет прогнозировать. Она может ответить на вопрос: «А что будет, если…?», не дожидаясь, пока реальный агрегат заклинит или взорвётся. Двойник работает на основе той самой IIoT-платформы. Он потребляет её данные, переваривает их и выдаёт не просто графики, а причинно-следственные связи.

Сейчас приведу пример, станет понятнее. Допустим, у нас есть электропривод или насосный агрегат. Мы собираем по нему токи, напряжения, скорость, температуру подшипников, вибрацию, режимы работы, сигналы от частотного преобразователя, время разгона, поведение ^[4] под нагрузкой. На основе этих данных строим модель его поведения ^[5], которую можно использовать для нескольких задач:

• сравнивать фактическое состояние с ожидаемым;

• выявлять ранние признаки деградации;

• оценивать последствия изменения режима работы;

• прогнозировать ресурс и окно обслуживания;

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

Трёхмерную модель тоже можно сделать, хотя обычно это не имеет особого смысла. 

Важно подчеркнуть: использование модного ML — тоже не обязательная составляющая двойника. Оно может быть, но не обязано. Условное уравнение Бернулли вполне справится с предсказанием проблем насоса без всякого ИИ.

Вопрос: «Куда нам поместить такую сущность, как цифровой двойник?» Явно, что ни в SCADA, ни в MES ему не место. Можно развернуть отдельный специализированный софт, но чаще всего двойник помещают именно внутрь IIoT-платформы, где он вполне органично существует.

Цифровая тень

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

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

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

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

Следуя вышеописанной логике, за цифровой двойник пытаются выдать даже SCADA. Дёшево и сердито. Но нет, не прокатит: нет прогнозирования и реального воздействия — нет двойника.

Граничные вычисления

Ещё один удар по стройной пирамидке АСУТП/АСУП нанесли так называемые edge-устройства. В русском прижился термин «граничные вычисления». В чём его смысл? Уровень развития контроллеров и микроПК позволяет нам не тащить на центральный сервер любое сколько-нибудь серьёзное вычисление. Часть решений можно принимать на местах, часть расчётов делать локально. Экономия каналов, ресурсов, времени отклика — одни достоинства.

Как всегда, поясню на примере. Камера над конвейером считает детали с помощью ML. Тащить тяжёлый видеопоток на сервер, занимать канал и ресурсы ради простенькой нейросетки? Сомнительно. Проще реализовать на борту камеры счётчик и на выходе отдавать только число. Это и есть граничные вычисления: не передавать всё на центральный сервер, а сделать здесь и сейчас, силами того процессора, что стоит на объекте.

По подсчетам Гартнера, в 2026 году 75% корпоративных данных будет создаваться и анализироваться не в ЦОДах, а на периферии.

И тут возникает вопрос: а что же такое этот самый edge-контроллер? И как он вписывается в нашу пирамидку уровней?

Раньше всё было просто: первый уровень — датчики и исполнительные механизмы, второй — ПЛК (программируемые логические контроллеры), третий — SCADA. ПЛК жестко и детерминированно вел техпроцесс в реальном времени. Но современные ПЛК — это уже не просто железки с циклами 10–100 мс. Например, Siemens S7-1500, Beckhoff CX, Wago и отечественные аналоги имеют многоядерные процессоры, поднимают веб-сервер, поддерживают REST API, MQTT, а в некоторых (через TcCOM или OpenPLC) можно запустить Python-скрипт. Такой ПЛК спокойно:

• ведёт техпроцесс с циклом 1 мс;

• собирает данные с десятка подчинённых устройств;

• агрегирует их, усредняет и сжимает;

• отдаёт результат наверх по MQTT или OPC UA;

• и даже может запустить модельку для предиктивной аналитики прямо внутри себя.

Так кто перед нами — ПЛК второго уровня или edge-контроллер? Ответ: и то, и другое. Граница стёрлась. И это не страшно, и не проблема. Проблема была бы, если бы кто-то пытался всунуть вместо ПЛК на ответственном контуре обычный Raspberry Pi с Linux — детерминизм и отказоустойчивость у такого «контроллера» никакие. Но если промышленный контроллер с сертификатами IEC 61508 имеет ещё и edge-функции, то это прекрасно.

Так что правильнее говорить не о «смешивании» как об ошибке ^[6], а о сближении, слиянии нескольких понятий. Edge-устройство может стоять на первом уровне (быть умным датчиком), на втором (совмещать функции ПЛК и шлюза), а может висеть как отдельный шлюз сбора данных, вообще не влияя на техпроцесс. Классический подход к АСУ ТП/АСУП в силе, но он обрастает горизонтальными связями и распределённым интеллектом ^[7]. Иногда это сбивает с толку.

И да, Гартнер прав: данных на периферии будет всё больше. Но это не революция, а эволюция ^[8]: мы и раньше делали локальные вычисления, просто теперь делаем их умнее и массовее.

Итог

Стройная пирамидка АСУ ТП/АСУП не то, чтобы развалилась, но серьёзно усложнилась дополнительными пристройками и надстройками. Появились интересные вопросы. Например, такой: «А может ли IIoT-Платформа иметь какие-то управляющие функции?» С одной стороны — должна, если на ней живёт цифровой двойник, у которого двусторонние связи — одна из базовых составляющих. С другой — мы даже уровню SCADA управление делегируем крайне ограниченно. Как нам теперь органично вплести влияние IIoT, чтобы у нас нигде ничего не переклинило?

Пока практика только нарабатывается, и жёстких правил ещё нет. Но один пункт уже вырисовывается чётко: если цифровой двойник претендует на двустороннюю связь и тем более на управляющее воздействие, то он должен быть сертифицирован по промышленной безопасности. Без этого никто не даст ему крутить ручки реального техпроцесса. Пока что двойники живут преимущественно в рекомендательном режиме: «А не снизить ли нам обороты?» — и инженер сам решает. А вот когда они начинают взаимодействовать с ПЛК напрямую, начинается настоящая боль ^[9] и настоящие вопросы. 

Нам бы выдохнуть и опыта ^[10] накопить, но нет — будущее наступает. И перед нами уже развернулась следующая концепция: ИИ-агенты, ассистенты и прочие разработки искусственного интеллекта. Жутко полезные, повсеместно внедряемые и пока тяжело осознаваемые. О них поговорим в следующей части.