Содержание
Читайте в Telegram
|
На промышленном объекте может быть утвержденный проект, архив на инженерной станции, резервная копия в сетевой папке и уверенность, что программа контроллера соответствует документации.
Но сам ПЛК может выполнять уже другую логику. После пусконаладки, ремонта, локальной доработки, действий подрядчика или аварийного вмешательства проект на диске и программа в контроллере начинают жить разной жизнью.
Пока оборудование работает, это расхождение часто не видно. Линия выполняет план, SCADA показывает привычные параметры, операторы не жалуются, технологический процесс не остановлен. Но при сбое главный инженер и служба ИБ сталкиваются с простым и неприятным вопросом: какая программа прямо сейчас управляет оборудованием и совпадает ли она с утвержденной версией.
Для парка Siemens S7-300 и S7-400 этот вопрос стал особенно острым. Siemens перевел SIMATIC S7-300 и ET 200M в стадию Product Phase-Out, S7-400 также движется к завершению жизненного цикла, а в российских условиях официальная поддержка и обновления фактически недоступны уже несколько лет. При этом такие контроллеры продолжают работать в энергетике, насосных, химии, металлургии и других промышленных сегментах.
В этой ситуации предприятию нужен не идеальный, а доступный и проверяемый способ первичного контроля: программа в контроллере та же или нет. Для S7-300/400 таким индикатором могут стать контрольные суммы.
Старый ПЛК не становится безопаснее от того, что он продолжает работать
Оборудование S7-300/400 установлено на многих объектах не потому, что оно новое, а потому что оно надежно, давно встроено в технологический процесс и будет эксплуатироваться еще долго. В промышленности жизненный цикл контроллера часто измеряется десятилетиями. Замена ПЛК - это не покупка нового сервера. Это изменение проекта, проверка логики, испытания, остановы, совместимость с оборудованием и риск для производства.
Поэтому предприятия продолжают жить с контроллерами, для которых вендорская поддержка постепенно исчезает, а привычная модель обновлений, патчей и консультаций уже не работает. Но технологическая ответственность остается. Нужно понимать, какая программа выполняется на устройстве, кто ее менял, когда, почему и совпадает ли она с эталоном.
Здесь и возникает разница между «контроллер работает» и «контроллер работает в подтвержденном состоянии». Первый факт виден по технологическому процессу. Второй нужно доказывать.
«Для парка Siemens S7-300/400 без полноценной вендорской поддержки контрольная сумма становится простым первичным ответом на вопрос, который волнует и главного инженера, и службу ИБ: программа в контроллере соответствует утвержденной версии проекта или уже нет. Это не полноценная система контроля целостности, но это доступный сенсор изменений на уровне самого ПЛК», - говорит Владислав Иванов, инженер АСУ ТП компании UDV Group.
В этом смысле checksum важен не как техническая мелочь, а как минимальная точка опоры. Он не объясняет все, но помогает понять, есть ли расхождение, которое нужно расследовать.
Что знают четыре байта
В S7-300/400 контроллер хранит два коротких значения. Одно относится к аппаратной конфигурации, System Data. Второе - к пользовательской программе, User Program. Каждое занимает четыре байта. Их можно увидеть через Simatic Manager в свойствах папки Blocks на вкладке Checksums.
Практический смысл простой. Если контрольные суммы проекта на инженерной станции и проекта, снятого с контроллера, совпадают, это признак соответствия. Если они разошлись, значит, что-то изменилось и нужно понять, где именно появилось расхождение.
Для предприятия ценность такого подхода в его легкости. Контрольную сумму можно снять с работающего контроллера. Для этого не нужно останавливать технологический процесс, сильно нагружать канал или вмешиваться в логику ПЛК. При автоматизации такой запрос можно выполнять по расписанию и сравнивать полученные значения с эталоном.
Это особенно важно для старого парка. Там не всегда доступны современные средства контроля целостности, не всегда есть поддержка вендора, не всегда можно поставить дополнительные агенты или изменить архитектуру. Но даже первичный индикатор «совпало - не совпало» уже снижает слепоту.
Главное - не переоценивать его. Checksum не является магическим доказательством безопасности. Он показывает изменение определенного слоя, но не видит все действия с контроллером.
Checksum видит программу, но не видит все состояние процесса
Перед тем как строить мониторинг на контрольных суммах, нужно понимать, к чему они чувствительны, а к чему нет. Иначе предприятие быстро придет к одной из двух ошибок. Первая - ложные тревоги, из-за которых инженеры перестанут реагировать. Вторая - спокойная консоль при реальных изменениях, которые checksum не отслеживает.
Важное ограничение касается значений в реальном времени. Если инженер подключился к контроллеру онлайн и через Monitor/Modify Variables изменил текущее значение переменной в блоке данных, контрольная сумма ПЛК не изменится. Это нормально. Значения переменных в DB отражают текущий процесс: уровень, температуру, положение задвижки, уставку, промежуточное состояние. Они могут меняться постоянно. Если бы checksum реагировал на каждое такое изменение, он бы потерял смысл.
Поэтому контрольная сумма чувствительна к программе и конфигурации, а не ко всем текущим значениям рабочей памяти. Из этого следует практический вывод: изменение уставки прямо на ПЛК checksum может не показать. Такой риск нужно закрывать другими средствами: журналами диспетчерской системы, регламентами изменения уставок, разграничением прав и отдельным контролем действий инженеров.
«Checksum нельзя воспринимать как всевидящий контроль. Он рассчитан на проверку целостности программы и конфигурации, но не показывает каждое изменение технологических значений в рабочей памяти. Если оператор или инженер меняет уставку прямо на ПЛК, это ограничение нужно закрывать журналами SCADA, регламентом изменения уставок и контролем прав», - отмечает Владислав Иванов, инженер АСУ ТП компании UDV Group.
Это важный момент для руководителя. Контрольная сумма полезна только тогда, когда предприятие понимает ее границы. Иначе число на экране создает ложное чувство защищенности.
Проект на инженерной станции живет иначе, чем контроллер
У S7-300/400 есть особенность, которая часто создает путаницу. Если изменить Actual Value в проекте на инженерной станции, контрольная сумма User Program у проекта поменяется, даже если в ПЛК ничего не загружали. Для среды разработки это изменение проекта, потому что Actual Value хранится в исходнике блока наряду с Initial Value.
Получается странная, но важная ситуация. В контроллере программа не менялась. На инженерной станции проект изменился. Суммы разошлись. Это не обязательно инцидент, но это расхождение между эталоном и фактическим состоянием контроллера, которое нужно объяснить и зафиксировать.
Еще сложнее выглядит операция Upload. Если выгружать один блок через Upload to PG, Step7 собирает блок «на лету» и внедряет в его структуру текущие значения из рабочей памяти. В проекте на инженерной станции поле Actual Value обновляется, поэтому checksum проекта меняется. Сам ПЛК при этом не меняется.
Если выгружать всю станцию целиком через Upload Station to PG, поведение другое. Среда считывает блоки из загрузочной памяти, актуальные значения из рабочей памяти в проект не переносятся, и контрольная сумма проекта не меняется.
Для инженера оба действия могут звучать как «снять проект с контроллера». Для мониторинга это разные сценарии. Один меняет checksum проекта на инженерной станции, другой нет. Поэтому событие бэкапа нельзя выводить только из значения контрольной суммы. Оно должно фиксироваться отдельным регламентом.
Иначе предприятие получит тревогу там, где был обычный Upload, или, наоборот, не поймет, почему эталон начал расходиться с контроллером без фактической загрузки новой логики.
Причина в трех слоях памяти
Поведение checksum объясняется архитектурой памяти S7-300/400. В контроллере и вокруг него фактически существуют три слоя.
Первый - загрузочная память, Load memory. Туда попадает программа при Download из Simatic Manager: блоки OB, FB, FC, DB, комментарии, символика и Initial Value. Это энергонезависимая память, которая сохраняет программу после отключения питания.
Второй - рабочая память, Work memory. Это RAM, из которой CPU исполняет программу в цикле. Здесь живут актуальные значения переменных и те изменения, которые выполняются через Monitor/Modify Variables.
Третий - проект на инженерной станции. Это отдельная сущность, которая синхронизируется с загрузочной памятью через Download и Upload, но напрямую не равна рабочей памяти.
Checksum считается по загрузочной памяти. Именно поэтому он не реагирует на все текущие значения процесса, но реагирует на изменения проекта и программы, которые попадают в соответствующий слой. Для специалиста это техническая деталь. Для руководителя - объяснение, почему один индикатор не заменяет весь контроль изменений.
Самый опасный сценарий - загрузить старый DB в работающий ПЛК
Из этой трехслойной архитектуры вытекает риск, который уже напрямую связан с производством. Когда инженер выполняет Download блока данных из проекта в ПЛК, в рабочую память вместе с блоком записываются значения переменных. В S7-300/400 офлайн-блок DB хранит Actual Value, и именно он попадает в ПЛК как новое рабочее значение.
Это значит, что проект на инженерной станции может хранить замороженный снимок Actual Value с момента последней синхронизации или создания блока. Если с тех пор оператор менял уставки прямо на ПЛК, эти изменения в старом проекте не отразились. При загрузке такого DB обратно в контроллер актуальные уставки могут быть перезаписаны значениями многолетней давности.
На практике операция «перезалить один блок» может сбросить параметры температуры, давления, скорости, положения задвижек и других технологических величин. Для непрерывного производства это уже не проблема версии файла. Это риск скачка технологических параметров, срабатывания защит, повреждения оборудования или аварийной остановки.
С точки зрения ИБ такой сценарий важен еще и потому, что его можно использовать как вектор атаки. Достаточно загрузить правильно выглядящий блок с подмененными Actual Value. Логика программы формально может выглядеть легитимно, а процесс уйдет из штатного режима за счет измененных рабочих значений.
«В S7-300/400 Download блока данных опасен тем, что он перезаписывает DB как единый объект. Вместе с блоком в ПЛК могут попасть устаревшие Actual Value из проекта на инженерной станции. Для производства это означает риск одномоментно сбросить актуальные уставки температуры, давления, скорости или положения исполнительных механизмов к старым значениям», - подчеркивает Владислав Иванов, инженер АСУ ТП компании UDV Group.
Это уже не тонкость Step7. Это пример того, как инженерная операция превращается в производственный риск.
Новые линейки частично сняли проблему, старый парк остался
В более новых S7-1200 и S7-1500 в TIA Portal поле Actual Value в офлайн-блоке данных убрали. Проект хранит Initial Value, а фактические рабочие значения живут в памяти ПЛК. Такое архитектурное решение снижает описанный класс рисков.
Но российским предприятиям это помогает только там, где уже внедрены новые линейки. Парк S7-300/400 останется в эксплуатации еще долго. Он продолжает работать на важных объектах, встроен в технологические процессы и часто не может быть заменен быстро.
Поэтому для старых контроллеров нужен не только план модернизации, но и план текущего контроля. Какие CPU стоят на площадках. Где хранятся эталонные проекты. Кто имеет право на загрузку. Когда последний раз проект синхронизировался с контроллером. Какие значения checksum считаются эталонными. Кто реагирует на расхождение и в какой срок.
Без этого предприятие остается в режиме надежды: контроллер работает, значит, все хорошо. Но работающий контроллер не доказывает, что его логика соответствует принятой версии.
Контрольную сумму можно снимать автоматически
Ручная проверка через Simatic Manager полезна для диагностики, но не подходит для постоянного мониторинга. Инженер не будет регулярно заходить в каждый проект и вручную сравнивать значения на всем парке контроллеров.
Для S7-300/400 checksum можно получать по сети через S7COMM. Контроллер отдает контрольные суммы в ответ на запрос CPU functions, Read SZL с ID 0x0132 и Index 0x0004. Нужные значения находятся в полях, относящихся к аппаратной части и пользовательской программе.
Автоматизация позволяет снимать эти значения по расписанию, сравнивать их с эталоном и поднимать событие при расхождении. По сути, это легкий сенсор целостности логики ПЛК. Он не останавливает процесс, не требует постоянного входа в инженерное ПО и может работать на множестве контроллеров.
Но автоматизация не отменяет регламента. Если система обнаружила расхождение, должно быть понятно, кто его разбирает. Было ли изменение согласованным. Есть ли заявка. Кто выполнял Download. Какая версия проекта считается эталонной. Нужно ли останавливать работы, уведомлять ИБ, подключать службу АСУ ТП или готовить восстановление.
Без этих правил автоматический мониторинг превращается в еще один источник тревог. Число есть, отклонение есть, а решения нет.
Начинать нужно не с инструмента, а с инвентаризации
Перед мониторингом checksum нужно пройти подготовительный этап. Сначала зафиксировать, какие S7-300 и S7-400 реально работают на объекте. Какие версии CPU и прошивки используются. Где хранятся эталонные проекты. Кто имеет доступ к загрузке. Какие инженерные станции применяются. Какие контроллеры критичны для технологического процесса.
Затем нужно синхронизировать эталоны. Это отдельная работа, которую часто недооценивают. Во многих организациях эталонный проект последний раз обновлялся при вводе объекта в эксплуатацию. С тех пор были ремонты, наладки, корректировки уставок, изменения логики, вмешательства подрядчиков и локальные доработки. Считать старый архив эталоном без проверки нельзя.
После этого фиксируются эталонные значения контрольных сумм для каждого контроллера. Хранить их нужно не в файле на рабочем столе одного инженера, а в системе с контролируемым доступом и понятной историей изменений.
И только затем появляется регламент состояния. Что считается легитимным изменением. Как оно заранее фиксируется. Кто утверждает новую версию. Кто расследует несанкционированное расхождение. В каком порядке проводится проверка и восстановление.
Число без регламента не защищает
Контрольная сумма дает быстрый ответ на вопрос «совпало или нет». Но она не отвечает на вопрос «что делать дальше». Если предприятие не определило владельцев, правила реакции и порядок расследования, checksum останется просто числом на экране.
При совпадении нужно понимать, что именно подтверждено, а что нет. Совпадение checksum говорит о соответствии контролируемого слоя, но не отменяет проверку уставок, журналов операторских действий, прав доступа и других источников. При расхождении нужно понимать, кто проверяет проект, где искать заявку, как сопоставлять изменения и когда принимать решение о возврате к предыдущей версии.
Главное - не превращать контрольную сумму в формальность. Она полезна только как часть процесса управления изменениями ПЛК. В этом процессе есть эталон, доступ, событие, расследование, решение и восстановление.
Если на предприятии нет точных ответов на вопросы, какая программа реально работает в контроллере, где хранятся эталонные проекты, совпадают ли они с ПЛК, кто фиксирует легитимные изменения и что произойдет при загрузке устаревшего DB, начинать с автоматизации преждевременно.
Сначала нужно навести порядок в самой модели управления логикой контроллера.
