Страница 4: ГОСТ Р МЭК 61508-2-2007. Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 2. Требования к системам (78658)

7.4.2.5. Если требуется независимость функций безопасности (см. 7.4.2.3 и 7.4.2.4), то в процессе проектирования должны быть задокументированы:

a) метод достижения независимости;

b) обоснование метода.

7.4.2.6. Требования к программному обеспечению (см. МЭК 61508-3) должны быть доступны разработчику Е/Е/РЕ системы, связанной с безопасностью.

7.4.2.7. Разработчик Е/Е/РЕ системы, связанной с безопасностью, должен еще раз пересмотреть требования к программному обеспечению и аппаратным средствам с тем, чтобы убедиться, что они корректно специфицированы. В частности, разработчик E/E/PES должен рассмотреть:

a) функции безопасности;

b) требования к полноте безопасности Е/Е/РЕ системы, связанной с безопасностью;

c) интерфейсы между оборудованием и обслуживающим персоналом.

7.4.2.8. Проектная документация на Е/Е/РЕ систему, связанную с безопасностью, должна определять методы и средства, необходимые для достижения уровня полноты безопасности в течение стадий жизненного цикла безопасности E/E/PES.

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

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

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

7.4.2.11. Проект Е/Е/РЕ системы, связанной с безопасностью, должен быть основан на декомпозиции на подсистемы, каждая из которых имеет специфицированный проект и набор тестов интеграции (см. 7.4.7).

Примечания

1. Конкретная подсистема может состоять из единственного компонента или группы компонентов. Полная Е/Е/РЕ система, связанная с безопасностью, может состоять из множества идентифицируемых и отдельных подсистем, которые при их объединении обеспечивают выполнение рассмотренной функции безопасности. Подсистема может иметь более чем один канал (см. 7.4.7.3).

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

7.4.2.12. Если подсистема имеет многоканальный выход, необходимо определить наличие какой-либо комбинации выходных состояний, которые могут быть вызваны отказом самой Е/Е/РЕ системы, связанной с безопасностью, способной непосредственно вызвать событие опасного отказа (см. анализ опасностей и рисков в МЭК 61508-1, подпункт 7.4.2.10). Если это определено, то предотвращение такой комбинации выходных состояний должно быть расценено как функция безопасности, работающая в режиме с высокой частотой обращения или с непрерывными обращениями (см. 7.4.6.3 и 7.4.3.2.5).

7.4.2.13. Для любых компонентов Е/Е/РЕ системы, связанной с безопасностью, в максимальной степени должно использоваться ограничение допустимых значений (см. МЭК 61508-7, подраздел 2.8). Обоснование работы на пределах любых компонентов должно быть документировано (см. МЭК 61508-1, раздел 5).

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

7.4.3. Требования к полноте безопасности аппаратных средств

Примечание - Обзор необходимых шагов для достижения требуемой полноты безопасности приведен в МЭК 61508-6 (пункт А.2, приложение 2) и там же показано, как этот пункт соотносится с другими требованиями настоящего стандарта.

7.4.3.1. Архитектурные ограничения полноты безопасности аппаратных средств

7.4.3.1.1. В контексте полноты безопасности аппаратных средств наиболее высокий уровень полноты безопасности, который может потребоваться для функции безопасности, ограничивается отказоустойчивостью аппаратных средств и составляющей безопасных отказов подсистем, которые выполняют эту функцию безопасности (см. приложение С). Наибольший уровень полноты безопасности, который может потребоваться для функции безопасности, использующей подсистему, с учетом отказоустойчивости аппаратных средств и составляющей безопасных отказов этой подсистемы представлен в таблицах 2 и 3 (см. также приложение С). Требования таблиц 2 и 3 должны применяться к каждой подсистеме, выполняющей функцию безопасности, и, следовательно, к каждой части Е/Е/РЕ системы, связанной с безопасностью. Подпункты 7.4.3.1.2 - 7.4.3.1.4 определяют, какая из таблиц 2 или 3 применяется к конкретной подсистеме. Подпункты 7.4.3.1.5 и 7.4.3.1.6 определяют самый высокий уровень полноты безопасности, который может быть применен к функции безопасности по запросу. В соответствии с этими требованиями:

a) отказоустойчивость аппаратных средств N означает, что отказ N + 1 может привести к потере функции безопасности. В определении отказоустойчивости не должны учитываться средства, которые могли бы управлять влиянием ошибок, например диагностика, и

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

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

d) долю безопасных отказов подсистемы определяют как отношение суммы средних частот безопасных отказов и опасных отказов, обнаруженных тестами, к полной средней частоте отказов подсистемы (см. приложение С).

Примечания

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

2. Архитектура и подсистема, сформированные для соответствия требованиям отказоустойчивости аппаратных средств, должны быть такими, какие обычно используются в режиме эксплуатации. Требования отказоустойчивости могут быть снижены, если Е/Е/РЕ система, связанная с безопасностью, восстанавливается, находясь под управлением основного оборудования (on-line). Однако ключевые параметры, связанные с любым ослаблением, должны быть предварительно оценены (например, среднее время восстановления по сравнению с вероятностью запроса).

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

7.4.3.1.2. Конкретная подсистема (см. 7.4.2.11, примечание 1) может быть отнесена к типу А, если для ее компонентов, необходимых для реализации функции безопасности:

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

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

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

7.4.3.1.3. Конкретная подсистема (см. 7.4.2.11, примечание 1) должна быть отнесена к типу В, если для ее компонентов, необходимых для реализации функции безопасности:

a) вид отказа, по крайней мере, одного составляющего компонента не определен, или

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

c) нет достоверных эксплуатационных данных по подтверждению требований для частот обнаруженных отказов и необнаруженных опасных отказов (см. 7.4.7.3 и 7.4.7.4).

Примечание - Если, по крайней мере, один из компонентов конкретной подсистемы соответствует условиям для типа В, то такая подсистема должна быть отнесена к типу В, а не к типу А (см. также 7.4.2.11, примечание 1).

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

a) требования отказоустойчивости аппаратных средств достигались для полной Е/Е/РЕ системы, связанной с безопасностью;

b) требования таблицы 2 применялись для любой подсистемы типа А, составляющей часть Е/Е/РЕ системы, связанной с безопасностью.

Примечание - Если Е/Е/РЕ система, связанная с безопасностью, содержит только подсистемы типа А, то требования, приведенные в таблице 2, следует применять к полной Е/Е/РЕ системе, связанной с безопасностью;

c) требования таблицы 3 применялись для любой подсистемы типа В, составляющей часть полной Е/Е/РЕ системы, связанной с безопасностью.

Примечание - Если Е/Е/РЕ система, связанная с безопасностью, содержит только подсистемы типа В, то требования, приведенные в таблице 3, будут применяться для полной системы, связанной с безопасностью;

d) требования таблиц 2 и 3 применялись к Е/Е/РЕ системам, связанным с безопасностью, содержащим оба типа подсистем А и В, поскольку требования таблицы 2 должны применяться к подсистемам типа А, а требования таблицы 3 - к подсистемам типа В.

Таблица 2 - Полнота безопасности аппаратных средств: архитектурные ограничения подсистем, связанных с безопасностью, типа А

Таблица 3 - Полнота безопасности аппаратных средств: архитектурные ограничения подсистем, связанных с безопасностью, типа В

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

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

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

Пример - Пусть система, в которой реализована конкретная функция безопасности, выполнена по одноканальной архитектуре, состоящей из подсистем 1, 2 и 3, типы которых указаны на рисунке 5, и эти подсистемы соответствуют требованиям таблиц 2 и 3 следующим образом:

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

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