Практика программирования промышленных контроллеров (ПЛК)

В любом программировании не существует единого способа разработки логики для задачи или процесса. Это, конечно, приводит к необходимости принимать решения, основанные на конкретных задачах или операциях, которые необходимо выполнить в данный конкретный момент. Однако гибкость среды программирования ПЛК дает широкие возможности для создания разнообразных решений.

В компании Гекомс мы придерживаемся определенных рекомендаций в программировании ПЛК, какие не только доказывают свою полезность, но и обеспечивают согласованность программистов друг с другом, что позволяет проводить простую диагностику и четкое понимание модификаций, когда необходимо внести изменения.

Помимо упрощения понимания будущих изменений и поиска неисправностей, некоторые из этих передовых методов значительно сокращают время разработки HMI и SCADA.

Производители промышленных контроллеров. Купить в Гекомс

Allen Bradley Rockwell Automation

Allen-Bradley

Rockwell Automation, Inc. — американский поставщик промышленной автоматизации и информационных продуктов

Программирование промышленных контроллеров 1

Siemens

Контроллеры Simatics от немецкого концерна Siemens являются одними изсмых популярных ПЛК на российском рынке

Рекомендации по программированию ПЛК

Вот лишь некоторые из основных рекомендаций, которым мы следуем:

Именование тегов

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

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

Кроме того, многие системы именования тегов имеют ограничение на количество разрешенных символов. Даже если не существует ограничения на количество символов, управлять длинными именами тегов сложно. В таком случае рекомендуется иметь хорошо задокументированные сокращенные наименования. Есть сокращения, которые существуют в мире управления технологическими процессами на протяжении десятилетий.

Идентификация устройства также должна быть максимально простой. Обычно используется идентификатор устройства, указанный на диаграмме процесса и КИПиА. Например, вход состояния работы для насоса 1 должен иметь название P1.YI, P1/YI или P1_YI в зависимости от структуры тегов организации используемого ПЛК. У каждого тега в его свойствах должно быть включено описание, которое четко объясняет функцию тега.

UDTs

UDTs или «тип тегов определяемые пользователем» — еще один инструмент, который следует учитывать при разработке программного обеспечения ПЛК. UDT помогают группировать ключевые теги устройства или логической функции, что позволяет создавать шаблоны тегов.

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

Логическая структура программы

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

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

Комментарии как документация

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

Это не только помогает при диагностике, но и дает четкий путь к пониманию наилучшего подхода к будущим модификациям.

Управление изменениями. Ведение журнала изменений

Комментарии вне файла логики в специальном журнале изменений — это важный инструмент для понимания работы системы управления. Когда вносятся изменения, не всегда понимается, каким будет полный эффект от изменения.

Некоторые изменения могут включать ошибки логики, на создание которой ушли часы. Вот почему важно архивировать версии файла проекта, которые можно отслеживать с помощью списка внесенных изменений. Некоторые производители предоставляют программные утилиты для сравнения различий между файлами. Они могут быть очень полезны, но не отменяют необходимости в документе отслеживания изменений.

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