РСУ и ПАЗ в АСУ ТП: как правильно разделить управление и аварийную защиту

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

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

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

Что такое РСУ и за что она отвечает

РСУ — распределенная система управления технологическим процессом. В международной терминологии близкое понятие — BPCS, Basic Process Control System.

РСУ используется прежде всего для нормального ведения технологического процесса:

• сбора и обработки технологических сигналов;
• управления насосами, клапанами, электроприводами и другим оборудованием;
• автоматического регулирования;
• выполнения последовательностей и технологических алгоритмов;
• управления оборудованием с АРМ оператора;
• передачи информации в SCADA;
• архивирования параметров и событий;
• диагностики оборудования.

Например, при наливе продукта РСУ может открыть требуемые клапаны, запустить насос, контролировать расход, рассчитывать набранную массу или объем и штатно завершить операцию.

Именно такие функции обычно реализуются при проектировании промышленной автоматизации и АСУ ТП.

Что такое ПАЗ

ПАЗ — система противоаварийной защиты. Ее основная задача — не управление технологическим процессом, а выполнение заранее определенных защитных функций при возникновении опасного состояния.

В международной практике для таких систем используется понятие SIS — Safety Instrumented System. Конкретная защитная функция внутри такой системы называется SIF — Safety Instrumented Function.

Типовая защитная функция включает три основные части:

датчик → логическое устройство ПАЗ → конечный исполнительный элемент

Например:

• аварийный уровень → ПАЗ → закрытие отсечного клапана;
• опасная концентрация газа → ПАЗ → останов оборудования;
• аварийное давление → ПАЗ → запрет работы насоса.

Таким образом, задача ПАЗ — обнаружить опасное состояние и обеспечить перевод оборудования или технологического процесса в заранее определенное безопасное состояние.

Основное отличие ПАЗ от РСУ — независимость защитной функции

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

Нежелательная архитектура выглядит так:

датчик → РСУ → линия связи → ПАЗ → исполнительный механизм

Если единственная информация об аварии сначала проходит через РСУ, защита становится зависимой от нее.

При отказе могут возникнуть ситуации:

• контроллер РСУ завис и не передал аварийный сигнал;
• отказал модуль ввода РСУ;
• потеряна связь между РСУ и ПАЗ;
• ошибка программы РСУ не позволила сформировать правильное состояние;
• общий сетевой компонент вывел из строя одновременно управление и защиту;
• отказ общего источника питания нарушил работу обеих систем.

Поэтому ПАЗ не должна зависеть от исправности РСУ в тех элементах, которые необходимы для выполнения конкретной функции безопасности.

Как обычно строится правильная архитектура

Упрощенно разделение можно представить так:

• Рабочие датчики → РСУ → штатное управление → исполнительное оборудование.
• Датчики или сигналы безопасности → ПАЗ → аварийное воздействие → исполнительное оборудование.

При этом РСУ и ПАЗ совершенно не обязательно должны быть информационно изолированы друг от друга.

Они могут обмениваться состояниями, диагностикой и технологической информацией. ПАЗ может передавать в РСУ:

• факт срабатывания защиты;
• причину останова;
• состояние защитных каналов;
• неисправность ПАЗ;
• запрет пуска;
• состояния аварийных датчиков.

Эти данные могут далее отображаться в SCADA и системе диспетчеризации.

Принципиально другое требование: срабатывание защитной функции не должно зависеть от того, дошла ли информация до SCADA или исправно ли работает РСУ.

Всегда ли ПАЗ нужны отдельные датчики

Не обязательно.

Фраза «у РСУ свои датчики, а у ПАЗ обязательно свои» слишком категорична.

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

Отдельный датчик необходим или целесообразен, если отказ общего датчика способен одновременно:

1. создать опасную ситуацию или лишить РСУ информации о ней;
2. не дать ПАЗ обнаружить эту ситуацию.

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

Поэтому правильный вопрос при проектировании звучит не «можно ли использовать один датчик?», а скорее так:

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

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

Пример с отсечным клапаном

Рассмотрим клапан, которым в нормальном режиме управляет РСУ.

Штатная логика может выглядеть так:

• РСУ выдает команду открыть или закрыть клапан;
• сигналы положения «Открыт» и «Закрыт» возвращаются в РСУ.

Однако при возникновении аварийного условия ПАЗ должна иметь предусмотренный проектом способ перевести клапан в безопасное состояние независимо от штатной команды РСУ.

Например:

• ПАЗ снимает разрешение на открытие клапана;
• ПАЗ отключает питание соленоида;
• ПАЗ воздействует на отдельную цепь аварийного закрытия.

Для многих отсечных клапанов применяется принцип fail-safe: при исчезновении управляющего воздействия клапан механически переходит в безопасное положение, например закрывается под действием пружины.

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

Пример с насосом и электроприводом

РСУ в обычном режиме управляет насосом: выдает команды пуска и останова и получает сигналы «Работа», «Готовность», «Авария».

При наличии защитной функции ПАЗ получает возможность независимо запретить опасную работу. Это может быть реализовано через:

• снятие разрешения на работу;
• аварийный вход частотного преобразователя;
• отдельную цепь останова;
• отключение контактора или другого коммутационного аппарата.

Конкретный способ зависит от оборудования, требуемого безопасного состояния и принятой категории защитной функции.

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

Газоанализаторы: информация для РСУ и аварийный сигнал для ПАЗ

Хороший пример разделения функций — система контроля загазованности.

Современный газоанализатор или газоаналитическая система может предоставлять:

• аналоговый сигнал 4–20 мА;
• дискретные пороговые выходы;
• выход неисправности;
• цифровую связь, например Modbus.

Для РСУ и SCADA удобно получать текущее численное значение концентрации. Это позволяет:

• показывать значение оператору;
• строить графики;
• архивировать параметры;
• контролировать динамику концентрации;
• выполнять диагностику.

Одновременно защитная функция может использовать отдельный дискретный сигнал достижения аварийного порога:

• Газоанализатор → значение концентрации / Modbus → РСУ / SCADA.
• Газоанализатор → аварийный порог → ПАЗ.

Так информационная функция и функция аварийной защиты имеют разные задачи.

Конкретные пороги, необходимость резервирования и способ передачи сигнала определяются проектом и нормативными требованиями для конкретного объекта.

Можно ли передавать сигналы ПАЗ по промышленной сети

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

Через промышленную Ethernet-сеть РСУ и ПАЗ могут передавать в SCADA:

• технологические параметры;
• состояния;
• диагностические сообщения;
• историю событий;
• информацию о срабатывании блокировок.

Например:

• РСУ → сеть → SCADA;
• ПАЗ → сеть → SCADA.

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

То есть исчезновение связи с АРМ оператора не должно мешать локальной ПАЗ остановить насос или закрыть аварийный клапан.

ПАЗ не обязательно означает отдельный шкаф

Еще одно распространенное упрощение — считать, что независимая ПАЗ всегда должна находиться в физически отдельном шкафу.

Отдельный шкаф часто является хорошим решением, потому что упрощает разделение:

• питания;
• контроллеров;
• модулей ввода-вывода;
• клеммных цепей;
• кабелей;
• обслуживания;
• ответственности оборудования.

Но физическое размещение само по себе не определяет безопасность системы.

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

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

Поэтому архитектуру необходимо оценивать по всей цепочке:

датчик → входной канал → логика → выходной канал → промежуточные устройства → конечный исполнительный элемент → питание → коммуникации

Что происходит при отказе РСУ

Это один из самых полезных вопросов при проверке проекта.

Предположим, РСУ полностью остановилась.

Нужно последовательно проверить:

• обнаружит ли ПАЗ опасное состояние;
• поступят ли необходимые сигналы на ее входы;
• сможет ли логика ПАЗ выполниться;
• сформируется ли выходной сигнал;
• получит ли его конечный исполнительный элемент;
• перейдет ли оборудование в безопасное состояние;
• сохранится ли защита при потере связи со SCADA;
• не потребуется ли для аварийного действия команда от РСУ.

Если ответ на критичный вопрос зависит от работоспособности РСУ, необходимо проверить, не нарушает ли такая архитектура требования к функции безопасности.

Может ли РСУ управлять оборудованием после срабатывания ПАЗ

Как правило, защитное воздействие должно иметь приоритет над обычной командой управления.

Например, для насоса:

• Команда РСУ: Пуск.
• Разрешение ПАЗ: Нет.
• Результат: насос не запускается.

Аналогично для клапана:

• Команда РСУ: открыть клапан.
• Требование ПАЗ: перевести клапан в безопасное положение.
• Результат: выполняется требование ПАЗ, а штатная команда РСУ не должна его отменять.

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

Что нужно определить до разработки программы ПЛК

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

Сначала необходимо определить сами функции безопасности.

Для каждой функции желательно ответить минимум на следующие вопросы:

1. Какое опасное событие необходимо обнаружить?
2. Каким параметром оно определяется?
3. Какие датчики используются?
4. Какой порог является аварийным?
5. Какое состояние процесса считается безопасным?
6. На какие исполнительные механизмы должна воздействовать ПАЗ?
7. Каким электрическим способом выполняется это воздействие?
8. Что происходит при обрыве линии датчика?
9. Что происходит при потере питания?
10. Что происходит при отказе контроллера?
11. Что происходит при потере связи?
12. Какие элементы являются общими для РСУ и ПАЗ?
13. Может ли отказ общего элемента одновременно нарушить обе системы?
14. Нужно ли резервирование датчиков, контроллеров или выходных цепей?
15. Как выполняется сброс сработавшей защиты?
16. Какие события должны архивироваться и передаваться оператору?

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

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

Нормативный принцип

Для систем функциональной безопасности промышленных процессов базовым международным документом является IEC 61511. Он рассматривает безопасность на протяжении всего жизненного цикла — от анализа опасностей и определения функций безопасности до проектирования, ввода в эксплуатацию, эксплуатации, испытаний и модернизации.

Для российских объектов дополнительно необходимо учитывать требования нормативных документов, распространяющихся именно на конкретный объект.

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

Это важное уточнение: требования к конкретной архитектуре определяются не только названием «РСУ» или «ПАЗ», но и назначением объекта, анализом опасностей, требуемым снижением риска и применимыми нормативами.

Типичные ошибки при разделении РСУ и ПАЗ

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

ПАЗ получает единственный аварийный сигнал по обычной сети от РСУ.
В этом случае отказ сети или РСУ способен одновременно лишить систему защитной функции.

ПАЗ программно сообщает РСУ об аварии, но физического воздействия на оборудование нет.
Получается сигнализация, а не полноценное аварийное действие.

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

РСУ может отменить команду ПАЗ.
Для защитной функции приоритет должен быть определен в пользу безопасного состояния.

Есть отдельный шкаф ПАЗ, но критичные входы и выходы проходят через оборудование РСУ.
Физическое разделение шкафов само по себе проблему не решает.

Итоговая архитектура

Назначение основных частей АСУ ТП можно сформулировать так:

• РСУ — штатно управляет технологическим процессом: регулирование, последовательности, команды операторов и управление оборудованием.
• ПАЗ — обнаруживает заданные опасные состояния и независимо выполняет необходимые защитные действия.
• SCADA — отображает состояние процесса, принимает операторские команды, архивирует параметры и события.
• Исполнительные механизмы — в нормальном режиме выполняют команды РСУ, а при срабатывании защиты переходят в предусмотренное безопасное состояние.

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

Именно поэтому при проектировании важно рассматривать не только контроллер ПАЗ, но всю защитную цепочку — от датчика до конечного исполнительного механизма, включая питание, линии связи, модули ввода-вывода и возможные общие причины отказа.