ПАЗ и загазованность: Почему защиту нельзя прятать в обычную автоматику

Система контроля загазованности выглядит для оператора почти как обычная часть АСУ ТП: на экране есть датчики, проценты или мг/м3, цветовые зоны, аварии, сирена, журнал событий. Из-за этого возникает опасное упрощение: раз всё уже видно на HMI, значит можно сделать отключение в том же обычном ПЛК, где живут пуски, уставки, рецепты и архив.

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

Поэтому вопрос не в том, «может ли обычная автоматика прочитать датчик газа». Может. Вопрос в другом: имеет ли она право быть единственным слоем, от которого зависит отключение, сирена и безопасное состояние. На многих объектах ответ будет отрицательным, и это лучше понять на стадии проекта, а не после пуска.

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

Здесь есть два разных режима. Первый - информационный: показать концентрацию, дать предупреждение, записать тренд, вывести сообщение смене. Второй - защитный: выполнить действие, которое не должно зависеть от того, успел ли оператор нажать кнопку или открыта ли мнемосхема.

Обычная АСУ ТП отлично работает с первым режимом. Она удобна для визуализации, архива, отчетов, анализа причин. Но когда речь идет о защите, появляется ПАЗ - противоаварийная автоматическая защита. Она не конкурирует с SCADA и технологическим ПЛК, а закрывает другую ответственность: не дать событию развиться до опасного сценария.

Хорошая граница обычно формулируется не по названию шкафа, а по вопросу: что должно произойти без участия человека и без надежды на верхний уровень?

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

В статье «Граница между ПЛК и Safety PLC» мы разбирали похожий принцип для машинной безопасности: обычный ПЛК управляет процессом, safety-контур отвечает за перевод в безопасное состояние. В ПАЗ логика та же, только контекст другой: вещество, концентрация, пороги, вентиляция, отсечки, оповещение и действия смены.

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

Обычная технологическая автоматика живет в режиме постоянных изменений. В ней добавляют ручной режим, меняют уставки, расширяют HMI, временно обходят датчик на пуске, правят блокировки, меняют текст аварии, переносят теги в SCADA. Это нормальная жизнь АСУ ТП. Но защитная функция не должна становиться побочным эффектом этой жизни.

Самый плохой сценарий выглядит тихо. На пуске датчик загазованности мешает испытаниям, его «временно» отключают в программе. Затем меняют экран, забывают вернуть признак блокировки. Потом оператор видит аварию, но сирена не включается, потому что кто-то сделал квитирование удобнее. Через месяц никто уже не помнит, где именно в логике спрятан обход.

ПАЗ как отдельная защитная функция нужна не для красоты архитектуры. Она нужна, чтобы было понятно:

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

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

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

Ошибка - делать все пороги одинаковыми «авариями на экране». Тогда смена быстро привыкает квитировать сообщения, не разделяя информационный шум и защитное событие. Еще хуже, когда аварийный порог можно обойти тем же способом, что и обычное предупреждение о низком уровне или перегреве второстепенного узла.

Порог ПАЗ должен быть оформлен как событие с понятной реакцией. Не просто «красная лампа», а конкретный сценарий: что отключается, что включается, что блокируется, кто получает сигнал, где фиксируется время, как выполняется восстановление.

Обычная АСУ ТП может красиво показать этот сценарий оператору. Но она не должна быть единственным местом, где он существует.

Сирена в такой системе - не декоративный выход. Если она нужна по сценарию защиты, ее тестируют, фиксируют и обслуживают. То же касается световой сигнализации, отсечных клапанов, вентиляции и отключающих цепей.

Журнал тоже бывает разным. SCADA-журнал удобен для разбора: когда начался рост концентрации, кто квитировал, какие команды были на оборудовании, что происходило рядом. Но журнал защитной функции должен отвечать на более жесткие вопросы: был ли датчик в исправном состоянии, был ли обход, кто его разрешил, прошел ли тест, сработал ли выход, когда восстановили нормальный режим.

Если журнал ПАЗ растворился в общем списке событий «насос включен, насос выключен, оператор открыл экран», потом трудно доказать, что защита действительно была в работе. И еще труднее понять, почему она не сработала.

Система загазованности требует регулярной проверки. Не только «датчик показывает число», а вся цепочка: датчик, порог, логика, сирена, отключение, журнал, восстановление. Иногда проверяют имитацией сигнала, иногда поверочной газовой смесью, иногда отдельной процедурой без воздействия на реальные исполнительные механизмы. Способ зависит от объекта и регламента, но сама идея неизменна: защита должна подтверждаться.

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

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

Таблица специально не делит мир на «только ПАЗ» и «только SCADA». На практике они работают вместе. Разница в том, кто является владельцем решения, а кто помогает видеть, архивировать и обслуживать.

Инженеру АСУ ТП не обязательно превращать каждое обсуждение загазованности в лекцию по SIL. Для старта достаточно задать несколько простых вопросов.

Что является опасным событием? Какие датчики участвуют в его обнаружении? Какие пороги только предупреждают, а какие требуют автоматического действия? Что должно произойти без оператора? Что будет при отказе датчика? Как оформлен байпас? Кто тестирует сирену и отключение? Где хранится журнал проверок? Кто имеет право изменить порог?

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

Обычная АСУ ТП здесь не враг. Наоборот, без нее защита часто становится слепой для оператора. SCADA или HMI показывают концентрации по зонам, состояние датчиков, активные пороги, историю, тренды, действия смены, состояние исполнительных механизмов и причину запрета пуска. Это очень полезно.

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

Хорошая архитектура выглядит спокойно: ПАЗ делает свою работу, АСУ ТП помогает ее видеть и обслуживать, эксплуатация поддерживает датчики, тесты и регламенты. Никто не пытается заменить всех остальных.

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

АСУ ТП показывает, архивирует, помогает смене и дает контекст. ПАЗ обнаруживает опасный порог и выполняет защитное действие. Эксплуатация проверяет датчики, сирены, байпасы и журнал тестов. Когда эти роли смешивают, защита постепенно превращается в набор аварийных сообщений. Когда роли разделены, система остается понятной: что увидели, кто отреагировал, что отключилось, кто проверил и кто имеет право вернуть объект в работу.

•Функциональная безопасность SIL на практике;

•Граница между ПЛК и Safety PLC: когда нужен отдельный контроллер;

•Паспорт объекта АСУ ТП после пуска: что передать заказчику;

•MES и АСУ ТП: где заканчивается рецепт в ПЛК.