ПЛК на диете: Как заставить контроллер сбросить лишний вес и ускорить цикл

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

А теперь посмотрите на современный ПЛК. Это изнеженный офисный сотрудник, который оброс гигабайтами оперативной памяти и многоядерными процессорами ARM-архитектуры. Разработчики АСУ ТП, избалованные средами вроде TIA Portal, Studio 5000 или Codesys 3.5, начали кормить эти бедные контроллеры откровенным цифровым фастфудом. В программу пихают огромные вложенные структуры данных, текстовые строки, тяжелые математические функции и бесконечные циклы.

В результате контроллер жиреет. Его цикл сканирования (Scan Time), который в идеале должен составлять пару миллисекунд, начинает задыхаться и переваливает за сто или даже двести миллисекунд. Сторожевой таймер (Watchdog) смотрит на этот ужас с нескрываемым раздражением и уже держит палец на кнопке экстренной остановки процессора. Оборудование начинает реагировать с задержкой, пневмоцилиндры промахиваются мимо позиций, а инженеры чешут затылки, думая, что нужно просто купить процессор подороже.

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

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

Эта дорожка состоит из нескольких строгих этапов. Сначала контроллер читает физические входы (собирает данные с датчиков). Затем он выполняет пользовательскую программу (ваш код). После этого он записывает результаты в физические выходы (щелкает клапанами). И в самом конце он делает глубокий вдох - выполняет системные задачи, общается с панелями оператора (HMI) по сети и проводит самодиагностику. После этого забег начинается заново.

Если вы пишете плохой, тяжелый код, этап выполнения программы растягивается. Контроллер бежит по дорожке все медленнее. Физическому миру плевать на ваши сложные алгоритмы. Если бутылка на конвейере пролетает мимо оптического датчика за десять миллисекунд, а ваш контроллер думает над кодом пятьдесят миллисекунд, он просто не заметит эту бутылку. Она улетит в стену, на заводе будет лужа пива, а виноваты будете вы. Поэтому первое правило диетолога АСУ ТП: код должен быть быстрым, как рефлекс.

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

Спросите себя честно: вам действительно нужно вычислять уровень жижи в танке с точностью до четырнадцатого знака после запятой? Да ваш аналоговый датчик давления врет на один процент просто из-за того, что в цеху открыли форточку! Перестаньте гонять по сети тяжелые типы REAL там, где это не нужно. Старая школа АСУ ТП учит нас использовать целые числа (INT или DINT) с подразумеваемой запятой. Если вам нужна точность до сотых долей, просто умножьте значение на сто и работайте с целым числом. Уровень 54.32 процента превращается в целое число 5432. Целочисленная математика выполняется в процессоре за один такт. Это чистый протеин для вашего контроллера.

А теперь поговорим про абсолютное зло - текстовые строки (тип STRING). Строки в ПЛК - это как поход в ресторан быстрого питания в три часа ночи. ПЛК вообще не созданы для обработки текста. Если вы пишете логику, в которой контроллер склеивает строки, ищет подстроки или, упаси боже, пытается парсить JSON-формат прямо в языке Structured Text (ST), санитары из психиатрической клиники автоматизаторов уже выехали за вами.

Работа со строками чудовищно фрагментирует память и съедает циклы процессора, потому что контроллер вынужден перебирать массивы символов по одному байту. Оставьте работу с текстом панелям оператора, SCADA-системам или специализированным Edge-шлюзам. Контроллер должен оперировать битами, байтами и целыми числами. Точка.

Айтишники, которые приходят в промышленную автоматизацию из мира веб-разработки, любят писать код так, будто у них под капотом сервер с 64 гигабайтами оперативной памяти. Они создают массивы из тысячи булевых переменных (тип BOOL), чтобы хранить статусы аварий.

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

Правильная инженерная кето-диета - это ручная упаковка битов. Возьмите одну переменную типа DWORD (32 бита). Внутри этого одного слова вы можете математически упаковать тридцать два различных аварийных сигнала, обращаясь к ним через точку (например, AlarmWord.0, AlarmWord.1 и так далее). Вы не только экономите память в тридцать два раза, но и радикально ускоряете передачу данных на SCADA-систему. Вместо того чтобы SCADA запрашивала тридцать два отдельных тега по сети, она забирает одно слово за один микроскопический сетевой пакет и сама распаковывает его на экране диспетчера.

Здесь же кроется коварная проблема выравнивания памяти (Memory Alignment). Современные 32-битные процессоры внутри ПЛК любят читать память ровными блоками по 4 байта. Если вы создаете пользовательский тип данных (UDT), в котором сначала идет один BOOL, затем тяжелый REAL (4 байта), а затем снова один BOOL, компилятор придет в ужас. Чтобы процессору было удобно читать REAL, компилятор набьет пустые "мусорные" байты (Padding) между вашими переменными. Ваша структура разбухнет, как дрожжевое тесто. Правильный подход - группировать переменные по размеру. Сначала объявляйте все тяжелые LREAL и REAL, затем DINT, потом INT, и в самом конце плотной кучей сваливайте все BOOL. Так структура займет минимально возможный объем оперативной памяти без единого пустого байта.

Огромная проблема раздутого времени цикла (Scan Time) заключается в том, что программисты заставляют ПЛК выполнять абсолютно весь код в каждом цикле сканирования.

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

Примените к вашему коду интервальное голодание. В любом уважающем себя ПЛК есть циклические прерывания (Cyclic Interrupts) или возможность создавать отдельные задачи (Tasks) с разным приоритетом и временем вызова.

Оставьте в главной, самой быстрой задаче (Main Task, вызываемой каждый цикл) только критическую логику: концевики безопасности, аварийные блокировки, быстрые датчики положения и энкодеры. Всю тяжелую математику, ПИД-регуляторы температуры, вычисление статистики и расчеты для SCADA вынесите в медленную задачу, которая будет просыпаться ровно один раз в сто миллисекунд, делать свои дела и снова засыпать. Ваш основной цикл сканирования мгновенно похудеет в три раза, а клапаны начнут закрываться с математической точностью.

Кроме того, используйте условные вызовы функциональных блоков. Если автоматический режим станка выключен, зачем ваш контроллер продолжает каждый цикл обрабатывать внутри себя логику движения в автоматическом режиме? Поставьте простое условие (IF AutoMode THEN...), и если условие ложно, процессор просто перепрыгнет этот огромный кусок кода за наносекунду, не тратя на него свои вычислительные калории.

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

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

Этот мусор не только съедает драгоценную память загрузки (Load Memory), из-за чего вам приходится покупать более дорогие SD-карты для контроллера. Этот мусор делает невыносимым процесс отладки. Когда вы ищете перекрестные ссылки (Cross-References) для переменной, среда разработки вываливает вам сотни совпадений в мертвых, неиспользуемых блоках.

Проведите генеральную уборку. В современных средах разработки (например, в TIA Portal или Codesys) есть встроенные инструменты поиска неиспользуемых переменных. Нажмите эту кнопку, глубоко вдохните и удалите весь список. Не бойтесь удалять закомментированный код. Для хранения старых версий существуют системы контроля версий (Git, SVN, или специализированные системы типа Octoplant). ПЛК - это устройство исполнения логики реального времени, а не архив пыльных исторических документов.

Любая промышленная программа кишит таймерами (TON, TOF, TP). И каждый такой таймер стандарта IEC 61131-3 требует своего собственного блока памяти (Instance Data Block), где он хранит текущее время, уставку и состояние выхода.

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

Но контроллер уже всё придумал за вас. Практически в любом ПЛК есть так называемый системный байт тактовых импульсов (Clock Memory Byte). Вы просто ставите галочку в настройках процессора, и контроллер начинает аппаратно пульсировать битами этого байта с разной частотой: один бит мигает с частотой один герц, другой - два герца, третий - пять герц. Вам вообще не нужны таймеры для мигания лампочками! Просто возьмите этот готовый системный бит и привяжите его к вашему выходу.

Более того, если вам нужно отслеживать задержки для ста разных клапанов, не обязательно создавать сто таймеров. Продвинутые инженеры используют один системный счетчик миллисекунд процессора (System Time). Когда клапан получает команду на открытие, программа просто запоминает текущее значение системного времени в обычную целочисленную переменную DINT. А на следующем цикле математически вычитает старое время из нового. Если разница превысила три тысячи миллисекунд (три секунды), а концевик клапана не сработал - выдаем аварию. Вы заменили тяжелый блок таймера одним простым математическим вычитанием. Это экономит память так же эффективно, как отказ от ужина экономит вашу талию.

Пользовательские типы данных (UDT) - это великолепный инструмент, который делает код читаемым и структурированным. Вы создаете тип "Насос", запихиваете туда команду старта, статус работы, ток и температуру. Все красиво.

Но некоторые программисты впадают в архитектурный экстаз и начинают вкладывать UDT друг в друга до бесконечности. Они создают структуру "Завод", внутри нее массив "Цехов", внутри цеха массив "Линий", внутри линии массив "Станций", а уже там лежат насосы. Эта гигантская информационная матрешка весит сотни килобайт.

Катастрофа наступает в тот момент, когда программист решает передать эту гигантскую матрешку внутрь функционального блока (FB) или функции (FC) в качестве входного параметра (Input). По законам архитектуры ПЛК (передача по значению - Pass by Value), в момент вызова функции контроллер берет эту гигантскую структуру и физически копирует ее бит в бит в другую область памяти, чтобы функция могла с ней работать. На копирование сотен килобайт уходит драгоценное процессорное время. А если функция вызывается в цикле FOR сто раз подряд? Ваш цикл сканирования просто улетает в космос.

Золотое правило диетологии АСУ ТП: тяжелые структуры данных всегда должны передаваться в функции исключительно по ссылке (Pass by Reference). В стандарте IEC это реализуется через зону IN_OUT (или с помощью указателей POINTER/REFERENCE, если вы не боитесь олдскульного программирования). В этом случае контроллер не копирует структуру. Он просто передает функции крошечный адрес (ссылку) на то место в памяти, где эта матрешка уже лежит. Функция идет по этому адресу и читает данные напрямую. Экономия памяти и времени исполнения при таком подходе просто фантастическая.

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

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

Желаете, чтобы я более глубоко разобрал процесс работы с указателями (Pointers) и косвенной адресацией в языке Structured Text для еще более экстремальной экономии памяти при обработке больших массивов данных?