На FAT заказчик открывает паспорт ПЛК и спрашивает: «здесь написано Linux RT. Это точно реальное время? У нас линия 200 мс». Наладчик кивает, потому что на стенде цикл стабильный. На третьем дне пуска после включения архива трендов и OPC-сервера цикл поплыл на 40–60 мс, дозирование дергается, в журнале - редкие watchdog warning. В отчёте заказчик пишет: «ОСРВ не соответствует ТЗ». Спор идёт не о марке контроллера, а о том, что именно проверяли на приёмке и что считать «нормой» для данного runtime.
Статья разбирает, зачем на пуске смотрят на операционную систему реального времени в контроллере: предсказуемость времени цикла, джиттер, нагрузка CPU, отличие RT-профиля от «обычной» Linux на том же железе. Фокус - что проверять на FAT и SAT, какие симптомы на объекте связаны с ОСРВ, а какие с проектом или сетью. Здесь нет курса по настройке ядра Linux и не сравнение вендоров по именам. Не дублируем материал про перенос проекта с Windows на Linux RT - он про другой слой.
Короткий ответ
ОСРВ в контроллере нужна, чтобы циклическая задача ПЛК выполнялась с заданным периодом и ограниченным разбросом (джиттером), а не «когда освободится процессор». На пуске это проверяют нагрузкой, близкой к эксплуатации: полный проект, опрос I/O, HMI, связь с SCADA, журналы. От «обычной» Linux контроллер отличает приоритизация задач runtime, выделение ядер под цикл, отключение или ограничение фоновых служб, иногда отдельный preemptive RT-патч. На FAT смотрят максимальный и средний цикл, пиковый джиттер, загрузку CPU при штатной и аварийной нагрузке, поведение при обрыве сети и при записи на eMMC. Если в ТЗ указан цикл 10 мс, а на объекте при полной конфигурации стабильно 14–16 мс - это предмет согласования до SAT, а не «дожмём после пуска».
Что называют ОСРВ на промышленном контроллере
В рекламных листах «real-time» встречается часто. В инженерном смысле для АСУ ТП важны три параметра: период задачи (cycle time), разброс периода (jitter) и worst-case время отклика на дискретное событие, если оно обрабатывается в том же runtime.
На контроллере с Linux RT обычно работает связка: ядро с RT-профилем или PREEMPT_RT, поверх - служба runtime CODESYS или MasterSCADA, внутри - циклическая задача IEC 61131-3. «Обычная» Linux без RT-профиля на том же ARM может крутить тот же байт-код, но фоновые процессы (обновление времени, сетевой стек, запись лога) вытесняют цикл непредсказуемо.
Windows Runtime на инженерной станции или панельном ПК - другая история: пригоден для отладки и HMI, но на объекте 2026 года для полевого цикла чаще выбирают встроенный RT-контроллер. Различия слоёв при переносе проекта разобраны в материале про Linux RT и Windows Runtime.
Зачем заказчик спрашивает про ОСРВ именно на пуске
В ТЗ на АСУ ТП всё чаще есть строка про максимальное время цикла и допустимый джиттер. Для линии с быстрым дозированием, синхронизацией приводов или жёсткой логикой межблокировок это не академия - от цикла зависит качество и безопасность остановки.
На FAT заказчик хочет увидеть доказательство, что контроллер тянет не «голый» проект наладчика, а конфигурацию, близкую к SAT: все модули I/O, связь с частотниками, экраны, архив, если он на том же узле. Пуск без этой нагрузки даёт ложное «цикл 8 мс», которое на следующей неделе превращается в 15 мс.
Вторая причина - граница ответственности. Если джиттер вызван перегрузкой CPU из-за тяжёлой визуализации, спор идёт между проектированием HMI и выбором железа. Если из-за записи большого архива на eMMC - между политикой historian и диском. Явная проверка ОСРВ на стенде фиксирует baseline в протоколе.
Цикл, джиттер и загрузка CPU: что мерить
Cycle time - фактический период выполнения главной задачи PLC. В CODESYS смотрят в Online → Task monitoring; в MasterSCADA - аналоги в диагностике runtime. Важно мерить в Run под production-проектом, не в Stop и не с отключённой связью.
Jitter - разница между минимальным и максимальным периодом за окно наблюдения (например, 10 минут штатной работы). Допуск в ТЗ часто задают как «не более X % от номинала» или абсолютным числом в миллисекундах.
CPU load - процент загрузки процессора runtime и системы. Устойчивые 85–90 % при штатной работе - запас на аварийный всплеск отсутствует. Правило с объекта: оставлять голову минимум 30–40 % на непредвиденные пики (одновременное аварийное событие, запись рецепта, всплеск Modbus).
На FAT записывают таблицу замеров: холостой ход линии, номинальная производительность, сценарий «авария + квитирование + тренд на экране». Без сценариев замеры не воспроизводимы.
Отличие RT-профиля от «просто Linux на ПЛК»
Контроллер на базе Linux без RT может честно работать годами на медленных задачах: насосная, климат, простые линии с циклом 100–500 мс. Проблемы начинаются, когда маркетинг называет его RT, а в ТЗ - 10 мс.
Типичные признаки RT-образа от производителя: фиксированная версия ядра, отключённые лишние службы, приоритет процесса runtime, запрет или лимит на swap, иногда выделенное ядро CPU под цикл. Обновление «как на сервере» через общий репозиторий пакетов на таком контроллере - красный флаг для эксплуатации.
Watchdog на уровне runtime и аппаратный watchdog платы - разные уровни. Первый ловит зависание логики; второй - перезагрузку при полном зависании ОС. На пуске проверяют оба по регламенту: принудительная бесконечная петля в тестовой задаче не должна оставлять линию без остановки, если так спроектирована безопасность.
Что проверять на FAT и что оставить на SAT
На FAT (заводские испытания, стенд интегратора) закрывают: соответствие цикла ТЗ при полной конфигурации железа и проекта; рост джиттера при включении всех каналов связи; поведение при отключении Ethernet на 30–60 секунд; восстановление после reboot с сохранением retain; запись журнала и тренда в типовом объёме.
На SAT (на объекте заказчика) повторяют ключевые замеры уже на реальных кабелях, помехах, длине линий RS-485 и на фоне соседних пусков. Сеть объекта добавляет задержки, которых не было на стенде.
Материал про приёмку FAT и SAT без сюрпризов подчёркивает: протокол замеров цикла - часть акта, не устная договорённость.
Симптомы на объекте, которые путают с «плохим ПЛК»
Рывки аналогового регулирования при стабильном PID часто связаны с дрожанием цикла, а не с настройкой коэффициентов. Сначала смотрят монитор задачи, потом анатомию PID.
Потеря отдельных кадров Modbus при нормальном ping - сеть или сканирование в главной задаче, а не «ОСРВ сломалась». Но если опрос I/O вынесен в ту же задачу, что и тяжёлая обработка строк, джиттер бьёт по опросу.
«Зависание» панели при живой логике - разделение потоков визуализации и цикла. На ARM с 1 ГБ RAM одновременный архив historian и тяжёлые тренды на локальном HMI легко поднимают CPU.
После замены microSD или обновления образа цикл вырос - проверяют скорость носителя и не ушла ли запись логов в синхронный режим на каждый цикл.
Нагрузка от связи и OPC
OPC UA, Modbus TCP master на десятки устройств, опрос с SCADA с коротким scan time - всё это CPU и сеть. На пуске типичная ошибка: включили все каналы с минимальным интервалом «чтобы красиво на тренде», цикл ПЛК поплыл.
Правило: тяжёлый опрос - в отдельную задачу с более длинным периодом или на шлюзе, критичная логика - в быстрой задаче с минимальным содержимым. Проверка ОСРВ включает сценарий «SCADA опрашивает всё» и «SCADA отключена».
Для интеграции с IT-контуром смотрят OPC UA для инженера АСУ ТП - там же про таймауты и нагрузку, но базовый замер цикла всё равно на стенде ПЛК.
Температура, питание и throttling
ARM Cortex в шкафу без кондиционирования при +45 °C у лицевой панели может уходить в снижение частоты. Симптом - плавающий цикл только летом. На FAT редко гоняют тепловую камеру, но замер в закрытом шкафу после суток работы - разумный пункт для южных цехов.
Просадка 24 В при пуске мощных потребителей даёт кратковременные сбои записи и редкий reset - в журнале это не всегда «ОСРВ», но выглядит как джиттер. Осциллограф на питание контроллера - старый, но рабочий инструмент наладчика.
Документирование результатов для заказчика
В протокол FAT заносят: версию образа ОС, версию runtime, номинальный цикл задачи в проекте, min/avg/max цикл за каждый сценарий, CPU max, замечания. Скриншоты монитора задачи с датой. Это потом спасает при споре «на SAT стало хуже» - сравнивают конфигурацию, а не обвиняют железо.
При передаче паспорта объекта фиксируют запрет самовольного обновления ядра без согласования - иначе baseline ОСРВ теряется.
Разнесение задач в проекте: главный рычаг джиттера
В IEC 61131-3 один проект часто содержит несколько задач с разным периодом. Ошибка пуска: вся логика, опрос Modbus, обработка строк, математика рецепта и вызов FB визуализации сидят в одной задаче 10 мс. CPU честно не успевает, джиттер растёт, винят ОСРВ.
Правило с объекта: быстрая задача - только то, что должно отработать за миллисекунды: дискретные межблокировки, быстрые счётчики, критичный PID. Опрос полевых устройств по сети - в задаче 50–100 мс или на отдельном шлюзе. HMI и тренды - ещё медленнее. При FAT показывают заказчику структуру задач в IDE, не только цифру «цикл 10» в шапке проекта.
Перенос тяжёлого кода из главной задачи иногда снижает max cycle втрое без смены железа. Это дешевле, чем спор о «неправильной ОСРВ», если замеры задач не смотрели.
Стенд и объект: почему цифры расходятся
На стенде интегратора короткие кабели, один источник питания, нет помех от сварки в соседнем цеху. На SAT добавляются: реальная длина RS-485, рефлексии, параллельные пуски линий, общая шина с другими master. Цикл ПЛК может вырасти на 1–2 мс из-за сети, хотя ОСРВ та же.
Если на FAT было 9 мс, на SAT стало 11 мс при том же проекте - сначала проверяют сеть и scan time SCADA, потом обвиняют контроллер. Протокол с двумя колонками «стенд / объект» снимает спор на корню.
Симуляция нагрузки на стенде: включить искусственный опрос, генератор Modbus slave, запись архива - хотя бы приближение к полю. Идеал - FAT на макете с реальными приводами и датчиками, как в приёмке без сюрпризов.
Дискретные цепи, фильтры и «ложная» ОСРВ
Дребезг на входе, слишком короткий фильтр DI, гонка между задачами - симптом «плавающая логика», похожий на джиттер цикла. Оператор видит «мигание» разрешения, технолог винит ПЛК. Осциллограф на клемме и лог SOE с меткой времени разводят причины.
Если дискрет обрабатывают в медленной задаче, а межблокировку ждут в быстрой, задержка на один цикл медленной задачи выглядит как «ОСРВ тормозит». Согласование периодов задач и дискретных сигналов - часть пусковой проверки, не опция.
На практике
На промышленных контроллерах с Linux RT цикл и джиттер зависят не только от ядра, но и от дисциплины проекта: одна тяжёлая задача вместо двух разнесённых, лимит на опрос в главном цикле, архив не на том же узле, что быстрая логика. Паспорт контроллера задаёт потолок; проект и пусковая нагрузка определяют, упрётесь ли вы в него на первой же неделе.
На панельных ПЛК с Linux RT на ARM те же правила: 1 ГБ RAM быстро забивается historian и OPC на одном узле. Перед SAT имеет смысл прогнать сценарий «чёрный понедельник»: три аварии подряд, квитирование, открытый тренд, опрос SCADA - и снова снять min/max цикл. Если в этот момент цифры в протоколе, споров после сдачи меньше.
Заказчик иногда просит «выгрузить отчёт ОСРВ» без понимания, что это замеры под конкретный проект. Шаблон отчёта: дата, версия проекта, список сценариев, таблица min/avg/max, подпись наладчика. Повторять замеры после любого change request, который трогает задачи или связь - иначе baseline устаревает до SAT.
Симптом, параметр ОСРВ и проверка на пуске
| Симптом на объекте | Параметр ОСРВ / runtime | Проверка на FAT / SAT |
|---|---|---|
| Рывки регулирования, «плавающий» PID | Джиттер цикла, фактический cycle time | Task monitoring 10+ мин под нагрузкой; сравнение с ТЗ |
| Редкие пропуски опроса I/O | Max cycle, CPU load | Полный I/O map; аварийный сценарий; загрузка CPU < 70 % штатно |
| Задержка реакции на дискрет | Worst-case цикл, приоритет задачи | Осциллограф на выход; лог меток времени SOE |
| Зависание HMI при живой логике | Разделение задач visu / PLC | CPU по процессам; вынести архив с панели |
| Ухудшение после обновления образа | Версия ядра, RT-патч | Сверка с паспортом; откат образа; повтор замеров |
| Проблемы только летом в жарком шкафу | CPU throttling | Температура в шкафу; замер цикла после 24 ч работы |
Типовые ошибки при приёмке ОСРВ
Замер на пустом проекте. Один быстрый цикл без I/O и связи - не доказательство.
Игнор джиттера при «среднем» цикле норм. Max ушёл в 2× номинала - линия будет капризничать.
Включили всё в последний день SAT. Архив, OPC и тренды одновременно - «внезапно» не тянет.
Путаница watchdog и цикла. Watchdog не компенсирует систематический перерасход времени задачи.
Обновление Linux «как на офисном ПК». Сломали RT-профиль, цикл поплыл через неделю.
Вопросы с объекта
Достаточно ли надписи Linux RT в паспорте?
Нет. Нужны замеры цикла и джиттера на вашем проекте и версия образа, зафиксированная в акте.
Какой джиттер считать нормальным?
Смотрите ТЗ. Ориентир для цикла 10 мс на типовом ПЛК: разброс единиц миллисекунд при штатной нагрузке, не десятки, если иное не согласовано.
Можно ли вынести архив на сервер и разгрузить контроллер?
Часто да. Это проектное решение, которое нужно заложить до FAT, а не «после жалоб оператора».
Влияет ли CODESYS или MasterSCADA на ОСРВ?
Влияет нагрузка проекта в runtime, не название среды. Обе среды на одном железе исполняются поверх того же класса RT-образа.
Нужно ли согласовывать допустимый цикл с технологом?
Да. Цифра из ТЗ должна совпадать с тем, что реально нужно технологии на останов и дозирование. Иногда снижают требование к циклу и выносят быстрый контур на отдельный модуль - дешевле, чем гнаться за 5 мс на перегруженной задаче.
Обсуждение