Промышленный интернет вещей (IIoT): что мерят на производстве и какие сценарии окупаются

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

Пять слоёв, и стоимость проекта размазана по ним неравномерно.

Датчики и съём сигнала. Температура, вибрация, давление, расход, ток, положение. Часть параметров уже есть в контроллере оборудования, часть придётся добавлять отдельными датчиками.

Шлюз и edge-обработка. Устройство в цехе, которое опрашивает оборудование, буферизует данные при обрыве связи и отбрасывает лишнее. Именно здесь решается, поедет ли в центр весь поток или только агрегаты и события.

Транспорт. Промышленные шины внутри участка, дальше — MQTT или защищённый канал до платформы. В закрытых контурах данные не выходят за периметр вовсе.

Платформа и хранение. База временных рядов, правила и пороги, оповещения, интерфейсы для оператора и инженера.

Аналитика и интеграции. От простых алертов до моделей предсказания отказов; передача событий в производственный учёт, в обслуживание, в планирование.

Наша зона в этом списке — три последних слоя. Датчики, шлюзы и прошивки мы не производим и не поставляем: работаем поверх готового оборудования и говорим об этом сразу, чтобы в проекте был понятен стык ответственности.

Список параметров без ответа на вопрос «какое решение по нему принимается» бесполезен, поэтому таблица с третьей колонкой.

Не всё, что технически возможно, стоит делать первым. Сценарии по соотношению эффекта и сложности:

Здесь больше всего маркетинга, поэтому по существу. Предиктив — это модель, которая по потоку параметров узнаёт приближение отказа. Чтобы она узнавала, ей нужно на чём-то учиться.

История отказов с метками. Не просто телеметрия за год, а записи «в такую-то дату этот узел вышел из строя по такой-то причине». Без разметки алгоритм видит колебания, но не знает, какие из них закончились аварией.

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

Стабильный режим работы. Если оборудование каждую смену работает с новым материалом и на разных скоростях, «нормальное поведение» описать сложнее, и модели нужен признак режима.

Кому уходит предупреждение. Алерт без адресата и регламента бесполезен: должно быть понятно, кто получает сигнал, что делает и в какой срок.

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

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

Главная техническая реальность российского производства: значительная часть парка старше двадцати лет, и никакого «подключим по API» там нет.

Оборудование с контроллером. Если есть ПЛК, данные снимают через промышленные протоколы: OPC UA как современный стандарт с моделью данных и безопасностью, Modbus — как рабочая лошадка старых систем. Дальше телеметрия уходит в платформу, часто через MQTT.

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

Оборудование, которое нельзя трогать. На части агрегатов вмешательство снимает гарантию или требует согласования. Тогда работают только с тем, что доступно снаружи, и это ограничение фиксируют в проекте до старта.

Разные протоколы на одном участке. Норма, а не исключение: пять поставщиков оборудования — пять способов отдавать данные. Приведение к единому формату — отдельная работа, и она обычно недооценена в первой смете.

Промышленная телеметрия — это временные ряды, и они растут быстрее, чем ожидают.

Частота против объёма. Опрос раз в секунду по сотне точек — это миллионы записей в день. Раз в минуту — в шестьдесят раз меньше. Частоту выбирают не «на всякий случай», а по тому, какое решение принимается по параметру.

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

Срок хранения. Сырьё детально — недели, агрегаты — годы. Без политики хранения база через год начинает стоить дороже пользы.

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

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

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

Данные с линии полезны, когда доходят до тех систем, где принимаются решения: MES, учётный контур, а на складе — WMS.

• Производственный учёт. Факт выпуска, простои и брак уходят в систему управления производством; как устроен этот контур, разобрано в материале про MES-систему.
• Обслуживание и ремонты. Заявка на ремонт создаётся автоматически по превышению порога, с указанием узла и накопленной наработки.
• 1С и учёт. Списание материалов и энергии по факту, а не по нормативу.
• Склад. Потребность в запчастях по состоянию оборудования вместо страховых запасов «на всякий случай».
• Планирование. Реальная доступность оборудования вместо оптимистичного графика.

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

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

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

Односторонняя передача. Для критичных участков данные отдают наружу, но не принимают команды внутрь. Мониторинг — да, управление — нет.

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

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

Промышленный проект почти никогда не делает один подрядчик, и половина срывов сроков происходит на стыках. Роли стоит расписать до старта:

Короткая рамка, чтобы понимать масштаб. По итогам 2023 года рынок интернета вещей в России оценивался примерно в 170 млрд ₽, и промышленный сегмент занимал в нём основную часть — около 144,5 млрд ₽. Прогнозы на 2026 год расходятся в деталях: от 188,9 до 208,5 млрд ₽ при среднегодовом росте порядка 12% после спада 2022 года.

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

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

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

Что берут в пилот. Один агрегат или одну линию, где простои дороги и данные хотя бы частично доступны. Срок — два-три месяца, включая монтаж датчиков силами подрядчика по железу.

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

Чем заканчивается. Решением: тиражировать на другие участки, доработать или закрыть. Пилот, который «показал перспективность», но не дал цифр, — это не пилот, а демонстрация. Бюджет пилота и последующего тиража можно прикинуть в бесплатном калькуляторе оценки.

Ориентиры по нашим работам: софтовая часть IoT-решения начинается от 1,5 млн ₽, отдельная интеграция — от 150 тыс. до 1,5 млн ₽, мобильное приложение для персонала — от 1,8 млн ₽. Датчики, шлюзы и монтаж считает поставщик оборудования: мы работаем поверх готового железа. Сумму по вашему участку назовём после разбора: оценка проекта бесплатная — опишите задачу.

Начать с платформы, а не со сценария. Куплена система «под все задачи», а первый вопрос — что именно она должна показывать — остался без ответа.

Собирать данные без адресата решения. Телеметрия копится, дашборд красивый, но кто и что делает по сигналу — не описано. Через квартал на дашборд никто не смотрит.

Обещать предиктив без истории отказов. Модель не на чем обучить, и проект превращается в сбор данных с надеждой на будущее.

Тянуть сырой поток в центр. Частота опроса выбрана «максимальная на всякий случай», трафик и хранилище растут, польза не меняется.

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

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

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

С этими ответами обсуждение становится предметным: видно, начинать ли с учёта простоев, энергоучёта или сразу с диагностики конкретного узла — и сколько данных для этого придётся собрать.