ГОСТ Р 53195.3—2015
5.8.2.4 Интервал диагностических проверок любой подсистемы с устойчивостью АС к отказам,
равной нулю, от которой полностью зависит функция безопасности (см. примечание 1) и которая явля
ется лишь средством реализации функции или функций безопасности, действующей(их) в режиме с
низкой частотой запросов, должен быть таким, чтобы для Е/Е/РЕ СБЗС-системы обеспечивалась
возможность удовлетворения требований повероятности случайныхотказов АС.
П р и м е ч а н и я
1 В настоящем стандарте принято, что функция безопасности полностью зависит от подсистемы, если отказ
подсистемы вызываетотказ этой функции безопасности £/£/А£СБЗС-систвмы иесли этафункция безопасности не
относится «другой СБЗС-системе.
2 Если существует вероятность того, что некоторые комбинации выходных состояний подсистем могут
непосредственно привести к опасному событию и если комбинация их выходных состояний при наличии ошибки в
подсистеме не может бытьопределена (например, вподсистеме типа Б), тообнаружение опасныхотказов аподсис
теме следует рассматривать как функцию безопасности, действующую в режиме с высокой частотой запросов или с
непрерывным запросом, и применять требования 5.11.3 и 5.8.2.5.
5.8.2.5 Интервал диагностических проверок любой подсистемы с устойчивостью АС к отказам,
равной нулю, от которой полностью зависит функция безопасности (см. примечание 1) и которая
является лишь средством реализации функции безопасности, действующей в режиме с высокой час
тотой запросов или с непрерывным запросом (см. примечание 2), должен быть таким, чтобы значение
суммарного времени, в которое входит интервал диагностических проверок и время выполнения
предусмотренного действия (реакции на отказ), необходимое для достижения или поддержания
безопасного состояния, было меньше времени безопасности процесса.
П р и м е ч а н и я
1 В настоящем стандарте принято, что функция безопасности полностью зависит от подсистемы, если
отказ подсистемы вызывает отказ этой функции безопасности Е/Е/РЕ СБЗС-системы и еспи эта функция безо
пасности не относится кдругой системе, связанной с безопасностью.
2 Подсистему, выполняющую конкретную функцию безопасности, для которой отношение частоты диаг
ностических проверок «частоте запросов превышает 100. допускается рассматривать как осуществляющую функ
цию безопасности врежиме с низкой частотой запросов при условии, что функция безопасности не предотвращает
комбинацию состояний выходов, которые могли бы привести «опасному событию (см. примечание 3).
3 Если функция безопасности служит для предотвращения специфической комбинации состояний выходов,
которые могут непосредственно вызвать опасное событие, то необходимо расценивать такую функцию безопас
ности как функцию, действующую в режиме с высокой частотой запросов или с непрерывным запросом.
Б.8.2.6 Еслидля конкретногопроектазначениецелевой величиныотказовдля требуемойполноты
безопасностидля выполняемой функции безопасности не достигается, то следует:
- определить критические компоненты, подсистемы и/или параметры;
- оценитьэффект возможных мер усовершенствования критических компонентов, подсистем или
параметров (например, применение более надежных компонентов, дополнительных мер защиты от
отказов по общей причине, расширенного охвата диагностикой, расширенной избыточности, умень
шения интервала контрольных испытаний ит. л.),
- выбрать иосуществить подходящие меры усовершенствования;
- повторить вычисление нового значения вероятности отказов АС.
5.9 Требования по предотвращению отказов*
5.9.1 Для предотвращения внесения ошибок во время разработки и создания АС Е/Е/РЕ
СБЗС-системы должна быть использована соответствующая группа методов и средств (см. таблицу Б.2
(приложение Б)].
5.9.2 В соответствии с требуемым УПБ системы выбранный метод проектирования должен
обладать возможностями, способствующимидостижению:
а) прозрачности, модульности и других свойств, позволяющих управлятьсложностью проекта;
б) ясности и точности представления функциональных возможностей, интерфейсов между
подсистемами, а также информации, устанавливающей последовательность и время, параллельность
работы подсистем исинхронизацию;
в) ясности иточностидокументирования ипередачи информации.
г) обеспечения верификации (проверки)и подтверждения соответствия.
* Для подсистемы, соответствующей требованиям, которые расцениваются как «проверено в эксплуатации»
(см. 5.12.6— 5.12.12). требования 5.9.1—5.9.6 не применяют.
18