Залиште логіку процесу по можливості в ПЛК. HMI не найкраще рішення для виконання завдань, таких як інтегрування, підсумовування та інше.
Опис
HMIs/SCADAs надають певний рівень можливостей програмування, спочатку спрямований на те, щоб поліпшити візуалізацію та оповіщення. Однак деякі розробники використовують це для створення функціоналу, який повинен залишатися в ПЛК.
Розрахунок виразів в одному місці робить розрахунки більш точними. HMI не отримує достатньо часті оновлення даних для точного інтегрування. Крім того, завжди є затримка між HMI і ПЛК. Якщо HMI перезапускається, ПЛК повинен продовжувати працювати в звичайному режимі.
У коді HMI слід уникати всього, що пов'язано з функціями безпеки, такими як блокування, таймери, утримання або дозволу.
Для аналізу даних процесу краще використовувати локальний архів даних. Використовуйте запити до архіву даних за процесами для порівняння узагальнених значень (за період, за цикл процесу) із загальними агрегованими значеннями з архіву. Попереджайте про значну різницю значень.
Приклад
- Програма для активації кнопок (за умовою) повинна бути реалізована на рівні ПЛК, в іншому випадку дії можуть викликатися через HMI (або через мережу), хоча в реальності умови дотримуватися не будуть.
- Таймери, що дозволяють оператору виконувати будь-які дії (таймери затримки для послідовних запусків двигуна, таймер для визначення закриття або відкриття клапанів або зупинки двигуна) слід розміщувати не на рівні HMI, а в ПЛК, який управляє таким двигуном або клапаном.
- Порогові значення для сигналів тривоги повинні бути частиною коду ПЛК, хоча і відображаються на HMI.
- Резервуар для води із мінливим об'ємом: ПЛК, який контролює потік у резервуар і з нього, може легко підраховувати обсяг. HMI теж міг би це зробити, але дані до нього приходять із затримкою і при перезавантаженні розрахунки будуть відхилятися від дійсності.
Безпека
Забезпечує впевненість при перевірці змін коду. Програмування в HMI має систему контролю змін окремо від ПЛК. У HMI немає функцій утримання і контролю значень як у ПЛК, тому зміни на рівні HMI важче виявити.
Зловмиснику складніше маніпулювати даними, розподіленими в багатьох ПЛК, ніж маніпулювати даними, розрахованими в HMI. Якщо частина функцій включення/вимикання відсутня в ПЛК, зловмисники можуть мати можливість маніпулювати ПЛК, зокрема введенням/виведенням без необхідності маскування дій на HMI.
Надійність
Розрахунки будуть більш ефективними і точними, якщо вони будуть проводиться в одному місці. Крім того, підсумки і підрахунки як і раніше будуть доступні, якщо HMI перезапуститься (ПЛК не перезапускаються так часто і зазвичай зберігають важливі значення в енергонезалежній пам'яті).
Різна реалізація передачі даних (входів, блокувань) на HMI і ПЛК може призвести до збоїв через неузгоджену роботу.
Підтримка
Перенести код з одного ПЛК на інший простіше, ніж перенести функції однієї HMI на іншу.
Від себе
Розробники HMI/SCADA докладають зручних і сучасних інструментів для реалізації програм, зберігання даних, контролю значень, аналізу тощо. Той же функціонал не завжди можливий в ПЛК, а якщо і можливий, то швидше за все вимагає великих зусиль для реалізації. Багато хто не замислюючись виносять в SCADA частину функціоналу, на це я бачу 2 причини:
- прискорення процесу розробки (функціонал легше реалізувати в SCADA)
- розвантаження ПЛК (можна заощадити на ПЛК)
Якщо є причини винести функціонал з ПЛК в SCADA, то перед тим як це зробити раджу відповісти на 3 запитання:
- Що буде, якщо зв'язок між ПЛК і SCADA буде розірвано в самий не відповідний момент?
- Що буде, якщо зв'язок буде переодично розриватися на невеликий час?
- Що буде, якщо сервер SCADA буде перезавантажено (замінено резервним)?
Якщо відповіді не містять аварійних ситуацій, проблем з синхронізацією або даними, то функціонал можна винести в SCADA.
Що хочу
Запрошую всіх у telegram чат і telegram канал для фахівців у галузі промислової автоматизації. Тут можна безпосередньо поставити дуже вузькоспеціалізоване питання і навіть отримати відповідь.
Чекаю вашу думку і досвід щодо даного пункту в коментарі. Всього буде 20 пунктів з "" Top 20 Secure PLC Coding Practices ", сподіваюся на кожен отримати якомога більше коментарів, щоб скласти свій список рекомендацій щодо програмування для ПЛК.
Безпека ПЛК: 2) Стежте за режимом роботи
Безпека ПЛК: 4,5) Використовуйте змінні-прапори, хеші та контрольні суми для перевірки цілісності проекту
