Контрольные суммы проектов в экосистеме Siemens Step7 Classic

Владислав Иванов — Fri, 14 Aug 2026 10:13:00 +0000

Автор: Владислав Иванов, инженер АСУ ТП компании UDV Group

С 1 октября 2025 года Siemens официально перевёл SIMATIC S7-300 и ET 200M в стадию Product Phase-Out: новых заказов не принимают, более 260 модулей доступны только как запчасти, поддержка постепенно сворачивается. S7-400 идёт тем же путём с горизонтом до 2030 года. Для российских предприятий картина ещё жёстче: вендор ушёл с рынка в 2022-м, официальных обновлений и патчей нет уже несколько лет, а парк S7-300/400 продолжает управлять энергоблоками, насосными, химией и металлургией. В этой ситуации у главного инженера и службы ИБ остаётся один вопрос: программа, которая сейчас реально работает на контроллере, соответствует утверждённой версии проекта? И как это доказать без вендорской поддержки? Ответ на уровне первичного контроля лежит в четырёх байтах.

Что показывает checksum

В S7-300/400 контроллер хранит два коротких значения: контрольную сумму аппаратной конфигурации (System Data) и контрольную сумму пользовательской программы (User Program). По четыре байта каждая, например A4 00 25 10 и A0 37 E0 41. Увидеть их можно через Simatic Manager: правой кнопкой на папке Blocks, Object Properties, вкладка Checksums. Открывается и для проекта на инженерной станции, и для проекта, снятого с контроллера. Практическая ценность простая: суммы совпадают, значит программа в ПЛК соответствует утверждённой версии. Суммы разошлись, это повод разобраться, что и когда изменилось. Это самый лёгкий индикатор целостности, который можно снять с работающего контроллера. Не требует остановки процесса, не грузит канал, снимается по расписанию. Для парка S7-300/400 без вендорской поддержки это часто единственный доступный сенсор изменений на уровне самого ПЛК.

Сначала предупреждение

Прежде чем строить на checksum систему мониторинга целостности, нужно понимать, к чему он чувствителен, а к чему слеп. Если этого не сделать, получится один из двух плохих сценариев. Первый: постоянные ложные тревоги, из-за которых операторы и инженеры перестанут реагировать вообще. Второй: тишина в консоли мониторинга при реальных изменениях, которые checksum просто не увидит.

Ниже три поведенческие особенности, о которые чаще всего спотыкаются на практике.

Особенность 1. Изменение значений в реальном времени контрольную сумму не трогает

Если инженер зайдёт в контроллер онлайн и через таблицу PLC, Monitor/Modify Variables изменит текущее значение переменной в блоке данных (например, запишет новое значение в DB127.DBW0), контрольная сумма ПЛК останется прежней. Правка данных в рабочей памяти на checksum не отражается. Это осмысленное поведение. Значения переменных в DB - это текущие показания процесса: уровень в резервуаре, температура, положение задвижки, уставка регулятора. Они меняются десятки раз в секунду просто потому, что процесс работает. Если бы checksum реагировал на каждое такое изменение, он бы менялся непрерывно и терял смысл как индикатор целостности. Поэтому он чувствителен к самой программе и конфигурации, а не к результатам их работы.

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

Особенность 2. Правка Actual Value в проекте на инженерной станции меняет сумму

Обратная сторона той же логики. Если открыть тот же блок данных в проекте на инженерной станции (режим Data View) и изменить поле Actual Value той же переменной, а затем сохранить блок, контрольная сумма User Program поменяется. Причина: в исходнике блока Actual Value хранится наравне с Initial Value и является частью описания блока, а не текущего состояния. С точки зрения среды разработки это изменение проекта.

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

Особенность 3. Upload одного блока и Upload всей станции ведут себя по-разному

Здесь нужно различать два похожих на первый взгляд действия.

Upload to PG для конкретного блока (правой кнопкой на блоке, PLC, Upload to PG) - это выгрузка одного DB. При таком поблочном Upload среда Step7 заставляет ПЛК собрать блок «на лету», внедрив в его структуру текущие значения из рабочей памяти. Результат: в проекте на инженерной станции поле Actual Value обновляется, значит и контрольная сумма User Program у проекта меняется. В самом ПЛК сумма при этом остаётся прежней, потому что Upload читает данные из контроллера, но ничего не пишет обратно в его память.

Upload Station to PG (выгрузка всей станции целиком) работает иначе. При полной выгрузке актуальные значения из рабочей памяти в проект не переносятся. Среда считывает блоки из загрузочной памяти ПЛК, и выгруженные DB получают старые Initial-значения вместо живых значений из рабочей памяти. Контрольная сумма проекта после такой операции не меняется.

*Практический вывод: *одинаковое по смыслу действие «синхронизировать проект с контроллером» может как изменить checksum на инженерной станции, так и оставить его прежним. Для системы мониторинга это значит, что событие «инженер снял бэкап» должно фиксироваться регламентом отдельно, а не выводиться из показаний checksum.

Почему checksum ведёт себя именно так

Вся эта механика объясняется устройством памяти S7-300/400. В контроллере есть три различных области хранения программы.

Загрузочная память (Load memory). Сюда попадает вся программа при Download из Simatic Manager: блоки OB, FB, FC, DB целиком, с комментариями, символикой и полными Initial Value. Физически это либо встроенная память CPU, либо съёмная карта MMC. Загрузочная память энергонезависима, программа не пропадает при отключении питания.

Рабочая память (Work memory). Это RAM, из которой CPU исполняет программу в цикле. Сюда копируется только то, что нужно для выполнения: без комментариев и символьных имён, но с актуальными значениями переменных. Здесь живут те правки, которые делает Monitor/Modify Variables.

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

Checksum считается только по одному из трёх слоёв: по загрузочной памяти. Отсюда вся логика поведения, которую разобрали выше.

Отдельный риск: Download блока данных может обнулить актуальные уставки

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

Когда инженер выполняет Download блока данных из проекта в ПЛК (например, чтобы залить исправленную логику или новую версию DB), в рабочую память вместе с блоком записываются и значения переменных. Особенность S7-300/400: офлайн-блок DB хранит собственное поле Actual Value, и именно оно, а не Initial Value, попадает в ПЛК как новое рабочее значение. По сути, проект на инженерной станции хранит замороженный снимок Actual Value с момента последней синхронизации или с момента создания блока. Если с тех пор процесс эксплуатировался, а оператор менял уставки прямо на ПЛК, эти изменения в проекте никак не отражаются.

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

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

С точки зрения информационной безопасности это полноценный вектор атаки: заливка «правильно выглядящего» блока с подменёнными Actual Value позволяет незаметно вывести процесс из штатного режима, вообще не трогая логику программы. Для внешнего аудита checksum User Program такого блока будет выглядеть просто как результат легитимного Download.

Причина в самой механике загрузки. Блок данных в S7-300/400 не редактируется дельтой (по принципу «поменялось только это поле, остальное не трогаем»). При загрузке блок целиком перезаписывается заново, как единый объект. У CPU нет встроенного механизма построчной сверки, и компилятор Step7 формирует блок так, как он описан в исходнике проекта. Значение из поля Actual Value офлайн-блока записывается в работающий ПЛК как новое рабочее значение, полностью заменяя то, что было в рабочей памяти.

Практическая рекомендация: перед любым Download блока данных на действующий ПЛК критично убеждаться, что проект на инженерной станции синхронизирован с актуальными уставками (например, через предварительный Upload актуального состояния). Полагаться на «старую» версию в репозитории или на диске одного инженера, значит планово идти к инциденту.

Отдельно стоит упомянуть, что в более новых S7-1200 и S7-1500 (TIA Portal) поле Actual Value в офлайн-блоке данных убрали. Проект хранит только Initial Value, а фактические рабочие значения живут исключительно в памяти ПЛК. Это архитектурное решение снимает описанный класс рисков. Проблема остаётся именно на парке S7-300/400, который вероятно на многих российских предприятиях ещё долго будет частью действующей инфраструктуры.

Как снимать checksum по сети

Для системы непрерывного мониторинга ручной способ через Simatic Manager не подойдет. И заходить в инженерное ПО каждый раз не требуется: ПЛК отдаёт контрольные суммы прямо по протоколу S7COMM в ответ на запрос [CPU functions], Read SZL с ID=0x0132, Index=0x0004. Нужные значения лежат в полях ken_ver1_hw / ken_ver2_hw (аппаратная часть) и ken_ver1_awp / ken_ver2_awp (пользовательская программа).

Автоматизация через python-snap7 сводится к трём шагам. Установить соединение с ПЛК командой client.connect(ip, rack, slot). Выполнить client.read_szl(306, 4) - это тот же запрос SZL ID=0x132 (306 в десятичном виде), Index=4. Распарсить полученные байты по смещениям с 16 по 23, где лежат пары байт контрольных сумм.

Такой подход позволяет снимать checksum по расписанию с любого числа контроллеров в сети и сравнивать с эталонными значениями. По сути, получается лёгкий сенсор целостности логики ПЛК без нагрузки на канал и без остановки процесса. Для парка S7-300/400 без вендорской поддержки это, вероятно, единственный доступный способ автоматизировать хотя бы первичный контроль изменений.

Итого: с чего начать на своём парке

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

Инвентаризация. Зафиксировать, какие S7-300 и S7-400 работают на объекте, какие версии CPU и прошивки, где хранятся эталонные проекты, кто из инженеров имеет доступ к загрузке.
Синхронизация эталонов. Перед первой фиксацией эталонных значений убедиться, что проекты в репозитории соответствуют реальному состоянию контроллеров. Это отдельная и часто недооценённая работа: во многих организациях эталонный проект последний раз обновлялся в момент ввода в эксплуатацию.
Фиксация эталонных оценок. Снять и задокументировать контрольное количество системных данных и пользовательской программы для каждого контроллера. Хранить не в файле на диске одного инженера, а в системе с контролируемым доступом.
Регламент состояния. Прописать, что делать при рассчете суммы. Какие изменения проекта являются законными и как они зафиксированы заранее. Кто расследует несанкционированное прохождение. В каком порядке проводится проверка и восстановление.

Вместо вывода

Контрольная сумма в S7-300/400 не заменяет полноценную систему контроля целостности, но даёт то, чего в российской промышленности сейчас часто не хватает: доказуемый первичный ответ на вопрос «программа в контроллере та же, что была принята в эксплуатацию, или нет». Без вендора, без дорогого инструментария, по обычному сетевому запросу.

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

Если на эти вопросы точных ответов нет, снимать контрольную сумму бесполезно: индикатор без регламента реагирования, это просто число на экране. Если есть, четыре байта становятся первой линией контроля логики контроллера, работающего без поддержки вендора. Для парка S7-300/400 в российской критической инфраструктуре - это рабочий сценарий, а не теория.

DEV Community: Владислав Иванов

Контрольные суммы проектов в экосистеме Siemens Step7 Classic