Почему объём памяти стал ключевым параметром современного ПЛК: 4 ГБ RAM и 32 ГБ eMMC

Когда первый Modicon 084 появился в 1969 году, его оперативная память была в диапазоне нескольких килобайт. Инженеры тогда буквально считали биты - каждая переменная требовала обоснования. Спустя полвека в промышленной автоматизации произошло нечто, о чём не принято говорить прямо: современный ПЛК перестал быть «умным реле» и превратился в полноценный встраиваемый компьютер, от которого требуют задачи, непредставимые в эпоху Modicon.

Он должен одновременно управлять технологическим процессом в реальном времени, поднимать OPC UA-сервер с сотнями тегов, хранить historian-архив последних суток, отображать WebVisu-интерфейс на браузере смартфона технолога, выполнять SQL-запросы к локальной базе данных PostgreSQL и участвовать в VPN-туннеле с корпоративной сетью. И всё это - в одном корпусе шириной 85 мм, без вентилятора, при температуре от -40 до +70°C.

Стало понятно: пора поговорить о памяти всерьёз.

В архитектуре любого современного ПЛК-контроллера оперативная память (RAM) и постоянная память (Flash/eMMC) решают принципиально разные задачи - и их нехватка проявляется по-разному.

ОЗУ - это рабочее пространство процессора. Здесь живут: исполняемый код приложения после загрузки из Flash, все переменные CODESYS или MasterSCADA с их текущими значениями, стек вызовов функциональных блоков, буферы коммуникационных стеков (Modbus TCP, OPC UA, EtherCAT, MQTT - у каждого свои буферы), heap операционной системы Linux, на которой работает runtime, данные веб-сервера для WebVisu, кеш базы данных.

Когда ОЗУ заканчивается, операционная система начинает использовать swap - сброс части данных в Flash-память. Это называется свопинг. Для Linux на персональном компьютере это нормально и почти незаметно. Для ПЛК с требованиями к детерминированному циклу сканирования это катастрофа: внезапный своп в середине цикла может вызвать джиттер в сотни миллисекунд там, где допустимо несколько. Сторожевой таймер - watchdog - видит это как зависание и может инициировать перезапуск контроллера прямо в середине технологического процесса. Именно поэтому в серьёзных embedded-приложениях swap вообще отключают, а объём ОЗУ должен перекрывать пиковое потребление всех задач с запасом.

eMMC (embedded MultiMediaCard) - это встроенная Flash-память с контроллером прямо на чипе. В отличие от внешней microSD-карты, она припаяна к плате, работает по высокоскоростному интерфейсу (до 400 МБ/с у eMMC 5.1 против 50-100 МБ/с у microSD), имеет встроенный wear-leveling алгоритм и рассчитана на значительно большее число циклов перезаписи. Именно здесь хранятся: образ операционной системы, runtime CODESYS или MasterSCADA, проект пользователя, логи системы, historian-архив, рецептурная база данных, сертификаты для OPC UA и VPN, обновления прошивки.

Когда Flash заканчивается, система перестаёт логировать. Потом перестаёт записывать новые рецептуры. Потом начинает вести себя непредсказуемо при попытке обновить прошивку. А самый неприятный сценарий - когда логи переполнились и операционная система отказывается работать, потому что не может записать временные файлы в /tmp. Системный администратор знает этот сценарий как «диск кончился» - у ПЛК та же история.

Возьмём не абстрактный, а конкретный проект - водоочистная станция средней мощности. ПЛК управляет 120 аналоговыми сигналами, 80 дискретными, 15 частотными преобразователями, ведёт 6 ПИД-контуров. Звучит умеренно по меркам 2000-х.

Но заказчик хочет: WebVisu с мнемосхемой, доступную через браузер без установки ПО - CODESYS WebVisu сервер занимает от 50 МБ ОЗУ при подключённых клиентах. OPC UA сервер с 300 тегами и историзацией - ещё 30-60 МБ. PostgreSQL 14 для хранения аналитики и журнала аварий - от 100 МБ в рабочем состоянии. Modbus TCP Master для 40 счётчиков - буферы и таблицы переменных. CANopen Master для 15 приводов - библиотека и объектный словарь. OpenVPN-клиент для удалённого доступа - 20-30 МБ. MQTT-клиент для передачи данных в облако - 10-15 МБ. Плюс сама ОС Linux с драйверами и системными процессами - 150-200 МБ как минимум.

Итого только по крупным статьям - около 500-600 МБ ОЗУ в рабочем режиме. На контроллере с 1 ГБ ОЗУ это 50-60% объёма. При пиковых нагрузках (одновременное подключение нескольких WebVisu-клиентов, массовая запись historian) система подходит к границе. При добавлении следующего функционального требования - «хочу ещё записывать видео с IP-камеры по RTSP» - начинаются проблемы.

По Flash: один год работы historian с интервалом записи 1 минута для 200 тегов - это порядка 100-150 МБ данных в сжатом виде (зависит от алгоритма сжатия и изменчивости сигналов). Проект CODESYS с крупной визуализацией - 50-200 МБ. Образ ОС - 1-2 ГБ. При 4 ГБ eMMC место заканчивается быстро, особенно если задача предполагает хранение рецептур, обновлений прошивок «на борту» или локальных баз данных.

Посмотрим на актуальные ARM-контроллеры ведущих производителей - именно ту категорию, которая конкурирует с ПЛК СТАБУР по функциям и назначению.

Beckhoff CX8190 - флагман compact-сегмента предыдущего поколения: ARM Cortex-A9 800 МГц, 512 МБ DDR3 RAM, microSD 512 МБ (расширяемая до 8 ГБ). Это устройство всё ещё продаётся и устанавливается на новых объектах. На нём работает TwinCAT 3 и он функционально полноценен для классических задач, но его потолок по памяти виден невооружённым взглядом.

Beckhoff CX9240 - актуальный флагман компактного класса, выпущенный в 2024-2025 году: ARM Cortex-A53 1.2 ГГц, 2 ГБ LPDDR4 RAM, microSD 16 ГБ минимум. По меркам Beckhoff это удвоение по сравнению с предшественником - прогресс реальный. По меркам задач Индустрии 4.0 - уже комфортный базис, но запас невелик.

WAGO PFC200: ARM Cortex-A8 600 МГц, 512 МБ RAM, 256 МБ Flash. Бюджетный и надёжный, но явно не для задач с historian и WebVisu одновременно.

Phoenix Contact AXC F 2152: от 512 МБ RAM в базовой конфигурации. Средний класс с поддержкой CODESYS.

Siemens SIMATIC S7-1500 с CP 1543-1 - отдельная история. Это классическая архитектура с выделенной рабочей памятью ПЛК (128-8 192 КБ рабочей памяти в зависимости от модели), которая не совсем сопоставима напрямую: у неё нет ОС Linux, нет WebVisu как такового (есть WebServer с ограниченными возможностями). Это другая философия - специализированное железо для специализированного ПО. Требовательные функции (historian, база данных) выносятся на отдельный сервер. Надёжность и детерминизм максимальные, гибкость - ниже.

Линейка ПЛК СТАБУР от ООО ПО «Промсвязь» (Екатеринбург) традиционно строилась на балансе между функциональностью, производственными затратами и требованиями рынка. Поколение, работающее сегодня на тысячах объектов - 1 ГБ ОЗУ и 4 ГБ eMMC - позволяло решать задачи среднего уровня сложности при грамотном проектировании.

Новое поколение, которое выходит в производство прямо сейчас - 4 ГБ ОЗУ и 32 ГБ eMMC. Это не очередная маркетинговая строчка в пресс-релизе, это смена класса устройства.

Четырёхкратный прирост ОЗУ в абсолютных цифрах - с 1 до 4 ГБ - переводит ПЛК СТАБУР из «достаточно для большинства задач» в «с запасом для любой реалистичной задачи». Вот конкретно что это открывает:

Полноценный historian на борту. PostgreSQL 14 при 4 ГБ ОЗУ получает достаточно памяти для кеширования, параллельных запросов и работы с индексами без конкуренции с runtime CODESYS. Прежде при 1 ГБ ОЗУ разработчику приходилось делать выбор: либо historian, либо WebVisu, либо комфортно работающий OPC UA-сервер под нагрузкой. Теперь - всё одновременно.

WebVisu под нагрузкой. При одновременном подключении 5-10 браузерных клиентов к WebVisu (что вполне реально на крупном объекте, где доступ к данным нужен и диспетчеру, и технологу, и начальнику цеха) потребление памяти растёт пропорционально числу соединений. 4 ГБ держат эту нагрузку без деградации.

Машинное обучение прямо на контроллере. Инференс лёгких ML-моделей (ONNX Runtime, TensorFlow Lite) для предиктивного обслуживания или детектирования аномалий на edge-уровне требует от 200 МБ до 1 ГБ ОЗУ в зависимости от размера модели. С 4 ГБ это перестаёт быть экзотикой и становится штатным функционалом.

32 ГБ eMMC vs 4 ГБ - это тоже восьмикратный прирост, и он не менее значим. Два года historian-архива при интервале 1 минута для 300 тегов - это около 250-300 МБ данных. С запасом на обновления прошивки, резервные копии проектов, логи и рецептурные базы 32 ГБ eMMC создаёт комфортный горизонт эксплуатации без необходимости периодически «подчищать» память.

Важно: eMMC, а не microSD. Это принципиальный момент. microSD-карты, которые используют многие конкуренты для хранилища, имеют ограниченный ресурс по числу циклов записи и более низкую надёжность в промышленных условиях. Вибрация, температурные циклы, электромагнитные помехи - всё это создаёт нагрузку на карту памяти. eMMC с её контроллером wear-leveling, прямым подключением к процессорному модулю и значительно большим ресурсом перезаписи - это другой уровень надёжности. Для системы, которая работает 24/7 в течение 10 лет, разница ощутима.

Можно было задаться вопросом: а зачем вообще эти цифры нужны на ПЛК? Ведь сто лет инженеры обходились килобайтами.

Обходились, пока у ПЛК не было задачи выступать одновременно контроллером, OPC UA-сервером, historian-узлом, веб-сервером и VPN-endpoint. Три процесса изменили ситуацию необратимо.

Первый - конвергенция IT и OT. До Индустрии 4.0 ПЛК жил в изолированном OT-мире: опрашивал датчики, управлял приводами, отдавал данные в SCADA по Modbus. SCADA жила на отдельном сервере. Historian - на ещё одном. Веб-интерфейс - на третьем. Сейчас заказчик хочет всё это в одном устройстве, потому что ставить три сервера ради 50 точек мониторинга экономически бессмысленно.

Второй - стандарт OPC UA. Его правильная реализация с шифрованием, сертификатами, информационной моделью и subscription-механизмом - это сотни мегабайт ОЗУ при нескольких десятках клиентов. Экономный OPC UA «на 1 клиента» - это полумера, не отвечающая реальным требованиям интеграции.

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

Сравнение показывает положение честно: новое поколение СТАБУР по объёму ОЗУ вдвое превосходит самое новое compact-устройство Beckhoff (CX9240 с его 2 ГБ) и в восемь раз превосходит массово распространённые устройства среднего класса. По Flash - в два раза больше того, что Beckhoff рекомендует как минимальный объём для своего RT Linux.

Это не означает, что СТАБУР «лучше Beckhoff» в целом - у TwinCAT своя экосистема, своя история, своя надёжность. Но по ресурсам памяти, которые доступны прикладному инженеру прямо сейчас без каких-либо доплат, новый СТАБУР выходит вперёд значимо.

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

С 4 ГБ ОЗУ и 32 ГБ eMMC ответ на большинство типовых требований становится «да, на борту»:

Historian за 2 года без внешней БД - да. WebVisu для 10 одновременных пользователей - да. OPC UA-сервер под нагрузкой с шифрованием - да. Одновременно Modbus Master, CANopen, EtherCAT и MQTT - да. PostgreSQL для рецептур и журналов - да. Edge-аналитика с лёгкой ML-моделью - да. VPN для удалённого доступа + всё вышеперечисленное одновременно - с 4 ГБ уже реально.

Для небольших и средних объектов это означает отказ от отдельного SCADA-сервера как обязательного компонента архитектуры. Заказчик получает функциональность, которая ещё пять лет назад требовала стойку с сервером, в одном щитовом устройстве.

Почему объём ОЗУ стал критичным для современного ПЛК? Потому что современный ПЛК - это не «умное реле», а встраиваемый компьютер, одновременно выполняющий управление процессом, OPC UA-сервер, historian, WebVisu-сервер, VPN-клиент и базу данных. Каждая из этих задач требует своей доли ОЗУ. При нехватке памяти операционная система уходит в своп, что ломает детерминизм цикла управления.

Чем eMMC отличается от microSD в контексте надёжности ПЛК? eMMC - это Flash-память с контроллером, припаянная непосредственно к плате. Она имеет более высокий ресурс перезаписи, встроенный wear-leveling, более высокую скорость (до 400 МБ/с) и значительно лучшую устойчивость к вибрации и температурным циклам. microSD-карты, которые используют многие конкуренты, заменимы, что удобно при отказе, но сам носитель менее надёжен для непрерывной промышленной эксплуатации.

Как изменение с 1 ГБ до 4 ГБ ОЗУ отражается на реальных задачах? С 1 ГБ разработчику приходилось делать выбор: historian, WebVisu или тяжёлый стек коммуникаций - всё одновременно не помещалось с комфортным запасом. С 4 ГБ эта задача снимается: все перечисленные функции работают параллельно без деградации производительности и без риска своп-зависания.