3. Для достижения и поддержания состояния безопасности, которое должно быть определено в требованиях безопасности E/E/PES, необходимо выполнить конкретное действие (реакцию на отказ). Это действие может состоять, например, в безопасном отключении в дефектной подсистеме управляемого оборудования или его части, предназначенной для сокращения риска.
7.4.7. Требования к развитию E/E/PES
7.4.7.1. Е/Е/РЕ системы, связанные с безопасностью, должны быть изготовлены в соответствии с проектом.
7.4.7.2. Подсистемы, используемые для одной или более функций безопасности, должны быть идентифицированы и документированы как подсистемы, связанные с безопасностью.
7.4.7.3. Для каждой подсистемы, связанной с безопасностью, должна быть представлена следующая информация (см. также 7.4.7.4):
a) функциональная спецификация тех функций и интерфейсов подсистемы, которые могут быть использованы функциями безопасности;
b) оценочные частоты отказов (из-за случайных отказов аппаратных средств) в любых режимах, которые могли бы привести к отказу Е/Е/РЕ системы, связанной с безопасностью, обнаруживаемые диагностическими тестами (см. 7.4.7.4);
c) оценочные частоты отказов (из-за случайных отказов аппаратных средств), которые могли бы привести к отказу Е/Е/РЕ системы, связанной с безопасностью, не обнаруживаемые диагностическими тестами (см. 7.4.7.4);
d) любые ограничения на окружающую среду подсистемы, которые должны быть соблюдены для обеспечения легитимности оценочных частот отказов из-за случайных отказов аппаратных средств;
e) любое ограничение срока жизни подсистемы, который не должен быть превышен для обеспечения легитимности оценочных частот отказов из-за случайных отказов аппаратных средств;
f) требования к любым контрольным испытаниям и/или техническому обслуживанию;
h) диагностический охват в соответствии с приложением С (при необходимости).
Примечание - Испытания по перечислениям g) и h) относятся к диагностическим испытаниям, которые являются внутренними для подсистемы. Эта информация необходима, если требуется доверие к действиям по проведению диагностических тестов в подсистемах в модели надежности Е/Е/РЕ систем, связанных с безопасностью (см. 7.4.3.2.2);
i) любая дополнительная информация (например, время восстановления), необходимая для обеспечения возможности получения среднего времени восстановления (MTTR), после обнаружения отказа с помощью диагностики.
Примечания
1. Испытания по требованиям перечислений b) и i) необходимы для оценки функции безопасности вероятности отказов по запросу или вероятности отказов в час (см. 7.4.3.2.2).
2. Требования перечислений b), с), g), h) и i) нужны лишь для оценки отдельных параметров подсистем, таких как сенсорные устройства и приводы, которые могут быть объединены в избыточные архитектуры для улучшения полноты безопасности аппаратных средств. Для логических решающих устройств, которые сами не объединяются в избыточные архитектуры в Е/Е/РЕ системе, связанной с безопасностью, с учетом требований перечислений b), с), g), h) и i) допускается определять характеристики в терминах вероятности отказов по запросам или вероятности отказов в час. Для таких устройств необходимо также устанавливать интервал контрольных испытаний для необнаруженных отказов;
j) информация, необходимая для обеспечения выделения составляющей безопасных отказов (SFF) подсистемы, как принято в Е/Е/РЕ системе, связанной с безопасностью, в соответствии с приложением С;
k) отказоустойчивость подсистемы.
Примечание - Требования перечисленийj) и k) необходимы для определения самого высокого уровня полноты безопасности, который может потребоваться для функции безопасности в соответствии с архитектурными ограничениями (см. 7.4.3.1);
l) любые ограничения по применению подсистемы, которые должны быть рассмотрены во избежание систематических отказов;
m) самый высокий уровень полноты безопасности, который может потребоваться для функции безопасности в подсистеме, на основе:
- методов и средств, используемых для предотвращения систематических ошибок, которые вносятся в период проектирования и изготовления аппаратных средств и программного обеспечения (см. МЭК 61508, подпункт 7.4.4.1 и подраздел 7.4),
- особенностей проекта, которые делают подсистему устойчивой к систематическим отказам (см. 7.4.5.1).
Примечание - Не требуется в случаях, если эти подсистемы расцениваются как «проверенные в эксплуатации» (см. 7.4.7.5);
n) любая информация, необходимая для идентификации конфигурации аппаратных средств и программного обеспечения подсистемы для обеспечения возможности управления конфигурацией Е/Е/РЕ системы, связанной с безопасностью, в соответствии с МЭК 61508-1, пункт 6.2.1.
7.4.7.4 Оценочные частоты отказов подсистем из-за случайных отказов аппаратных средств (см. 7.4.7.3, перечисления b) и с)) могут быть определены:
а) методом отказов и анализом влияния проекта с использованием данных по отказам компонентов из признанного промышленного источника.
Примечания
1. Уровень доверия любых используемых данных о частоте отказов должен быть, по крайней мере, равен 70 %. Статистическое определение уровня доверия приведено в IEEE 352. Эквивалентный термин «уровень значимости» используется в МЭК 61164 [4].
2. Предпочтительно, чтобы место размещения данных об отказах было доступным. Если это требование не выполняется, может потребоваться использование исходных данных.
3. Хотя понятие «постоянная частота отказов» подсистемы принято большинством вероятностных оценочных методов, оно применимо лишь при условии, что не превышен срок жизни компонентов подсистемы. Вне их полезного срока жизни (так как вероятность отказов значительно увеличивается со временем) результаты большинства вероятностных расчетных методов бесполезны. Таким образом, любая вероятностная оценка должна включать в себя спецификацию полезного срока жизни компонентов. Полезный срок жизни компонентов подсистем в значительной степени зависит от самого компонента и условий его эксплуатации, особенно температуры окружающей среды компонента (например, могут быть очень чувствительны к температуре электролитические конденсаторы). Опыт показывает, что полезный срок жизни компонентов часто находится в пределах 8-12 лет. Однако эти сроки могут быть значительно меньшими, если компоненты работают в заданных пределах их использования. Компоненты с более длительным полезным сроком жизни стоят значительно дороже;
b) либо из предыдущего опыта использования подсистемы в похожих условиях окружающей среды (см. 7.4.7.9).
7.4.7.5. Для подсистем, проверенных в эксплуатации (см. 7.4.7.6), информация о методах и средствах предотвращения и управления систематическими ошибками (см. 7.4.7.3, перечисление m)) не требуется.
7.4.7.6. Ранее разработанная подсистема должна рассматриваться только как проверенная в эксплуатации, если она имеет явно ограниченные функциональные возможности и имеется соответствующее документальное свидетельство, основанное на предыдущей эксплуатации конкретной конфигурации этой подсистемы (в течение, которого все отказы были формально зарегистрированы (см. 7.4.7.10)) и учитывающее любые требующиеся (см. 4.4.7.8) дополнительные анализы и тесты. Документальное подтверждение должно продемонстрировать, что вероятность любого отказа подсистемы (из-за случайных и систематических отказов аппаратных средств) в Е/Е/РЕ системе, связанной с безопасностью, настолько низка, что достигается(ются) требуемый(ые) уровень(ни) полноты безопасности функции(ий) безопасности.
7.4.7.7. Документальное свидетельство в соответствии с 7.4.7.6 должно продемонстрировать, что предыдущие условия эксплуатации конкретной подсистемы являются такими же или достаточно близкими к тем, в которых будет эксплуатироваться подсистема в Е/Е/РЕ системе, связанной с безопасностью, и установить, что вероятность любых необнаруженных систематических отказов настолько низка, что достигается требуемый уровень(ни) полноты безопасности функции(ий) безопасности для подсистемы.
Примечание - Условия эксплуатации (эксплуатационный профиль) включают в себя все факторы, которые могут повлиять на вероятность систематических ошибок аппаратных средств и программного обеспечения подсистемы (например, окружающую среду, виды использования, выполняемые функции, конфигурацию, связи с другими системами, операционную систему, тип транслятора, человеческий фактор).
7.4.7.8. Если имеются различия между предыдущими условиями эксплуатации подсистемы и условиями, в которых будет эксплуатироваться Е/Е/РЕ система, связанная с безопасностью, то такие различия должны быть идентифицированы и с помощью комбинации соответствующих аналитических методов и испытаний должно быть явно показано, что вероятность любой необнаруженной систематической ошибки настолько низка, что достигается требуемый уровень(ни) полноты безопасности для функции(ий) безопасности подсистемы.
7.4.7.9. Документальное свидетельство по 7.4.7.6 должно установить, что мера предыдущего использования конкретной конфигурации подсистемы (в часах эксплуатации) является достаточной, чтобы статистически рассматривать заявленные частоты отказов. Как минимум, требуется достаточное время эксплуатации для установления данных заявленной частоты отказов в одностороннем нижнем пределе доверия, по крайней мере, 70 % (см. МЭК 61508-7, приложение D, а также IEEE 352). В статистическом анализе время эксплуатации любой индивидуальной подсистемы меньше одного года не рассматривается как часть полного времени эксплуатации.
Примечание - Требуемое время часов эксплуатации для установления заявляемой частоты отказов может быть получено по результатам эксплуатации нескольких идентичных подсистем при условии, что отказы всех подсистем были эффективно обнаружены и документированы (см. 7.4.7.10). Например, если имеется 100 подсистем, каждая из которых проработала без отказов 10000 ч, то полное время эксплуатации без отказов можно считать равным 1000000 ч. В этом случае каждая подсистема должна эксплуатироваться более одного года, и действия при расчетах относят к полученному выше полному числу часов эксплуатации.
7.4.7.10. При проверке выполнения требований по 7.4.7.6 и 7.4.6.9 принимают во внимание только предыдущую эксплуатацию, при которой все отказы подсистем были эффективно обнаружены и документированы (например, если информация об отказах была собрана в соответствии с рекомендациями МЭК 60300-3-2).
7.4.7.11. При проверке выполнения или невыполнения требований по 7.4.7.6 и 7.4.6.9 учитывают как охват, так и уровень детализации имеющейся информации (см. также МЭК 61508-1, подраздел 4.1) для следующих факторов:
a) сложности подсистемы;
b) вклада, внесенного конкретной подсистемой в сокращение риска;
c) последствий, связанных с отказом системы;
d) новизну проекта.
7.4.7.12. Термин «проверено в эксплуатации» применяют к подсистеме, связанной с безопасностью, в Е/Е/РЕ системе, связанной с безопасностью, и ограничивают его рассмотрение функциями и интерфейсами подсистемы, соответствующими требованиям по 7.4.7.6 и 7.4.7.10.
Примечание - Требования 7.4.7.4 - 7.4.7.12 также применимы для подсистем, содержащих программное обеспечение. В этом случае должна быть уверенность в том, что конкретная подсистема выполняет в системе, связанной с безопасностью, только те функции, для которых задана требуемая полнота безопасности (см. также МЭК 61508-3, подпункт 7.4.2.11).
7.4.8. Требования к передаче данных
7.4.8.1. При любой форме передачи данных, используемой при выполнении функции безопасности, оценивается вероятность необнаруженного отказа процесса связи с учетом ошибок передачи, повторов, удалений, вставок, повторного упорядочения, искажения, задержки и ошибок идентификации (см. 7.4.8.2). Эта вероятность должна быть принята во внимание при оценке вероятности опасного отказа функции безопасности из-за случайных отказов аппаратных средств (см. 7.4.3.2.2).
Примечание - Ошибка идентификации означает, что истинное содержание сообщения не идентифицировано правильно (например, сообщение от компонента, не связанного с безопасностью, идентифицировано как сообщение от компонента, связанного с безопасностью).
7.4.8.2. При оценке вероятности отказа функции безопасности из-за процесса передачи данных, в частности, должны быть учтены:
a) остаточный коэффициент ошибок (см. МЭК 60050-371);
b) остаточный коэффициент потери информации (см. МЭК 60050-371);
c) пределы и непостоянство скорости передачи информации (битовая скорость);
d) пределы и непостоянство задержки распространения информации.
Примечания
1. Можно показать, что вероятность опасного отказа в час равна частному от деления вероятности остаточных ошибок на длину сообщения (в битах) и умноженному на скорость передачи в шине сообщений, относящихся к безопасности, и на коэффициент 3600.
2. Более подробную информацию см. в МЭК 60870-5-1 [5], ЕН 50159-1 [7] и ЕН 50159-2 [8].
7.5. Интеграция E/E/PES
Примечание - Эта стадия показана как блок 9.4 на рисунке 2.
7.5.1. Цель
Целью настоящего подраздела является формирование требований к интеграции и испытанию Е/Е/РЕ систем, связанных с безопасностью.
7.5.2. Требования
7.5.2.1. Е/Е/РЕ системы, связанные с безопасностью, должны быть интегрированы в соответствии с конкретным проектом E/E/PES и испытаны в соответствии с конкретными тестами интеграции для E/E/PES (см. 7.4.2.11).
7.5.2.2. Как часть интеграции всех модулей в Е/Е/РЕ систему, связанную с безопасностью, Е/Е/РЕ системы, связанные с безопасностью, должны быть испытаны в соответствии с 7.4. Эти испытания должны показать, что все модули взаимодействуют правильно и не выполняют непредназначенные для них функции.
Примечания
1. Испытание всех входных комбинаций не проводится. Считается достаточным испытание всех классов эквивалентности (см. МЭК 61508-7, пункт В.5.2, приложение В). Статический анализ (см. МЭК 61508-7, пункт В.6.4, приложение В), динамический анализ (см. МЭК 61508-7, пункт В.6.5, приложение В) или анализ отказов (см. МЭК 61508-7, пункт В.6.6, приложение В) могут сократить число испытаний до приемлемого уровня. В случае разработки, проводимой в соответствии с правилами, приводящими к структурному проектированию (см. МЭК 61508-7, пункт В.3.2, приложение В), или полуформальными методами (см. МЭК 61508-7, пункт В.2.3, приложение В) эти требования выполнить легче.
