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