Как превратить диагностику ПЛК и SCADA в надежное техническое обслуживание без нарушения работы системы управления.
Сигнал уже существует внутри уровня управления
ПЛК часто продолжает работать, даже когда его состояние ухудшается. Сначала изучите историю диагностики, а не мнемосхему. Перерывы связи постепенно учащаются. Модуль удаленного ввода-вывода сообщает о периодически возникающих неисправностях. На уровне SCADA сбои повторяются еще до остановки производства. Это ранние предупреждения, а не шум. Современные контроллеры уже предоставляют эти данные. Новая сеть датчиков нужна не всегда. Сложность заключается в том, чтобы найти для каждого сигнала полезное назначение. Таким назначением должна быть запись о техническом обслуживании, связанная с реальным активом.
Шаг 1 - Получайте достоверные данные о состоянии контроллера
Прогностическая логика должна использовать сигналы, которые устройство действительно поддерживает. Не предполагайте, что каждый ПЛК предоставляет одинаковые данные о состоянии. В системе Allen-Bradley ControlLogix (например, с процессором Allen-Bradley ControlLogix) или CompactLogix отслеживайте счетчики ошибок портов EtherNet/IP на коммуникационных картах, таких как коммуникационный модуль 1756 ControlLogix. Отслеживайте количество устранимых неисправностей для каждой удаленной станции. В контроллере Woodward, доступном по Modbus TCP (в системах мониторинга с модулями ввода-вывода Woodward), считывайте регистры необходимости технического обслуживания и предельного ресурса. Некоторые устройства напрямую сообщают о внутренних неисправностях или аномальном напряжении питания.
-
Шаг 1 - Составьте список всех диагностических параметров, которые действительно предоставляет целевое устройство.
-
Шаг 2 - Еженедельно отслеживайте динамику счетчиков, поскольку частота лучше единичного события показывает ухудшение состояния.
-
Шаг 3 - Формируйте аварийный сигнал только при возрастающем тренде или определенной длительности, а не из-за единичного всплеска.
-
Шаг 4 - Связывайте каждый счетчик с одним активом, имеющим тег, а не с общей стойкой.
Шаг 2 - Не превращайте каждую аварию в заявку
SCADA привлекает внимание оператора. Техническое обслуживание решает, кто возьмет в руки инструмент. Если смешать эти задачи, реальные признаки ухудшения состояния утонут в ненужных заявках. Аварийный сигнал высокой температуры может быть всего лишь нормальным производственным режимом. Кратковременный сбой может устраниться сам. Поэтому оценивайте состояние до создания задания. Повторяемость важнее единичного события. Длительность часто важнее максимальной интенсивности. Медленный дрейф ниже аварийного порога все равно может требовать проверки. Кроме того, разделяйте подтверждение и завершение. Оператор подтверждает, что неисправность была замечена. Это не доказывает, что оборудование отремонтировано.
-
Шаг 1 - Добавьте правило, по которому для создания задания требуется три повторения в течение семи дней.
-
Шаг 2 - Прикрепляйте контекст: актив, тренд и сведения о предыдущих ремонтах.
-
Шаг 3 - Закрывайте заявку только после выполнения и регистрации работ.
История ремонтов повышает точность модели
Данные архиватора показывают, что происходило до неисправности. История технического обслуживания показывает, что произошло после осмотра. Допустим, ошибка связи постоянно приводит к созданию заявок. Каждый раз специалисты не находят дефекта оборудования. Вероятно, условие срабатывания задано слишком чувствительно. Однако если одно и то же событие всегда заканчивается заменой одного разъема, доверяйте этой закономерности. Она требует более раннего внимания. Завершенные работы помогают отделить симптом от причины. Ложная неисправность ввода-вывода может быть вызвана потерей питания полевым устройством. Замена модуля устранит неисправность не того актива. Примечание о завершении сохраняет истинную причину для следующей смены.
Интегрируйте систему без повышения рисков
Система управления техническим обслуживанием не должна становиться привилегированным клиентом системы управления. Передавайте диагностические данные через уровень данных. Получайте тренд из SCADA или архиватора. Используйте OPC UA с доступом только для чтения для стандартизированной информации о состоянии и диагностике. Затем интеграционный сервис передает квалифицированные события на платформу технического обслуживания через API. Это не допускает проникновения служебного трафика технического обслуживания в контур критически важной логики. Прогностические вычисления не обязательно выполнять внутри контроллера. Кроме того, защищайте сеть. Приложению для технического обслуживания редко требуется записывать данные в память ПЛК. Ограничьте его доступ режимом только для чтения. Перед тем как автоматизированная связь с производством начнет работать, соблюдайте установленный на предприятии процесс управления изменениями. Наконец, синхронизируйте часы. Если событие SCADA отмечено временем, отличающимся от записи в системе управления техническим обслуживанием на несколько минут, восстановление последовательности неисправности становится невозможным.
Заключение и рекомендации к действию
Прогностическое техническое обслуживание вознаграждает терпение и чистый поток данных, а не эффектные информационные панели. Сначала получайте только те данные о состоянии, которые устройства действительно предоставляют. Затем оценивайте состояние по повторяемости и длительности, прежде чем создавать заявку. Кроме того, со временем совершенствуйте условия срабатывания на основе подтвержденной истории ремонтов. Однако никогда не позволяйте системе управления техническим обслуживанием записывать данные в логику управления или обходить процесс управления изменениями. Поэтому создайте путь только для чтения через архиватор и OPC UA с синхронизированным временем. Наконец, относитесь к самой инфраструктуре управления как к оборудованию, требующему обслуживания. На этой неделе начните с одного критически важного соединения EtherNet/IP. Проверьте весь цикл от начала до конца, прежде чем масштабировать решение на весь завод.
Автор: Сунь Ифэй - инженер по промышленной автоматизации с более чем 10-летним опытом работы с ПЛК, DCS и системами управления.
