LD, FBD, SFC, ST и наследуемый IL — не конкуренты за звание «самого правильного» языка. Это разные способы сделать алгоритм понятным, проверяемым и удобным в эксплуатации. Разбираемся, что выбирать для блокировок, ПИД-контуров, рецептур, расчётов и сложных АСУ ТП.

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

Почему выбор языка ПЛК — это не вопрос вкуса

В промышленной автоматизации код редко живёт в одиночестве. Сначала его пишет программист, затем проверяет инженер ПНР, после запуска к нему возвращаются технолог, сервисная служба и дежурная смена. Через год в проект приходит другой специалист и пытается за десять минут понять, почему насос не запускается, заслонка не открывается, а линия стоит с сообщением «нет готовности».

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

Поэтому выбирать нужно не «язык для всего проекта», а форму представления для каждой инженерной задачи. Релейные разрешения удобно видеть как цепь. Аналоговый сигнал — как поток преобразований. Стадийный процесс — как последовательность шагов. Массивы, циклы и обмен структурами — как текстовый алгоритм. Это и есть практический смысл IEC 61131-3.

Что изменилось в актуальной редакции IEC 61131-3

В инженерной литературе и старых средах разработки часто говорят о «пяти языках IEC 61131-3»: LD, FBD, SFC, ST и IL. Такая классификация полезна для практики и сопровождения установленной базы, но требует уточнения.

Для инженера вывод простой: старый проект на IL не перестаёт существовать из-за новой редакции стандарта, но новый проект лучше строить на читаемых и поддерживаемых средствах — ST, LD, FBD и, где доступно в конкретной среде, SFC. При этом реализация и набор поддерживаемых возможностей зависят от производителя ПЛК и среды программирования.

Критерии выбора: что важнее красивой схемы

Перед тем как открыть редактор и начать расставлять контакты или писать CASE, полезно ответить на пять вопросов:

1. Кто будет диагностировать этот участок логики на объекте: программист, наладчик, электрик или технолог?

2. Как выглядит сама задача: цепочка разрешений, поток данных, последовательность стадий или вычислительный алгоритм?

3. Нужно ли видеть текущее состояние онлайн на одном экране?

4. Будет ли модуль многократно использоваться в других проектах и на других объектах?

5. Как алгоритм должен вести себя при старте, перезапуске, потере связи, недостоверном датчике и ручном режиме?

Если на эти вопросы нет ответа, выбор языка превращается в привычку. А привычка — плохой архитектор: она уверенно строит одинаковые решения для совершенно разных задач.

LD: когда логику нужно читать как электрическую схему

Ladder Diagram, или лестничная диаграмма, ближе всего к релейно-контактной логике. Контакты, катушки, самоподхваты, разрешения и межблокировки воспринимаются привычно для электрика и инженера ПНР. В онлайн-режиме хорошо видно, по какой ветви «идёт питание» и на каком условии цепь разорвалась.

Где LD особенно уместен

· Разрешение пуска: автоматический режим, готовность привода, открытая задвижка, отсутствие аварии и активная команда.

· Межблокировки: запрет одновременного включения двух контакторов, вводов, направлений вращения или взаимоисключающих механизмов.

· Сигнализация и квитирование: простые условия формирования, удержания и сброса сообщений.

· Дискретная обвязка: концевики, кнопки, сухие контакты, состояния автоматов и контакторов.

· Локальная диагностика: когда состояние реального входа нужно быстро сопоставить с клеммой и цепью на электрической схеме.

Где LD начинает мешать

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

FBD: когда сигнал проходит через цепочку преобразований

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

Где FBD работает особенно хорошо

· Аналоговые каналы: масштабирование 4–20 мА, фильтрация, контроль диапазона, замещение недостоверного значения.

· ПИД- и ПИ-регулирование: уставка, обратная связь, ограничения, ручной режим, anti-windup и плавное переключение режимов.

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

· Обработка сигналов: средние значения, гистерезисы, детекторы фронта, таймеры, селекторы, сумматоры и лимитеры.

· Наглядная проверка динамики: рядом с трактом удобно выводить тренды и контрольные точки.

Главная опасность FBD — «паутинный синдром». Если на одном листе десятки блоков, линии пересекаются, а сигнал путешествует через скрытые коннекторы, визуальный язык теряет главное преимущество. Спасают декомпозиция, однонаправленный поток слева направо, короткие сети и типовые блоки с понятными интерфейсами.

SFC: когда процесс живёт по стадиям

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

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

Сильные стороны SFC

· Прозрачная пусконаладка: видны активный шаг и условие, которое мешает переходу.

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

· Тайм-ауты стадий: каждый шаг получает допустимое время выполнения и понятную аварию при превышении.

· Ручной пошаговый режим: удобен для наладки, обучения и локализации «зависшего» условия.

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

SFC не должен хранить внутри себя всю логику установки. Он задаёт скелет: какой шаг активен и какие действия требуются. Межблокировки механизмов лучше оставить в LD/FBD, а расчёты доз, компенсаций и таблиц — в ST. Иначе граф быстро обрастает условиями и становится таким же трудным, как плохо организованная лестница.

ST: когда нужно считать, перебирать и работать со структурами

Structured Text близок к классическим языкам программирования высокого уровня. Он хорошо выражает ветвления, циклы, CASE-автоматы, работу с массивами, структурами, строками, таблицами параметров и протоколами обмена. То, что в графическом редакторе заняло бы несколько экранов, в ST часто помещается в компактный и тестируемый модуль.

Где ST обычно выигрывает

· Расчётные ядра: формулы, компенсации, интерполяция, нормализация и сложные ограничения.

· Массивы и однотипные каналы: обработка десятков датчиков, приводов, сообщений или рецептов в цикле.

· Протоколы и структуры данных: подготовка пакетов, разбор регистров, контроль последовательности и качества обмена.

· Рецептурные таблицы и архивы: копирование, сравнение, валидация, версии и контроль диапазонов.

· Повторно используемые библиотеки: функции и FB с чётким контрактом, которые удобно тестировать и версионировать.

Но компактность сама по себе не гарантирует качество. Пятьдесят строк с вложенными IF, неочевидными побочными эффектами и переменными x1, x2, flag3 читаются хуже, чем аккуратный FBD. ST требует дисциплины: коротких функций, понятных имён, явных типов, ограниченной вложенности и отделения вычислений от управления оборудованием.

IL: язык, который важно уметь читать, но не обязательно выбирать

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

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

Практическая матрица выбора языка

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

Почему гибридный проект обычно лучше «монокультуры»

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

Гибридная архитектура не означает хаотичное смешивание. Наоборот, она требует чётких границ:

· SFC или автомат состояний: верхний уровень процесса — режимы, стадии и переходы.

· LD: разрешения, блокировки, дискретная обвязка и быстро читаемая диагностика.

· FBD: аналоговые тракты, регуляторы и библиотечные технологические блоки.

· ST: расчёты, структуры, таблицы, коммуникации и сервисные функции.

· HMI/SCADA: представление состояния, причин запрета, трендов и действий оператора без дублирования логики ПЛК.

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

Четыре практических примера выбора

Пример 1. Насосная станция

Для каждого насоса удобно создать типовой функциональный блок. В LD формируются разрешения: уровень, положение арматуры, готовность ПЧ, отсутствие сухого хода и аварии. В FBD обрабатывается давление и работает ПИ-регулятор. В ST можно реализовать ротацию насосов по наработке, выбор рабочего и резервного агрегата, расчёт часов и сервисных интервалов. Верхний автомат состояний управляет режимами «Стоп», «Авто», «Промывка», «Авария».

Пример 2. Приточно-вытяжная вентиляция

Последовательность пуска — заслонки, подтверждение положения, запуск вентилятора, контроль перепада, разрешение нагревателя — удобно описывать SFC или автоматом состояний. Логику защит нагревателя и вентиляторов лучше сделать в LD/FBD, чтобы она была прозрачна на ПНР. ПИД температуры и давления естественно собрать в FBD. Расчёт плавающей уставки, компенсации по наружной температуре и расписания — в ST.

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

Пример 3. Дозирование и рецептурное производство

SFC задаёт стадии: подготовка, тара, грубая подача, точная подача, стабилизация, выгрузка. ST рассчитывает упреждение отключения, коррекцию по истории, допуски и работу с рецептами. FBD обрабатывает сигнал весов и контролирует стабильность. LD отвечает за концевики, разрешения шнеков, затворов и аспирации. Такая декомпозиция позволяет технологу видеть процесс, а программисту — развивать расчётную часть без переделки всей последовательности.

Пример 4. Шкаф управления с Modbus и архивом

Обмен с приборами разумно вынести в адаптеры на ST: чтение регистров, контроль тайм-аутов, преобразование типов, проверка диапазонов и формирование кода качества. Основная логика получает уже нормализованные данные и не знает деталей протокола. В FBD можно построить тракт измерения, а в LD — разрешения пуска по состоянию прибора. Потеря связи при этом не «роняет» весь алгоритм, а переводит конкретный канал в заранее определённое безопасное состояние.

Как собрать устойчивую архитектуру POU

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

1. Разделяйте уровни ответственности

· Функция выполняет вычисление без скрытого состояния, если это возможно.

· Функциональный блок хранит состояние конкретного механизма или технологического узла.

· Программа координирует крупные подсистемы, но не дублирует их внутренние защиты.

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

· HMI отображает и задаёт команды, но критическая логика остаётся в ПЛК.

2. Формализуйте интерфейсы

Для входов и выходов указывают тип, единицы измерения, допустимый диапазон, поведение при недостоверности, значение при инициализации и назначение. Булевый вход xEnable без пояснения может означать разрешение, команду, выбор режима или обход защиты. Через полгода это четыре разных ошибки под одним именем.

3. Создавайте библиотеку типовых блоков

Повторно используемые блоки насосов, клапанов, приводов, аналоговых каналов, ПИД-контуров и аварий уменьшают копирование и ускоряют ПНР. Библиотека должна иметь версии, журнал изменений и правила совместимости. Изменение типового FB без контроля версии способно улучшить один объект и одновременно удивить пять уже работающих.

4. Договоритесь о код-стайле

Единый стиль имён, типов, комментариев, перечислений состояний и кодов ошибок важнее личных предпочтений. Особенно полезны понятные имена шагов SFC, ограничение вложенности в ST, направление потока в FBD и единый шаблон диагностических выходов для LD/FB.

Диагностика и тестирование: код должен объяснять своё поведение

Самая полезная диагностика отвечает не на вопрос «что сейчас выключено?», а на вопрос «почему ожидаемое действие не произошло?». Для этого у каждого крупного POU должны быть не только биты Ready и Fault, но и состояние, код причины запрета, таймер ожидания и данные, которые помогают восстановить цепочку событий.

Для LD и FBD

· Предусматривайте режим имитации входов с явным признаком SIMULATION.

· Выводите ключевые промежуточные сигналы на HMI или тренды, а не только конечную команду.

· Формируйте отдельные диагностические признаки для каждого блокирующего условия.

· Не прячьте важную логику в неименованных коннекторах и длинных цепочках перекрёстных ссылок.

Для ST

· Проверяйте граничные значения, ноль, переполнение, недостоверные числа и потерю связи.

· Создавайте эталонные наборы входов и ожидаемых выходов для регрессионных тестов.

· Логируйте смену состояний и ключевые причины переходов.

· Не используйте «магические числа»: параметры и пределы должны иметь имена и единицы измерения.

Для SFC и автоматов состояний

· Каждый переход получает диагностируемое условие.

· Каждый шаг — тайм-аут и реакцию на превышение времени.

· Предусматриваются пошаговый режим и безопасная остановка.

· После перезапуска ПЛК поведение определяется явно: возврат в INIT, восстановление стадии или управляемое завершение.

Цикл ПЛК, задачи и производительность

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

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

· Основной цикл: управление механизмами, режимами и большей частью технологической логики.

· Медленные задачи: архив, отчёты, сложная статистика, обслуживание интерфейсов и некритичный обмен.

· ПИД-контуры: фиксированный и известный период дискретизации, согласованный с динамикой объекта и настройками регулятора.

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

Типичные ошибки при выборе и смешивании языков

Ошибка 1. Весь проект на любимом языке

ST превращает простые блокировки в текст, который сложнее трассировать электрику. LD превращает массивы и расчёты в километры сетей. FBD превращается в паутину, а SFC — в хранилище всех условий мира. Лекарство одно: выбирать язык по природе задачи.

Ошибка 2. Смешивание без границ

Команда формируется в SFC, корректируется в ST, дополнительно блокируется в LD и ещё раз переписывается на HMI. В итоге никто не знает, какой слой главный. Для каждого выхода и состояния должен быть один владелец, а остальные слои передают только запросы и условия.

Ошибка 3. Диагностика добавляется после ПНР

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

Ошибка 4. Ручной режим отменяет защиты

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

Ошибка 5. Копирование блоков вместо библиотеки

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

Инженерный чек-лист перед началом программирования

1. Разделите технологию на режимы, стадии, механизмы, измерения и сервисные подсистемы.

2. Для каждой части определите главного пользователя диагностики: оператор, электрик, наладчик или программист.

3. Выберите форму представления: цепочка условий — LD; поток сигналов — FBD; стадии — SFC; данные и вычисления — ST.

4. Зафиксируйте владельца каждой физической команды и каждого состояния.

5. Опишите интерфейсы POU: типы, единицы, диапазоны, инициализация, реакция на недостоверность и потерю связи.

6. Заложите коды состояния, причины запрета, тайм-ауты и диагностические сообщения до написания основной логики.

7. Разделите быстрые, основные и медленные задачи контроллера.

8. Создайте сценарии FAT/SAT: нормальный запуск, отказ датчика, потеря связи, перезапуск, ручной режим, аварийная остановка и восстановление.

9. Проведите ревью с участием того, кто будет обслуживать систему на объекте.

10. Сохраните версию библиотек, прошивки, среды разработки и резервную копию исходного проекта.

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

Можно ли использовать несколько языков в одном проекте?

Да. Для крупных АСУ ТП это обычно наиболее рациональный подход. Важно не количество языков, а чёткие границы между POU, единые правила именования и отсутствие конкурирующей записи одних и тех же команд.

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

Электрику часто проще начать с LD, потому что он похож на релейную схему. Инженеру с опытом обычного программирования — со ST. Но профессиональная работа требует понимать минимум LD, FBD и ST, а для стадийных процессов — принципы SFC или эквивалентной машины состояний.

ST всегда быстрее графических языков?

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

Что лучше для аварийных остановов и функций безопасности?

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

Нужно ли переписывать старый IL-проект?

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

Вывод: язык ПЛК выбирают ради эксплуатации, а не ради красоты редактора

IEC 61131-3 ценен не тем, что предлагает несколько способов написать одну и ту же логику. Его практическая сила — в возможности подобрать представление под задачу и собрать проект, который остаётся понятным после монтажа, ПНР и передачи в эксплуатацию.

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

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