ГОСТ Р МЭК 62061-2013 Безопасность оборудования. Функциональная безопасность систем управления электрических, электронных и программируемых электронных, связанных с безопасностью.

     ГОСТ Р МЭК 62061-2013

Группа Т51

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

 БЕЗОПАСНОСТЬ ОБОРУДОВАНИЯ. ФУНКЦИОНАЛЬНАЯ БЕЗОПАСНОСТЬ СИСТЕМ УПРАВЛЕНИЯ ЭЛЕКТРИЧЕСКИХ, ЭЛЕКТРОННЫХ И ПРОГРАММИРУЕМЫХ ЭЛЕКТРОННЫХ, СВЯЗАННЫХ С БЕЗОПАСНОСТЬЮ

 Safety of machinery - Functional safety of safety-related electrical, electronic and programmable electronic control systems

ОКС 13.110,

         25.040.49,

         29.020*

Дата введения 2014-08-01

Предисловие

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

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 58 "Функциональная безопасность"

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

4 Настоящий стандарт идентичен международному стандарту МЭК 62061:2005* "Безопасность оборудования. Функциональная безопасность систем управления электрических, электронных и программируемых электронных, связанных с безопасностью" (IEC 62061:2005 "Safety of machinery - Functional safety of safety-related electrical, electronic and programmable electronic control systems)

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

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

Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (gost.ru)

 Введение

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

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

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

Настоящий стандарт соответствует требованиям МЭК 61508 для области оборудования (машин). Он предназначен для того, чтобы способствовать спецификации характеристик СБЭСУ для основных опасностей (см. ИСО 12100-1, п.3.8), вызванных работой машин.

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

СБЭСУ часто используются в оборудовании (машинах) в качестве одной из мер по обеспечению безопасности для снижения риска выполнения опасного события. Типичный случай - блокирование доступа, которое предоставляет доступ к опасной зоне и сигнализирует электрической системе управления о необходимости остановить работу машины. Также при автоматизации электрическая система управления, используемая для обеспечения корректного выполнения процессов машины, часто способствует безопасности, смягчая риски, связанные с опасностями, возникающими непосредственно из-за отказов системы управления. В настоящем стандарте представлены методология и требования к:

- определению требуемого уровня полноты безопасности для каждой связанной с безопасностью функции управления, реализуемой СБЭСУ;

- выполнению проекта СБЭСУ для соответствующей(их) определенной(ых) связанной(ых) с безопасностью функции(й) управления;

- интеграции связанных с безопасностью подсистем, разработанных в соответствии с ИСО 13849;

- подтверждению соответствия СБЭСУ.

Настоящий стандарт должен использоваться в рамках подхода к систематическому снижению риска, описанного в ИСО 12100-1, и в сочетании с оценкой степени риска согласно принципам, описанным в ИСО 14121 (ЕН 1050). Предлагаемая методология для определения уровня полноты безопасности (УПБ) дана в приложении А.

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

На рисунке 1 показана связь настоящего стандарта с другими соответствующими стандартами.

Рисунок 1 - Связь настоящего стандарта с другими соответствующими стандартами. Информация о рекомендуемых применениях настоящего стандарта и ИСО 13849-1

В таблице 1 даны рекомендации по применению настоящего стандарта и ИСО 13849-1.

Таблица 1 - Рекомендуемое применение настоящего стандарта и ИСО 13849-1     

Настоящий стандарт и ИСО 13849-1 определяют требования к проектированию и реализации связанных с безопасностью систем управления оборудованием машин. Использование любого из этих стандартов в соответствии с их областями применения предполагает выполнение соответствующих важных требований к обеспечению безопасности. В таблице 1 совместно рассмотрены области применения настоящего стандарта и ИСО 13849-1.     

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

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

Примечания

1 В настоящем стандарте термин "электрические системы управления" используется вместо "электрические, электронные и программируемые электронные (Э/Э/ПЭ) системы управления", а СБЭСУ - вместо "связанные с безопасностью электрические, электронные и программируемые электронные системы управления".

2 В настоящем стандарте предполагается, что проектирование сложных программируемых электронных подсистем или их элементов удовлетворяет соответствующим требованиям МЭК 61508. Стандарт представляет методологию для применения, а не разработки, подсистем и их элементов, являющихся частью СБЭСУ.

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

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

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

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

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

- не определяет требования к характеристикам неэлектрических (например, гидравлических, пневматических) элементов системы управления машин;

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

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

Цели разделов настоящего стандарта представлены в таблице 2.

Таблица 2 - Цели разделов настоящего стандарта     

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

В настоящем стандарте использованы нормативные ссылки на следующие стандарты*:

МЭК 60204-1 Безопасность машин. Электрооборудование машин и механизмов. Часть 1. Общие требования (IEC 60204-1, Safety of machinery - Electrical equipment of machines - Part 1: General requirements)

МЭК 61000-6-2 Электромагнитная совместимость (ЭМС). Часть 6-2. Общие стандарты. Устойчивость в промышленных условиях (IEC 61000-6-2, Electromagnetic compatibility (EMC) - Part 6-2: Generic standards - Immunity for industrial environments)

МЭК 61000-4 Электромагнитная совместимость (ЭМС). Части 4. Методы испытаний и измерений (IEC 61000-4, Electromagnetic compatibility (EMC) - Parts 4: Testing and measurement techniques)

МЭК 61310 (все части) Безопасность машин. Индикация, маркирование и запуск. (IEC 61310 (all parts), Safety of machinery - Indication, marking and actuation)

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

МЭК 61508 (все части) Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью (IEC 61508 (all parts), "Functional safety of electrical/electronic/programmable electronic safety-related systems")

МЭК 61511 (все части) Безопасность функциональная. Приборные системы безопасности, для технологических процессов в промышленности. (IEC 61511-1 (IEC 61511 (all parts), Functional safety - Safety instrumented systems for process industry sector)

ИСО 12100-1:2003 Безопасность оборудования. Основные понятия, общие принципы конструирования. Часть 1. Основные термины, методика (ISO 12100-1:2003, Safety of machinery - Basic concepts, general principles for design - Part 1: Basic terminology, methodology)

ИСО 12100-2:2003 Безопасность оборудования. Основные понятия, общие принципы конструирования. Часть 2. Технические принципы (ISO 12100-2:2003, Safety of machinery - Basic concepts, general principles for design - Part 2: Technical principles)

ИСО 13849-1:1999

Безопасность оборудования. Элементы систем управления, связанные с безопасностью. Часть 1. Общие принципы конструирования (ISO 13849-1:1999, Safety of machinery - Safety related parts of control systems - Part 1: General principles for design)

_______________

Отменен. Действует ИСО 13849-1:2003 Безопасность оборудования. Элементы систем управления, связанные с безопасностью. Часть 1. Общие принципы конструирования.

ИСО 13849-2:2003

Безопасность оборудования. Элементы систем управления, связанные с безопасностью. Часть 2. Подтверждение соответствия (ISO 13849-2:2003, Safety of machinery - Safety-related parts of control systems - Part 2: Validation)

_______________

Отменен. Действует ИСО 13849-2:2012 Безопасность оборудования. Элементы систем управления, связанные с безопасностью. Часть 2. Подтверждение соответствия.

ИСО 14121 Безопасность оборудования. Принципы оценки риска (ISO 14121, Safety of machinery - Principles of risk assessment)

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

      3.1 Алфавитный список терминов

Термин	Пункт раздела 3
архитектура	3.2.35
архитектурное ограничение	3.2.36
безопасный отказ	3.2.41
верификация	3.2.51
вероятность опасного отказа в час;	3.2.28
встроенное программное обеспечение	3.2.47
доля безопасных отказов; ДБО	3.2.42
запрос	3.2.25
компонент низкой сложности	3.2.7
контрольная проверка	3.2.37
мера защиты	3.2.12
механизмы	3.2.1
опасность	3.2.10
опасная ситуация	3.2.11
опасный отказ	3.2.40
отказ	3.2.39
отказ по общей причине	3.2.43
охват диагностикой	3.2.38
подсистема	3.2.5
подтверждение соответствия	3.2.52
полнота безопасности	3.2.19
полнота безопасности аппаратных средств	3.2.20
полнота безопасности, касающаяся систематических отказов	3.2.22
полнота безопасности программного обеспечения	3.2.21
предельное требование к УПБ (для подсистемы); ПТУПБ	3.2.24
прикладное программное обеспечение	3.2.46
программное обеспечение, связанное с безопасностью	3.2.50
режим с высокой частотой запросов или непрерывный режим	3.2.27
режим с низкой частотой запросов	3.2.26
риск	3.2.13
сбой	3.2.30
связанная с безопасностью функция управления, СБФУ	3.2.16
связанные с безопасностью электрические системы управления; СБЭСУ	3.2.4
система управления машиной	3.2.2
систематический отказ	3.2.45
сложный компонент	3.2.8
случайный отказ аппаратных средств	3.2.44
среднее время до отказа; ( )	3.2.34
уровень полноты безопасности; УПБ	3.2.23
устойчивость к отказам	3.2.31
функциональная безопасность	3.2.9
функциональный блок	3.2.32
функция безопасности	3.2.15
функция диагностики	3.2.17
функция реакции на отказ СБЭСУ	3.2.18
функция управления	3.2.14
целевая величина отказов	3.2.29
электрическая система управления	3.2.3
элемент подсистемы	3.2.6
элемент функционального блока	3.2.33
язык программирования с ограниченной изменчивостью; ЯОИ	3.2.49
язык программирования с полной изменчивостью; ЯПИ	3.2.48

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

В настоящем стандарте используются следующие термины и определения:

3.2.1 механизмы (machinery): Совокупность связанных между собой деталей и устройств, как минимум одно из которых движется, имеет соответствующий привод, органы управления и сети электропитания, соединенные вместе для конкретного применения, например для обработки, переработки, производства, транспортирования или упаковки материалов.

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

[ИСО 12100-1:2003, п.3.1]

3.2.2 система управления машиной (machine control system): Система, которая реагирует на входной сигнал, например, от процесса, других элементов машины, оператора, внешнего управляемого оборудования и генерирует выходной(ые) сигнал(ы), заставляющий(ие) машину вести себя предназначенным способом.

3.2.3 электрическая система управления (electrical control system): Система управления машины, выполняющая, например, операционное управление, контроль, взаимную блокировку, связь, защиту и связанные с безопасностью функции управления и использующая только электрические, электронные и программируемые электронные компоненты.

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

3.2.4 связанные с безопасностью электрические системы управления, СБЭСУ (Safety-Related Electrical Control System, SRECS): Электрическая система управления, отказ которой может непосредственно привести к увеличению риска(ов).

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

3.2.5 подсистема (subsystem): Объект проекта архитектуры верхнего уровня СБЭСУ, в которой отказ любой подсистемы приведет к отказу связанной с безопасностью функции управления.

Примечания

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

2 Данное определение является ограничением общего, представленного в МЭК 61508-4: набор элементов, взаимодействующих в соответствии с проектом, где элементом системы может быть другая, названная подсистемой, которая может включать аппаратные средства, программное обеспечение и взаимодействие с человеком.

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

3.2.6 элемент подсистемы (subsystem element): Часть подсистемы, включающая отдельный компонент или группу компонентов.

3.2.7 компонент низкой сложности (low complexity component): Компонент, для которого:

- хорошо определены режимы отказов;

- может быть полностью определено поведение в условиях отказа.

[МЭК 61508-4, п.3.4.4 модифицирован]

Примечания

1 Поведение компонента низкой сложности в условиях отказа может быть определено аналитическими и/или методами испытаний.

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

3.2.8 сложный компонент (complex component): Компонент, для которого:

- плохо определены режимы отказов;

- не может быть полностью определено поведение в условиях отказа.

3.2.9 функциональная безопасность (functional safety): Часть безопасности машины и системы управления машины, которая зависит от корректного функционирования СБЭСУ, систем, связанных с безопасностью, основанных на других технологиях и внешних средств снижения риска.

[МЭК 61508-4, п.3.1.9 модифицирован]

Примечания

1 Настоящий стандарт рассматривает только функциональную безопасность, которая зависит от корректного функционирования СБЭСУ в применениях для оборудования машин.

2 В ИСО/МЭК Руководство 51 безопасность определена как отсутствие неприемлемого риска.

3.2.10 опасность (hazard): Потенциальный источник телесного повреждения или причинения вреда здоровью.

[ИСО 12100-1:2003, п.3.6 модифицирован]

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

3.2.11 опасная ситуация (hazardous situation): Обстоятельства, при которых человек подвергается одной или нескольким опасностям.

[ИСО 12100-1:2003, п.3.9 модифицирован]

3.2.12 мера защиты (protective measure): Мера, направленная на достижение снижения риска.

[ИСО 12100-1:2003, п.3.18 модифицирован]

3.2.13 риск (risk): Сочетание вероятности причинения вреда и его тяжести.

[ИСО 12100-1:2003, п.3.11]

3.2.14 функция управления (control function): Функция, которая оценивает входную информацию или сигналы и формирует выходную информацию или действия.

3.2.15 функция безопасности (safety function): Функция машины, отказ которой может привести к непосредственному увеличению риска(ов).

[ISO 12100-1:2003, п.3.28]

Примечание - Данное определение отличается от определений в МЭК 61508-4 и ИСО 13849-1.

3.2.16 связанная с безопасностью функция управления, СБФУ (Safety-Related Control Function, SRCF): Функция управления, реализованная СБЭСУ с заданным уровнем полноты и предназначенная для поддержки безопасных условий работы машины или предотвращения увеличения риска(ов).

3.2.17 функция диагностики СБЭСУ (SRECS diagnostic function): Функция, предназначенная для обнаружения отказов в СБЭСУ и формирования заданной выходной информации или действия при обнаружении отказа.

Примечание - Данная функция предназначена для обнаружения отказов, которые могут привести к опасному отказу СБФУ, и запуска заданной функции реакции на отказ.

3.2.18 функция реакции на отказ СБЭСУ (SRECS fault reaction function): Функция, которая запускается, когда в СБЭСУ обнаружен отказ с помощью функции диагностики СБЭСУ.

3.2.19 полнота безопасности (safety integrity): Вероятность того, что СБЭСУ или ее подсистема будет удовлетворительно выполнять требуемые связанные с безопасностью функции управления при всех указанных условиях.

[МЭК 61508-4, п.3.5.2 модифицирован]

Примечания

1 Чем выше уровень полноты безопасности элемента, тем ниже вероятность, что элемент не выполнит требуемую связанную с безопасностью функцию управления.

2 Полнота безопасности включает полноту безопасности аппаратных средств (см. 3.2.20) и систематическую полноту безопасности (см. 3.2.22).

3.2.20 полнота безопасности аппаратных средств (hardware safety integrity): Составляющая полноты безопасности СБЭСУ или ее подсистем, включающая требования к вероятности опасных случайных отказов технических средств и к архитектурным ограничениям.

[МЭК 61508-4, п.3.5.5 модифицирован]

3.2.21 полнота безопасности программного обеспечения (software safety integrity): Составляющая систематической полноты безопасности СБЭСУ или ее подсистем, связанная с возможностью программного обеспечения в программируемой электронной системе выполнять в ней связанные с безопасностью функции управления при всех заданных условиях в течение установленного промежутка времени.

[МЭК 61508-4, п.3.5.3 модифицирован]

Примечание - Обычно полнота безопасности программного обеспечения не может быть охарактеризована количественно.

3.2.22 систематическая полнота безопасности (systematic safety integrity): Составляющая полноты безопасности СБЭСУ или ее подсистем, касающаяся ее противодействия систематическим отказам (см. 3.2.45), проявляющимся в опасном режиме.

[МЭК 61508-4, п.3.5.4 модифицирован]

Примечания

1 Обычно полнота безопасности, касающаяся систематических отказов, не может быть охарактеризована количественно.

2 Требования к полноте безопасности, касающейся систематических отказов, применяются как к аппаратным средствам, так и к аспектам программного обеспечения СБЭСУ или ее подсистем.

3.2.23 уровень полноты безопасности; УПБ (safety integrity level (SIL)): Дискретный уровень (принимающий одно из трех возможных значений), устанавливающий требования к полноте безопасности связанных с ней функций управления, которые были определены для СБЭСУ, при этом уровень 3 является высшим уровнем полноты безопасности, а уровень 1 является самым низшим.

[МЭК 61508-4, п.3.5.6 модифицирован]

Примечание - УПБ 4 в настоящем стандарте не рассматривается, поскольку такие требования к снижению риска обычно не используют для машинного оборудования. О требованиях при применении УПБ 4 см. МЭК 61508-1 и МЭК 61508-2.

3.2.24 предельное требование к УПБ (для подсистемы), ПТУПБ (SIL Claim Limit (for a subsystem), SILCL): максимальное значение УПБ, которое может быть заявлено для подсистемы СБЭСУ относительно архитектурных ограничений и систематической полноты безопасности.

3.2.25 запрос (demand): Событие, которое инициирует СБЭСУ выполнять свою СБФУ.

3.2.26 режим с низкой частотой запросов (low demand mode): Режим работы, в котором частота запросов к СБЭСУ не больше, чем один раз в год, и не больше удвоенного значения частоты контрольных проверок.

Примечание - Оборудование, которое в соответствии с требованиями спроектировано для работы только в режиме с низкой частотой запросов, описанном в МЭК 61508-1 и МЭК 61508-2, может быть непригодно для применения в качестве элемента СБЭСУ, соответствующей настоящему стандарту. Режим работы с низкой частотой запросов не используется для применений СБЭСУ в оборудовании машин.

3.2.27 режим с высокой частотой запросов или непрерывный режим (high demand or continuous mode): Режим работы, в котором частота запросов к СБЭСУ больше, чем один раз в год, либо больше, чем удвоенная частота контрольных проверок.

[МЭК 61508-4, п.3.5.12 модифицирован]

Примечания

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

2 Режим запроса означает, что связанная с безопасностью функция управления выполняется только по запросу (требованию), чтобы перевести машину в указанное состояние. СБЭСУ не влияет на машину, пока нет требований к связанной с безопасностью функции управления.

3 Непрерывный режим подразумевает стабильное выполнение связанной с безопасностью функции управления, т.е. СБЭСУ постоянно управляет машиной и (опасный) отказ ее функции может привести к опасному событию.

3.2.28

вероятность опасного отказа в час,

(probability of a dangerous failure per hour,

): Средняя вероятность опасного отказа в час.

Примечание -

не надо путать с вероятностью отказов по запросу (PFD).

3.2.29

целевая величина отказов

(target failure value): Заданное значение

, которое должно быть достигнуто, чтобы удовлетворить конкретное требование полноты безопасности.

Примечание - Целевая величина отказов задается в терминах вероятности опасного отказа в час.

[МЭК 61508-4, п.3.5.13 модифицирован]

3.2.30 сбой (fault): Ненормальный режим, способный вызвать снижение или потерю способности СБЭСУ, подсистемы или элемента подсистемы выполнять требуемую функцию.

[МЭК 61508-4, п.3.6.1 модифицирован]

3.2.31 устойчивость к отказам (fault tolerance): Способность СБЭСУ, подсистемы или элемента подсистемы продолжать выполнять необходимую функцию при наличии сбоев или ошибок.

[МЭК 61508-4, п.3.6.3 модифицирован]

3.2.32 функциональный блок (functional block): Наименьший элемент СБФУ, отказ которого может привести к отказу СБФУ.

Примечания

1 В настоящем стандарте СБФУ (Ф) можно рассматривать как логическую функцию из функциональных блоков (ФБ), то есть

.

2 Это определение функционального блока отличается от используемого в МЭК 61131-3 и других стандартах.

3.2.33 элемент функционального блока (function block element): Часть функционального блока.

3.2.34 среднее время до отказа (Mean Time То Failure, MTTF): Ожидание среднего времени наработки на отказ.

[МЭС 191-12-07 модифицирован]

Примечание - MTTF обычно выражается как среднее значение ожидания времени безотказной работы.

3.2.35 архитектура (architecture): Конкретная конфигурация элементов аппаратных средств и программного обеспечения СБЭСУ.

[МЭК 61508-4, п.3.3.5 модифицирован]

3.2.36 архитектурное ограничение (architecture constraint): Набор требований к архитектуре, ограничивающих УПБ, который может быть востребован для подсистемы.

Примечание - Требования к архитектурным ограничениям представлены в 6.7.6.

3.2.37 контрольная проверка (proof test): Проверка, выполняемая для того, чтобы обнаружить отказы и ухудшение функционирования СБЭСУ и ее подсистем с тем, чтобы при необходимости СБЭСУ и ее подсистемы могли быть восстановлены настолько близко к "исходному" состоянию, насколько это возможно в данных условиях.

[МЭК 61508-4, п.3.8.5 модифицирован]

Примечание - Контрольная проверка предназначена для того, чтобы подтвердить, что СБЭСУ находится в состоянии, которое обеспечивает заданную полноту безопасности.

3.2.38 охват диагностикой (diagnostic coverage): Уменьшение вероятности опасных отказов аппаратного обеспечения, связанное с выполнением автоматических диагностических проверок.

[МЭК 61508-4, п.3.8.6 модифицирован]

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

- охват диагностикой,

- интенсивности выявленных опасных отказов,

- общая интенсивность опасных отказов:

.

3.2.39 отказ (failure): Прекращение способности СБЭСУ, подсистемы или элемента подсистемы выполнять требуемую функцию.

[МЭК 61508-4, п.3.6.4 модифицирован и ИСО 12100-1:2003, п.3.32]

Примечание - Отказы могут быть случайными (в аппаратных средствах) или систематическими (в аппаратных средствах или в программном обеспечении).

3.2.40 опасный отказ (dangerous failure): Отказ СБЭСУ, подсистемы или элемента подсистемы, который может привести к опасному состоянию или ошибке при выполнении функции.

[МЭК 61508-4, п.3.6.7 модифицирован]

Примечания

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

2 В многоканальной подсистеме вероятность опасного отказа может быть меньше, чем интенсивность опасного отказа канала, который включен в подсистему. Вероятность же опасного отказа СБЭСУ не может быть меньшей, чем вероятность опасного отказа любой из подсистем, составляющей СБЭСУ (это следует из определения "подсистемы", данного в настоящем стандарте).

3 Опасный отказ обычно приводит к отказу или возможному отказу выполнения СБФУ.

3.2.41 безопасный отказ (safe failure): Отказ СБЭСУ, подсистемы или ее элемента, не вызывающий опасность.

[МЭК 61508-4, п.3.6.8 модифицирован]

Примечание - Безопасный отказ не приводит к отказу или возможному отказу выполнения СБФУ.

3.2.42 доля безопасных отказов, ДБО (safe failure fraction, SFF): Доля общей интенсивности отказов подсистемы, которые не приводят к опасному отказу.

Примечание - Значение ДБО может быть вычислено по следующей формуле:

,

где

- интенсивность безопасных отказов;

- общая интенсивность отказов;

- интенсивность опасных отказов, выявляемых диагностикой;

- интенсивность опасных отказов.

Диагностический охват (если таковой имеется) каждой подсистемы в СБЭСУ учитывается при вычислении вероятности случайных отказов аппаратных средств. ДБО - при определении архитектурных ограничений на полноту безопасности аппаратных средств (см. 6.7.7).

3.2.43 отказ по общей причине (common cause failure): Отказ, который является результатом одного или нескольких событий, вызвавших одновременные отказы двух и более отдельных каналов в многоканальной подсистеме (с архитектурой с резервированием), ведущий к отказу СБЭСУ.

[МЭК 61508-4, п.3.6.10 модифицирован]

Примечание - Данное определение отличается от представленного в ИСО 12100-1 и МЭС 191-04-23.

3.2.44 случайный отказ аппаратных средств (random hardware failure): Отказ, возникающий в случайный момент времени и являющийся результатом одного или нескольких возможных механизмов ухудшения характеристик аппаратных средств.

[МЭК 61508-4, п.3.6.5]

3.2.45 систематический отказ (systematic failure): Отказ, обусловленный определенной причиной, которая может быть исключена только путем модификации проекта, производственного процесса, операций, документации или других факторов.

[МЭК 61508-4, п.3.6.6]

Примечания

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

2 Систематический отказ может быть вызван имитацией причины отказа.

3 Примерами причин систематических отказов являются ошибки человека:

- в спецификации требований к безопасности;

- в проекте, при изготовлении, вводе в эксплуатацию или работе аппаратных средств;

- при проектировании, реализации и т.п. программного обеспечения.

3.2.46 прикладное программное обеспечение (application software): Определенное для применения программное обеспечение, реализованное разработчиком СБЭСУ, обычно содержащее последовательность логических операций, ограничения и выражения и управляющее соответствующей входящей и выходящей информацией, вычислениями и решениями, удовлетворяющими функциональные требования СБЭСУ.

3.2.47 встроенное программное обеспечение (embedded software): Программное обеспечение, поставленное производителем, которое является частью СБЭСУ и, как правило, недоступное для модификации.

Примечание - Программное обеспечение программируемой электроники, а также системное программное обеспечение - примеры встроенного программного обеспечения.

3.2.48 язык программирования с полной изменчивостью, ЯПИ (full variability language, FVL): Тип языка, позволяющий реализовать широкий диапазон функций и прикладных задач.

[МЭК 61511-1, п.3.2.81.1.3 модифицирован]

Примечания

1 Типичными примерами систем, применяющих ЯПИ, являются системы, широко используемые компьютерами.

2 Обычно ЯПИ применяется во встроенном программном обеспечении и реже - в прикладном.

3 Примерами ЯПИ являются Ada, С, Pascal, языки ассемблера, C++, Java, SQL.

3.2.49 язык программирования с ограниченной изменчивостью, ЯОИ (limited variability language, LVL): Тип языка программирования, который позволяет объединять предварительно определенные, специфические для предметной области библиотечные функции для выполнения спецификаций требований к системе безопасности.

[МЭК 61511-1, п.3.2.81.1.2 модифицирован]

Примечания

1 ЯОИ обеспечивает близкое соответствие функциям, необходимым для реализации применения.

2 Типичные примеры ЯОИ приведены в МЭК 61131-3 и включают языки многоступенчатых диаграмм, функциональных блок-диаграмм, последовательностных функциональных схем.

3 Типичными примерами систем, использующих ЯОИ, являются программируемые логические контроллеры (ПЛК), сконфигурированные для управления оборудованием машин.

3.2.50 программное обеспечение, связанное с безопасностью (safety-related software): Программное обеспечение, которое используется для реализации СБФУ в системах, связанных с безопасностью.

3.2.51 верификация (verification): Подтверждение проверкой (например, тестами, анализом), что СБЭСУ, ее подсистемы или элементы подсистемы удовлетворяют требованиям, установленным соответствующей спецификацией.

[МЭК 61508-4, п.3.8.1 модифицирован и МЭК 61511-1, п.3.2.92 модифицирован]

Примечание - Результаты верификации должны быть представлены в виде документально оформленных объективных доказательств.

Пример - Процессы верификации включают:

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

- просмотр проектов;

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

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

3.2.52 подтверждение соответствия (validation): Подтверждение проверкой (например, тестами, анализом), что СБЭСУ соответствует требованиям функциональной безопасности для конкретного применения.

[МЭК 61508-4, п.3.8.2 модифицирован]

      3.3 Сокращения

В настоящем стандарте использованы следующие сокращения.

Сокращение	Полное выражение
ООП	Отказ по общей причине
	Охват диагностикой
ЭМС	Электромагнитная совместимость
ФБ	Функциональный блок
ЯПИ	Язык программирования с полной изменчивостью
Вх/Вых	Вход/Выход
ЯОИ	Язык программирования с ограниченной изменчивостью
	Вероятность опасного отказа в час
	Среднее время до отказа
	Среднее время восстановления
	Вероятность опасности ошибки передачи
ДБО	Доля безопасных отказов
УПБ	Уровень полноты безопасности
ПТУПБ	Предельное требование к УПБ (для подсистем); ПТУПБ
СБ	Связанный с безопасностью
СБЭСУ	Связанная с безопасностью электрическая система управления
СБФУ	Связанная с безопасностью функция управления
СТСБ	Спецификация требований к системе безопасности
СИС	Система

      4 Управление функциональной безопасностью

      4.1 Цель

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

      4.2 Требования

4.2.1 План обеспечения функциональной безопасности должен быть составлен и документально оформлен для каждого проекта СБЭСУ и обновляться по мере необходимости. Он должен включать процедуры по управлению действиями, определенными в разделах 5-9.

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

- размер;

- степень сложности;

- степень новизны и используемых технологий;

- уровень стандартизации характеристик;

- возможное(ые) последствие(я) в случае отказа.

В частности план должен содержать:

a) идентификацию соответствующих действий, заданных в разделах 5-9;

b) описание политики и стратегии для выполнения заданных требований к функциональной безопасности;

c) описание стратегии обеспечения функциональной безопасности для прикладного программного обеспечения, разработки, интеграции, верификации и подтверждения соответствия СБЭСУ;

d) идентификацию лиц, департаментов или других подразделений и ресурсов, которые отвечают за проведение и рассмотрение каждого из мероприятий, указанных в разделах 5-9;

e) определение или формирование процедуры и ресурсов для записи и сохранения информации, относящейся к функциональной безопасности СБЭСУ;

Примечание - Необходимо рассмотреть следующее:

- результаты идентификации опасностей и оценки рисков;

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

- организацию, ответственную за поддержание функциональной безопасности;

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

f) описание стратегии управления конфигурацией (см. 9.3), учитывающей соответствующие организационные проблемы, такие как наличие уполномоченных лиц и внутренней структуры организации;

g) созданный план верификации, включающий:

- подробную информацию о том, когда проводится верификация;

- подробную информацию о лицах, отделах или подразделениях, которые осуществляют верификацию;

- информацию о выборе стратегий и методов верификации;

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

- информацию о выборе действий по верификации;

- критерии приемки;

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

h) созданный план подтверждения соответствия, включающий:

- подробную информацию о том, когда проводится подтверждение соответствия;

- информацию об определении соответствующих режимов работы машины (например, нормальная работа, установка);

- требования, в соответствии с которыми должно проводиться подтверждение соответствия СБЭСУ;

- описание технической стратегии для подтверждения соответствия, например аналитические методы или статистические тесты;

- критерии приемки;

- описание предпринимаемых действий в случае невыполнения критериев приемки.

Примечание - Необходимо, чтобы план подтверждения соответствия указывал, должны ли СБЭСУ и ее подсистемы быть предметом для обычного тестирования, типовых испытаний и/или выборочного тестирования.

4.2.2 План обеспечения функциональной безопасности должен быть реализован для оперативного наблюдения и удовлетворительного решения вопросов, связанных с СБЭСУ и вытекающих из:

- действий, указанных в разделах 5-9;

- действий по верификации;

- действий по подтверждению соответствия.

      5 Требования к спецификации связанных с безопасностью функций управления

      5.1 Цель

Данный раздел устанавливает процедуры для определения требований к связанным с безопасностью функциям управления (СБФУ), реализуемых СБЭСУ.

      5.2 Спецификация требований к СБФУ

5.2.1 Общие положения

5.2.1.1 Как указано в ИСО 12100-1, ИСО 12100-2 и ИСО 14121, необходимость в функциях безопасности определяется из стратегии по снижению риска.

5.2.1.2 Если функции безопасности выбраны для реализации (полностью или частично) СБЭСУ, то СБФУ должны быть специфицированы (см. 3.2.16).

5.2.1.3 Спецификация каждой СБФУ должна включать спецификацию:

- функциональных требований (см. 5.2.3);

- требований к полноте безопасности (см. 5.2.4).

Они должны быть документально оформлены в спецификации требований к системе безопасности (СТСБ).

Примечания

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

- электромеханические устройства;

- непрограммируемые электронные устройства;

- программируемые электронные устройства.

2 Необходимо обеспечить управление версиями СТСБ, которое должно быть одной из процедур управления конфигурацией (см. 9.3).

5.2.1.4 СТСБ должна быть проверена, чтобы обеспечить согласованность и полноту для предназначенного использования.

Примечание - Например, это может быть достигнуто путем осмотра, анализа, применения метода таблицы контрольных проверок. См. также МЭК 61508-7, п.В.2.6.

5.2.2 Необходимая информация

Для формирования спецификации функциональных требований и спецификации требований к функциональной безопасности для каждой СБФУ необходима следующая информация:

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

- эксплуатационные характеристики машины, в том числе:

- режимы работ;

- время цикла;

- характеристика времени отклика;

- условия окружающей среды;

- взаимодействие персонала с машиной (например, при ремонте, установке, уборке);

- вся информация, относящаяся к СБФУ, которая может повлиять на проектирование СБЭСУ, например:

- описание поведения машины, которое СБФУ должна обеспечить или предотвратить;

- все интерфейсы между СБФУ, а также между СБФУ и любыми другими функциями (внутри или вне машины);

- требуемая функциональная реакция на отказ для СБФУ.

Примечание - Некоторая информация может быть недоступна или полностью не определена перед началом итерационного процесса проектирования СБЭСУ, поэтому в процессе проектирования необходимо обновлять спецификации требований к безопасности СБЭСУ.

5.2.3 Спецификация функциональных требований к СБФУ

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

- условие(я) (например, режим работы) машины, при котором(ых) СБФУ должна быть активна или заблокирована;

- приоритет тех функций, которые могут быть одновременно активны и вызвать конфликтную ситуацию;

- частоту работы каждой СБФУ;

- требуемое время реакции каждой СБФУ;

- интерфейс(ы) СБФУ с другими функциями машины;

- требуемое время отклика (например, устройства ввода и вывода);

- описание каждой СБФУ;

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

- описание окружающих условий (например, температуры, влажности, пыли, химических веществ, механических вибраций и ударов);

- испытания и любые необходимые для этого средства (например, испытательное оборудование, порты доступа тестов);

- частоту циклов выполнения операций, рабочий цикл и/или категории применения для электромеханических устройств, предназначенных для использования в СБФУ

5.2.3.2 Кроме требований МЭК 61000-6-2 к СБЭСУ, предназначенных для использования в промышленных условиях, должны выполняться требования к уровням электромагнитной (ЭМ) устойчивости, приведенные в приложении Е. СБЭСУ для использования в другой ЭM среде (например, жилые помещения), должны иметь уровни устойчивости в соответствии с указанными в различных стандартах по электромагнитной совместимости (например, для жилых помещений по МЭК 61000-6-1).

Примечания

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

2 Критерий электромагнитной устойчивости для функциональной безопасности СБЭСУ приведен в 6.4.3.

5.2.4 Спецификация требований к полноте безопасности для СБФУ

5.2.4.1 Требования к полноте безопасности для каждой СБФУ должны определяться исходя из оценки возможного риска, чтобы обеспечить его необходимое снижение. В настоящем стандарте требование к полноте безопасности выражается в виде целевой величины отказов для вероятности опасных отказов в час для каждой СБФУ.

5.2.4.2 Требования к полноте безопасности для каждой СБФУ должны задаваться в терминах УПБ в соответствии с таблицей 3 и документально оформляться. Пример метода определения УПБ приведен в приложении А.

Таблица 3 - Уровни полноты безопасности. Целевые величины отказов

Уровень полноты безопасности (УБП)	Вероятность опасных отказов в час ( )
3	10 -<10
2	10 -<10
1	10 -<10

Примечание - Если требуемая полнота безопасности СБФУ меньше, чем УПБ 1, то, как минимум, требования категории В ИСО 13849-1 должны быть удовлетворены.

5.2.4.3 Если в стандарте на изделие определен УПБ для СБФУ, то он должен иметь приоритет над приложением А.

      6 Проектирование и интеграция СБЭСУ

      6.1 Цель

Данный раздел устанавливает требования к выбору или проектированию СБЭСУ, удовлетворяющей функциональные требования и требования к полноте безопасности, указанные в спецификации требований к системе безопасности (см. 5.2).

      6.2 Общие требования

6.2.1 СБЭСУ должна быть выбрана или разработана с учетом спецификации требований к системе безопасности (см. 5.2) и, где это необходимо, с учетом спецификации требований к программному обеспечению системы безопасности (см. 6.10) в соответствии с требованиями настоящего стандарта.

6.2.2 Методы выбора или проектирования СБЭСУ (в том числе общей архитектуры аппаратных средств и программного обеспечения, датчиков, приводов, программируемой электроники, встроенного и прикладного программного обеспечения и т.п.) должны соответствовать п.6.5 или п.6.6. Какой бы метод ни использовался, СБЭСУ должна соответствовать следующим требованиям:

a) к полноте безопасности аппаратных средств, включая:

- ограничения архитектуры на полноту безопасности аппаратных средств (см. 6.6.3.3);

- требования к вероятности опасных случайных отказов аппаратных средств (см. 6.6.3.2).

b) к систематической полноте безопасности, включая:

- требования к возможности избежать отказы;

- требования к управлению систематическими ошибками;

c) к поведению СБЭСУ при выявлении ошибки (см. 6.3);

d) к проектированию и разработке связанного с безопасностью программного обеспечения (см. 6.10 и 6.11).

6.2.3 Проект СБЭСУ должен учитывать возможности и ограничения человека (в том числе разумно предсказуемое неправильное использование) и быть пригодным для действий, выполняемых операторами, обслуживающим персоналом и другими, кто может взаимодействовать с СБЭСУ. Необходимо, чтобы проектирование всех интерфейсов оператором следовало "хорошим практикам" учета человеческого фактора (см. МЭК 61310), а также учитывало вероятный уровень подготовки или осведомленности операторов, в частности при массовом производстве подсистем, где оператором может быть любой человек.

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

6.2.4 В целях содействия реализации этих свойств в ходе разработки и интеграции СБЭСУ должны быть рассмотрены ремонтопригодность и тестируемость СБЭСУ.

6.2.5. Необходимо, чтобы проект СБЭСУ, его диагностические функции и функции реакции на отказ были документально оформлены. Эта документация должна:

- быть точной, полной и краткой;

- соответствовать предназначенной цели;

- быть доступной и поддерживаемой;

- обеспечиваться управлением версиями.

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

      6.3 Требования к поведению СБЭСУ при обнаружении в ней сбоя

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

Такая спецификация может содержать действия по изоляции неисправных частей подсистемы для продолжения безопасной эксплуатации машины в то время, как происходит ремонт неисправных частей. Если неисправная деталь не будет восстановлена в течение максимального времени оцененного, как принято из расчета вероятности случайного сбоя в технических средствах (см. 6.7.8), то для поддержки безопасного состояния должна быть выполнена реакция на второй сбой.

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

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

Примечание - При определении среднего времени восстановления (см. МЭС 191-13-08), которое рассматривается в модели надежности, необходимо учитывать интервал диагностических проверок, время ремонта и любые другие задержки при восстановлении.

6.3.2 Если для достижения требуемой вероятности случайных опасных отказов аппаратных средств необходима(ы) функция(и) диагностики и подсистема имеет устойчивость к сбоям аппаратных средств, равную нулю, то обнаружение сбоя и заданная на него реакция должны быть выполнены до того, как может произойти опасная ситуация, предусмотренная СБФУ

Исключение к п.6.3.2. Если подсистема реализует конкретную СБФУ, у которой устойчивость к сбоям аппаратных средств равна нулю, а отношение частоты диагностического тестирования к частоте запросов превышает 100, то интервал диагностического тестирования этой подсистемы должен быть таким, чтобы она удовлетворяла требование к вероятности опасного случайного сбоя технических средств.

6.3.3 Если выполнение функции реакции на сбой как части СБФУ, для которой определен УПБ 3, привело к остановке машины, то последующая нормальная работа машины с СБЭСУ (например, ее повторный запуск) не должна выполняться до тех пор, пока сбой не будет восстановлен или исправлен. Для СБФУ с заданной полнотой безопасности менее УПБ 3, поведение машины после выполнения функции реакции на сбой (например, перезапуск нормальной работы) должно зависеть от спецификации соответствующих функций реакции на сбой (см. 5.2.3).

      6.4 Требования к систематической полноте безопасности СБЭСУ

Примечание - Данные требования применимы на "системном уровне", где подсистемы объединены для реализации СБЭСУ. Требования, относящиеся к реализации подсистемы, см. в п.6.7.8.

6.4.1 Требования для предотвращения систематических отказов аппаратных средств

6.4.1.1 Должны быть применены следующие меры:

a) необходимо, чтобы СБЭСУ была спроектирована и реализована в соответствии с планом функциональной безопасности (см. 4.2);

b) правильные выбор, состав, схемы, сборка и установка подсистем, в том числе кабелей, проводов и любых соединений;

c) применение СБЭСУ в соответствии со спецификацией производителя;

d) следование указаниям производителя по применению, например, каталог, инструкции по установке и использование хорошей технической практики (см. также ИСО 13849-2, п.D.1);

e) применение подсистем с совместимыми рабочими характеристиками (см. также ИСО 13849-2, п.D.1);

f) СБЭСУ должна быть защищена в соответствии с МЭК 60204-1;

g) предотвращение потери функции заземления в соответствии с МЭК 60204-1;

h) не должны использоваться документально не оформленные режимы работы компонентов (например, "зарезервированные" регистры программируемого оборудования);

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

6.4.1.2 Кроме этого, должен(на) быть применен(а), по крайней мере, один(на) из следующих методов и/или мер, с учетом сложности СБЭСУ и УПБ для тех функций, которые будут реализованы СБЭСУ:

a) анализ проекта аппаратных средств СБЭСУ (например, с помощью проверки или сквозного контроля) для выявления в результате осмотров и/или анализа расхождений между спецификацией и реализацией;

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

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

Примечание - Полнота этих инструментов может быть продемонстрирована конкретным тестированием, обширной историей удовлетворительного использования или независимой верификацией их выходных результатов для конкретно разрабатываемой СБЭСУ. См. 6.11.3.4.

c) моделирование, которое систематически и полно реализует представление проекта СБЭСУ как в терминах функциональных характеристик, так и с точки зрения правильного определения размеров и взаимодействия ее подсистем;

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

6.4.2 Требования к управлению систематическими сбоями

Должны быть применены следующие меры:

a) использование обесточивания: необходимо, чтобы СБЭСУ были сконструированы таким образом, чтобы при потере их электропитания машины переходили в безопасное состояние или оставались в нем.

b) контроль за влиянием временных отказов подсистемы: СБЭСУ должна быть сконструирована таким образом, чтобы, например:

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

Примечание - См. также соответствующие требования в МЭК 60204-1. В частности:

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

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

- воздействие электромагнитных помех от физического окружения или подсистем(ы) не приводило к опасности.

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

Примечания

1 Более подробную информацию можно найти в МЭК 60870-5-1, ЕН 50159-1, ЕН 50159-2 и МЭК 61508-2.

2 Термин "нелегальное проникновение" означает, что истинное содержание сообщения определено неправильно. Например, сообщения от опасного компонента приняты как сообщения от безопасного.

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

(см. 6.7.4.4.2, перечисление g)).

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

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

6.4.3 Электромагнитная (ЭМ) устойчивость

Кроме требований МЭК 61000-6-2 и требований к ЭМ процессам, приведенным в приложении Е, СБЭСУ должна удовлетворять следующим критериям электромагнитной устойчивости для функциональной безопасности:

- опасные условия или опасности не должны вноситься;

- связанные с безопасностью функции управления должны выполняться без перебоев;

- выполнение СБФУ, реализуемых СБЭСУ, может быть нарушено временно или постоянно, если безопасное состояние машины поддерживается или достигнуто до возникновения опасности. Если ЭМ явления могут привести к повреждению компонентов, то необходимо удостовериться (например, путем анализа), что они не повлияют на функциональную безопасность, в том числе и для более низких значений параметров ЭМ явлений, которые могут привести к частичному повреждению.

Примечание - Следует рассмотреть вопрос о поведении СБЭСУ при воздействии на нее ЭМ явлений для всех значений характеристик, приведенных в приложении Е.

      6.5 Выбор связанной с безопасностью электрической системы управления

Если поставщик предоставляет СБЭСУ для конкретной функции, указанной в спецификации требований к безопасности системы, то им могут быть выбраны заранее разработанные СБЭСУ, вместо проекта, заказанного клиентом, при условии, что эти решения соответствуют спецификации требований к безопасности системы, а также п.п.6.3, 6.4 и 6.6.1.

Примечание - Выбор заранее разработанных СБЭСУ является альтернативой проектирования и разработки конкретных СБЭСУ в соответствии с п.6.6.

      6.6 Проектирование и разработка СБЭСУ

6.6.1 Общие требования

6.6.1.1 СБЭСУ должна быть спроектирована и разработана в соответствии со спецификацией требований к безопасности СБЭСУ (см. 5.2).

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

6.6.1.3 Если для достижения требуемой полноты безопасности при обнаружении сбоя необходимо использование диагностики, то СБЭСУ должна выполнять заданную функцию реакции на отказ (см. 5.2 и п.6.3).

6.6.1.4 Если СБЭСУ или компонент СБЭСУ (т.е. ее подсистема(ы)) реализует СБФУ и другие функции, не относящиеся к безопасности, то все ее технические средства и программное обеспечение должны рассматриваться как связанные с безопасностью до тех пор, пока не будет установлено, что СБФУ и другие функции выполняются достаточно независимо (т.е. нормальная работа или отказ какой-либо функции не станет причиной отказа СБФУ).

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

6.6.1.5 Если СБЭСУ или ее подсистемы реализуют связанные с безопасностью функции управления с различными уровнями полноты безопасности, то требования к аппаратным средствам и программному обеспечению СБЭСУ или ее подсистем должны определяться уровнем полноты безопасности СБФУ с самым высоким уровнем полноты безопасности, если не будет установлено, что выполнение СБФУ с различными уровнями полноты безопасности достаточно независимо.

Примечание - Достаточную независимость выполнения устанавливают демонстрацией того, что вероятность зависимого отказа между компонентами, выполняющими СБФУ с различными уровнями полноты безопасности, эквивалентна уровню полноты безопасности, достигаемому СБЭСУ.

6.6.1.6 Соединения (например, проводники, кабели), кроме используемых для цифровой передачи данных, должны рассматриваться как элементы одной из подсистем, к которой они подключены (см. также перечисление g) п.6.4.2).

6.6.1.7 Если система цифровой передачи данных реализуется как часть СБЭСУ, то она должна удовлетворять соответствующим требованиям МЭК 61508-2 в соответствии с целевыми значениями УПБ для СБФУ.

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

6.6.2 Процесс проектирования и разработки

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

Примечание - В настоящем стандарте используется подход, основанный на применении структурированного процесса проектирования СБЭСУ, начиная с требований, определенных в спецификации требований к системе безопасности. На рисунке 2 представлен процесс проектирования и терминология, которая применяется на разных стадиях.

Рисунок 2 - Структура процесса проектирования и разработки СБЭСУ

6.6.2.1 Проектирование архитектуры системы

6.6.2.1.1 Каждая СБФУ, как указано в спецификации требований к безопасности СБЭСУ, должна быть структурно декомпозирована до функциональных блоков, например, как показано на рисунке 3. Необходимо, чтобы такая структура была документально оформлена и включала:

- ее описание;

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

- определение входов и выходов каждого функционального блока.

Примечания

1 Процесс декомпозиции позволяет сформировать структуру функциональных блоков, полностью описывающую функциональные требования и требования к полноте СБФУ. Этот процесс должен быть применен до уровня, позволяющего установить функциональные и требования к полноте для каждого функционального блока, который будет реализован в подсистеме, если такое выделение функциональных блоков и полных требований для реализации подсистемами возможно. Тем не менее можно реализовать несколько функциональных блоков в одной подсистеме, но невозможно один функциональный блок реализовать несколькими подсистемами, каждая из которых имеет свои функциональные и требования к полноте безопасности. Если это необходимо, то следует выделить функциональные требования одного функционального блока для их реализации дополнительными элементами подсистемы, см. 6.7.4.

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

3 Функциональные блоки представляют функции СБФУ (см. 3.2.16) и не включают диагностические функции СБЭСУ (см. 3.2.17). Для достижения целей настоящего стандарта диагностические функции рассматриваются как отдельные, которые могут иметь структуру, отличную от СБФУ (см. 6.8).

Рисунок 3 - Распределение требований к безопасности между функциональными блоками в подсистемах (см. 6.6.2.1.1)

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

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

6.6.2.1.3 Каждый функциональный блок должен быть реализован соответствующей подсистемой в архитектуре СБЭСУ. Одна подсистема может реализовать более одного функционального блока.

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

6.6.2.1.5 Необходимо, чтобы архитектура была документально оформлена, ее подсистемы и их взаимосвязи были описаны.

6.6.2.1.6 Требования к безопасности для каждого функционального блока должны быть сформулированы, как указано в спецификации требований к безопасности соответствующей СБФУ, в терминах:

- функциональных требований (например, входная информация, внутренняя логика работы и выходная информация функционального блока);

- требований к полноте безопасности.

6.6.2.1.7 Требования к безопасности для подсистемы должны быть такими же, как и для функциональных блоков, которые она реализует. Если подсистема реализует более одного блока, то для нее применяется требование с наибольшим значением полноты безопасности (см. 6.6.3). Эти требования должны быть документально оформлены в качестве спецификации требований к безопасности подсистемы.

6.6.3 Требования к оценке полноты безопасности, достигаемой СБЭСУ

6.6.3.1 Общие положения

УПБ, который может быть достигнут СБЭСУ, должен рассматриваться отдельно для каждой СБФУ, выполняемой СБЭСУ. УПБ, который может быть достигнут СБЭСУ, определяется вероятностью опасных случайных отказов технических средств, архитектурными ограничениями, а также систематической полнотой безопасности подсистем, входящих в СБЭСУ. Достигаемый УПБ меньше или равен наименьшему значению предельного требования к УПБ любой из подсистем для систематической полноты безопасности и архитектурных ограничений.

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

6.6.3.2.1 Вероятность опасного отказа каждой СБФУ из-за случайных опасных отказов технических средств должна быть меньше или равна целевой величине отказов, заданной в спецификации требований к безопасности.

Примечание - Целевые значения отказов, связанные с УПБ, приведены в таблице 3.

6.6.3.2.2 Вероятность опасного отказа каждой СБФУ из-за случайных опасных отказов технических средств должна быть оценена с учетом:

a) архитектуры СБЭСУ, поскольку это касается каждой рассматриваемой СБФУ;

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

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

6.6.3.2.3 Оценка вероятности опасных отказов должна быть основана на вероятности случайных опасных отказов аппаратных средств каждой соответствующей подсистемы, которая определяется с использованием информации, перечисленной в п.6.7.2.2, с учетом в соответствующих случаях п.6.7.2.2, перечисление к) для цифровой передачи данных между процессами подсистем. Вероятность случайных отказов аппаратных средств в СБЭСУ является суммой вероятностей опасных случайных отказов аппаратных средств всех подсистем, участвующих в реализации СБФУ, и включает в случае необходимости вероятность опасных ошибок цифровой передачи данных коммуникационных процессов:     

Примечания

1 Данный подход основан на определении функционального блока, то есть отказ любого функционального блока может привести к отказу СБФУ (см. 3.2.16).

2 Взаимодействия, отличные от цифровой передачи данных, считаются частью подсистем.

6.6.3.3 Ограничения архитектуры

УПБ, достигаемый СБЭСУ в соответствии с архитектурными ограничениями, меньше или равен наименьшему значению предельного требования к УПБ любой из подсистем (см. 6.7.6), участвующих в выполнении СБФУ.

Примечание - Например, СБЭСУ состоит из двух последовательно соединенных подсистем (подсистема 1 и подсистема 2), где ДБО и устойчивость к отказам каждой подсистемы равны значениям, показанным в таблице 4. Оценка

для СБЭСУ 8х10

, что соответствует УПБ 3. Тем не менее в соответствии с таблицей 5 архитектурное ограничение подсистемы 2 лимитирует УПБ, которое может быть достигнуто СБЭСУ, до УПБ 2.

Таблица 4 - Характеристики подсистем 1 и 2, используемые в примере (см. примечание к п.6.6.3.3)

6.6.3.4 Систематическая полнота безопасности

УПБ, достигаемый СБЭСУ, меньше или равен наименьшему значению предельного требования к УПБ любой из подсистем, участвующих в выполнении СБФУ.

Примечание - Меры, описанные в 6.7.9, обеспечивают предельное требование к УПБ до значения УПБ 3 для систематической полноты безопасности подсистемы, реализуемой в соответствии с п.6.7.4.

      6.7 Реализация подсистем

6.7.1 Цель

Цель состоит в том, чтобы реализовать подсистему, отвечающую всем требованиям к безопасности, определенным для реализуемых ею функциональных блоков (см. рисунок 3). Рассматриваются два подхода:

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

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

6.7.2 Общие требования к реализации подсистемы

6.7.2.1 Подсистема должна быть реализована с помощью выбора из существующих подсистем (см. 6.7.3), либо спроектирована (см. 6.7.4) в соответствии с ее спецификацией требований к безопасности (см. 6.6.2.1.7) с учетом всех требований 6.2. Подсистема(ы), включающая(ие) сложные компоненты, должна(ы) удовлетворять МЭК 61508-2 и МЭК 61508-3 для требуемого УПБ.

Исключение. Если элемент проекта подсистемы является сложным компонентом, то применяются требования 6.7.4.2.3.

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

a) функциональная спецификация для тех функций и интерфейсов подсистемы, которые могут использоваться СБЭСУ;

b) предполагаемые интенсивности отказов (из-за случайных отказов аппаратных средств), заявленные в любых режимах, способные вызвать опасный отказ СБЭСУ;

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

(то есть ожидаемое время, в течение которого 10% от совокупного количества элементов подсистемы окажется неработоспособным). См. также МЭК 61810-2.

c) ограничения, накладываемые на подсистему:

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

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

d) любые требования к тестированию и/или техническому обслуживанию;

e) охват диагностикой и интервал диагностических проверок (если требуется, см. примечание);

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

f) любая дополнительная информация (например, о временах ремонта), которая необходима для определения среднего времени восстановления (

) после обнаружения ошибки диагностикой.

Примечание - Перечисления b)-f) необходимы для оценки вероятности отказа в час для СБЭСУ;

g) предельное требование к УПБ вследствие архитектурных ограничений (см. 6.7.6), или:

- вся информация, которая необходима для вычисления доли безопасных отказов (ДБО) подсистемы, как это принято для СБЭСУ;

Примечания

1 Необходима информация о возможных режимах отказов подсистемы. На основе информации о режиме отказа подсистемы можно решить, вызывает ли ее отказ безопасный или опасный отказ СБЭСУ

2 Более подробно об оценке ДБО см. 6.7.7.

- и устойчивость к отказам аппаратных средств подсистемы;

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

i) самый высокий уровень полноты безопасности, на который может претендовать СБЭСУ и который использует подсистема на основе:

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

- конструктивных особенностей, допускающих в подсистеме систематические ошибки.

Примечание - Перечисления h) и i) необходимы, чтобы определить самый высокий уровень полноты безопасности, на который может претендовать СБЭСУ согласно ограничениям архитектуры. Кроме того, эти перечисления могут использоваться для обеспечения связи (см. таблицы 4 и 5) с требованиями к категориям из ИСО 13849-1 и с точки зрения обнаружения ошибок, и с точки зрения устойчивости к отказам аппаратных средств;

j) любая информация, которая требуется для идентификации конфигурации аппаратных средств и программного обеспечения подсистемы, чтобы обеспечить управление конфигурацией СБЭСУ в соответствии с 6.11.3.2;

k) вероятность опасных ошибок передачи для цифровых процессов передачи данных, когда это применимо.

6.7.3 Требования к выбору существующих (предварительно спроектированных) подсистем

6.7.3.1 Если поставщик предлагает подсистему для конкретной СБФУ, указанной в спецификации требований к безопасности, то может быть выбрана заранее разработанная подсистема, а не специально спроектированная, при условии, что она удовлетворяет спецификации требований к безопасности для подсистемы, п.6.4.3 и п.6.7.3.2 или п.6.7.3.3.

6.7.3.2 Подсистемы, включающие сложные компоненты, должны соответствовать МЭК 61508-2 и МЭК 61508-3 в зависимости от требуемого УПБ.

Исключение. Если в проекте подсистемы ее элемент является сложным компонентом, то применяется п.6.7.4.2.3.

6.7.3.3 Подсистемы с компонентами только низкой сложности должны соответствовать 6.7.4.4.1, 6.7.6.2, 6.7.6.3, 6.7.7, 6.7.8 и 6.8 настоящего стандарта.

6.7.4 Проектирование и разработка подсистем

6.7.4.1 Цели

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

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

6.7.4.2 Общие требования

6.7.4.2.1 Необходимо, чтобы подсистема была спроектирована в соответствии со спецификацией требований к системе безопасности.

6.7.4.2.2 Подсистема должна удовлетворять все следующие требования к:

a) полноте безопасности аппаратных средств, включающие:

- ограничения архитектуры на полноту безопасности аппаратных средств (см. 6.7.6);

- требования к вероятности случайных опасных отказов аппаратных средств (см. 6.7.8);

b) систематической полноте безопасности, включающие:

- требования к предотвращению отказов (см. 6.7.9.1), а также к управлению систематическими отказами (см. 6.7.9.2);

- подтверждение того, что работа оборудования "доказана на практике". В этом случае подсистема должна отвечать соответствующим требованиям МЭК 61508-2, с 7.4.7.5 по 7.4.7.12;

c) поведению подсистемы при обнаружении отказа (реакция на отказ) (см. 6.3).

6.7.4.2.3 Если проект подсистемы включает сложный компонент (в качестве элемента подсистемы), который удовлетворяет все соответствующие требования МЭК 61508-2 и МЭК 61508-3, связанные с предельным требованием к УПБ, то он может рассматриваться как компонент низкой сложности в контексте проекта подсистемы, так как известна информация о его соответствующих режимах отказов, поведении при их обнаружении, интенсивности отказов, а также другая связанная с безопасностью информация. Такие компоненты должны использоваться только в соответствии с их спецификацией и информацией по их применению, предоставляемой поставщиком.

6.7.4.3 Процесс проектирования и разработки подсистемы

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

Рисунок 4 - Структура процесса проектирования и разработки подсистемы (см. блок 6В на рисунке 2)

6.7.4.3.1 Проектирование архитектуры подсистемы

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

Примечание - Структура процесса проектирования показана на рисунке 4.

Рисунок 5 - Декомпозиция функционального блока на его элементы и связанные с ними элементы подсистемы

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

6.7.4.4 Требования к выбору и проектированию элементов подсистемы

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

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