Оставьте логику процесса по возможности в ПЛК. 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", надеюсь на каждый получить как можно больше комментариев, чтобы составить свой список рекомендаций по программированию для ПЛК.
Astronom71
Очень кратко описаны некоторые основы программирования систем АСУ, чего то полезного или нового для себя не увидел. Даже не знаю, плюсовать или минусовать.
Efi-fi Автор
Это третья из 20 рекомендаций по безопасному программированию. Многие рекомендации очевидны, для многих это информация уже известна, но есть и те которым этот пост будет полезен -- молодым специалистам, как я. Кроме того перевода на русский данных рекомендаций ещё нет. Все пункты занимают около 40 страниц, поэтому решил публиковать по одной-две в публикации.
Если хотите минус поставить, то там есть вариант "В статье нет новой для меня информации".
Astronom71
Ок, посмотрим след. статьи. Может такая дифференциация и минимизация будет полезна для понимания
Efi-fi Автор
Хочется в конце сделать краткое, но полезное описание всех пунктов в одной статье. Но тут сложность в выборки главных мыслей.
Efi-fi Автор
Спасибо за комментарий.