ГОСТРМЭК 62061—2013
- выбор устройства, которое является достаточным для выполнения требований данной подси
стемы. то есть она должна отвечать спецификации требований к безопасности каждого из реализуемо го
ею функционального блока и требованиям настоящего стандарта;
- проектирование и разработка подсистемы на основе комбинирования элементов функциональ
ных блоков с учетом их организации и взаимодействия в функциональном блоке.
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) любая дополнительная информация (например, о временах ремонта), которая необходима
для определения среднего времени восстановления (MTTR) после обнаружения ошибки диагностикой.
П р и м е ч а н и е — Перечисления Ь)— f) необходимы для оценки вероятности отказа в часдля СБЭСУ;
д) предельное требование к УПБ вследствие архитектурных ограничений (см. 6.7.6). или;
- вся информация, которая необходима для вычисления доли безопасных отказов (ДБО) подси
стемы. как это принято для СБЭСУ;
П р и м е ч а н и я
1 Необходима информация о возможных режимах отказов подсистемы. На основе информации о режиме
отказа подсистемы, можно решить, вызывает ли ее отказ безопасный или опасный отказ СБЭСУ.
2 Более подробно об оценке ДБО см. 6.7.7.
- и устойчивость к отказам аппаратных средств подсистемы;
h) любые ограничения на применение подсистемы, которые необходимо рассмотреть для предот
вращения систематических отказов:
i) самый высокий уровень полноты безопасности, на который может претендовать СБЭСУ и кото
рый использует подсистема на основе:
- мер и методов, применяемыхдля предотвращения систематических отказов во время разработ
ки и реализации аппаратных средств и программного обеспечения подсистемы;
- конструктивных особенностей, допускающих в подсистеме систематические ошибки.
П р и м е ч а н и е — Перечисления h) и i) необходимы, чтобы определить самый высокий уровень полно
ты безопасности, на который может претендовать СБЭСУ согласно ограничениям архитектуры. Кроме того, эти
22