Оставьте логику процесса по возможности в ПЛК. 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) Используйте переменные-флаги, хеши и контрольные суммы для проверки целостности проекта

Комментарии (5)


  1. Astronom71
    04.10.2021 18:00

    Очень кратко описаны некоторые основы программирования систем АСУ, чего то полезного или нового для себя не увидел. Даже не знаю, плюсовать или минусовать.


    1. Efi-fi Автор
      04.10.2021 18:08
      +1

      Это третья из 20 рекомендаций по безопасному программированию. Многие рекомендации очевидны, для многих это информация уже известна, но есть и те которым этот пост будет полезен -- молодым специалистам, как я. Кроме того перевода на русский данных рекомендаций ещё нет. Все пункты занимают около 40 страниц, поэтому решил публиковать по одной-две в публикации.

      Если хотите минус поставить, то там есть вариант "В статье нет новой для меня информации".


      1. Astronom71
        05.10.2021 00:10

        Ок, посмотрим след. статьи. Может такая дифференциация и минимизация будет полезна для понимания


        1. Efi-fi Автор
          05.10.2021 09:19

          Хочется в конце сделать краткое, но полезное описание всех пунктов в одной статье. Но тут сложность в выборки главных мыслей.


    1. Efi-fi Автор
      04.10.2021 18:09

      Спасибо за комментарий.