ГОСТ Р 59504-2021 /IEC TR 61511-4:2020 Безопасность функциональная. Системы безопасности приборные для промышленных процессов. Часть 4. Пояснение и обоснование изменений, внесенных в МЭК 61511-1 из издания 1 в издание 2.

  ГОСТ Р 59504-2021/IEC TR 61511-4:2020

 НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

 БЕЗОПАСНОСТЬ ФУНКЦИОНАЛЬНАЯ

 Системы безопасности приборные для промышленных процессов

 Часть 4

 Пояснение и обоснование изменений, внесенных в МЭК 61511-1 из издания 1 в издание 2

 Functional safety. Safety instrumented systems for the process industry sector. Part 4. Explanation and rationale for changes in IEC 61511-1 from Edition 1 to Edition 2

ОКС 13.110

Дата введения 2021-11-30

 Предисловие

1 ПОДГОТОВЛЕН Федеральным государственным учреждением "Федеральный исследовательский центр "Информатика и управление" Российской академии наук" совместно с Обществом с ограниченной ответственностью "Информационно-аналитический вычислительный центр" (ООО ИАВЦ) и Обществом с ограниченной ответственностью "Корпоративные электронные системы" на основе собственного перевода на русский язык англоязычной версии документа, указанного в пункте 4

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 022 "Информационные технологии"

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 19 мая 2021 г. N 395-ст

4 Настоящий стандарт идентичен международному документу IEC TR 61511-4:2020* "Безопасность функциональная. Системы безопасности приборные для промышленных процессов. Часть 4. Пояснение и обоснование изменений, внесенных в МЭК 61511-1 из издания 1 в издание 2" (IEC TR 61511-4:2020 "Functional safety - Safety instrumented systems for the process industry sector - Part 4: Explanation and rationale for changes in IEC 61511-1 from Edition 1 to Edition 2", IDT).     

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

5 ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. N 162-ФЗ "О стандартизации в Российской Федерации". Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

 Введение

В МЭК 61511 (все части) рассматриваются приборные системы безопасности (SIS) для сектора промышленных процессов. В настоящем стандарте предлагается использовать известную в данном секторе терминологию и определять практические требования к реализации на основе независимых от сектора положений, представленных в базовом стандарте по безопасности МЭК 61508. МЭК 61511-1 во многих странах признается эффективной инженерной практикой и во все большем числе стран является обязательным требованием.

Тем не менее стандарты развиваются с учетом опыта их применения в рассматриваемом секторе. Второе издание МЭК 61511-1 отредактировано на основе десятилетнего международного опыта применения в секторе промышленных процессов требований, представленных в первом издании МЭК 61511-1:2003. Изменения издания 1, внесенные в издание 2, инициированы замечаниями специалистов национальных комитетов, представляющих широкий спектр пользователей стандарта во всем мире.

Требования первого издания 2003 г. (изд.1)

, относящиеся к предотвращению и управлению систематическими ошибками, которые возникают при проектировании, разработке, эксплуатации, обслуживании и модификации, были предназначены прежде всего для независимых функций безопасности, имеющих целевой уровень полноты безопасности вплоть до значения SIL 3. В отличие от этого, во втором издании 2016 г. (изд.2) необходимо было учитывать устоявшуюся тенденцию разделяемого использования систем автоматики сразу несколькими функциями безопасности.

________________

Для удобства чтения в настоящем стандарте будут использоваться "изд.1" и "изд.2" вместо МЭК 61511-1:2003 и МЭК 61511-1:2016, соответственно.

В изд.2 также потребовалось устранить основные некорректные интерпретации требований изд.1, которые за прошедшие годы стали очевидными для разработчиков МЭК 61511 (MT 61511). Например, в изд.2 вместо узкой концентрации на расчетах основное внимание уделено менеджменту функциональной безопасности при проектировании и обеспечению фактических характеристик SIS в течение ее жизненного цикла.

Настоящий стандарт был создан для краткого ознакомления широкой аудитории с вышеупомянутыми вопросами, при этом более подробное содержание осталось в основных частях комплекса стандартов МЭК 61511. Настоящий стандарт описывает обоснование основных разделов МЭК 61511-1, уточняет некоторые распространенные ошибочные представления об их применении, приводит перечень основных различий между первым и вторым изданиями МЭК 61511-1 и дает краткое объяснение типовых подходов для применения каждого основного раздела в секторе промышленных процессов.

      1 Область применения

Настоящий стандарт:

- предоставляет обоснование всех разделов МЭК 61511 и взаимосвязь между ними;

- информирует о наиболее распространенных ошибках и неправильном толковании конкретных разделов стандарта и об изменениях в них;

- объясняет различия между изд.1 и изд.2 МЭК 61511-1 и причины этих изменений;

- профессионально и кратко представляет, как выполнить требования его разделов;

- объясняет различия в терминологии между МЭК 61508 и изд.2 МЭК 61511.

      2 Нормативные ссылки

В настоящем стандарте использованы нормативные ссылки на следующие международные стандарты. Для датированных ссылок применяют только указанное издание ссылочного стандарта, для недатированных - последнее издание (включая все изменения к нему).

IEC 60050-192, International Electrotechnical Vocabulary (IEV) - Part 192: Dependability (доступно по адресу http://www.electropedia.org) (Международный электротехнический словарь. Часть 192. Надежность)

IEC 61508-4:2010, Functional safety of electrical/electronic/programmable electronic safety-related systems - Part 4: Definitions and abbreviations (Системы электрические/электронные/программируемые электронные, связанные с функциональной безопасностью. Часть 4. Термины и определения)

IEC 61511-1:2016, Functional safety - Safety instrumented systems for the process industry sector - Part 1: Framework, definitions, system, hardware and application programming requirements (Безопасность функциональная. Приборные системы безопасности, для промышленных процессов. Часть 1. Термины, определения и технические требования)

IEC 61511-1:2016/AMD 1:2017

ISO/IEC Guide 51:2014, Safety aspects - Guidelines for their inclusion in standards (Аспекты безопасности. Руководящие указания по включению их в стандарты)

      3 Термины, определения и сокращения

      3.1 Термины и определения

Для целей настоящего стандарта применяются термины и определения, приведенные в Руководстве ИСО/МЭК 51, МЭК 60050-192, МЭК 61508-4 и МЭК 61511-1.

ИСО и МЭК для применения в стандартизации поддерживают терминологические базы данных:

- IEC Electropedia: доступна по адресу http://www.electropedia.org/

- ИСО онлайн платформа: доступна по адресу https://www.iso.org/obp

      3.2 Сокращения

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

Таблица 1 - Сокращения терминов, используемых в настоящем стандарте

      4 Предварительная информация

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

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

      5 Управление функциональной безопасностью (изд.2, раздел 5)

      5.1 Почему этот раздел важен?

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

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

Для успешного выполнения каждой задачи МЭК 61511-1 требует компетентности всех сотрудников, назначенных для выполнения обязанностей по обеспечению безопасности на протяжении жизненного цикла SIS. В число таких сотрудников входят как руководители, так и подчиненные им ответственные исполнители. Ответственным исполнителем является лицо, которое в конечном счете несет ответственность за выполняемое действие или принимаемое решение. Для выполнения действия может быть назначен только один ответственный исполнитель. Руководителем является лицо(а), выполняющее определенную задачу.

Существует различие между оценкой функциональной безопасности (FSA) и аудитом функциональной безопасности. FSA представляет собой подробный обзор всех аспектов конкретной стадии жизненного цикла системы безопасности. Сроки проведения 1-го, 2-го и 3-го аудита функциональной безопасности связаны с основными стадиями реализации проекта с учетом того, где с точки зрения затрат эта работа будет выполнена наиболее эффективно, в отличие от одной оценки функциональной безопасности, выполняемой в конце проекта. С другой стороны, в процессе аудита функциональной безопасности выполняется анализ информации, документов и записей для определения того, что система менеджмента функциональной безопасности соответствует требованиям.

      5.2 Распространенные ошибки

Существует ошибочное мнение, что система менеджмента МЭК 61511-1 и строгость требования к проекту для SIL 1 менее важны, чем для SIL 3. Системы менеджмента функциональной безопасности более высокого уровня (такие как квалификация, управление изменениями, оценка и аудит) в МЭК 61511-1 одинаково важны и направлены на предотвращение систематических ошибок или управление ими. Хотя реализация связанных и несвязанных с безопасностью функций в одной и той же системе не рекомендуется, но некоторые процедуры менеджмента функциональной безопасности, реализуемые для SIS, могут успешно использоваться для критических небезопасных систем, таких как системы защиты активов.

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

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

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

      5.3 Что изменилось во 2-м издании по сравнению с 1-м и почему?

5.3.1 Существующие системы

Новое требование менеджмента функциональной безопасности в изд.2, указывающее на приемлемость существующих систем, реализованных в соответствии с изд.1 (или с предшествующими стандартами), признано необходимым и соответствующим области применения изд.2. Это понятие иногда называют "освобождение от соблюдения новых норм". Обычно, это понимают неверно и считают, что для управления этими системами никакие действия не нужны. Поэтому в новом пункте 5.2.5.4 изд.2 использован термин "существующие системы". С целью обеспечения достижения функциональной безопасности проводится оценка существующих систем и практик. Это требует, по крайней мере, выполнения оценки рисков, а затем анализ каждого независимого слоя защиты (IPL) для предотвращения и снижения оцениваемых рисков. Этот новый пункт также привел к пересмотру раздела 17, связанного с модификацией таких существующих систем.

В изд.2 изменен пункт: 17.2.3.

В изд.2 по отношению к изд.1 включен новый пункт: 5.2.5.4.

5.3.2 Управление изменениями

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

В изд.2 по отношению к изд.1 включены новые пункты: 5.2.6.1.9, 5.2.6.2.5 (см. также раздел 17).

5.3.3 Показатели производительности и обеспечение качества

Общей проблемой при проектировании SIS является использование чрезмерно оптимистичных данных, которые не применимы к условиям эксплуатации, в которой будет использоваться SIS. Однако даже если при первоначальном проектировании SIS используются данные и допущения, подходящие для данных условий эксплуатации, то изменения характеристик процесса, параметров эксплуатации, технического обслуживания и систем управления автоматикой со временем могут привести к снижению производительности системы и неприемлемому повышению риска. Основным подходом, указанным в МЭК 61511-1, для определения реально достигаемого снижения риска и его восстановления, является постоянный сбор данных о рабочих характеристиках, периодическая оценка их соответствия результатам анализа опасностей и рисков (H&RA) и требованиям SRS (то есть периодическое выполнение стадии 4 FSA) и, при необходимости, устранение отклонений. Ожидаемые результаты, связанные с контролем функционирования и обеспечением качества, соответствуют основным правилам менеджмента безопасности производственных процессов, таким как USA CFR 1910.119(j) США, контроль опасности возникновения крупномасштабных аварий на производстве (COMAH) Великобритании, правила, касающиеся опасных веществ и взрывоопасных сред (DSEAR) и приложение III к Директиве Совета 2012/18/EU Европейского сообщества, а также международным отраслевым стандартам (например, ИСО 14224).

В изд.2 изменены пункты: 3.2.51, 5.2.5.3, 16.2.2.

В изд.2 по отношению к изд.1 включены новые пункты: 5.2.6.1.10, 11.4.9, 11.9.4, 16.2.9.

5.3.4 Компетентность

SIS, как правило, изменяются и влияют друг на друга реже, чем BPCS. Без переподготовки и постоянного практического опыта первоначальная компетентность специалистов со временем может снизиться. Наиболее распространенными областями, где это вызывает озабоченность, являются квалификация поставщиков услуг по проектированию SIS и при выполнении работ по H&RA и разработке SRS, персонал которых не имеет профессиональной подготовки и не демонстрирует компетентность как в области предотвращения ущерба, так и при реализации требований МЭК 61511-1. Поэтому необходима система управления компетентностью персонала.

В изд.2 изменены пункты: отсутствуют.

В изд.2 по отношению к изд.1 включен новый пункт: 5.2.2.3.

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

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

В изд.2 изменены пункты: отсутствуют.

В изд.2 по отношению к изд.1 переработан пункт 5.2.5.2.

      5.4 Кратко о том, что изменилось

Каждый проект SIS должен иметь четкие роли и обязанности. Все участвующие стороны должны быть осведомлены о своих обязанностях и компетентны выполнять соответствующие мероприятия, необходимые для обеспечения функциональной безопасности. Профессиональные качества должны обновляться. Все необходимые операции в проекте должны описываться в плане обеспечения безопасности, который может быть специальным для проекта или общим документом компании. Для всех соответствующих видов деятельности должен выполняться анализ функциональной безопасности (FSA), чтобы продемонстрировать, что функция безопасности SIS удовлетворяет всем требованиям и соответствует согласованным стандартам. Управление эффективностью функционирования в ходе эксплуатации должно осуществляться путем сбора полевых данных для обеспечения безотказности SIS и информации о запросах к SIS. Аудиты функциональной безопасности должны проводиться через равные промежутки времени, чтобы продемонстрировать, что участвующие организации по-прежнему способны выполнять заданные требования функциональной безопасности. Деятельность по оценке и аудиту должна осуществляться отдельными лицами, независимыми от группы проектировщиков. По результатам оценки и аудита должна быть сформирована содержательная документация, а рекомендации должны сопровождаться с целью их эффективного выполнения.

      6 Жизненный цикл системы безопасности (изд.2, раздел 6)

      6.1 Почему этот раздел важен?

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

      6.2 Распространенные ошибки

Помимо необходимости включить в план обеспечения безопасности детальную информацию, связанную с конкретной организацией, проектные команды, не имеющие опыта реализации жизненного цикла системы безопасности, часто не понимают и не планируют итеративный характер выполнения H&RA, разработки SRS и проектирования SIS. Это может привести к неожиданным исправлениям проекта и увеличению затрат. Если персонал проекта прошел достаточно узкоспециализированную подготовку, то необходимые (в процессе проектирования) взаимодействия могут быть не замечены.

      6.3 Что изменилось во 2-м издании по сравнению с 1-м и почему?

Раздел 6 был обновлен с целью охвата всех видов деятельности, в частности прикладного программирования. Материалы, касающиеся прикладного программирования, из раздела 12 были включены в раздел 6. Дополнительные сведения о перемещении информации, связанной с прикладным программированием, см. также в 12.3.

      6.4 Кратко о том, что изменилось

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

      7 Верификация (изд.2, раздел 7)

      7.1 Почему этот раздел важен?

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

      7.2 Распространенные ошибки

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

      7.3 Что изменилось во 2-м издании по сравнению с 1-м и почему?

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

В изд.2 изменены пункты: 7.2.1, 7.2.6 (был 7.1.1.2).

В изд.2 по отношению к изд.1 включены новые пункты: 7.2.2, 7.2.3 и 7.2.5.

      7.4 Кратко о том, что изменилось

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

      8 Анализ опасностей и рисков (изд.2, раздел 8)

      8.1 Почему этот раздел важен?

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

Частота отказов, связанных с отказами, возникающими в BPCS, а также некоторое снижение риска, распределенное по уровням защиты BPCS (см. 9.3.1, где рассматриваются уровни защиты BPCS), непосредственно влияют на целевое значение уровня снижения риска и режим работы, соответствующей функции безопасности SIS. Поэтому изд.2 ограничивает (на основе устоявшегося консенсуса в области промышленных процессов) значение интенсивности отказов, которое может быть заявлено для BPCS.

      8.2 Распространенные ошибки

Персонал, выполняющий H&RA технологического процесса с помощью методов анализа рисков (HAZOP, FMEA, что если?), часто не понимает требования к определению режима работы функции безопасности SIS и необходимому значению SIL для нее. Кроме того, разработчикам часто не хватает навыков для надлежащего выполнения этих задач из-за того, что они не знакомы с методологиями назначения величины интенсивности отказов для BPCS, SIS и SIL (такими как LOPA, граф рисков, Матрица рисков, описанные в МЭК 61511-3), что часто приводит к неудовлетворительному выполнению процессов H&RA и распределению приборных уровней защиты.

Одно из распространенных заблуждений состоит в том, что МЭК 61511-1 не включает требования к H&RA или приборным уровням защиты с уровнем снижения риска (RRF) менее или равным 10. Из-за непосредственного и неизбежного влияния отказов BPCS и других приборных уровней защиты на спецификацию и проектирование функции безопасности SIS эти требования были признаны необходимыми и были включены в разделы, рассматривающие H&RA.

Другое ошибочное мнение состоит в том, что предельное значение частоты отказов BPCS в качестве исходного источника предназначено специально для аппаратных средств BPCS (или даже только для самого контроллера). BPCS, как определено в изд.2, включает в себя все устройства, необходимые для обеспечения того, чтобы технологический процесс выполнялся заданным способом, за конкретным исключением устройств, выполняющих функции безопасности SIS (то есть SIS). Задавая планируемую частоту отказов (примерно один отказ в десять лет), важно понимать, что в характеристике интенсивности отказов BPCS обычно доминирует частота ошибок человека (например, контроллеры были оставлены в ручном режиме, неуправляемые изменения в настройках программы или эксплуатация при значениях параметров, выходящих за ограничения, предусмотренные в первоначальном проекте технологического процесса).

Команды H&RA, которые не привлекают специалиста, компетентного в обеспечении функциональной безопасности технологического процесса, как правило, недооценивают долгосрочные затраты и сложность выполняемых действий на стадиях жизненного цикла SIS. Это приводит к тому, что не рассматриваются другие методы снижения риска, что приводит к дополнительным функциям безопасности SIS или аварийным сигналам вместо того, чтобы создать изначально более безопасный проект, используя предохранительные клапаны давления или пассивные средства обеспечения безопасности, которые будут иметь более низкую стоимость владения на протяжении длительного времени. Также зачастую недооценивается последствие несвоевременного выполнения работы по H&RA.

H&RA - это, как правило, итеративная работа, которая часто не понимается или не отражается в графике проекта и штатном расписании. Например проекты, в которых используются поставляемые комплекты, обычно предоставляют информацию по функциональной безопасности позже, чем это необходимо для конкретной проектной деятельности, или не могут использовать подходы H&RA, которые соответствуют основным принципам безопасности предприятия. Это может привести к дополнительной верификации и оценкам (см. раздел 5).

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

      8.3 Что изменилось во 2-м издании по сравнению с 1-м и почему?

В связи с увеличением числа инцидентов кибербезопасности в системах управления и безопасности промышленной автоматики во всем индустриальном мире и более частым применением SIS с возможностью цифровой связи с другими устройствами, в изд.2 были добавлены повышенные требования к защите информации. В область применения и цели изд.1 не предполагалось включать дополнительные подробные требования к информационной безопасности в модель жизненного цикла SIS. Изд.1 указывает, что функциональная безопасность может быть достигнута только с учетом угроз кибербезопасности путем тесной координации между соответствующими дисциплинами в рамках общего управления технологическим процессом. Изд.2 уточняет, какие минимальные действия по защите информации должны быть выполнены для ее обеспечения в SIS без дублирования необходимых средств или целей обеспечения такой защиты, поскольку это входит в область применения специальных документов, таких как МЭК 62443 (все части). Новые разделы указывают, что должна быть выполнена оценка рисков, связанных с возможными нарушениями защиты информации, включая SIS, и чтобы SIS была разработана с учетом обеспечения необходимой устойчивости к рискам защиты информации и постоянного управления ими (см. также раздел 10).

В изд.2 по отношению к изд.1 включен новый пункт: 8.2.4.

      8.4 Кратко о том, что изменилось

H&RA технологического процесса должен быть выполнен во время начальной стадии проектирования и повторно выполняется после рабочего проектирования. В разделах 8 и 9 определяются требуемое снижение риска и слои защиты для обеспечения снижения риска с любым значением коэффициента снижения риска от значения риска, присущего технологическому процессу, до допустимого значения риска, установленного уполномоченным органом. Примеры того, как это может быть выполнено, приведены в МЭК 61511-3:2016. Анализ системы защиты информации BPCS, включающей в себя SIS, выполняется, как определено в 8.2.4 изд.2. В примечаниях к 8.2.4 изд.2 приведены примеры выполнения такого анализа. Несоответствия, выявленные в ходе этого анализа, оформляются документально и устраняются перед запуском нового или измененного технологического процесса.

      9 Распределение функций безопасности по слоям защиты (изд.2, раздел 9)

      9.1 Почему этот раздел важен?

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

      9.2 Распространенные ошибки

Зависимость между слоями защиты и инициирующим источником опасного события часто считают незначительной. Как правило, это связано с несоответствующей документацией по функциональной безопасности или неполным H&RA технологического процесса. Аналогичным образом при назначении целей снижения риска средствам обеспечения безопасности часто не учитываются ограничения существующего оборудования, например устройства могут находиться в труднодоступном месте или иметь известные проблемы с производительностью. Наконец, команды часто игнорируют возможную зависимость слоя защиты BPCS и завышают оценку снижения риска для BPCS.

Другое ошибочное мнение состоит в том, что слой защиты BPCS и BPCS являются терминами, которые могут использоваться как взаимозаменяемые. BPCS - это интегрированная система устройств (таких как полевые приборы, контроллеры, вспомогательные системы и HMI), которые используются для безопасной эксплуатации производственной системы, за исключением SIS. Слой защиты BPCS является конкретным независимым механизмом в BPCS (устройством BPCS или набором устройств BPCS), реализующим функции безопасности. С достаточным уровнем независимости между слоями защиты BPCS в BPCS могут поддерживаться до двух таких слоев защиты BPCS.

Часто считают, что МЭК 61511-1 применяется только к превентивным мерам обеспечения безопасности. Требования жизненного цикла в МЭК 61511-1 применяются также к слоям защиты, которые смягчают последствия опасного события и основаны на приборных функциях с требуемым значением SIL, равным 1 или более, определенным в результате анализа опасности технологического процесса. Например, системы обнаружения пожарной и газовой опасности и запуска водяной завесы. Верификация снижения риска для этих систем включает в себя анализ охвата устройства обнаружения и эффективности ослабления не только датчика, логического решателя, исполнительного устройства, но и аппаратных средств системы вспомогательных устройств, вносящими вклад в интенсивность отказов. Реализация мер по смягчению последствий, осуществляющих снижение риска более, чем в 10 раз, является достаточно трудной задачей.

      9.3 Что изменилось во 2-м издании по сравнению с 1-м и почему?

9.3.1 Ограничения на слои защиты BPCS

Частота отказов, заявленная для инициирующих источников, связанных с отказом контура управления BPCS, и снижение риска, распределенное слоям защиты BPCS, таким как типовые аварийные сигнализации, непосредственно влияют на достижение цели снижения риска и режим работы для соответствующей функции безопасности SIS. Опыт применения изд.1 показал, что в его пунктах 9.4.2 и 9.4.3 недостаточно четко были выражены следующие ограничения, предусмотренные ТК МЭК 65А:

- максимальное снижение риска, которое может быть назначено для слоя защиты BPCS;

- максимальное количество независимых слоев защиты, которые могут быть реализованы в BPCS для данного опасного события;

- требования к независимости для слоев защиты, реализуемых в BPCS.

Эти ограничения отражают общее влияние на эффективность, связанное с менее строгими методами проектирования, реализации и менеджмента, обычно применяемыми для BPCS (по сравнению с методами, используемыми для SIS). Важность каждого из этих ограничений, представленных в изд.1, соответствуют постоянно развивающейся практике, которая в последнее время была продемонстрирована в публикации в области обрабатывающей промышленности, такой как CCPS Guidelines for Initiating Events and Independent Protection Layers in Layer of Protection Analysis, опубликованной в 2014 году.

Следует помнить о следующих ключевых моментах:

a) если для слоя защиты BPCS было назначено RRF>10, то к подсистеме, реализующей этот слой защиты, применяются все соответствующие требования изд.1 (т.е. ее функция безопасности реализуется как для функции безопасности SIS);

b) если конкретное опасное событие затрагивает две функции BPCS (являющиеся инициирующим источником опасного события или слоем (слоями) защиты), то системы, выполняющие эти функции, либо должны быть независимыми, либо эти совместно используемые подсистемы должны соответствовать требованиям изд.1 к совместному снижению частоты последствий (т.е. совместно используемая подсистема фактически является подсистемой SIS).

В изд.2 изменены пункты: 3.2.3, 8.2.2, 9.3.2, 9.3.3.

В изд.2 по отношению к изд.1 включены новые пункты: 9.3.4, 9.3.5.

9.3.2 Требование общего снижения риска более, чем в 10000 раз, для мер снижения риска

Основная причина изменения заключается в том, что, в то время как изд.1 предусматривало требования для одиночной функции с SIL 4, в изд.2 было принято решение о том, что вопрос об общем снижении риска в 10000 раз следует рассматривать независимо от того, относится ли оно к одной или нескольким функциям на различных слоях защиты. Если определено, что SIS или SIS совместно с BPCS должны обеспечить высокий уровень снижения риска (RRF > 10000), то группе H&RA следует пересмотреть изначально более безопасный проект или другие слои защиты (например, предохранительную арматуру, пассивные барьеры, административные средства управления доступом) для снижения риска. В то время как функция с SIL 4 или значение RRF, равное 10000, могут быть достигнуты математически, опыт сектора промышленных процессов показывает, что вопросы, связанные с систематическими отказами, при реализации таких высоких уровней снижения риска чрезвычайно затрудняют (и существенно повышают стоимость) не только их достижение, но и вызывают гораздо больше проблем при их технической поддержке. Даже когда снижение риска распределяется по нескольким слоям защиты с независимыми устройствами исходной системы безопасности (датчиками, логическими решателями, исполнительными устройствами), то для программирования, эксплуатации и обслуживания приборных средств обеспечения безопасности часто используется общий персонал. Если после анализа изначально более безопасного варианта реализации приборных функций защиты все еще подтверждается необходимость для RRF>10000, то требуется более глубокий анализ случайных и систематических ошибок.

В изд.2 изменен пункт: 9.2.5.

В изд.2 по отношению к изд.1 включены новые пункты: 9.2.6, 9.2.7.

      9.4 Кратко о том, что изменилось

Анализ риска опасных событий (см. примеры в МЭК 61511-3) должен проводиться в соответствии с допустимыми требованиями к риску, установленными соответствующим уполномоченным органом или нормативно-правовой базой.

Одним из результатов этого анализа является выбор функций безопасности и их распределение по слоям защиты для снижения риска до допустимого уровня. Анализ функций безопасности и уровней защиты, используемый для проверки общего снижения риска, должен быть обоснованным и заслуживающим доверия подходом. Этот анализ должен учитывать множество факторов, таких как независимость, разнообразие, общая причина, обеспечение полноты, аудитопригодность, тестируемость и разделение между слоями. Если общее снижение риска, распределяемое приборным средствам обеспечения безопасности, превышает 10000, то следует тщательно проанализировать допущения, касающиеся эффективности и независимости слоев защиты (для каждого и инициирующего события). Если зависимость будет выявлена, то анализ ее последствий должен быть включен в общий количественный анализ. Этот анализ должен быть выполнен в процессе H&RA, а также в конце рабочего проектирования функций.

      10 Спецификация требований безопасности SIS (изд.1, раздел 10)

      10.1 Почему этот раздел важен?

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

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