Введение
Некоторое время в мире автоматики и ПЛК царил «Вавилон». Каждый крупный производитель создавал собственные «диалекты». Инженер, владеющий языком одной платформы, оказывался почти беспомощным перед оборудованием конкурента. Это замедляло внедрение новых решений, делало обучение специалистов дорогим и привязывало заводы к одному бренду на десятилетия. Ситуация начала меняться с принятием стандарта IEC 61131-3, который стал попыткой создать единый «протокол общения» между инженерами и машинами.
Но и сейчас технологии не стоят на месте. Стандарт эволюционирует, и совсем недавно, в мае 2025 года, появилась уже 4я редакции IEC 61131-3.
В этой статье мы не станем просто пересказывать документацию. И типичным описанием языков в две строчки тоже не ограничимся. Наша цель — составить карту современного ландшафта языков программирования ПЛК.
Мы разберемся, зачем нужны пять языков стандарта, почему STL – это не то же самое, что ST, зачем разработчики внедряют Python и как объектно-ориентированное программирование меняет подход к написанию кода для АСУ.
Пристегнитесь, мы отправляемся в путешествие от релейных схем 70-х до современных гибридных архитектур Industry 4.0!
Историческая справка: от релейных шкафов к первым стандартам
Чтобы понять, почему современные языки ПЛК выглядят именно так, нужно вернуться во времена, когда автоматизация была физическим, а не программным процессом. Об этом у нас уже есть отдельная статья, но вкратце пробежимся по основным вехам.
До ПЛК. Эпоха железной логики
До конца 60-х годов управление промышленными станками и конвейерами осуществлялось с помощью релейно-контактной логики. Это были громоздкие шкафы, наполненные сотнями электромеханических реле, таймеров, счетчиков и километрами проводов.
Логика работы задавалась схемой соединений: чтобы изменить алгоритм работы станка, инженеру нужно было физически переключить провода. Это была «аппаратная» реализация алгоритмов. Если технология производства менялась (а например, в автопроме это происходило довольно часто), перенастройка линии занимала недели, а стоимость модификации шкафа управления была сопоставима со стоимостью самого оборудования.
Плюс, не говоря уже о каких-то поломках и авариях, каждое реле имеет ограниченный ресурс срабатываний, и это требовало постоянного обслуживания, а для поиска неисправности нужно было прозвонить сотни точек.
Рождение концепции: техзадание от General Motors (1968)
Переломный момент наступил в мае 1968 года. Инженеры подразделения Hydramatic компании General Motors (GM далее) в рамках машиностроительного форума в Филадельфии представили конкретные требования к новому типу устройств, вот некоторые из них:
- устройство должно иметь модульную конструкцию и работать в тяжёлых условиях цеха: при вибрации, запылённости, повышенной влажности и электромагнитных помехах;
- контроллер должен иметь дискретные и аналоговые входы и выходы для управления разными устройствами, иметь возможность расширения их количества;
- программа должна легко изменяться без физической перекоммутации всей схемы;
- данные должны сохраняться в памяти не менее 12 часов при полном отключении питания и так далее.
Выступление GM стало фактическим техзаданием для всего рынка. Именно под эти требования в 1969 году компания Bedford Associates (впоследствии Modicon) выпустила контроллер Modicon 084, который не только решил задачи GM, но и заложил архитектурные принципы, используемые в ПЛК до сих пор.
Modicon 084 и рождение Ladder Diagram (LD)
Итак, Modicon 084 был первым коммерческий ПЛК, но в рамках данной статьи нас интересует не «железо», а способ взаимодействия с ним. Разработчики понимали: если они дадут инженерам-электрикам язык программирования наподобие Fortran или Assembler, те просто не смогут им пользоваться без должного обучения.
Так родился Ladder Diagram (LD) — язык релейно-контактных схем.
Идея была в том, чтобы визуально имитировать электрическую схему, но вместо физических контактов и катушек использовать виртуальные программируемые элементы. Электрики могли на экране (или даже на распечатке) читать программу так же, как они читали чертежи релейных шкафов. Для работы требовалось минимальное переобучение. Гораздо сложнее было объяснить людям, что ПЛК – это штука надежная и ей можно доверять 😊
Предпосылки к созданию IEC 61131-3
Успех Modicon 084 вызвал бум на рынке. В 70-х и 80-х годах множество производителей занялись разработкой своих ПЛК: Allen-Bradley (США), Siemens (Германия), Mitsubishi (Япония), Telemecanique (Франция).
Однако единого стандарта не было. Началась эпоха фрагментации.
Американские компании, вроде Allen-Bradley, сделали ставку на развитие LD. Они добавили в него функции таймеров и счетчиков, но база в целом оставалась чисто на релейной логике.
Siemens и другие европейские производители столкнулись с более сложными физическими задачами (нефтехимия, непрерывные производства). А LD в принципе не был предназначен для математических вычислений. Поэтому в Европе начали активно развивать текстовые языки, такие как Statement List (STL) — низкоуровневый язык, похожий на Assembler, GRAFCET (будущий SFC) – язык функционального описания алгоритмов работы последовательных систем управления и Function Block Diagram (FBD) — блочное программирование.
Была разница и в том, каких специалистов привлекали: бывшие электрики и слаботочники, инженеры по автоматизации или системные программисты.
И тут возникла проблема: код, написанный для ПЛК Siemens, не мог работать на ПЛК Allen-Bradley. Инженеры оказывались привязаны к бренду. Обучение новому оборудованию занимало время.
К концу 80-х годов стало очевидно, что индустрии нужен единый стандарт программирования ПЛК.
Рынок требовал:
- единой терминологии и стандартов проектирования;
- стандартизации структуры самой программы;
- единых требований для всех производителей, чтобы объекты можно было бы переносить с одного вендора на другой с минимальными потерями;
- твердой базы для подготовки кадров по всему миру.
В 1979 году технический комитет IEC в сфере автоматизации начал работу над стандартом. К 1982 году была закончена работа над черновиками и произошло разделение на 5 рабочих групп. Одна из них занялась как раз программированием и языками. В работе участвовали эксперты от ведущих производителей и институтов. За основу были взяты лучшие практики уже существующих языков и национальные стандарты: DIN 19239, DIN 40719-6, руководство VDI 2880 (лист 4), стандарт GRAFCET (IEC 60848), NEMA ICS 3-304 и др. Это была командная работа: стандарт должен был задать общий вектор развития, а не убить все наработки.
Результатом стала публикация первой редакции IEC 1131-3 (тогда нумерация была без шестерки) в 1993 году, которая официально «узаконила» 5 языков программирования ПЛК: IL, LD, ST, SFC и FBD. Отдельная статья про стандарт скоро будет здесь.
В России международные стандарты (IEC, ISO) не просто переводятся, а официально принимаются как национальные стандарты (ГОСТ Р) через процедуру, регулируемую Росстандартом. Мы не смогли найти записи о ГОСТе, основанном на первой версии IEC 1131-3 1993 года. Вполне вероятно, что в 90е было не до этого. Первый официально зафиксированный в реестре вариант стандарта — ГОСТ Р МЭК 61131-3-2010 — появился уже после принятия второй редакции МЭК. Далее в 2016 появилась актуализированная версия ГОСТ Р МЭК 61131-3-2016. Она сейчас является действующей в РФ.
Пять языков ГОСТ Р МЭК 61131-3
Стандарт ГОСТ Р МЭК 61131-3 не навязывает какой-то конкретный язык для программирования ПЛК. Вместо этого он описывает несколько языков, объединенных единой моделью. Каждый из них эффективен в своей области. И современная практика автоматизации подразумевает осмысленную комбинацию их всех.
Давайте разберем каждый язык в отдельности.
Язык LD
Ladder diagram (LD, LAD) — язык релейной (лестничной) логики. Применяются также названия: язык релейно-контактной логики, релейные диаграммы, релейно-контактные схемы (РКС), язык программирования релейно-лестничной логики стандарта МЭК 61131-3.
Как уже было отмечено, это один из первых языков программирования ПЛК. Наибольшую популярность приобрел в Американских странах, а также в Японии. Синтаксис удобен для замены логических схем, выполненных на релейной технике. Ориентирован на инженеров КИП и электриков, работающих с производственными линиями, конвейерами.
Логические операции представляются как электрическая цепь с замкнутыми и разомкнутыми контактами. Наличие или отсутствие тока в этой цепи соответствует результату логической операции (истина — если ток течёт; ложь — если ток не течёт).
Основными элементами языка LD являются:
- Контакты. Их можно представить в виде пары контактов реле или кнопки. Отождествляются с логической переменной, а состояние контактов — со значением переменной (0 или 1).
Контакты могут быть соединены параллельно, тогда соединение передает состояние «логическое ИЛИ». Если контакты соединены последовательно, то соединение передаёт «логическое И». Контакт также может быть инвертированным. Тогда он передает состояние «ON», если значение переменной 0. - Катушки (обмотки, coil). Это целевая переменная, в которую записывается итог вычислений всей цепи.
- Функциональные блоки. Таймеры (TON, TOF, TP), счетчики (CTU, CTD, CTUD), триггеры, математические и строковые операции (в расширенных реализациях).
- Ветвление. Последовательное (AND), параллельное (OR), вложенные параллели, перемычки.
Преимущество LD в том, что в режиме онлайн или эмуляции среда разработки подсвечивает «поток питания» отличающимся цветом. Инженер мгновенно видит, где обрывается логика, без необходимости расставлять точки останова и вчитываться в код.
Но когда дело касается других типов переменных, кроме булевых, программа на LD перестает быть похожа на себя. Для реализации функций таймеров, счетчиков, тригеров, математики и других операций в этом языке используются вставки на других языках, например блоки FBD или какой-то единый блок «OPERATE», внутри которого функционал может быть описан на ST.
Поэтому конкретные версии языка реализуются обычно в рамках программных продуктов для работы с определёнными типами ПЛК, так как такие реализации содержат команды, расширяющие стандартные команды языка. Это вызвано желанием производителя полнее учесть требования заказчика, но в то же время приводит к несовместимости программ, созданных для контроллеров разных марок. Несмотря на это, LD до сих пор широко применяется в ПЛК и имеет свои поклонников.
Язык IL (исключен из стандарта в 2025 г.)
Instruction List (IL, список инструкций) — это низкоуровневый текстовый язык, напоминающий машинный код. Программа представляет собой последовательность инструкций, каждая из которых выполняет элементарную операцию: загрузить значение, выполнить логическую операцию, сохранить результат.
IL был создан в эпоху, когда ресурсы контроллеров (память, процессор) были крайне ограничены. В то же время, он позволял писать максимально плотный и эффективный код в противовес LD. Был введен в стандарт как результат наработок европейский производителей, прообразом IL стал сименсовский STL (AWL).
Основа IL — это переходы по меткам и понятие «аккумулятор».
Аккумулятор в IL — это универсальный контейнер для временного хранения данных, способный сохранять значения переменных любого типа. Большинство инструкций языка выполняют действия с содержимым аккумулятора: загружают в него значения, извлекают значение и совершают над ним операции, а затем результат может быть сохранён в переменной или использован иным образом.
Переходы по меткам используются для изменения порядка выполнения программы и организации циклов. Например, оператор JMP выполняет безусловный переход к указанной метке, а JMPC — условный переход, который выполняется только при значении аккумулятора, равном TRUE.
На рисунке ниже приведён пример программы на языке IL, которая эквивалентна следующему логическому выражению: C = A AND NOT B
Первый оператор примера LD помещает значение переменной A в аккумулятор. Второй оператор ANDN выполняет «побитовое И» аккумулятора и обратного значения операнда, результат помещается в аккумулятор. Последний оператор примера, ST, присваивает переменной C значение аккумулятора.
Как видите, понять логику без комментариев и глубокого погружения крайне сложно. Кроме того, порог входа для инженеров достаточно высок - требует понимания архитектуры процессора и низкоуровневых команд. Вместо того, чтобы думать над тем, как будет происходить техпроцесс, нужно думать о каждом бите информации.
Сейчас во всех этих сложностях нет необходимости. Рынок сам выбрал более удобные и функциональные языки. Именно поэтому с 2025 года язык IL исключен из стандарта IEC 61131-3 и поддерживается некоторыми производителями исключительно ради старых объектов. Современные ПЛК обладают достаточной мощностью, чтобы выполнять более «выразительные» языки (ST, FBD) без потери производительности. А разработка, тестирование и отладка кода на IL занимает больше времени в сравнении с другими. Именно поэтому индустрия и сместила фокус с экономии каждого байта на снижение стоимости владения кодом.
Легко поддерживаемый код гораздо важнее супер-оптимизированного.
Язык SFC
Sequential Function Chart (SFC, последовательные функциональные схемы) — это графический язык, визуально похожий на блок-схемы. Его прообразом стал французский GRAFCET и теория сетей Петри.
В основе SFC лежит концепция конечного автомата: программа разбивается на шаги, между которыми существуют переходы. Система всегда находится в каком-то состоянии (Шаге) и ждет выполнения условия для перехода в следующее состояние.
Этот язык ближе всего к технологам и инженерам-механикам, так как он визуально описывает цикл работы машины: Загрузка — Нагрев — Ожидание — Выгрузка — Сброс.
Основными элементами языка являются:
- Начальный шаг. Любая SFC диаграмма должна содержать начальный шаг (шаг, выделенный двойной рамкой). Это точка входа в программу при запуске ПЛК, с нее начинается выполнение диаграммы.
- Шаг. Наиболее важный элемент языка SFC, описывает одну операцию. Шаг изображается в виде прямоугольника с собственным именем внутри
- Переход. Горизонтальная линия на вертикальной связи, условие перехода между шагами. Это может быть логическая переменная или константа, логический адрес или логическое выражение, описанное на любом языке. Условие может включать серию инструкций, образующих логический результат.
- Действие. Прямоугольник, соединённый горизонтально с шагом. Это операции, выполняемые в активном шаге. Каждый шаг имеет нулевое или большее количеством действий, объединённых, как правило, на диаграмме, в блок действий.
- Прыжок. Шаг может быть также заменён «прыжком». Последовательности шагов всегда ассоциируются с прыжком к другому шагу той же самой последовательности шагов. Это означает, что они выполняются циклически. Переход на произвольный шаг – это соединение на шаг, имя которого указано под знаком «прыжка». Такие переходы нужны для того, чтобы избежать пересекающихся и идущих вверх соединений.
- Дивергенция – это множественное соединение в направлении от одного шага к нескольким переходам. Активируется только одна из ветвей. Условия, связанные с различными переходами в начале дивергенции, не являются взаимоисключающими по умолчанию. Взаимоисключение должно быть явно задано в условиях переходов, чтобы гарантировать, что во время выполнения программы активируется одна конкретная ветвь.
- Конвергенция – это множественное соединение, направленное от нескольких переходов к одному и тому же шагу. Она обычно используется для группировки ветвей SFC – программы, которые берут начало из одинарной дивергенции.
Сейчас этот язык используется очень редко и возможно будет исключен из стандарта, как и IL через некоторое время.
Язык FBD
Function Block Diagram (FBD) — это графический язык, представляющий собой список цепей функциональных блоков, соединенных между собой линиями связи. Если в LD мы видим, как «течет ток», то в FBD – как «текут данные».
Основной элемент FBD — это блок. Он представляет собой некий «черный ящик» - фрагмент кода, который выполняет конкретную операцию. Это может быть оператор, программа, функция или функциональный блок. Этот язык — буквально графическое воплощение архитектуры программы согласно стандарту МЭК 61131-3. Блоки могут быть стандартные, библиотечные и пользовательские, которые также пишутся на FBD или других языках МЭК 61131-3.
Каждый блок обычно имеет входы и выходы. На входы приходят данные (числа или логические значения, например), и блок обрабатывает эти данные по своему алгоритму. Результаты вычисления передаются на выходы. Таким образом данные перетекают от входов в блок, там обрабатываются и подаются на выход.
Один или несколько связанных друг с другом функциональных блоков образуют цепь. Программа состоит из списка таких цепей и выполняется в строго организованном порядке. Результат вычисления цепи обязательно записывается во внутреннюю переменную либо подается на выход ПЛК.
Кроме того, цепи могут содержать метки. Инструкция перехода на метку позволяет изменять последовательность выполнения цепей для программирования условий и циклов.
Язык FBD прост в изучении, нагляден и удобен для прикладных специалистов, не имеющих специальной подготовки в области информатики. Жесткая последовательность выполнения приводит к простой внутренней структуре команд, которая транслируется в быстрый и надежный код. При условии качественной проработки алгоритма с позиции передачи сигналов, его представление в виде FBD диаграммы получается нагляднее, чем в текстовых языках программирования. Поэтому язык FBD по праву зовется одним из самых распространенных среди мэковских языков.
Язык ST
Structured Text (ST) — это текстовый язык программирования, синтаксис которого близок к языку PASCAL.
Самый распространенный и функциональный язык программирования ПЛК. Очень богатый и в то же время, достаточно простой синтаксис, который постоянно расширяется от стандарта к стандарту. Позволяет решать любые задачи в программировании ПЛК.
Его сильной стороной является гибкость и независимость от поставщиков. Ведь скопировать текст из одной среды разработки в другую очень просто – это вам не графические блоки, которые никак не перенести. Это позволяет отраслям менять или модернизировать оборудование ПЛК с минимальной перезаписью кода, снижая долгосрочные затраты на проектирование и избегая блокировки поставщиков.
По мере того, как промышленные процессы становятся более продвинутыми, ST становится все более предпочтительным для приложений, требующих использования циклов, сложных условий, обработки больших массивов данных.
Инженеры предпочитают его за скорость разработки, простоту устранения неполадок и возможность писать модульную масштабируемую логику. Независимо от того, используется ли структурированный текст отдельно или в сочетании с визуальными языками, например FBD, он играет решающую роль в современных системах автоматизации и определяет «тренды».
Расширения и «диалекты» разных производителей: когда стандарт встречается с реальностью
Стандарт IEC 61131-3 — это база. Но производители оборудования не просто реализуют стандарт «как есть» — они расширяют его, добавляют собственные функции, а иногда даже меняют названия языков.
Почему так происходит? Например, почему STL от Siemens это совсем не то же самое, что ST? Давайте разбираться!
Почему производители отходят от «чистого» стандарта?
Есть три основные причины, по которым производители создают собственные «диалекты» и расширения стандартных языков.
- Историческое наследие. Некоторые компании разрабатывали свои языки еще до широкого внедрения IEC 61131-3. Чтобы не ломать совместимость со старыми проектами, они сохраняют старые названия и синтаксис. Например, язык STL (Statement List) у Siemens существовал еще до стандарта и до сих пор поддерживается в TIA Portal для старых проектов.
- Оптимизация под железо. Стандарт описывает абстрактную модель. Вендоры же знают особенности своих процессоров, ОСРВ и механики передачи данных. Они добавляют функции, которые работают быстрее именно на их оборудовании. Пример - расширенные инструкции работы с буфером и строками в Rockwell Studio 5000 и оптимизированные математические блоки в Beckhoff TwinCAT.
- Экосистемная привязка. Уникальные расширения усложняют переход на оборудование конкурента. Это бизнес-стратегия: если инженер выучил «фирменный» язык, он с большей вероятностью останется в экосистеме этого бренда. К примеру, библиотеки Siemens TIA Portal (SCL, GRAPH, CFC) глубоко интегрированы с аппаратной конфигурацией и диагностикой, что делает смену оборудования не простой затеей.
Важный момент: Модифицирование языков производителями — это не нарушение стандарта, а его расширение. Базовая совместимость обычно сохраняется. Впрочем, код с уникальными функциями вряд ли нормально скомпилируется на контроллере другой марки.
CFC (Continuous Function Chart)
CFC - это графический язык программирования, который был разработан немецкой компанией 3S-Smart Software Solutions GmbH (сейчас — CODESYS GmbH). Он представляет собой расширение языка FBD и позволяет свободно размещать функциональные блоки на рабочем поле и задавать произвольный порядок их выполнения.
CFC удобен для сложных схем регулирования, где стандартная компоновка FBD (строго организованными цепями) может быть ограничивающей, и позволяет явно представлять обратные связи, что упрощает разработку регуляторов, например.
Интересно, что CFC сейчас поддерживается не только в CODESYS-подобных средах разработки, но и например, в Siemens TIA Portal.
Особенности языка CFC делают его весьма удобным и наглядным в сочетании с кодом на ST. Так можно сделать верхний уровень программы на CFC, разместив все основные составляющие блоки программы, как черные ящики, а непосредственно их код написать на ST. Это будет очень удобно потом наблюдать в отладке.
Siemens: SCL вместо ST, GRAPH вместо SFC и т.д.
Компания Siemens — один из самых ярких примеров «творческого переосмысления» стандарта. В основном это связано с тем, что они включились в разработку языков программирования ПЛК еще до принятия стандарта.
ST (Structured Text) - SCL (Structured Control Language)
Синтаксически почти идентичен стандартному ST. Но SCL имеет доступ к специфическим функциям Siemens: работа с дата-блоками (DB), системные вызовы (GetErrorID), оптимизация под S7-1200/1500. Также в SCL есть расширения для работы с массивами и строками, специфичные для TIA Portal.
SFC (Sequential Function Chart) - GRAPH (S7-GRAPH)
GRAPH — это мощная надстройка над базовым SFC. Добавлены: альтернативные и параллельные ветвления с приоритетами, встроенные таймеры шагов, автоматическая обработка аварийных переходов, возможность «перепрыгивания» на любой шаг вручную (для отладки).
FBD (Function Block Diagram) - FBD (но с расширениями)
В Siemens FBD поддерживает специфические блоки библиотеки Simatic, которые не описаны в стандарте (например, блоки работы с Profinet, диагностикой, функциональной безопасностью).
IL (Instruction List) – STL (Statement List)
STL — проприетарный ассемблероподобный язык, появился еще до принятия стандарта МЭК 61131-3. Синтаксически он близок к IL, также, по сути, отличается тем, что лучше интегрирован с железом Siemens - доступ к специфическим областям памяти, прямая работа с адресами периферии и общая оптимизация под процессоры этих ПЛК.
Другие производители
Меняют языки в своих средах разработки и другие производители.
Так в SMLogix и Owen Logic мы видим свободное расположение блоков (нет цепей) и присутствие обратных связей, несмотря на то что оба производителя заявляют FBD языком разработки для своих сред. Очень многие производители добавляют свои собственные стандартные блоки для работы со специфичным оборудованием.
Поэтому важно понимать, что IEC 61131-3 задает правила этой «игры в слова»: типы данных, структуру POU, базовый синтаксис. А расширения производителей (CFC, SCL, GRAPH) дают дополнительные возможности и удобство (хоть и «привязывают» проект к конкретной экосистеме). Такой механизм позволяет инженеру, знающему стандарт, быстро освоить любую платформу.
Хорошим советом будет писать ваши часто используемые функции или блоки на стандартном языке (лучше всего ST). Так вы сможете хотя бы частично восстановить свою работу в случае смены платформы.
Как видите, индустрия не стоит на месте и, несмотря на всю инертность, стабильно развивается. К чему это ведет, разберем далее.
Объектно-ориентированное программирование в языках МЭК
Долгое время программирование ПЛК было сугубо процедурным: программа выполнялась линейно, данные хранились в глобальных переменных, а повторное использование кода сводилось к копированию функциональных блоков (что кстати уже является признаком ООП, если порассуждать).
Ситуация начала меняться с выходом редакции 3.0 стандарта в 2013 году, когда впервые были добавлены базовые конструкции ООП: CLASS, INTERFACE, EXTENDS, IMPLEMENTS
Редакция 4.0, опубликованная в мае 2025 года, не просто сохранила ООП-возможности, а расширила и модернизировала их, чтобы стандарт соответствовал современным практикам разработки промышленного ПО.
Почему потребовалось обновление?
- Рост сложности систем. Современные линии автоматизации — это сотни осей, тысячи регистров, распределённая архитектура. Процедурный код становится неподдерживаемым.
- Конвергенция с IT. Инженеры в АСУ всё чаще приходят из мира «большого» программирования, где ООП, свойства и асинхронность — обычное дело.
- Многоядерные контроллеры. Появление ПЛК с параллельным исполнением задач потребовало и стандартных примитивов синхронизации.
Но важно понимать, что ООП в ПЛК — это не прямое копирование подходов из Java или C++. Это адаптация принципов ООП под ограничения детерминированного выполнения и реального времени.
Что ООП дает инженеру-программисту ПЛК?
Вместо разрозненных функциональных блоков и глобальных переменных инженер получает возможность описывать типовое оборудование — например, привод, клапан или датчик — один раз в виде класса, а затем многократно использовать его экземпляры в разных частях проекта. Изменения в логике класса автоматически применяются ко всем его экземплярам, что упрощает сопровождение и масштабирование системы: добавление нового узла на линию часто сводится к созданию ещё одного экземпляра уже отлаженного класса, а не к копированию и правке десятков сетей.
Кроме того, механизмы наследования и интерфейсов позволяют выстраивать гибкую и расширяемую архитектуру. Наследование даёт возможность создавать специализированные версии базовых компонентов без дублирования кода, а интерфейсы обеспечивают полиморфизм: разные реализации одного и того же интерфейса могут взаимозаменяемо использоваться в алгоритмах управления. Это особенно ценно при разработке модульных систем, где требуется подмена оборудования или алгоритмов без переписывания всей логики.
В результате код становится не только более читаемым и структурированным, но и легче поддаётся тестированию, верификации, изменениям конфигурации и командной разработке — качества, которые критически важны в современных проектах с длинным жизненным циклом.
Однако применение объектно-ориентированного подхода не всегда целесообразно.
ООП идеально подходит для создания библиотек стандартных компонентов поскольку позволяет заключить логику и параметры в готовые повторно используемые блоки. Оно также полностью оправдано при разработке сложных машин с множеством однотипных узлов.
В то же время для решения простых задач дискретной логики, вроде управления включением и выключением насоса, ООП оказывается избыточным инструментом — здесь гораздо эффективнее и нагляднее придерживаться процедурного стиля или использовать классические функциональные блоки.
Также стоит аккуратно использовать ООП в задачах, где важна каждая миллисекунда — например, в быстрых контурах регулирования или управлении сервоприводами. Перед внедрением обязательно проверяйте, не замедляет ли код работу контроллера: механизмы могут добавлять небольшие задержки, которые в реальном времени иногда становятся критичными.
За пределами стандарта: G-код, Python, скрипты и IT/OT-интеграция
Языки стандарта IEC 61131-3 отлично справляются с главной задачей ПЛК: детерминированным управлением машиной в реальном времени. Но современная автоматизация требует большего. Производству нужны уведомления в мессенджеры, веб-панели для офиса, автоматические отчёты, обмен с MES/ERP, хранение телеметрии, аналитика, машинное зрение, цифровые двойники и интеграция со сложным оборудованием: станками ЧПУ, роботами, камерами, лабораторными установками. Здесь на помощь программистам ПЛК приходят смежные специалисты и языки, не входящие в стандарт.
Важно сразу обозначить границу: описываемые далее языки не заменяют мэковские. Они их дополняют, расширяют функционал системы АСУ. ПЛК продолжает управлять приводами и клапанами, а внешние инструменты берут на себя задачи, для которых актуальны другие требования.
G-код и робототехника
Для управления станками с ЧПУ и робототехники используются G-код и специализированные языки — KRL (KUKA), RAPID (ABB), URScript (Universal Robots) и т.д. Они решают свои задачи: G-код описывает траекторию движения инструмента с точностью до микрона, а языки роботов фокусируются на кинематике, планировании путей и координации осей. В отличие от детерминированного цикла ПЛК, программы для роботов и ЧПУ часто выполняются как последовательность команд с собственным планировщиком и системой интерполяции.
На первый взгляд кажется, что эти миры изолированы. Но в реальном проекте ПЛК может управлять таким станком или роботом, или даже несколькими такими устройствами. Быть своего рода «дирижёром», который координирует их работу, обрабатывает сигналы готовности, управляет безопасными остановками и обменивается данными через промышленные сети. Понимание основ G-кода или структуры программы робота поможет инженеру ПЛК правильно спроектировать интерфейс взаимодействия: какие сигналы нужны для запуска, как обрабатывать ошибки, как синхронизировать циклы. Это не значит, что нужно становиться экспертом по программированию роботов — достаточно понимать логику их работы, типичные состояния («авто», «ручной», «ошибка») и протоколы обмена. Тогда ПЛК, робот и ЧПУ будут работать как единое целое, а не как набор разрозненных устройств.
Скриптовые языки для панелей оператора (HMI) и SCADA
Современные панели оператора, которые являются базой HMI и SCADA, всё чаще строятся на веб-технологиях, а здесь скриптовые языки – обычное дело. Среди них:
- JavaScript
- TypeScript
- Lua
- VBScript
Эти языки и их производные применяются для создания динамических веб-интерфейсов, обработки событий нажатий, анимации, локальной валидации данных перед отправкой ее в ПЛК, работы с файлами, для реализации какой-то бизнес-логики, генерации отчетов, отображения журнала аварий, интеграции с ERP, базами данных, корпоративными приложениями и т.п.
Важный момент: скрипты в HMI не управляют физикой процесса. Они работают с данными, которые уже прочитаны из ПЛК, и отвечают только за удобство оператора, визуализацию и передачу команд.
Python в экосистеме автоматизации: зачем он нужен в CODESYS и не только?
От контроллеров все чаще требуют не только решения типичных для них задач, но и специфического функционала – например, интеграцию с web-сервисами через REST API, передачу в MES или ERP систему файлов, формирование отчетов в разных форматах и т.д. Нейросети и промышленность в РФ пока что не упоминаются вместе, но зарубежные разработчики уже внедряют технологии по автоматизации среды разработки и управлению с помощью ИИ-агентов.
Решать все эти специфические задачи на языках программирования МЭК 61131-3 довольно сложно и нерационально.
С другой стороны, для решения подобных задач вполне подходит язык Python. Простой синтаксис, огромная база библиотек и широкое распространение. Для асушника это мост в мир данных и большое IT. Некоторые производители ПЛК в своих средах разработки уже внедряют поддержку Python-скриптов.
Что касается задач — вот несколько примеров:
- генерация отчетов в форматах json/xml/xlsx/docx/pdf с форматированием, таблицами, скриншотами;
- работа с web-сервисами через REST API (например, для получения информации о текущей погоде, передачи данных в платформы типа Эвотор, ЗООТЕХНИК.рус и т.д., обмена с устройствами, подключенными к OwenCloud и т.д., и т.п.);
- можно поднять в самом ПЛК web-сервер - если уже система верхнего уровня хочет выступать REST-клиентом для получения данных от ПЛК;
- автоматическая генерация проектов, загрузка проектов и обновлений на ПЛК, экспорт, импорт тегов и переменных из баз данных и многое другое, на что хватит вашей фантазии.
Связь IT и OT
Продолжая тему расширения возможных интеграций, можно обратить внимание и на другие языки:
Go часто выбирают для промышленных edge-сервисов и шлюзов, когда важны производительность, параллельная обработка, простое развёртывание и работа в Linux-среде. Go-сервис может опрашивать несколько устройств, принимать MQTT-сообщения, писать данные в базу и отдавать REST API для веб-панели.
C# / .NET удобен для Windows-инфраструктуры, инженерных утилит, OPC UA/ADS-клиентов, внутренних HMI/MES-инструментов и интеграции с корпоративными системами. Особенно часто он полезен там, где предприятие уже использует Windows, SQL Server, Active Directory и десктопные инженерные приложения.
C и C++ остаются фундаментом низкоуровневого промышленного ПО: прошивки, драйверы, embedded-разработка, realtime-компоненты, SDK устройств и высокопроизводительные библиотеки.
Rust пока остаётся нишевым языком в промышленной автоматизации, но интерес к нему растёт в embedded, edge и safety-critical системах, где важны безопасность памяти, производительность и отказоустойчивость.
Python как самостоятельное приложение - хорошо подходит для обработки данных, отчётов, тестовых стендов, аналитики, машинного зрения и быстрых прототипов. Например, HMI-панель может отправить результаты испытания в JSON, а локальное Python-приложение сформирует XLSX-файл отчета. Для ПЛК такая задача неудобна (встроенный движок Python – это штука относительно новая, не все ПЛК и тем более программисты ПЛК так умеют), а для Python — обычное дело, потому что есть готовые библиотеки для Excel, графиков, баз данных и API.
Кстати, у нас есть пример такой разработки – генерация отчета по испытанию пламегасителей на стенде. Разрабатывали вот такое ПО, рассказываем об этом и других объектах на наших вебинарах, записывайтесь.
Можно отметить, что для решения одних и тех же задач могут применяться разные технологии. И это нормально – каждый выбирает инструмент под себя, свое оборудование и возможности.
Заключение
Мы прошли большой путь: от релейных шкафов 1960-х до современных интеграций PLC в другие IT-системы. Может показаться, что нужно знать кучу языков, и вообще кучу всего, чтобы программировать ПЛК и работать инженером АСУ ТП.
Это не совсем так. Большинство задач на рынке связано с базовой автоматизацией ПЛК (FBD, ST, LD, CFC) + панель оператора (без скриптов, базовая диспетчеризация).
Для каких-то более сложных решений принято привлекать других специалистов, разделение компетенций - это норма сферы. И это отличная новость для тех, кто только начинает заниматься автоматизацией. Ведь языки программирования ПЛК гораздо проще системного программирования. Их можно освоить достаточно быстро, например у нас на курсах.
Но если вам интересно выйти за рамки классического ПЛК-программирования, никто не мешает освоить Python, базы данных или G-код. Это только увеличит вашу ценность, как специалиста. Цель нашей статьи как раз и была в том, чтобы показать вам все возможности и вдохновить на развитие! Индустрия не стоит на месте, может быть, уже совсем скоро нас ждет прямая генерация кода из BIM-моделей, CI/CD для ПЛК и полноценное тестирование «как в IT». Не стоит бежать за каждой новинкой, но полезно держать руку на пульсе.
Учиться никогда не поздно, а мы с коллегами с радостью вам в этом поможем! Подписывайтесь, чтобы не пропускать наши полезные посты и подобные исследования.
Статья получилась объёмной, но тема языков ПЛК безгранична. Если у вас есть:
✔️ опыт перехода с одного производителя на другого,
✔️ кейсы использования Python/JS в промышленных проектах,
✔️ вопросы по ООП или выбору стека под задачу,
— делитесь в комментариях. Обмен практикой — лучший способ расти профессионально!