ГОСТ Р МЭК 60880—2010
12.4.2.3 В руководстве пользователя следует определить каждое устройство связи оператора. Каж
дая функция каждого устройства должна бытьобъяснена и проиллюстрирована в соответствии с ео слож
ностью.
12.4.3 Обучающая система
12.4.3.1 Обучение операторадолжно проводиться на обучающей системе, эквивалентной реальной
системе технического и программного обеспечения.
12.4.3.2 Должны быть обеспечены задающие сигналы станции с помощью испытательной системы,
способной моделировать нормальные и аномальные состояния реактора.
13 Защита от отказов по общей причине, вызываемых
программным обеспечением
В настоящем разделе приведены требования к защите от дефектов программного обеспечения и
кодирования, способных привести к отказам по общей причине (ООП) функций, классифицированных по
категории А в соответствии с МЭК 61226.
13.1 Общие сведения
ООП могут произойти в системах контроля и управления и воборудовании, реализующих различные
схемы защиты от тех же ИПС (см. пункт 5.3.1 МЭК 61513). Само по себе программное обеспечение не
вызывает ООП. ООП относятся к отказам системы, возникающим в результате дефектов в функциональ ных
требованиях, проектахсистемы или программного обеспечения.
МАГАТЭ требует применения «защиты в глубину» (см. 2.9 Требований МАГАТЭ NS-R-1) при всех
действиях, будь то организационные, поведенческие или проектирующие действия с целью обеспечения
перекрывающих другдруга защит, такчтобы в случае возникновения отказа в подсистеме он компенсиро
вался или корректировался в интегральной системе.
В соответствии с критерием единичного отказа (см. 5.34 — 5.39Требований МАГАТЭ NS-R-1) требует
ся. чтобы комплекс систем безопасности был способен соответствовать своему назначению, несмотря на
единичный случайный отказ, произошедший влюбой части комплекса.
13.1.1 Дефекты программного обеспечения являются систематическими, а не случайными, поэтому
критерий единичного отказа не может быть применен к программному обеспечению системы так же. как он
применяется ктехническому обеспечению. При применении концепции защиты в глубину следует рассмат
ривать возможные последствия ООП. вызванные программным обеспечением внутри каждого уровня за
щиты и между резервными уровнями защиты, и следует принимать соответствующие контрмеры во время
проведения разработки и оценок (если ООП программного обеспечения является потенциальной причиной
отказа), например:
1) при проектировании и реализации, верификации каждого отдельного слоя защиты и
2) при оценке независимости и разнообразия резервных защитных слоев.
Средством улучшения надежности некоторых систем и снижения вероятности определенных ООП
является разнообразие (см. 4.23 — 4.31 Руководства по безопасности МАГАТЭ NS-G-1.3).
Обоснованием необходимости защиты от дефектов программного обеспечения является тот факт,
что любой дефект программного обеспечения остается незамеченным в соответствующей системе или
соответствующем канале до тех пор. пока не будет зарегистрирован и устранен, и он может вызвать отказ
в случае, если осуществляются обращения к нему при определенной сигнальной траектории. Если две
или более системы либо два или более канала, реализующие различные уровни защиты для одного и того
же ИПС (см. пункт 5.3.1 МЭК 61513), имеют дефект и оказываются под воздействием определенной сиг
нальной траектории в период времени, когда они чувствительны к такому воздействию, то отказ способен
произойти в обеих (или всех) системах и в обоих (или всех) каналах, и это называется ООП. Более подроб
ное описание этих условий приведено в разделе G.1 приложения G.
13.1.2 Возможность возникновения ООП из-за программного обеспечения должна поэтому рассмат
риваться уже при проектировании. Если постулированные условия возникновения ООП могут быть спрог
нозированы. тодля защиты от ООП из-за программного обеспечения может потребоваться изменение про
екта и применение специальных средств защиты, включая разнообразие программного обеспечения.
Степень повышения защиты от ООП, а также степень повышения надежности, которые могут быть
достигнуты, не могут быть определены количественно. Решение должно приниматься на основании каче
ственной оценки надежности,достижимой для программного обеспечения.
30