Телеметрия обещает переход от реактивного ремонта к предупреждающему: оборудование само сообщает, что скоро выйдет из строя. На практике между потоком показаний с датчиков и заявкой на ремонт лежит несколько слоёв обработки, и именно они определяют, будет ли от мониторинга польза или система утонет в ложных срабатываниях. Разберём архитектуру.
Три уровня зрелости
| Уровень | Что делает | Что требуется |
|---|---|---|
| Реактивный по сигналу | Авария на оборудовании — автоматическая заявка | Канал сигналов, правила создания заявок |
| По наработке | Обслуживание по фактическим часам, а не по календарю | Счётчики наработки, регламенты |
| Предупреждающий | Заявка по отклонению параметров до отказа | Пороги, история, модели |
Переходить сразу к третьему уровню — типичная ошибка. Он требует накопленной истории параметров, сопоставленной с историей отказов, а её появление занимает месяцы. Первые два уровня дают результат быстро и создают ту самую историю.
Уровень 1: сигнал об аварии
Простейший и самый быстрый в реализации сценарий: система мониторинга фиксирует критическое событие и передаёт его в учётную систему, где автоматически создаётся заявка.
Что нужно настроить:
- сопоставление идентификатора оборудования в системе мониторинга с карточкой объекта;
- классификатор событий и правила: какие создают заявку, какие только регистрируются;
- приоритет заявки в зависимости от типа события;
- защиту от дублирования — повторный сигнал по той же проблеме не должен порождать вторую заявку;
- автоматическое закрытие сигнала, если оборудование восстановилось само.
Четвёртый и пятый пункты решают главную проблему таких интеграций: без них при нестабильной связи или мигающем датчике очередь заполняется сотнями одинаковых заявок за час, и диспетчер отключает интеграцию.
Уровень 2: обслуживание по наработке
Регламент обслуживания привязывается не к календарю, а к фактической наработке: моточасам, пробегу, числу циклов, объёму продукции.
Это уровень, дающий самый понятный экономический эффект: оборудование, работающее вполсилы, не обслуживается зря, а работающее в две смены — обслуживается вовремя, а не когда подойдёт календарный срок.
Что требуется: регулярная передача показаний счётчиков, хранение истории наработки по объекту, регламенты с интервалами в единицах наработки, автоматическое формирование заявок при приближении к порогу с запасом на планирование.
Уровень 3: предупреждающее обслуживание
Заявка формируется по отклонению параметров, предшествующему отказу: рост температуры, вибрации, потребляемого тока, падение производительности.
Условия, без которых это не работает:
- история параметров за достаточный период;
- история отказов, сопоставленная с этими параметрами по времени;
- определённые пороги — сначала экспертные, затем уточнённые по статистике;
- механизм оценки: сколько предупреждений оказались обоснованными.
Последний пункт критичен. Без обратной связи о том, подтвердилось ли предупреждение, пороги никогда не будут откалиброваны, а мастера перестанут воспринимать такие заявки всерьёз.
Архитектурные решения
- Не хранить сырую телеметрию в учётной базе. Поток показаний с сотен датчиков быстро сделает базу неработоспособной. В учётную систему передаются события и агрегаты — средние за период, пики, факты пересечения порогов.
- Обработка на стороне мониторинга. Правила и пороги логичнее держать там, где данные, а в учётную систему отдавать готовое решение.
- Один справочник оборудования. Ведущая система — учётная, мониторинг использует её идентификаторы.
- Контроль связи. Отсутствие данных от объекта — тоже событие, и оно должно быть заметно.
- Журнал событий с возможностью посмотреть, почему заявка была создана.
Первый пункт — самая частая техническая ошибка таких проектов: попытка складывать показания датчиков в учётную базу приводит к деградации производительности через несколько месяцев.
Что измерять
- долю заявок, созданных по сигналу, а не по обращению клиента;
- долю подтвердившихся предупреждений;
- долю ложных срабатываний;
- время от сигнала до начала работ;
- изменение доли аварийных ремонтов относительно плановых.
Последний показатель — итоговый: смысл всей затеи в том, чтобы сдвинуть баланс от аварийных работ к плановым.
Итог
Интеграция с мониторингом даёт результат, если идти по уровням: сначала автоматические заявки по авариям, затем обслуживание по фактической наработке и только потом предупреждающие сценарии, для которых нужна накопленная история. Технически ключевое решение — не хранить сырую телеметрию в учётной базе и обрабатывать пороги на стороне мониторинга. Организационно обязательна обратная связь о том, подтвердилось ли предупреждение, — без неё пороги не калибруются, а доверие к системе теряется.
Планирование планово-предупредительных работ по графикам поддерживается решением «1С:Сервисный Ремонт».
Компания «Сайфилд» настраивает интеграцию «1С» с системами мониторинга оборудования — от автоматических заявок по событиям до обслуживания по наработке. Опишите свой ландшафт, и мы оценим объём работ.