Мониторинг температуры в холодильном оборудовании кажется простой задачей. Особенно если речь идет всего о нескольких десятках ларей на одном производственном участке. Но когда эти лари от разных вендоров, с разными протоколами, и их еще и перемещают по цеху, задача перестает быть тривиальной. В этой статье в блоге ЛАНИТ - опыт внедрения IoT-решения без замены оборудования, с примерами ошибок и неочевидных решений. Материал будет полезен тем, кто сталкивается с промышленным мониторингом, выбирает между машинным обучением и простой логикой или пытается подружить разнородное оборудование и создать из него единую систему.

Как простая задача превратилась в IoT-интеграцию

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

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

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

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

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

Почему мониторинг температуры оказался задачей уровня MES

По сути, то, что мы внедрили на этом участке, можно рассматривать как MES-систему (ПО для управления в реальном времени) в пределах отдельного производственного процесса. Поэтому перед разговором об архитектуре решения стоит коротко объяснить, почему такие системы вообще важны для производства.

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

Если сильно упростить, у MES-систем на производстве есть несколько понятных задач.

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

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

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

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

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

Архитектура: от датчика до дашборда. Почему установить датчики – еще не значит решить задачу

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

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

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

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

Слой подключения. Как решается проблема зоопарка протоколов

Для этого использовали STAQ.Bridge – беспроводные температурные датчики, которые не зависят от цифрового интерфейса оборудования. Датчик крепится к ларю и начинает передавать данные. Не нужно дорабатывать прошивку, искать документацию на каждый тип оборудования или писать адаптер под каждого вендора.

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

На практике надежность такой схемы держится на двух вещах.

Первая – частота опроса. Мы выбрали интервал 15 минут. Температура в закрытом холодильном ларе меняется достаточно медленно, поэтому за 15 минут в закрытом объеме не происходит скачок, который система не успеет заметить следующим измерением.

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

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

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

Слой аналитики. Почему мы не стали делать ML

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

+2°C к норме – предупредительный уровень;

+4°C к норме – критический уровень.

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

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

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

Получилась не ML-модель, а простое инженерное правило. В этой задаче оно надежнее, понятнее для пользователей и проще для последующего аудита.

Слой реагирования. Кто получает алерт и что делает дальше

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

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

Одни и те же данные показываются разным людям по-разному. Оператору важно быстро понять, где проблема и что делать. Руководителю – увидеть общую картину по зонам, историю инцидентов и время реакции персонала.

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

Три вещи, которые мы не предусмотрели, и как с ними разобрались

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

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

1. Логика алертов: где сигнал, а где шум

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

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

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

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

После этого логику изменили: уведомление отправляется только после подтверждения отклонения следующим замером. Два последовательных значения выше порога – это уже не сигнал о том, что открыли дверцу ларя, а повод для реакции.

Цена такого решения – плюс 15 минут до первого уведомления. Для этой задачи это допустимо, потому что между предупредительным и критическим уровнями остается время на действие. Зато ложные срабатывания ушли, и персонал перестал воспринимать уведомления как фоновый шум.

2. Дедупликация инцидентов: один ларь, одна проблема, сто уведомлений

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

Через час у оператора уже четыре инцидента по одному и тому же ларю. Через два часа– восемь. Формально система работает, но с точки зрения процесса это бессмысленно. Проблема одна, а записей много. KPI по закрытым инцидентам тоже начинают искажаться.

Мы добавили группировку по ключу: оборудование, тип отклонения и временное окно. Все, что происходит с одним ларем в рамках одного непрерывного отклонения, считается одним инцидентом. Он живет до тех пор, пока температура не вернется в норму.

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

3. Поставили датчики. Потом разобрались, где какой

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

Пока система не работает в боевом режиме, это кажется не самой страшной проблемой. Но все меняется в момент, когда нужно понять, где именно находится датчик с конкретным номером. Если №318 сигналит о проблеме, оператор должен найти не приблизительные место и объект, а конкретное оборудование.

Решение нашли внутри той же платформы. Для инвентаризации использовали функционал ТОиР (технического обслуживания и ремонта): по каждому ларю создали заявку с чек-листом и фотоподтверждением соответствия номера датчика номеру оборудования.

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

Результаты: цифры и что за ними стоит

Минус 90% потерь от порчи продукции. Главный эффект появился из-за того, что система начала ловить проблему в момент, когда еще можно что-то сделать.

Предупредительный порог стоит на +2°C к норме, критический – на +4°C. Между этими значениями есть время что-то исправить. В закрытом холодильном ларе температура поднимается от предупредительного до критического уровня примерно за час.

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

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

Минус 43% к среднему времени реакции персонала. Эта цифра требует пояснения: люди не стали физически реагировать в полтора раза быстрее, а изменился сам характер инцидентов.

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

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

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

Итоги: что можно перенести в другие отрасли

Главный вывод из этого проекта простой: сложность IoT-интеграции часто находится не там, где ее сначала ищут.

Не всегда самая сложная часть – это датчики, протоколы или сама платформа. Иногда главная работа в том, чтобы правильно понять объект наблюдения: как он живет в реальном процессе, как его перемещают, кто с ним работает, какие события являются нормальными, а какие требуют реакции.

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

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

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

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

Описывать интерфейс текстом – не самое благодарное занятие. Поэтому мы проводим онлайн-разбор: берем реальный сценарий и показываем, как событие проходит путь от сигнала с датчика до закрытия инцидента руководителем.

Если интересно посмотреть решение вживую, добро пожаловать на наш вебинар 30 июня 2026 г. в 11:00 по МСК (ссылка на регистрацию).

А как вы решаете мониторинг разнородного оборудования? В какой момент IoT-интеграция у вас оказалась сложнее, чем выглядела на старте?