ГОСТ Р МЭК 60880—2010
Если ошибки совершаются до начала проектирования программного обеспечения, то они могут при вести
кдефектам требований и возможным отказам системы, защита от которых не может быть обеспечена лишь
средствами программотехники. Защита от таких ООП рассматривается вподпункте 5.3.1.5 МЭК61513. Если
ошибки совершаются человеком во время процесса разработки программного обеспечения, то
они могут привести к дефектам программного обеспечения и потенциальным отказам системы. Там. где
такие дефекты приводят к отказам более одного уровня защиты, отказы рассматриваются как ООП из-за
программного обеспечения.
13.2 Проектирование программного обеспечения с учетом ООП
Основной и наиболее важной защитой от ООП из-за программного обеспечения является создание
программного обеспечения высочайшего качества, т.е. насколько это возможно свободного от ошибок.
Другим важным фактором, ограничивающим возможность возникновения ООП из-за программного обес
печения. является расширение самоконтроля с помощью таких действий, как проверка диапазонов пара
метров и подсчет времени циклов с целью проверки достоверности данных и т.п.. как это указано в 6.2.7.1 и
А.2.2 приложения А.
Использованиедля разработки и верификации программного обеспечения развитых методов про
граммирования при поддержке инструментальных программ помогает уменьшить число принимаемых
человеком решений и. таким образом, уменьшить числодефектов в разработанном программном обеспе
чении.
13.3 Источники и последствия ООП из-за программного обеспечения
13.3.1 Анализ возможности возникновения ООП из-за программного обеспечения должен быть про
веден и документально оформлен на системном уровне и/или на уровне общей архитектуры контроля и
управления СКУ. важных для безопасности АЭС.
П р и м е ч а н и е 1— Требования к архитектуре контроля и управления приведены в 5.3.1 МЭК 61513.
П р и м е ч а н и е 2 — Требоеания кархитектуре отдельных систем контроля и управления приведены в 6.1.2
МЭК 61513.
13.3.2 Анализ должен включать в себя следующие шаги:
1) идентификация компонентов программного обеспечения, используемых в системе или в архитек
туре контроля и управления;
2) анализ возможности возникновения ООП из-за этих компонентов в системе или архитектуре конт
роля и управления:
3) анализ возможных последствий этих ООП.
П р и м е ч а н и е — Проведение анализа возможных последствий дефектов не избавляет от необходимо
сти проведения верификации и валидации в соответствии с требованиями раздела 8 настоящего стандарта. Цель
такого анализа состоит в обнаружении слабых мест в проекте и (затем) во внесении изменений в него и/или в
повышении доверия к проекту программного обеспечения.
13.3.3 Если общие модули используются более чем в одной системе, то эти модули должны быть
идентифицированы и должна быть проведена оценка обеспечения надежности таких общих модулей. Ме
тоды подтверждения правильности приведены в разделе G.4 приложения G.
13.3.4Данные, передаваемые внутри компьютерной системы или между компьютерными системами,
должны быть идентифицированы. Для определения того, могут ли дефектные данные привести к ООП в
принимающих компьютерах или системах, должен быть проведен анализ.
13.3.5 Должна бытьучтена возможность возникновения таких условий на станции, когда одно и то же
программное обеспечение, функционирующее в различных технических средствах, будет подвержено
воздействию идентичных или одновременных сигнальных траекторий и. следовательно, обнаружится один и
тот же дефект в нескольких каналах или функциональных частях.
П р и м е ч а н и е — Отказы могут быть вызваны сигнальными траекториями, которые не рассматривались
во время проектирования, верификации и валидации программного обеспечения отдельных каналов или систем.
13.3.6 Деятельность по модификации программного обеспечения (см. раздел 11) может стать причи
ной ООП. поэтому процессы, используемые для оценки изменения программного обеспечения или дан
ных. должны обеспечивать уверенность вотсутствии вносимых дефектов.
31