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