Газоанализатор в норме, разрешение не снимает: PAZ-цепочка и задержки

На компрессорной оператор смотрит на индикатор газоанализатора - зелёный, концентрация 0 % LEL. На мнемосхеме блок «разрешение на пуск» красный, кнопка «Пуск» неактивна. Наладчик в отладчике видит CH4_OK=TRUE, а PERMIT_RUN=FALSE. Технолог говорит: «датчик же живой». Вы открываете функциональную схему PAZ и находите цепочку из voting, задержек на снятие, interlock от вентиляции и, возможно, не сброшенный bypass после калибровки.

В стандартной АСУ «норма датчика» и «разрешение на пуск» - не одна переменная. Между ними - логика функциональной безопасности или технологических блокировок с таймерами, подтверждениями, SIL-реле и разными шинами. Статья разбирает PAZ-цепочку и задержки, не подменяя полный курс по IEC 61508 - за оценкой и документами см. практику функциональной безопасности. Отдельно от «дверь открыта - нет разрешения» на HMI: там дискретный концевик без voting 2oo3.

Короткий ответ

Если газоанализатор показывает норму, а разрешение не снимается, идите по цепочке PAZ от сырого сигнала до PERMIT, не по индикатору на корпусе прибора. Проверьте: не активен ли bypass/calibration mode, не держит ли задержка OFF-delay (типично 10-60 с и больше), не провалилось ли voting 2oo3, не блокирует ли другая зона или ESD, совпадает ли тег HMI с safety-тегом. SIL-цепь и стандартная логика часто живут в разных контроллерах - «OK на экране» может быть не тем OK. Таблица ниже: состояние датчика - логика PAZ - что измерить. Приёмка таких цепочек - в чек-листе HMI на FAT.

От датчика к разрешению: не одна переменная

Газоанализатор выдаёт 4-20 мА или цифровой статус по Modbus/HART. В проекте появляются: сырое значение, scaled ppm или % LEL, fault, maintenance, alarm high. «Норма» на дисплее прибора - работа внутренней логики прибора. PAZ-логика может требовать: два из трёх каналов ниже порога, отсутствие fault, стабильность ниже порога не менее T секунд, отсутствие режима калибровки.

Разрешение на пуск (PERMIT, ENABLE, READY) - выход цепочки, который ещё AND с другими условиями: клапаны в позиции, вентиляция работает, ESD не активен, дверь закрыта. Оператор видит один красный значок, причин может быть пять, HMI показывает только агрегированный запрет.

Первый шаг диагностики - cause list на экране наладчика или в SCADA с приоритетом первой невыполненной interlock. Если его нет - проектирование HMI не дотянуло до эксплуатации.

Цепочка в типовом проекте выглядит так: сенсор и электроника прибора, дискретный выход реле «газ OK» или safety вход, voting по нескольким каналам, таймеры после ALARM, итоговый бит Permit как AND всех условий. SCADA может показывать только аналог 0 % LEL, а safety сидит на дискретном контакте - отсюда классический спор «на экране норма».

Задержки ON-delay и OFF-delay в PAZ

Типичная ошибка ожиданий: концентрация упала, индикатор зелёный, а разрешение придёт через 30-120 с. OFF-delay на снятие аварии и ON-delay на выдачу permit после нормализации - разные таймеры. В IEC 61131-3 это TOF и TON. Технолог ждёт мгновенно, проект заложил anti-flutter.

Обратная ситуация: краткий пик концентрации сбросил цепочку, recovery delay 5-30 минут. На экране уже «норма», permit ещё нет - смотрите активный TON PermitDelay или PostGasOK_Delay.

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

В документации PAZ должны быть таблицы: порог, задержка, voting. Если таблицы нет - любая задержка кажется «глюком». На FAT прогоняют сценарии: выход в норму - фиксация времени до permit, вход в аварию - время до отзыва.

Пороги alarm, warning и permit: три разных уровня

Warning «повышенная концентрация» может гореть жёлтым, пока alarm ещё не достигнут. Оператор видит «не красный» и считает нормой. Permit часто привязан к отсутствию alarm high, а не к warning. В online смотрите отдельные биты ALM_H, ALM_L, WARN, не агрегированную лампочку на приборе.

Гистерезис порогов: снятие alarm при 20 % LEL, выдача permit при 10 % - типичная схема. Между 10 и 20 % прибор «в норме» по дисплею, permit ещё нет. Без подписи порогов на HMI смена будет звонить наладчику каждую неделю.

Voting 2oo3, fault и обрыв линии

Три газоанализатора на одну зону, логика 2oo3: при отказе одного канала система может держать запрет или перейти в degraded mode - по проекту. Оператор смотрит на «главный» прибор у двери, voting считает по всем трём.

Обрыв 4-20 мА часто даёт fault, не «ноль ppm». HMI может показывать last good value с плохим quality, если плохо настроен - кажется «норма». Сверяйте quality и raw, не только EU.

Цифровой анализатор по Modbus: бит GasOK и отдельный DeviceFault. Можно получить GasOK=1 при Fault=1 в разных регистрах, если карта тегов перепутана.

Bypass, калибровка и SIL vs standard logic

После ежемесячной калибровки техник ставит bypass на анализатор или в logic - ключ «CAL», «MAINT». Забыли снять - permit не придёт, хотя датчик в норме после калибровки. Bypass должен быть виден на HMI с миганием, записью в журнал и ограничением по времени.

Ключ bypass на шкафу PAZ должен быть снят и зафиксирован. В проекте standard PLC не должно быть скрытого OR на разрешение. После пусконаладки проверьте ключи и jumper на реле.

SIL-функция и standard logic разделены: safety PLC выдаёт SIF_OK, основной ПЛК комбинирует с технологией. Если safety channel в lockout после теста ESD - standard «всё зелёное» не поможет.

Отличие от дверного концевика

Дверь кожуха - обычно прямой DI: дверь открыта, permit снят мгновенно (или с коротким delay на дребезг). Газ - аналоговая величина с фильтрацией, voting, задержками. Оператор переносит опыт «закрыл дверь - сразу пуск» на газ и получает конфликт с технологом.

На мнемосхеме разные иконки и разные тексты причины обязательны. Один красный «НЕТ РАЗРЕШЕНИЯ» без расшифровки - проектный долг.

Проводка, реле и расхождение поля и HMI

Реле промежуточное между анализатором и ПЛК: контакт залип, катушка без питания - в поле «норма» по лампочке с другой цепи. Дискретный вход ПЛК не совпадает с 4-20 мА на AI - разные цепи PAZ.

Проверка: мультиметр, отладчик, сравнение с функциональной схемой as-built. Для FAT - принудительные режимы симуляции каждого входа цепочки (где допускает регламент безопасности).

Диагностика на объекте по шагам

Зафиксируйте скрин: ppm, alarm, permit, список interlocks. В online пройдите цепочку от AI/DI до PERMIT - какой булевый первый FALSE. Проверьте bypass bits, timer ET, safety feedback.

Сверьте время: если permit должен прийти через 60 с после нормы - засеките. Если не пришёл - смотрите другой FALSE, не удлиняйте ожидание «на глаз».

После сброса bypass/калибровки - запись в журнал оператора. Для повторяющихся случаев - разбор проекта: не дублируется ли задержка в ПЛК и в анализаторе.

После сброса bypass/калибровки - запись в журнал оператора. Для повторяющихся случаев - разбор проекта: не дублируется ли задержка в ПЛК и в анализаторе.

Калибровка и замена сенсора: сброс цепочки

После замены сенсора или span/zero check анализатор может требовать подтверждение «gas free» или ручной ввод, что зона безопасна. Пока процедура не завершена, внутренний статус NOT_READY, хотя цифра ppm уже стабильна.

В проекте PAZ иногда забывают привязать SensorReady к permit - используют только Concentration_OK. Добавьте в cause list явно.

FAT: как принять цепочку без сюрпризов на пуске

На FAT прогоняют сценарии: симуляция ALARM, выход в норму с засечкой времени до permit, включение bypass с проверкой индикации, voting при отказе одного канала (где регламент позволяет). Результаты - в протокол вместе с чек-листом HMI.

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

SIL и standard: кто что сбрасывает

После срабатывания safety-функции сброс может требовать ключ на шкафу, последовательность кнопок или специальную процедуру по IEC 61511. Standard PLC квитирование аварии не снимает safety lockout. Наладчик квитирует ALARM на SCADA - permit всё ещё нет, потому что safety PLC ждёт reset.

Документация функциональной безопасности и cause list на HMI должны быть согласованы. Оператор не обязан знать разницу SIL и standard, но экран обязан подсказать следующий шаг.

Типичные ошибки эксплуатации

Первая - сброс только аварии на SCADA без процедуры PAZ. Вторая - обход bypass «на пять минут» без журнала. Третья - сравнение одного прибора при voting из трёх. Четвёртая - ожидание мгновенного permit после проветривания, когда в проекте 20 минут PostGasOK.

Обучите смену читать cause list, а не только лампу «норма» на приборе. Это дешевле, чем ночной выезд наладчика из-за таймера.

При замене газоанализатора на модель с другим временем отклика пересмотрите задержки в ПЛК - старые TON могут не соответствовать новому прибору, и permit будет казаться «залипшим» при нормальной работе датчика.

Состояние датчика, логика PAZ и проверка

Вопросы с пуска

Можно ли убрать задержку «чтобы быстрее пускали»?
Только с пересмотром PAZ-расчёта и подписью ответственного за безопасность. Уменьшение TON без анализа - путь к ложным пускам при пиках.

Почему после калибровки всё норма, но permit нет?
Часто не снят bypass или не пройден тестовый reset анализатора. Смотрите процедуру в паспорте прибора и PAZ.

Кто сбрасывает PAZ - оператор или только наладчик?
По процедуре; часто сброс ALARM отдельно от снятия блокировки пуска.

HMI показывает permit, кнопка не работает?
Возможен разрыв между SCADA permit и ПЛК enable - разные теги. Проверьте цепочку до физического выхода.

Ссылки по теме

• Функциональная безопасность SIL: практика, оценка, документы;
• Приёмка панели HMI: чек-лист наладчика на FAT;
• Дискретные и аналоговые сигналы в АСУ ТП;
• Сигнал 4-20 мА на экране: фильтрация и Bad quality;
• Панель оператора и SCADA: граница уставок и аварий.