Развенчание мифов о верификации SIL: применение ISA-TR84.00.02 для приборных функций безопасности в нефтегазовой отрасли

Развенчание мифов о верификации SIL: применение ISA-TR84.00.02 для приборных функций безопасности в нефтегазовой отрасли

Приборная функция безопасности, имеющая на бумаге целевой уровень SIL 2, но не прошедшая расчет верификации, не является функцией SIL 2 — это обязательство, прикрытое документацией. Тем не менее, на эксплуатационных объектах верификация SIL часто воспринимается как бумажная работа: данные вводятся в программу, появляется зеленый результат, и файл закрывается. Когда расследование инцидента позже открывает этот файл, пробелы обходятся дорого. В этой статье рассматривается методология верификации, описанная в ISA-TR84.00.02, объясняется, где специалисты постоянно допускают ошибки, и даются рекомендации по принятию решений для инженеров, руководителей служб технического обслуживания и отделов закупок, которым необходимы обоснованные результаты.

Чем на самом деле является верификация SIL — и чем она не является

Выбор SIL отвечает на вопрос: какое снижение риска должна обеспечить данная приборная функция безопасности (SIF)? Верификация SIL отвечает на другой вопрос: обеспечивает ли спроектированная SIF это снижение риска на самом деле, учитывая выбранное оборудование, архитектуру, интервал контрольных испытаний и диагностический охват?

ISA-TR84.00.02 — это технический отчет, дополняющий IEC 61511, стандарт функциональной безопасности для систем приборной безопасности (SIS) в перерабатывающих отраслях. Технический отчет содержит отработанные методы расчета — упрощенные уравнения, анализ Маркова, анализ дерева отказов и структурные схемы надежности, — которые позволяют инженерам рассчитать вероятность отказа по запросу (PFD) или вероятность отказа в час (PFH) для SIF и сравнить результат с целевым уровнем SIL, установленным в ходе оценки опасностей и рисков.

Это различие важно для отделов закупок: покупка датчика с сертификатом SIL 2 не делает SIF соответствующей SIL 2. Сертификат относится к устройству в отдельности. Верификация же касается всего контура SIF — подсистемы датчиков, логического решающего устройства и подсистемы исполнительных элементов — работающих в конкретных условиях объекта.

Структура расчета

PFD против PFH: выбор правильного показателя

ISA-TR84.00.02 предписывает инженерам использовать PFD (средняя вероятность отказа по запросу) для SIF, работающих в режиме по запросу, и PFH (вероятность опасного отказа в час) для SIF с высоким спросом или непрерывным режимом работы. Выбор неправильного показателя для режима работы является фундаментальной ошибкой, которая аннулирует результат верификации независимо от того, насколько тщательно выполнены расчеты.

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

Декомпозиция подсистем

ISA-TR84.00.02 структурирует SIF как три подсистемы:

• Подсистема датчиков (инициирующие элементы, включая датчики, переключатели и схемы голосования)
• Подсистема логического решающего устройства (контроллер безопасности, релейная логика или пневматическая логика)
• Подсистема исполнительных элементов (клапаны, приводы, позиционеры, соленоиды)

Каждая подсистема вносит вклад в общую PFD SIF. Общая PFD SIF является суммой значений PFD трех подсистем. Это свойство аддитивности означает, что слабая подсистема исполнительных элементов может исчерпать весь бюджет SIL, даже если датчик и логическое устройство имеют отличные характеристики.

Ключевые входные параметры

Для каждого компонента расчет требует:

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

Где расчеты верификации терпят неудачу на практике

Оптимизм в отношении интервала контрольных испытаний

Интервал контрольных испытаний, вводимый в расчет, должен отражать интервал, фактически достигаемый в полевых условиях, а не интервал, прописанный в регламенте обслуживания. Если регламент предусматривает ежегодное тестирование, но эксплуатационные ограничения регулярно продлевают этот интервал, результат PFD будет неконсервативным. ISA-TR84.00.02 требует, чтобы предполагаемый интервал был достижим в нормальных условиях эксплуатации. Руководители служб ТО должны проверять фактические записи о выполнении тестов перед подтверждением интервала, используемого при верификации.

Неполный охват контрольных испытаний

Контрольное испытание, которое не проверяет всю SIF от датчика до исполнительного элемента, не получает полного зачета. Например, испытание на частичный ход клапана обнаруживает определенную долю отказов клапана, но оставляет остальные необнаруженными до испытания на полный ход. ISA-TR84.00.02 содержит рекомендации по учету частичного охвата контрольных испытаний в расчете PFD. Использование полного зачета при проведении только частичного теста завышает кажущееся снижение риска.

Недооценка отказов по общей причине

Бета-фактор учитывает отказы, которые сводят на нет резервирование — одно событие, вызывающее одновременный отказ двух независимых каналов. Отказы по общей причине в SIF нефтегазовой отрасли возникают из-за общих линий подачи инструментального воздуха, прокладки импульсных линий через зону термического влияния, идентичных версий ПО с общей ошибкой или неправильной калибровки нескольких датчиков одним и тем же техником в одно и то же окно обслуживания. ISA-TR84.00.02 предлагает структурированный метод оценки бета-фактора. Применение минимального бета-фактора по умолчанию без проработки чек-листа недооценивает риск общей причины в архитектурах, где физическая или процедурная независимость не была строго реализована.

Игнорирование систематических отказов

Расчеты PFD касаются случайных отказов оборудования. ISA-TR84.00.02, в соответствии с IEC 61511, признает, что систематические отказы — ошибки в спецификации, проектировании, монтаже или обслуживании — не учитываются арифметикой надежности. SIF, которая проходит расчет PFD, но имеет неправильную уставку срабатывания в логическом устройстве или клапан, который не закрывается из-за неправильного подбора привода, не сработает. Верификация должна сопровождаться оценкой функциональной безопасности, которая проверяет спецификацию SIF, диаграмму причинно-следственных связей и акты пусконаладочных работ.

Иллюстративный сценарий: SIF защиты от избыточного давления сепаратора высокого давления

(Этот сценарий является иллюстративным и не представляет конкретный объект или инцидент.)

Рассмотрим сепаратор высокого давления с SIF, предназначенной для закрытия входного отсечного клапана при сверхвысоком давлении. Целевой уровень SIL 2 требует, чтобы PFD находилась в диапазоне, определенном IEC 61511 для SIL 2. Архитектура использует один датчик давления (датчик 1oo1), логическое устройство на базе контроллера безопасности и один шаровой клапан с пневмоприводом и соленоидом (исполнительный элемент 1oo1).

Предварительный расчет PFD с использованием данных производителя об интенсивности опасных отказов и запланированного ежегодного интервала контрольных испытаний дает результат, который соответствует SIL 1, но не достигает SIL 2. У инженера есть три варианта: увеличить резервирование в подсистеме датчиков (например, перейти к голосованию 1oo2 или 2oo3), увеличить частоту контрольных испытаний или улучшить диагностический охват. Добавление второго датчика с голосованием 1oo2 существенно снижает PFD подсистемы датчиков, а повторный расчет с обновленными данными по бета-фактору выводит общую PFD SIF в диапазон SIL 2 — при условии, что интервал контрольных испытаний соблюдается, а допущения бета-фактора о физическом разделении двух датчиков соблюдены при монтаже.

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

Практический чек-лист для верификации SIL

Используйте этот чек-лист перед подачей верификации SIF на проверку оценки функциональной безопасности.

Объем и исходные данные

• [ ] Подтвердите режим работы (низкий запрос против высокого запроса/непрерывного) и выберите PFD или PFH соответственно
• [ ] Получите значения λ_D и DC из листов данных SIL производителя, а не из общих баз данных, если только данные по конкретному объекту недоступны и общий источник не задокументирован
• [ ] Подтвердите интервал контрольных испытаний (proof-test) в соответствии с фактическим графиком технического обслуживания и записями о недавнем выполнении
• [ ] Документируйте охват частичных контрольных испытаний отдельно от полных испытаний и применяйте правильный коэффициент в расчете
• [ ] Проработайте чек-лист бета-фактора ISA-TR84.00.02 для каждой резервированной архитектуры; не применяйте значение по умолчанию без обоснования

Архитектура и проектирование

• [ ] Убедитесь, что границы SIF соответствуют диаграмме причинно-следственных связей: от точки отбора датчика до седла конечного элемента
• [ ] Подтвердите, что логическое решающее устройство оценивается с использованием собственных сертифицированных данных об интенсивности отказов, а не общих показателей ПЛК
• [ ] Проверьте, включены ли электромагнитные клапаны, позиционеры и концевые выключатели в подсистеме конечного элемента в PFD конечного элемента — их часто упускают
• [ ] Проверьте физическое разделение и общие системы обеспечения для резервированных каналов; задокументируйте любые общие инженерные сети как факторы общей причины

Документация и управление

• [ ] Подтвердите, что целевой уровень SIL прослеживается до задокументированной оценки опасностей и рисков (анализ слоев защиты LOPA или эквивалент)
• [ ] Зафиксируйте все допущения, источники данных и отклонения в отчете о верификации
• [ ] Запланируйте проверку оценки функциональной безопасности завершенной верификации до того, как проект SIS будет утвержден
• [ ] Запланируйте триггер повторной верификации для любой модификации, изменяющей архитектуру, интервал контрольных испытаний или данные об интенсивности отказов компонентов

Заключение и следующие шаги

Верификация SIL — это количественная инженерная деятельность с конкретными входными данными, методами и критериями приемки, определенными в ISA-TR84.00.02. Это не просто результат работы программного обеспечения, который следует принимать без тщательного изучения лежащих в его основе допущений. Наиболее распространенные ошибки — оптимистичные интервалы контрольных испытаний, неполный учет охвата испытаний, недооцененные факторы общей причины и отсутствие компонентов конечных элементов — можно предотвратить с помощью дисциплинированного анализа входных данных перед выполнением расчета.

Для инженеров, начинающих или обновляющих программу верификации SIL, практическими следующими шагами являются:

1. Получите текущее издание ISA-TR84.00.02 и приведите свои расчетные шаблоны в соответствие с его методами и рекомендациями по бета-фактору.
2. Проведите аудит существующих записей верификации SIF на соответствие фактическим данным о выполнении контрольных испытаний и подтвердите соблюдение принятых интервалов.
3. Установите формальный триггер управления изменениями, чтобы любая модификация SIF — аппаратного обеспечения, ПО или процедур обслуживания — инициировала проверку повторной верификации до внедрения изменения.
4. Привлекайте оценщика функциональной безопасности на ранней стадии проектирования, а не на этапе документирования.

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