ГОСТ Р МЭК 61513—2011
c) Если управление функциями категории А или В выполняется вручную как дублирующеедействия
автоматики, то возможность отказа по общей причине в процессе этих действий должна быть сведена к
минимуму.
d) Если одна функция категории А может инициировать действие системы безопасности, а другая
функция категории А. применяемая при других обстоятельствах, может вызвать противоположное дей
ствие. необходимо провести анализ с целью определения того действия, которое требуется выполнить в
условиях отказа систем контроля и управления.
5.3.1.5.4 Защита от отказа по общей причине вследствие систематических сбоев
a) Планирование высокого качества, предусмотренное при разработке и создании различных систем
контроля и управления комплекса безопасности, должно исключать случаи невыявленных отказов и. та
ким образом, свести риск отказов этих систем по общей причине к минимуму. Настоящий стандарт содер
жит требования, которые следует применять для обеспечения качества систем контроля и управления
различных классов.
b
) Систематические отказыдолжны выявляться средствами самоконтроля (исключая использование
ручек настройки, аппаратуры самоконтроля, проверок правдоподобия), а выявляемые отказы должны пе
реводитьсистему(ы) в предварительно установленное, предпочтительно безотказное состояние, при этом
оператордолжен получать сообщение об отказе.
c) Если требуемая надежность безотказного выполнения функции безопасности больше, чем надеж
ность. полученная в результате оценки безотказногосостояния данной системы, то проект данной системы
следует переработать.
П р и м е ч а н и е 1— Требуемая степень защиты от отказов зависит от категории выполняемых функций.
П р и м е ч а н и е 2 — Цель настоящего подраздела — дать общие сведения. Детальные требования к
защите от отказов по общей причине вследствие ошибок в программном обеспечении для функций категории А
приведены в 4.1 МЭК 60880-2.
5.3.1.5.5 Защита за счет разнообразия
a) В случае, если требуется высокая надежность комплекса безопасности, при проектировании архи
тектуры контроля и управления следует опираться на принцип разнообразия, особенно если имеются нео
пределенности в выполненных в проекте оценках.
b
) Необходимо рассмотреть методы функционального разнообразия и разнообразия сигнала. Эти
методы являются эффективнымидля снижения вероятности отказа по общей причине, возникшего вслед
ствие ошибок в спецификациях требований или в спецификации и установке прикладного программного
обеспечения.
c) Разнообразие оборудования может быть эффективным против отказа по общей причине компонен
тов аппаратного обеспечения и можетобеспечить защиту против сбоев программного обеспечения систе
мы. В частности, ее следует рассматривать при создании сложных систем, если опыт эксплуатации подоб
ных систем ограничен.
d) Следует использовать разнообразие процедур или методов верификации и валидации (например,
разнообразие оборудования для электромагнитных испытаний, испытания на взаимную совместимость с
использованием эмулятора и пр.), что дополнительно поможет избежать отказов по общей причине без
усложнения системы защиты.
e) Еслидля защиты против отказа по общей причине используется защита за счет разнообразия, то в
проект следует включить анализ ее эффективности. Как положительный, так и отрицательный результат
следует зафиксировать и отразить в документации (см. 5.3.3).
5.3.1.5.6 Стратегические решения по ограничению сложности
Для того, чтобы снизить до минимума вероятность отказа по общей причине из-за сложности систем,
проектирование архитектуры контроля и управления должно включать в себя анализ, показывающий, что
степень применения компьютеров вместо систем, построенных на жесткой логике и степень участия чело
века приемлемы с точки зрения обеспечения безопасности.
П р и м е ч а н и е — Такой подход может зависеть от национального опыта, позиции регулирующего органа
и надежности компьютерных технологий.
5.3.2 Распределение функций
При задании функций контроля и управления все требования к ФСО. важные для безопасности,
указанные в 5.2. распределяются по отдельным системам полной архитектуры контроля и управления.
Если необходимо, одна функция может быть представлена в виде нескольких подфункций, раслределен-
23