Как выбрать язык под конкретную задачу, почему один проект нормально сочетает несколько представлений логики и где заканчивается «просто написать код» и начинается полноценная инженерия АСУ ТП.

Введение: язык ПЛК - это инструмент, а не предмет веры

Когда инженеры спорят, что лучше - LD, FBD или ST, разговор иногда начинает напоминать дискуссию о любимой марке автомобиля. На практике вопрос решается проще: какой язык яснее описывает конкретный алгоритм, кто будет обслуживать систему и насколько быстро проект придется менять после запуска.

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

Ниже разберем основные языки программирования ПЛК, их реальное назначение, ограничения и особенности применения в CODESYS. Отдельно рассмотрим выбор языка для дискретной логики, аналоговой обработки, последовательных процессов, обмена данными и типовых задач АСУ ТП.

Что именно программируют в ПЛК

Программируемый логический контроллер получает сигналы от кнопок, датчиков, приводов и других устройств, обрабатывает их по заданному алгоритму и формирует команды исполнительным механизмам. В простом шкафу это может быть запуск вентилятора по сухому контакту. В крупной АСУ ТП - десятки контуров регулирования, сотни сигналов, межблокировки, архивы событий, обмен с SCADA и диагностика распределенного ввода-вывода.

В типовом проекте программа ПЛК решает несколько разных классов задач:

• Дискретная логика: пуск, останов, блокировки, разрешения, аварийные отключения технологического уровня.
• Обработка аналоговых сигналов: масштабирование, фильтрация, контроль диапазона, диагностика обрыва и недостоверности.
• Последовательное управление: шаги рецепта, мойка, дозирование, запуск линии, останов по заданному сценарию.
• Регулирование: ПИ/PID-контуры, ограничения, ручной и автоматический режимы, безударное переключение.
• Коммуникации: Modbus RTU/TCP, PROFINET, EtherCAT, OPC UA и другие протоколы.
• Диагностика и сервис: коды состояний, сообщения, счетчики наработки, журналирование, контроль времени цикла.

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

Как ПЛК выполняет программу: цикл, задачи и время реакции

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

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

Для инженерной оценки учитывают:

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

Поэтому «код работает в симуляторе» еще не означает, что система корректно отработает на реальном объекте. Симуляция проверяет алгоритм, а пусконаладка проверяет алгоритм вместе с оборудованием, сетью, помехами, механикой и технологией.

IEC 61131-3: современная нормативная основа

Языки программирования ПЛК стандартизированы международным документом IEC 61131-3. В актуальной четвертой редакции IEC 61131-3:2025 основными языками указаны текстовый Structured Text (ST) и графические Ladder Diagram (LD) и Function Block Diagram (FBD). Для организации последовательных алгоритмов определены элементы Sequential Function Chart (SFC).

В старых учебниках часто приводят формулу «пять языков IEC 61131-3»: LD, FBD, ST, SFC и Instruction List (IL). Исторически это было справедливо для предыдущих редакций стандарта. Сегодня IL следует рассматривать как наследуемый язык для поддержки старых проектов. В CODESYS редактор IL может быть доступен, но сам язык помечен как устаревший и не развивается.

На практике инженер по-прежнему встретит все перечисленные представления, а также расширения конкретных платформ. Поэтому важно различать три вещи: что определено стандартом, что поддерживается средой разработки и что допускает конкретный контроллер.

Сравнение языков и представлений программ ПЛК

LD - Ladder Diagram: релейная логика без шкафа из сотен реле

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

LD особенно удобен для:

• цепей пуска и останова;
• разрешений и технологических блокировок;
• режимов «Местный/Дистанционный» и «Ручной/Автоматический»;
• простых таймеров и счетчиков;
• поиска причины, почему команда не дошла до исполнительного механизма.

Главное преимущество LD проявляется в режиме онлайн: обслуживающий специалист видит, какое условие истинно, где «обрывается» логическая цепь и почему не включилась катушка. Для эксплуатации это часто важнее экономии нескольких строк кода.

Ограничение LD - склонность к разрастанию. Сложная математика, работа со строками, парсинг телеграмм, массивы и многоуровневые циклы в лестничной логике превращаются в графический лабиринт. Технически сделать можно почти все, но обслуживать такой проект будет неприятно.

Упрощенная LD-логика запуска и останова насоса

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

FBD - Function Block Diagram: поток сигналов между функциями

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

Типовые применения FBD:

• масштабирование 4-20 мА в инженерные единицы;
• фильтрация и ограничение сигнала;
• сравнение с уставками и формирование предупредительных порогов;
• ПИ/PID-регулирование;
• цепочки арифметических и логических преобразований;
• стандартные библиотечные блоки управления приводами и клапанами.

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

ST - Structured Text: компактный язык для сложных алгоритмов

Structured Text - текстовый язык высокого уровня. Синтаксис напоминает Pascal, но предназначен для промышленного управления: в нем используются типы данных, функции, функциональные блоки, условия, циклы, массивы, структуры и объектно-ориентированные возможности, поддерживаемые конкретной средой.

ST особенно эффективен там, где графические языки становятся громоздкими:

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

Упрощенный пример на ST

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

Для ST особенно важны единые правила оформления: именование переменных, форматирование, комментарии к интерфейсам блоков, запрет «магических чисел», контроль преобразований типов и ограничение вложенности условий.

SFC - Sequential Function Chart: шаги, переходы и технологические последовательности

SFC описывает процесс как набор шагов и переходов. Шаг соответствует состоянию системы или этапу операции, а переход определяет условие перехода к следующему состоянию. Такое представление особенно удобно для рецептурных и последовательных процессов.

Примеры:

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

SFC хорошо отвечает на вопрос «на каком шаге находится система и чего она ждет». Но условия разрешения, диагностику приводов и вычисления обычно удобнее реализовать в действиях или функциональных блоках на LD, FBD или ST. Поэтому SFC часто играет роль верхнего уровня - своеобразного диспетчера последовательности.

IL и CFC: что с ними делать в современных проектах

IL - язык наследуемых программ

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

При модернизации не всегда нужно немедленно переписывать рабочую IL-программу. Сначала оценивают документацию, риски остановки, доступность исходников и тестового стенда. Однако при глубокой реконструкции разумно планировать перенос логики на ST, LD или FBD с обязательной проверкой поведения.

CFC - свободная функциональная схема

Continuous Function Chart позволяет свободнее размещать блоки и задавать порядок выполнения. Такое представление удобно для технологических алгоритмов, но относится к расширениям среды разработки, а не к базовому набору IEC 61131-3. Поэтому перенос проекта между платформами может потребовать ручной переработки.

CODESYS: не только редактор кода

CODESYS Development System - интегрированная среда разработки для систем промышленного управления. Она реализует языки IEC 61131-3 и объединяет конфигурацию контроллера, редакторы программ, отладку, библиотеки, визуализацию, настройку сетей и управление проектом.

Типовой проект CODESYS включает:

• Дерево устройств: процессор, модули ввода-вывода, полевые шины и подключенные устройства.
• Application: программы, функции, функциональные блоки, глобальные переменные и типы данных.
• Task Configuration: циклические и событийные задачи, периоды и приоритеты.
• Libraries: готовые блоки, интерфейсы и повторно используемые компоненты.
• Visualization: экраны оператора, мнемосхемы, тренды и диагностические окна.
• Online tools: мониторинг переменных, forcing, трассировка, точки останова и диагностика.

Важное преимущество CODESYS - общая инженерная платформа для контроллеров разных производителей. Но это не означает автоматическую переносимость любого проекта «одной кнопкой». Аппаратные адреса, библиотеки, драйверы, задачи, особенности runtime и настройки полевой сети могут быть привязаны к конкретному устройству.

Хорошо спроектированная программа уменьшает эту зависимость: технологическая логика отделяется от аппаратного слоя, работа с входами-выходами выполняется через интерфейсные переменные, а специфические функции контроллера локализуются в отдельных модулях.

Один проект - несколько языков: нормальная инженерная практика

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

Например, для насосной станции можно использовать:

• LD - для цепочек разрешения, ручного управления и наглядных блокировок.
• FBD - для масштабирования давления, фильтрации, уставок и PID-регулятора.
• ST - для выбора рабочего насоса, чередования агрегатов, подсчета наработки и обмена Modbus.
• SFC - для автоматического сценария заполнения, промывки или последовательного запуска оборудования.

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

Как выбрать язык программирования ПЛК

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

Инженеры ИК «ЭЛТЕКО» рекомендуют заранее согласовывать с заказчиком не только марку ПЛК, но и требования к исходному коду: допустимые языки, структуру проекта, правила именования, объем комментариев, формат резервной копии и перечень передаваемой документации. Это снимает половину споров еще до начала программирования.

Практический пример: управление насосом по уровню

Рассмотрим простую задачу: насос должен включаться по нижнему уровню и отключаться по верхнему. Даже такой алгоритм быстро перестает быть «двумя контактами», если добавить реальные требования: ручной режим, обратную связь контактора, защиту двигателя, задержку повторного пуска, аварию датчика и передачу состояния на HMI.

Минимальный состав сигналов

• LevelLow и LevelHigh - дискретные датчики уровня либо вычисленные признаки аналогового уровнемера;
• AutoMode и ManualMode - выбранный режим;
• StartManual и StopManual - команды оператора;
• Permissive - сводное разрешение;
• MotorRunning - обратная связь работы;
• MotorFault - авария защиты или привода;
• PumpCmd - команда ПЛК;
• StartTimeout - контроль неподтвержденного пуска.

Разумное распределение по языкам

В LD удобно показать разрешения и ручные команды. В ST - защелку автоматической команды, выбор режима и таймауты. В FBD - обработку аналогового уровнемера и гистерезис. Если насос участвует в многошаговой промывке, верхний сценарий можно оформить в SFC.

Такой подход дает два преимущества: логика остается читаемой, а каждый участок можно тестировать отдельно. При неисправности инженер видит не просто «насос не включился», а конкретную причину: нет разрешения, выбран ручной режим, активна авария двигателя, не подтвержден пуск или недостоверен уровень.

Архитектура программы: что важнее выбранного языка

Язык влияет на форму записи, но качество системы определяет архитектура. Плохо организованный проект останется сложным и на LD, и на ST. Для промышленной программы полезны следующие принципы:

• Разделяйте команды и состояния. Команда «запустить» не равна признаку «работает».
• Используйте функциональные блоки для типовых механизмов: насос, вентилятор, клапан, привод, аналоговый канал.
• Не записывайте одну переменную из разных мест без формального арбитража.
• Храните физические входы и выходы в отдельном слое привязки, а технологию программируйте через именованные сигналы.
• Формируйте диагностический код состояния и отдельные причины блокировки.
• Определяйте безопасное состояние при потере связи и недостоверности данных.
• Версионируйте проект, сохраняйте библиотечные зависимости и делайте проверяемые архивы.
• Документируйте интерфейс блока: входы, выходы, режимы, приоритеты команд и поведение после перезапуска.

Типовая структура функционального блока механизма

Типичные ошибки при программировании ПЛК

1. Весь проект находится в одной программе. Сначала это кажется простым, затем любое изменение затрагивает десятки неочевидных связей.
2. Один и тот же выход управляется из нескольких мест. Результат зависит от порядка выполнения, а поиск причины превращается в чтение всего проекта.
3. Нет разделения между автоматическим, ручным и дистанционным управлением. Команды начинают конфликтовать, а приоритеты остаются «в голове разработчика».
4. Аналоговый сигнал используется без диагностики. Значение при обрыве кабеля может выглядеть как реальный технологический параметр.
5. Таймер заменяет понимание процесса. Задержки добавляются до тех пор, пока система «примерно работает», но при изменении механики алгоритм рассыпается.
6. Не учитывается время цикла и асинхронность сетевого обмена. Логика ожидает мгновенного ответа от устройства, которое обновляет данные раз в несколько сотен миллисекунд.
7. Используются «магические числа». Уставка 27648, коэффициент 0.0030518 и таймаут 13750 мс появляются без имен и пояснений.
8. Нет сценария восстановления после пропадания питания. Не определено, какие переменные сохраняются, какие сбрасываются и можно ли автоматически возобновлять процесс.
9. Программа не передается заказчику в пригодном виде. Отсутствуют архив, версия среды, библиотеки, пароли, описание изменений и инструкция по восстановлению.

Функциональная безопасность: обычный ПЛК не заменяет safety-систему

В исходных учебных примерах часто встречается управление прессом двумя кнопками. Такой пример хорошо объясняет логику AND и таймер, но опасен как готовое техническое решение. Двуручное управление относится к функциям безопасности и проектируется с учетом оценки риска, требований к отказоустойчивости, контролю одновременности, отпусканию кнопок и предотвращению обхода защиты.

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

Тестирование и пусконаладка программы ПЛК

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

Рекомендуемая последовательность

1. Проверить структуру проекта, типы данных, предупреждения компилятора и правила именования.
2. Протестировать функциональные блоки на типовых и граничных значениях.
3. Проверить режимы запуска, останова, сброса и восстановления после перезапуска.
4. Смоделировать отказ датчика, потерю связи, зависание привода и отсутствие обратной связи.
5. Проверить приоритет ручных, автоматических и дистанционных команд.
6. Измерить время задач и убедиться в наличии резерва производительности.
7. Провести стендовое тестирование с HMI/SCADA и сетевыми устройствами.
8. На объекте выполнить поэтапную проверку входов-выходов, направлений вращения, блокировок и аварий.
9. Зафиксировать версию проекта, создать архив и оформить протокол испытаний.

Для крупных систем полезны чек-листы FAT и SAT, таблицы проверки сигналов, сценарии аварий и журнал замечаний. Это звучит менее романтично, чем «загрузили программу и все заработало», зато заметно сокращает количество ночных звонков после сдачи объекта.

Что передать заказчику вместе с программой

• архив проекта с указанием версии CODESYS и target-пакета контроллера;
• использованные библиотеки и сведения об их версиях;
• резервную копию параметров приводов, удаленных модулей и сетевых устройств;
• таблицу сигналов и карту адресов;
• описание алгоритма, режимов и блокировок;
• перечень аварий и сообщений;
• руководство оператора и инструкцию по восстановлению;
• протокол FAT/SAT или функциональных испытаний;
• журнал версий и перечень изменений;
• данные доступа и порядок их безопасной передачи.

Частые вопросы

Какой язык ПЛК проще для начинающего?

Для электрика обычно проще LD, потому что он похож на релейную схему. Для человека с опытом программирования быстрее осваивается ST. Но начинать лучше не с синтаксиса, а с понимания цикла ПЛК, типов сигналов, блокировок и поведения оборудования.

Можно ли написать весь проект на ST?

Можно. Вопрос в том, будет ли это удобно обслуживать. Для вычислений и библиотек ST отлично подходит, но дискретные цепочки разрешений иногда быстрее диагностируются в LD. Решение зависит от объекта и команды эксплуатации.

FBD и CFC - это одно и то же?

Нет. FBD является стандартизированным графическим языком. CFC - расширенное представление со свободным размещением блоков и дополнительными возможностями порядка выполнения. Реализация CFC зависит от среды разработки.

Почему IL встречается в старых проектах?

Ранее IL входил в стандартный набор языков и был удобен для контроллеров с ограниченными ресурсами. Сегодня его сохраняют главным образом ради совместимости с наследуемыми программами.

Подходит ли CODESYS для контроллеров разных производителей?

Да, CODESYS используется как общая платформа для многих устройств. Но переносимость зависит от hardware-конфигурации, библиотек, runtime и используемых расширений. Технологическую логику переносить проще, если она отделена от аппаратного слоя.

Нужно ли отдавать заказчику исходный код?

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

Вывод

LD, FBD, ST и SFC не конкурируют за звание единственно правильного языка. Они описывают разные стороны одной системы управления. LD удобен для дискретной логики и диагностики, FBD - для потоков сигналов и регулирования, ST - для данных и сложных алгоритмов, SFC - для последовательностей и состояний.

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

ИК «ЭЛТЕКО» выполняет разработку программ ПЛК, HMI и SCADA, интеграцию оборудования, стендовые испытания и пусконаладочные работы. Для предварительной оценки проекта подготовьте техническое задание, перечень сигналов, описание алгоритма, схемы подключения и требования к используемому контроллеру.

Нормативная и справочная база

• IEC 61131-3:2025 - Programmable controllers. Part 3: Programming languages
• ISO 13851:2019 - Safety of machinery. Two-hand control devices
• CODESYS Development System - официальное описание среды и поддерживаемых языков
• CODESYS Safety - решения для функциональной безопасности