Итак, в предыдущей статье мы разобрали общие принципы построения функциональной безопасности опасного промышленного объекта (ОПО) и закончили на техническом задании (ТЗ), которое должно содержать спецификацию функций безопасности (ФБ) для разрабатываемой приборной системы безопасности (ПСБ) в части противоаварийной автоматической защиты (ПАЗ), ну и некоторые другие параметры. Например, требуемый уровень полноты безопасности (УПБ) или по буржуйской традиции — Safety Integrity Level (SIL) для каждой ФБ.
Едем дальше.
Проектирование ПАЗ
В общем случае система ПАЗ по ГОСТ (МЭК) должна:
- быть разработана строго в соответствии со спецификацией требований к полноте безопасности и с требованиями нормативных документов (то есть берем каждый пункт и даем расшифровку по его реализации в системе);
- быть независимой от базовой АСУ ТП (ОСУП), в том числе по источнику питания и сети обмена информацией между компонентами (допускается обмен операционными данными между ПАЗ и ОСУП, который не должен влиять на функциональную безопасность ПАЗ и остальных слоев защиты);
- обеспечивать безопасность при отключении/включении питания (например, механически переводить систему в безопасное состояние при отключении питания);
- включать контуры управления, спроектированные с учетом оценки рисков и назначенного уровня SIL.
Проектирование включает разработку конструкции программно-технического комплекса (ПТК) и прикладного программного обеспечения (ПО) для него.
Разработка конструкции ПАЗ
Система ПАЗ исторически возникла как набор защитных блокировок, переводящих технологический процесс в безопасное состояние (как правило, это остановка процесса) при выходе его параметров за предельно допустимые значения. В настоящее время в качестве ПАЗ применяется чаще всего ПТК, который содержит: датчики, программируемый логический контроллер (ПЛК), исполнительные механизмы и элементы, вспомогательные электротехнические и защитные компоненты.
Порядок разработки конструктива ПАЗ:
- анализ ТЗ и спецификации требований к полноте безопасности;
- выбор подходящих технических компонентов и архитектуры для системы;
- проверка ПАЗ на требования по числу и вероятность отказов — изменения элементной базы и архитектуры для случая, когда требования не выполняются;
- утверждение технической документации на ПАЗ у заинтересованных лиц.
В общем случае отказ — это потеря системы способности функционировать соответствующим образом, либо событие, приводящее к состоянию сбоя. С понятием отказа связано среднее время на восстановление — ожидаемое время, чтобы достичь восстановления системы после отказа. Включает в себя: а) время нахождения отказа (диагностику); б) время до начала ремонта (время на подготовку к ремонту); в) время, затрачиваемое на ремонт (так называемое, среднее время ремонта); г) время до введения элемента обратно в систему. Среднее время на восстановление должно быть равно или чуть больше среднего времени ремонта, которое обычно определяется как 8 часов. Параметры во времени задаются в техническом задании.
Отказоустойчивость при проектировании ПАЗ достигается методами избыточности и разнообразия. Избыточность предполагает использование устройств с дублированием функций или даже нескольких устройств для выполнения одной функции. Разнообразие обеспечивается использованием в системе различных проектных подходов (применение оборудования разных производителей), физических принципов, методов программирования и т. д. Избыточность и разнообразие, как правило, применяются совместно. Так для получения одной величины расхода жидкости в ПАЗ могут быть запроектированы два расходомера: ультразвуковой и турбинный.
Анализ ТЗ и спецификации требований к полноте безопасности
Как правило, данный анализ сводится к переводу исходных документов в удобочитаемый разработчику формат по некоторому чек-листу. По итогу выполняется функциональная схема автоматизации ПАЗ, составляется предварительная ведомость требуемых компонентов.
Выбор подходящих технических компонентов и архитектуры для системы
Компоненты, используемые в системе ПАЗ, должны иметь действующий на момент приобретения сертификат соответствия, подтверждающий соответствие продукции заданному уровню полноты функциональной безопасности (УПБ/SIL), а также обеспечивать возможности проведения: а) диагностических испытаний (часто, встроенная подсистема), б) проверочных испытаний (редко, по графику в останов).
Обратите внимание, что что для второго сертификата из примера УПБ может различаться в зависимости от HFT(Hardware Fault Tolerance), что означает устойчивость к аппаратным отказам. Достигается путем устройства соответствующей архитектуры системы.
Архитектура ПАЗ обозначается, как MooN, что означает — система (или ее часть) выполнена из N независимых каналов, соединенных так, что Mканалов достаточно для выполнения функции безопасности. Для HFT X: X=N-M.
Избыточная архитектура системы 1oo2 (1 из 2) может выдерживать 1 аппаратный сбой, поэтому имеет HFT = 1. У конфигурации 2oo3 также HFT = 1. У конфигурации 1oo1 (не имеет резервирования, стандартный контур базовой АСУ ТП или ОСУП) HFT = 0, поэтому устойчивости к аппаратным сбоям нет.
Архитектура 1оо2 состоит из двух параллельных каналов, любой из них может выполнять ФБ. Архитектура 2оо2 состоит из двух параллельных каналов, но для выполнения ФБ необходима работа обоих. Ну и так далее.
Минимальная HFT для системы (подсистемы) ПАЗ с заданным УПБ в общем случае для сертифицированных устройств должна соответствовать таблице ниже. Стандарт МЭК 61508 различает два режима интенсивности запросов выполнения ФБ: низкая и высокая (непрерывная). В режиме низкой интенсивность запрос на выполнение функций безопасности не превышает одного раза в год. В другом режиме запросы на выполнение функции безопасности поступают непрерывно или чаще одного раза в год.
Однако в некоторых случаях минимально необходимая HFT может быть понижена, что, конечно, требует обоснования и документирования.
Согласно ГОСТ Р МЭК 61508 при необходимости для конструкции ПАЗ должны быть введены архитектурные ограничения полноты безопасности аппаратных средств, а далее — проведена количественная оценка случайных отказов.
Проверка ПАЗ на требования по числу и вероятность отказов
Количественная оценка выполняется путем расчета доли безопасных отказов (SFF) — свойства элемента, связанного с безопасностью, определяемое отношением суммы средних частот безопасных (S) и опасных обнаруженных (DD) обнаруженных отказов к сумме средних частот всех отказов (безопасных и опасных обнаруженных и необнаруженных (DU)).
Получив величину SFF, можно проверить выбранную архитектуру для реализации ФБ через отказоустойчивость HFT.
Следует отметить, что все компоненты системы ПАЗ разделяются на устройства типа А (в общем случае это простые элементы — все исполнительные механизмы, защитно-коммутационное оборудование и т. д.), и типа В (в общем случае к ним относят различную и непредсказуемую электронику). Чем сложнее устройство, тем выше требования к архитектуре системы.
Для определения максимального уровня УПБ (SIL) ФБ рассчитывают среднюю вероятность опасного отказа по запросу (probability of dangerous failure on demand, PFDavg). Эта характеристика определяет неготовность ПАЗ обеспечить безопасность (то есть выполнить конкретную ФБ) тогда, когда происходит запрос (в интервале между проверками системы). В ГОСТе данному параметру присвоена аббревиатура ВОНЗср.
Значение PFDavg для ФБ вычисляется, как сумма вероятностей отказа по запросу для подсистем датчиков, логики, исполнительных механизмов.
При этом конкретные значения для подсистем определяются в зависимости от назначенной архитектуры.
Ну и наконец, получившееся суммарное значение PFD (ВОНЗ ср) для контура ФБ сравнивается со значениями допустимой общей вероятности отказов требуемого УПБ (SIL) по таблице 4 ГОСТ МЭК 61511-1 — делается вывод о УБП ПАЗ в части рассматриваемой ФБ. Если получившийся результат вдруг не удовлетворил, следует вернуться на несколько шагов — использовать другую архитектуру для подсистем, другие компоненты. Также можно снизить интервал между проверками системы. Более частая профилактическая диагностика позволяет исключить опасные сбои, поэтому вероятность отказов объективно таким образом снижается. Однако часто Т1 задан техническим заданием, так как привязан к плановым остановам производства на обслуживание и не может быть назначен проектировщиком.
Следует отметить, что применение в ПАЗ для реализации ФБ элементов одного уровня УПБ (например УПБ2) не гарантирует соответствие всей ФБ этому УПБ.
Откуда брать данные для расчетов? Конечно, из паспортной информации. Если информация отсутствует, то следует выполнить запрос производителю — после сертификации своей продукции она у него точно есть. Если для несертифицированных компонентов (применение их с некоторыми оговорками допускается при наличии использования в аналогичных системах), которые тем не менее прописаны в ТЗ данных нет, то мы можем использовать такие компоненты в рамках так называемого «предшествующего применения». Однако, в этом случае всю информации для расчета должен предоставить заказчик, а все риски будет нести уже не производитель, а эксплуатирующая организация.
Если вы хотите ознакомиться с примером расчета УПБ ФБ рекомендую ознакомится с соответствующей лекцией, которая пока еще доступна на одном не до конца заблокированном видеохостинге.
Требования к разработке прикладного ПО для ПАЗ
Отдельный раздел ГОСТ посвящен ПО для системы ПАЗ. Требования к нему также должны быть конкретизированы в спецификации (ТЗ).
Спецификация для прикладной программы должна быть такой, чтобы:
- она описывала намерения и подход, лежащий в основе требований к безопасности ППО;
- была ясно выраженной и понятной для тех, кто будет использовать документ на любой стадии жизненного цикла ПСБ, что подразумевает использование четкой и понятной для всех пользователей терминологии и описаний (например, операторов, обслуживающего персонала, программистов);
- ее можно было верифицировать, проверить и модифицировать;
- она являлась прослеживаемой через всю выпускаемую документацию, включая документацию детального проектирования, спецификацию требований, а также анализ опасностей и рисков, идентифицирующий требующиеся ФБ ПСБ.
ПО выполняется в специальной программной среде, которая аттестована на требуемый уровень безопасности. Загрузка ПО в ПЛК требуемого уровня безопасности осуществляется по аттестованным коммутационным протоколам (например, Safe Ethernet).
Стандарт МЭК 61511 рекомендует реализацию ПО на определенных языках программирования (12.2.3): например, языки МЭК 61131: FBD, IL, SFC, ST.
Прикладная программа должна быть создана структурированным образом, чтобы добиться:
- разбиения функционала на модули;
- обеспечения минимальной сложности работы прикладной программы ФБ;
- возможность испытания функционала и внутренней структуры прикладной программы;
- прослеживаемости и объяснения ее связи с прикладными функциями и их ограничениями;
- отображение «один к одному» между архитектурой аппаратуры и архитектурой прикладной программы.
Прикладная программа подвергается верификации, заводским приемочным испытаниям, валидации (окончательным испытаниям).
Источники, дополнительная информация:
- МЭК 61508-4:2010 (ГОСТ Р МЭК 61508-4-2012) «Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 4. Определения и сокращения».
- МЭК 61511-1.2016 (ГОСТ Р МЭК 61511-1-2018) «Безопасность функциональная. Системы безопасности приборные для промышленных процессов. Часть 1. Тер мины, определения и технические требования».
- Федеральный закон от 21.07.1997 N 116-ФЗ (ред. от 08.08.2024) «О промышленной безопасности опасных производственных объектов»
- Приказ Ростехнадзора от 15.12.2020 N 533 «Об утверждении федеральных норм и правил в области промышленной безопасности «Общие правила взрывобезопасности для взрывопожароопасных химических, нефтехимических и нефтеперерабатывающих производств» (Зарегистрировано в Минюсте России 25.12.2020 N 61808)
- What is Hardware Fault Tolerance (HFT), статья сайта: https://www.methodfs.com (дата обращения 18.02.2025)
- Программно-методическое обеспечение проектной оценки показателей функциональной безопасности систем противоаварийной защиты опасных производственных объектов. И.А. Можаева, А.В. Струков, из сборника конференции, 2017 г.
- Лекции по курсу «Приборные системы безопасности» (видео), канал «Instrumentation and Control» (дата обращения 08.12.2024)
- Функциональная безопасность — SIL, электроприводы с УПБ до SIL3, брошюра фирмы AUMA
- Чэнь Я., Система противоаварийной защиты азотно-кислородной установки: магистерская диссертация
Ознакомиться с содержанием журнала.
Уважаемые коллеги, желаю хорошего дня. Подписывайтесь, чтобы иметь возможность обсудить со мной вашу задачу в комментариях. Буду рад лайку, альтернативному мнению или истории по теме статьи.
ПРЕДУПРЕЖДЕНИЕ №1: Оценки, суждения и предложения по рассматриваемым вопросам являются личным мнением автора.
ПРЕДУПРЕЖДЕНИЕ №2: Техническая информация, представленная на сайте, не является официальной и предоставлена только в целях ознакомления. Владелец сайта не несет никакой ответственности за риски, связанные с использованием информации, полученной из данного источника.
