АСУ ТП знает, что насос работает в пределах уставок и когда он три раза подряд ушёл в аварию.
CMMS знает, когда по календарю должна быть замена подшипника и кто из слесарей возьмёт наряд. Если между этими двумя мирамами нет нитки, получается классическая картина: оператор звонит в цех «отвалилось», а в системе обслуживания всё зелёное, потому что не было триггера.
Статья про интерфейсы, мастер-данные и живой поток от технологического события до закрытого наряда.
Короткий ответ
Связка работает, когда совпадают три вещи: единый идентификатор оборудования между контуром автоматизации и EAM, правила, которые превращают полевые события в осмысленные задачи ТОиР (не «создать тысячу нарядов на каждый дребезг датчика»), и обратная связь из CMMS в АСУ ТП - хотя бы флаг «работы выполнены», чтобы логика и экраны не вводили персонал в заблуждение.
Где проходит граница между АСУ ТП и CMMS
АСУ ТП живёт в реальном времени процесса: тренды, алармы, межлоковые блокировки, счётчики наработки часов двигателя, если их завели осмысленно.
CMMS живёт в ресурсном контуре: активации оборудования, BOM запчастей, маршруты обслуживания, трудозатраты, склад.
EAM (Enterprise Asset Management) часто шире CMMS и включает стандарты надёжности и управление жизненным циклом, но на заводе обычно спорят о том же: где истина про «объект ремонта».
Интеграция не про «протащить все теги в ERP». Интеграция про события и статусы, которые имеют деловой смысл для службы эксплуатации.
Интерфейсы: что реально подключают к CMMS
SCADA и аларм-сервер - источник немедленных триггеров: переход в состояние, наработка порога, комбинация условий (например, вибро высокая и температура подшипника растёт). Часто используют шлюз или сервис на среднем уровне: OPC UA subscription, REST webhook из SCADA, MQTT-топик с нормализованным payload.
Historian - источник деградации во времени: сколько часов работал узел под высокой нагрузкой, сколько раз срабатывал защитный режим за месяц. Из этого строят профилактические пакеты ТОиР или триггеры условного обслуживания.
MES иногда выступает оркестратором: партия закончилась - можно генерировать наряд на осмотр линии, если партии связаны с оборудованием в модели.
Плохой интерфейс - когда все события пишут напрямую в базу CMMS без очереди: любая сетевая пауза превращается в дыры данных или дубликаты нарядов.
Мастер-данные оборудования: без них интеграция ломается в первый месяц
Минимум, который должен быть согласован:
•Единый ID актива (functional location или equipment ID в SAP PM / IBM Maximo / Infor / 1С ТОиР и т. д.).
•Сопоставление между объектами SCADA (PLC-тэг группа / объект экрана) и активом в EAM - таблица соответствий с версией.
•Классы причин: технологическая авария, предупреждение по состоянию, календарное ТО, регламент после простоя.
Если инженер в SCADA назвал объект «Насос_P401», а в CMMS актив «P-401 насосная группа», интеграция будет создавать ложные дубликаты или привязываться не к тому узлу.
Триггеры из технологических событий: как не утонуть в шуме
Рабочие паттерны:
•Дебаунс и счётчики: три одинаковых аварии за час - один наряд, не тридцать.
•Приоритеты: событие SIL или межцеховая блокировка - немедленный наряд; желтый предупреждающий дрейф - задача на смену.
•Супрессия при активном ремонте: если актив уже «under maintenance», не создавать дочерние наряды на каждый новый аларм.
•Сегментация по режимам: не считать нормативный простой во время планового останова.
Ошибка - воспринимать каждый сигнал дискретного входа как заявку на ремонт. Это убивает доверие к CMMS за неделю.
Пример потока: событие в АСУ ТП - наряд в CMMS - закрытие - обратная связь
Рабочая последовательность, которую можно положить в ТЗ на интеграцию:
1.Событие в АСУ ТП. На линии фасовки датчик переполнения бункера даёт устойчивое состояние 90 секунд (антидребезг). SCADA фиксирует объект «Бункер B402», код события HIGH_LEVEL_CONFIRMED, прикладывает снимок тренда давления и счётчик срабатываний за смену.
2.Создание наряда в CMMS. Сервис интеграции переводит событие в заявку типа «диагностика» на актив LOC-PKG-L402-BNK402. В описании автоматически попадают время начала, оператор смены, ссылки на экран SCADA и ID партии из MES, если есть.
3.Работа в поле. Слесарь принимает наряд на планшете в CMMS, переводит оборудование в статус «ремонт», блокирует пуск через процедуру MOC или локальный ключ безопасности - зависит от регламента завода.
4.Закрытие наряда. Выполнена замена датчика уровня, заполнены строки запчастей, закрыта работа с кодом причины «отказ датчика». CMMS меняет статус актива на «эксплуатация».
5.Обратная связь в контур АСУ ТП. Интеграция отправляет в SCADA флаг MAINT_COMPLETED, при необходимости снимает технологический «ремонтный» блок на экране оператора и записывает в журнал событие о восстановлении. Если нужно - счётчики аварий сбрасываются или остаются в истории для аналитики надёжности.
Разрыв на шаге 5 частый: ремонт сделали, но оператор всё ещё видит «техобслуживание», потому что SCADA не получила статус.
Типовые ошибки
Отсутствие владельца данных. Кто правит карту соответствий при добавлении линии? Если непонятно, через полгода модель расходится.
Интеграция без тестов на шторме. Исторический архив показывает, что будет при лавине алармов при пуске завода.
Дублирование активов. Импорт из проекта ПЛК в EAM без сверки с финальной номенклатурой завода.
Игнорирование кибербезопасности. Открытый webhook из SCADA в CMMS без аутентификации - лишняя дверь в контур.
Где уместен СТАБУР
В архитектурах на базе СТАБУР технологический контур уже строится с учётом изменений и версий. Связка с CMMS ложится на ту же культуру: интеграционный сервис версионируется, изменения проходят через согласование, триггеры документируются так же, как параметры регулятора.
Заключение
EAM/CMMS и АСУ ТП должны говорить на языке активов и событий, а не на языке «тысячи тегов». Инвестиции в мастер-данные и антишум окупаются тем, что наряды появляются там, где реально нужны люди и запчасти, а оператор видит актуальный статус техники после закрытия работ.
FAQ
Обязательно ли OPC UA между SCADA и CMMS?
Не обязательно. Часто используют REST, очереди сообщений или файловый обмен в зависимости от версий систем и политики безопасности.
Кто должен владеть таблицей соответствий?
Лучше совместное владение: главный механик или reliability и инженер АСУ ТП, с формальным согласованием при изменениях.
Нужно ли хранить историю алармов в CMMS?
Не всю. Храните то, что влияет на классификацию отказов и повторяемость - остальное остаётся в historian.
Как связать с ISA-95?
Модель активов и локаций хорошо ложится на иерархию предприятие - цех - линия - узел; события поднимаются с Level 1-2 и порождают задачи на Level 3-4 через сервис интеграции.
Что делать, если CMMS на облаке, а SCADA изолирована?
Типичная схема - шлюз на DMZ или буфер очереди на среднем уровне с односторонними правилами и контролем исходящих запросов.