ГОСТ Р МЭК 60880—2010
13.3.7 Анализ возможности возникновения ООП из-за программного обеспечения должен быть про
веден и документально оформлен как часть оценки защиты от ООП проекта архитектуры контроля и управ
ления (см. 5.3.3 МЭК 61513).
13.3.8 В случае, если в результате анализа обнаружена неприемлемая угроза ООП, возникающая
из-за программного обеспечения, проект программного обеспечения или архитектура контроля и управле
ния должны быть исправлены. Методы реализации защиты от ООП приведены в разделе G.3 приложе
ния G, а методы реализации элементов разнообразия — в разделе G.5 приложения G.
13.4 Реализация разнообразия
13.4.1 При реализации разнообразия следует использовать независимые системы с функциональ
ным разнообразием. Если функциональное разнообразие неуместно или невозможно, то следует рассмот
реть системное разнообразие, разнообразие элементов программного обеспечения и разнообразие подхо
дов к проектированию. Признаки важности разнообразия приведены в разделе G.5 приложения G.
Методы, выбранныедля защиты от ООП. должны быть оформлены документально и обоснованы с
помощью соот
ветствующего анализа.
13.4.2 На уровне программного обеспечения защиту от ООП следует основывать на выборе соответ
ствующих методов, таких как:
1) обеспечение различных условий работы программного обеспечения;
2) защита от ошибки и распространения отказа;
3) снижение отрицательного воздействия ООП;
4) использование программного обеспечения, имеющего различные спецификации для различных
реализаций одних и тех же функциональных требований.
П р и м е ч а н и е 1 — Различия в методах проектирования и реализации следует рассмотреть, но это не
является обязательным требованием.
П р и м е ч а н и е 2 — N-версионное программирование не рекомендуется.
13.5 Баланс недостатков и преимуществ, связанных с использованием разнообразия
Если в программном обеспечении используется разнообразие, то следует обосновать и задокумен
тировать недостатки и преимущества, касающиеся общей надежности программного обеспечения, на ос
нове вышеуказанного анализа (см. 4.27 Руководства по безопасности МАГАТЭ NS-G-1.3 и 3.81 — 3.85
Руководства по безопасности МАГАТЭ NS-G-1.2). Аспекты потенциальных преимуществ, недостатков, а
также аспекты обоснований приведены в разделе G.6 приложения G.
14 Инструментальные программы для разработки
программного обеспечения
14.1 Общие сведения
В настоящем подразделе существующие требования настоящегостандарта представлены в расши
ренном видес тем. чтобы охватить инструментальные программы, используемые при разработке программ
ного обеспечения компьютеров в системах безопасности атомных электростанций.
Использование соответствующих инструментальных программ уменьшает число ошибок в процессе
разработки и. следовательно, повышает надежность программного продукта путем снижения риска внесе
ния дефектов во время этого процесса. Использование инструментальных программ может также иметь
экономические выгоды, поскольку уменьшает время и усилия, необходимые для получения программно
го обеспечения. Инструментальные программы могут применяться для автоматической проверки соблю
дения правил структурирования и требований стандарта, формирования соответствующих записей и со
гласованной документации в стандартных форматах, а такжедля поддержания управления изменениями.
Инструментальные программы могут также уменьшить усилия, необходимые для тестирований, а также
выполнения автоматизированных записей. Необходимость в инструментальных программах может возник
нуть при специфичной методологии разработки, требующей их применения.
14.1.1 Инструментальные программы особенно эффективны в тех случаях, когда они работают со
вместно. Следует соблюдать осторожность и не возлагать на инструментальные программы выполнение
задач, находящихся за пределами их возможностей, например, они не могут заменить человека при при
нятии решений. В некоторых случаях использование инструментальных программ дает больше, чем пол
ная автоматизация процесса. При использовании инструментальных программ должен быть найден баланс
32