Как составить ТЗ на систему IIoT-мониторинга цеха
IIoT-мониторинг заказывают расплывчато — собирать данные с оборудования — и получают россыпь узлов, которые теряются в металле цеха, садят батареи и шлют несводимые форматы. ТЗ переводит замысел в проверяемые требования по связи, автономности, данным и приёмке. Ниже — разделы, которые оно должно содержать. Материал дополняет гайды RF-антенны для промышленного IIoT и чеклист интеграции IIoT-датчиков.
Раздел 1. Что снимаем и зачем
Начинают с параметров, а не с датчиков: какие величины — температура, вибрация, ток, давление, уровень, — на каком оборудовании, с какой периодичностью и ради какого решения. Частоту опроса задают от физики явления: вибрация требует высокой частоты дискретизации в сотни герц, медленные тепловые процессы обходятся минутами. Без привязки к цели мониторинг превращается в сбор данных ради данных, которые никто не смотрит.
Раздел 2. Связь и топология
Фиксируют протокол под задачу (дальность, объём, периодичность), топологию — звезда через шлюз или ячеистая сеть, — число узлов и запас шлюза по подключениям. Ошибка выбора протокола влияет на всю эксплуатацию сильнее цены узла: протокол для редкой телеметрии на большие расстояния не потянет частый поток вибрации, и наоборот. Требование радиообследования на месте указывают здесь же: лабораторная дальность в цеху с металлом и работающим оборудованием не действует, и мёртвые зоны выявляют до монтажа.
Раздел 3. Питание и автономность
Для автономных узлов задают требуемый срок службы батареи при заданной частоте передачи, с запасом, и регламент замены. Частая передача сажает батарею за месяцы вместо лет, узлы гаснут по одному, и покрытие деградирует незаметно. Это требование определяет и класс узлов, и эксплуатационные расходы на весь срок.
Раздел 4. Данные, формат и время
Описывают единый формат — поля, единицы измерения, идентификатор узла, метки времени — и требование синхронного времени между узлами. Без синхронного времени временные зависимости разрушаются, корреляции становятся ложными, а на сведение разъезжающихся форматов из десятка источников уходит больше сил, чем на сам мониторинг. Формат фиксируют в ТЗ до монтажа, а не разгребают потом.
Раздел 5. Безопасность
Беспроводная сеть — поверхность атаки. Фиксируют шифрование канала, аутентификацию узлов и сегментацию от офисной сети. Подменённый или неаутентифицированный узел отравляет мониторинг ложными данными, а открытая сеть — риск для всего предприятия. Требования безопасности цеха указывают явно, согласовав со службой безопасности до развёртывания.
Раздел 6. Интеграция и реакция
Данные обязаны попадать в систему, где на них реагируют — SCADA, мониторинговая панель, аналитика, — а не оседать в отдельной базе. Указывают протокол и приёмник, а также пороги и адресатов оповещений: кто получает сигнал при выходе параметра за границу и что обязан сделать. Как связать с цеховыми системами — в гайде интеграция AI в MES/SCADA.
Раздел 7. Критерии приёмки
Приёмку задают измеримо: покрытие без мёртвых зон на заданном числе узлов, доля успешно доставленных пакетов не ниже порога на контрольном интервале, подтверждённая автономность узлов, корректное поведение при потере части узлов. Условия испытаний совпадают с рабочими — при работающем оборудовании, а не в тихом цеху. Полезно принимать на пилотной группе узлов до массового монтажа.
Образец раздела критериев приёмки
Критерии приёмки IIoT-мониторинга полезно свести в таблицу с порогами (значения — под ваш цех):
| Критерий | Порог | Как проверяется |
|---|---|---|
| Покрытие без мёртвых зон | все узлы на связи | обход при работающем оборудовании |
| Доставка пакетов | не ниже требуемой доли | контрольный интервал в сутки+ |
| Автономность узлов | не короче заданного срока | темп разряда под рабочей частотой |
| Синхронность времени | в пределах требуемой точности | сверка меток между узлами |
| Поведение при потере узла | детектируется как отказ | намеренное заглушение узла |
Приёмку проводят на пилотной группе при работающем оборудовании, а не в тихом цеху, — только так проверяется реальная радиообстановка.
Частая ошибка ТЗ
Мониторинг заказывают как собирать данные с оборудования без указания, ради какого решения и с какой периодичностью, — и получают поток, который никто не использует, а частота опроса случайно оказывается недостаточной для явления. ТЗ начинают с вопроса зачем: какое решение принимается по этим данным и какая периодичность нужна, чтобы поймать процесс. Тогда мониторинг становится инструментом, а не архивом.
Что это значит для внедрения на вашей линии
Хорошее ТЗ на IIoT-мониторинг отвечает до старта: какие параметры и с какой периодичностью, по какому протоколу и с каким покрытием, на какой автономности и в каком едином формате, куда уходят данные и как принимается система. Радиообследование и проверка доставки пакетов на приёмке превращают её из спора в измерение. С выбором протокола, обследованием покрытия и формулировкой метрик под конкретный цех помогаем на старте.