Как работать с расширениями производителей ПЛК: UDT против USER_DEFINED в IEC 61131-3

Стандарт IEC 61131-3 стандартизирует языки программирования ПЛК, но не полное поведение среды исполнения у разных производителей. Сложные структуры данных, такие как UDT, DUT и пользовательские типы данных (user-defined types), зависят от реализации, особенно в части компоновки памяти и доступа к блокам. OLLA Lab предоставляет ограниченную среду симуляции для отработки отображения данных, структурирования тегов и валидации логики перед развертыванием на конкретном оборудовании.

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

Практическое уточнение: большинство неудачных миграций вызваны не строкой кода, запускающей двигатель, а структурой, которая его окружает. Согласно внутреннему бенчмарку Ampergon Vallis, 68% смоделированных сбоев при кроссплатформенной миграции были связаны с несоответствием вложенных пользовательских структур данных, конфликтами выравнивания (padding) или допущениями в модели адресации, а не с ошибками синтаксиса языка Ladder [Методология: n=512 задач по симуляции миграции, включающих структуры с несколькими тегами и переназначение I/O; базовый компаратор = принятие кода только по синтаксису Ladder; временной интервал = с января 2025 по февраль 2026 г.]. Это подтверждает узкий вывод: моделирование данных является основным источником сбоев при подготовке к миграции. Это не доказывает универсальный отраслевой показатель.

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

IEC 61131-3 стандартизирует языки программирования, а не идентичное поведение систем разных производителей. Он определяет такие языки, как Ladder Diagram (LD), Function Block Diagram (FBD), Structured Text (ST), Sequential Function Chart (SFC) и связанные с ними концепции типов, но допускает поведение, зависящее от реализации, в областях, влияющих на выполнение, хранение и интероперабельность.

На практике «зависимость от реализации» — это не сноска. Это область, где производители принимают разные решения относительно:

• выравнивания данных и заполнения (padding),
• порядка байтов и соглашений о хранении,
• оптимизированного доступа к памяти по сравнению с абсолютным,
• обработки компилятором структур и вложенных типов,
• поведения при сохранении данных (retentive),
• реализации функциональных блоков в библиотеках.

Вот почему два контроллера могут быть описаны как соответствующие IEC 61131-3, но при этом по-разному хранить или адресовать сложную структуру.

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

Что стандарт оставляет открытым?

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

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

Результат прост: объявление типа может выглядеть стандартно, в то время как базовое поведение памяти — нет.

Почему это важно для работающей системы?

Это важно, потому что внешние интерфейсы не «договариваются» с вашими допущениями. Карта регистров Modbus, клиент OPC UA, графический интерфейс HMI или обмен данными между ПЛК требуют стабильной интерпретации данных. Если одна сторона добавляет заполнение (padding) к полю `BOOL` или меняет порядок структуры для оптимизации доступа, логика может скомпилироваться, но данные процесса «поедут».

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

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

Разные экосистемы используют разные термины для схожих идей:

Разбор терминологии производителей

- Rockwell Automation (Studio 5000):

• Использует User-Defined Data Types (UDTs).
• UDT являются основой моделирования тегов в Logix.
• Поведение памяти и выравнивание элементов следуют правилам компилятора конкретного производителя.
• Интеграторы часто сталкиваются с допущениями о выравнивании при обмене упакованными данными с системами не от Rockwell.

- Siemens (TIA Portal):

• Использует PLC data types и UDTs в общеинженерной терминологии.
• «Оптимизированный доступ к блокам» (Optimized block access) может изменить внутреннее расположение данных.
• Это повышает эффективность внутри среды Siemens, но может нарушить рабочие процессы, зависящие от фиксированных абсолютных смещений.
• Если внешняя система ожидает старые фиксированные адреса, оптимизированный доступ не поможет.

- Платформы на базе Codesys, включая многие реализации Beckhoff и WAGO:

• Обычно используют DUT (Data Unit Types), объявляемые через `TYPE ... END_TYPE`.
• Синтаксис стандартизирован по стилю, но упаковка в среде исполнения и поведение целевой системы зависят от платформы и компилятора.
• Переносимость между целевыми системами остается условной, а не автоматической.

- Другие среды производителей:

• Могут использовать термины, такие как `STRUCT`, `USER_DEFINED`, пользовательские типы записей или объектные модели, специфичные для платформы.
• Разница в именовании менее важна, чем результирующее поведение при хранении и доступе.

На что инженерам следует обратить внимание?

Операционное различие заключается в следующем: пользовательский тип — это не просто удобство именования; это контракт относительно формы данных, порядка элементов и ожиданий доступа. Если две системы не согласны с этим контрактом, логика вокруг данных становится ненадежной, даже если сам код Ladder выглядит совершенно обычно.

Именно здесь инженеры часто путают совместимость языка с возможностью развертывания. Первое — текстовое. Второе — физическое.

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

Рассмотрим упрощенное объявление:

TYPE Motor_Control_DUT : STRUCT Start_Cmd : BOOL; ( может быть дополнено (padded) в зависимости от производителя ) Speed_Ref : REAL; ( 32 бита ) Fault_Code : INT; ( 16 бит ) END_STRUCT END_TYPE

Это объявление кажется простым. Но оно не является универсально простым в памяти.

Один компилятор может поместить `Start_Cmd` в упакованный битовый слот, а `Speed_Ref` — сразу после следующей допустимой границы. Другой может выровнять `REAL` по 32-битной границе и вставить заполнение после `BOOL`. Третий может оптимизировать структуру внутри блока так, что абсолютные смещения станут небезопасными для внешних потребителей.

Конкретный режим отказа

Распространенный режим отказа проявляется при обмене данными через регистры.

• Отправляющий контроллер предоставляет структуру для карты Modbus TCP.
• Инженер предполагает, что `Start_Cmd`, `Speed_Ref` и `Fault_Code` занимают последовательные ожидаемые смещения.
• Принимающий контроллер импортирует или реконструирует ту же концептуальную структуру, используя свои правила компилятора.
• `REAL` оказывается по другому смещению, потому что первая платформа добавила заполнение к полю `BOOL`.
• Принимающая сторона теперь считывает поврежденные данные задания скорости или интерпретирует часть значения с плавающей запятой как код ошибки.

Код Ladder может быть «правильным», а машина при этом работать некорректно. Это практическое следствие несоответствия данных.

Почему вложенные типы усугубляют ситуацию

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

Паттерн сбоя предсказуем:

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

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

Rockwell Automation

UDT в Rockwell активно используются для моделей оборудования, графических элементов (faceplates) и организации тегов, связанных с AOI. На практике инженеры часто проектируют структуры тегов Logix, которые чисты внутри экосистемы Rockwell, но требуют тщательного переназначения при передаче сторонним системам.

Практические последствия:

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

Siemens

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

Практические последствия:

- необходимость явно решать, что важнее: внешняя интероперабельность или внутренняя оптимизация,

• эффективная внутренняя обработка структурированных данных,
• снижение надежности старых допущений об абсолютной адресации,
• дополнительная осторожность при интеграции HMI, архиваторов или других ПЛК, ожидающих стабильных адресов.

Codesys и подобные платформы

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

Практические последствия:

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

Миграция «lift and shift» (простое копирование) обычно терпит неудачу, потому что программное обеспечение промышленного управления связано с поведением оборудования, моделями памяти, соглашениями I/O, допущениями о сканировании и инструментами производителя. Логика — это лишь один слой системы.

Миграция обычно требует от инженеров согласования как минимум пяти аспектов:

- Системы типов: соглашения UDT, DUT, struct и блоков различаются. - Модели адресации: абсолютные, символьные, оптимизированные и протокольные макеты различаются. - Поведение инструкций: таймеры, счетчики, ПИД-блоки и библиотечные функции не всегда семантически идентичны. - Привязка I/O: полевые устройства, масштабирование и диагностические биты специфичны для платформы. - Допущения пусконаладки: последовательность запуска, поведение сброса ошибок и обработка разрешений часто закодированы в паттернах, родных для производителя.

Честный вывод таков: не существует промышленной «миграции копированием», которой можно доверять на реальном процессе. Существует только перевод, верификация и снижение рисков.

Готовность к симуляции (Simulation-Ready) должна определяться операционно, а не как стремление. Инженер, готовый к симуляции, может доказать, наблюдать, диагностировать и защитить логику управления от реалистичного поведения процесса до того, как эта логика попадет на реальный объект.

Для работы со структурированными данными между платформами это означает, что инженер может:

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

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

Эта формулировка согласуется с широкой инженерной литературой по валидации на основе симуляции, использованию цифровых двойников в промышленных системах и предпусковой верификации как мере снижения рисков в сложных системах автоматизации (например, Fuller et al., 2020; Jones et al., 2020; и принципы IEC 61508 по систематическому снижению рисков).

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

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

Что OLLA Lab делает в этом рабочем процессе

В рамках задокументированной области применения продукта OLLA Lab предоставляет:

• веб-редактор логики Ladder,
• режим симуляции для запуска и остановки логики,
• панель переменных (Variables Panel) для мониторинга и настройки тегов, I/O, аналоговых значений и связанных состояний,
• промышленные упражнения на основе сценариев,
• контексты симуляции в стиле цифровых двойников для валидации поведения относительно моделируемого оборудования.

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

Что здесь означает «независимость от производителя»

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

Это разделение полезно, потому что начинающие и младшие инженеры часто терпят неудачу по двум причинам сразу:

• они еще не понимают логику управления,
• и они уже погребены под деталями конкретной платформы.

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

### Шаг 1: Определите базовую логику управления

Постройте логику Ladder в редакторе, используя необходимый набор инструкций для сценария:

• контакты и катушки,
• таймеры и счетчики,
• компараторы и математические блоки,
• аналоговые и ПИД-элементы, где это уместно.

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

### Шаг 2: Создайте структурированные теги на панели переменных

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

• `Motor_Status.Running`
• `Motor_Status.Faulted`
• `Motor_Command.Start`
• `Motor_Command.Stop`
• `Motor_Analog.Speed_Ref`
• `Motor_Alarm.Overload`

Здесь OLLA Lab становится операционно полезной. Инженер может практиковать дисциплину именования, группировку логически связанных элементов и наблюдение за тем, как состояние строки кода отображается на состояние оборудования.

### Шаг 3: Симулируйте и наблюдайте за изменениями состояния

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

Проверьте:

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

Хорошая сессия симуляции отвечает на простой вопрос: когда процесс меняется, меняется ли логика по правильной причине?

### Шаг 4: Внедрите нештатную ситуацию

Введите случай отказа, такой как:

• отсутствие подтверждения обратной связи,
• срабатывание аналогового сигнала «высокий-высокий»,
• потеря разрешения во время работы,
• задержка подтверждения запуска,
• устаревшее состояние команды.

Цель состоит в том, чтобы убедиться, что структура и логика все еще имеют смысл, когда процесс перестает «сотрудничать».

### Шаг 5: Пересмотрите логику и задокументируйте допущения об отображении

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

Этот последний шаг — разница между практикой и доказательством.

Младший инженер должен создать компактный массив инженерных доказательств, демонстрирующих рассуждения, валидацию и пересмотр. Скриншоты — это вспомогательные артефакты. Они не являются аргументом.

Используйте эту структуру:

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

1. Описание системы Определите машину или объект процесса, его назначение, основные состояния и ключевые I/O.
2. Операционное определение «правильности»
3. Логика Ladder и состояние симулируемого оборудования Покажите соответствующие строки кода и соответствующие изменения состояния в симуляции (теги, выходы или моделируемое оборудование).
4. Внедренный случай отказа Опишите введенное нештатное условие и почему оно важно операционно.
5. Внесенные изменения Объясните, что изменилось в логике, структуре тегов или обработке последовательности после того, как была обнаружена ошибка.
6. Извлеченные уроки Запишите инженерный вывод, особенно там, где моделирование данных, последовательность или допущения об интерфейсе создавали риск.

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

Валидация цифровых двойников полезна, когда она определяется как проверка поведения относительно реалистичной модели машины или процесса перед развертыванием. Она бесполезна, когда рассматривается как декоративные 3D-декорации, прикрепленные к непроверенной логике.

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

• состояние Ladder,
• состояние I/O,
• аналоговое поведение,
• прогресс последовательности,
• и реакцию моделируемого оборудования.

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

Исследования промышленных цифровых двойников и инженерии на основе симуляции последовательно подтверждают ценность виртуальной валидации для снижения рисков интеграции на поздних этапах, улучшения понимания системы и поддержки обучения операторов или инженеров при правильном определении области применения (Fuller et al., 2020; Tao et al., 2019). Руководства по функциональной безопасности также подкрепляют более широкий принцип: систематические ошибки должны быть найдены как можно раньше посредством дисциплинированного проектирования и верификации, а не обнаружены на заводской площадке (IEC 61508; exida, 2024).

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

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

Используйте этот контрольный список передачи:

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

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

- IEC 61131-3: Программируемые контроллеры — Часть 3 - Семейство стандартов функциональной безопасности IEC 61508 - Ресурсы exida по функциональной безопасности и валидации - Рекомендация NAMUR NE 107 по сигнализации состояния - Цифровой двойник в промышленности: современное состояние (DOI)