Разделите код на модули, используя различные организационные единицы. Тестируйте модули независимо друг от друга.
Описание
Не закладывайте всю логику ПЛК в одном месте, например в основном POU. Вместо этого разделите его на разные организационные единицы: функциональные блоки, функции, подпрограммы - отслеживайте время их выполнения и размер. Создайте отдельные сегменты для логики, которая функционирует независимо.
Эти действия упростят:
проверку ввода
управление контролем доступа
проверку целостности
Модульный код также облегчает тестирование и отслеживание целостности модулей кода. Если код внутри модуля был тщательно протестирован, любые копии этих модулей могут быть проверены на соответствие хешу исходного кода, например, путем сохранения хеша каждого из этих модулей (если это опция присутствует в ПЛК). Таким образом, модули могут быть проверены во время FAT(Factory Acceptance Test) или SAT(On Site Acceptance Test). Проверка будет полезна если целостность кода находится под вопросом после инцидента.
Пример
Логика газовой турбины разделена на «запуск», «управление входными направляющими лопатками», «управление спускным клапаном» и т.д. чтобы вы могли систематически применять стандартную логику. Это также помогает быстро устранять неполадки. Пользовательские функциональные блоки, которые тщательно протестированы, могут быть повторно использованы без изменений (вы будете предупреждены, если были внесены изменения) и заблокированы от неправомерного использования паролем или цифровой подписью.
Пример с Хабра
Как сделать 240 килобайт исходников на ПЛК для управления одними рольставнями
Безопасность
Модульность кода облегчает обнаружение добавленных частей кода, которые могут представлять угрозу. Помогает в стандартизации логики, согласованности и блокировке несанкционированных модификаций.
Надёжность
Модульность кода помогает контролировать последовательность выполнения программы и избегать циклов, которые могут привести к тому, что логика не отреагирует должным образом или выйдет из строя.
Поддержка
Модульный код не только проще отлаживать (модули можно тестировать независимо), но также проще обслуживать и обновлять. Кроме того, модули могут использоваться для других ПЛК, что позволяет использовать один код, в разных ПЛК. Это поможет обслуживающиму персоналу быстро распознать общие модули во время устранения неполадок.
От себя
Паттерны проектирования
В данных пункт хотелось бы добавить рекомендацию использовать паттерны проектирования. Даже для языка LD можно найти типовые схемы(программы), которые помогают избегать избыточности или усложнений кода.
Язык ST во многих реализациях поддерживает ООП, что позволяет использовать большинство классических паттернов проектирования. Для себя выделил несколько, которые подходят для большинства моих проектов:
Знание паттернов проектирования позволяет экономить время, которое вы могли потратить на изобретение своего паттерна, который возможно уже кем-то хорошо описан и проверен.
Тестирование
Под данным пунктом я подразумеваю unit-тесты. В большинстве сред разработки нет инструментов для полноценного тестирования. Для простых проектов особой нужны в unit-тестах нет, однако в больших проектах тестирование необходимо.
Рекомендую поискать фреймворки для проведения тестов. Для TwinCAT 3 такой фреймворк уже написан. Если для вашей среды библиотек для тестирования ещё нет, то можно обойтись самописными тестирующими функциональными блоками. Данное решение полезно для проверки сложных функциональных блоков или функций, так как позволяет убедиться в их корректности после внесения изменений.
Что хочу
Приглашаю всех в telegram чат и telegram канал для специалистов в области промышленной автоматизации. Здесь можно напрямую задать очень узкоспециализированный вопрос и даже получить ответ.
Жду ваше мнение относительно данного пункта в комментариях. Всего будет 20 пунктов из "Top 20 Secure PLC Coding Practices", надеюсь на каждый получить как можно больше комментариев, чтобы составить свой список рекомендаций по программированию для ПЛК.
