ГОСТ Р МЭК 61513—2011
для конфигурирования, валидации, квалификации, внедрения, приемки, эксплуатации, периодических ис
пытаний, обслуживания, введения модификаций проекта и обеспечения защищенности системы.
Спецификации требований к сервисным функциям определяются разработчиком системы. Точность
требований к этим функциям определяют в разные периоды проектирования системы. В некоторых случа ях
они могут быть окончательно сформулированы в спецификациях на систему и на фазе разработки
проекта архитектуры после выбора подходящего технического решения в отношении оборудования и про
граммногообеспечения.
Требования к сервисным функциям должны принимать во внимание взаимодействия и ограничения,
которые могут возникать при планировании системы (см. 6.2).
П р и м е ч а н и е — Например, управление изменением параметров должно соответствовать результатам,
определенным планом защищенности (см 6.2.2), планом эксплуатации системы (см. 6.2.6) и планом обслужива
ния (см. 6.2.7).
6.1.1.1.3 Функции системного программного обеспечения
Спецификация требований ксистеме обычно не полностью описывает функции системного программ
ного обеспечения. Фактически эти функции, относящиеся к работе и самоконтролю собственно системы,
характерны для существующего оборудования, используемого при построении системы (см. 6.1.2.1).
и могут быть более точно определены на фазе спецификации системы. Однако требования к
системному программному обеспечению безусловно определяются требованиями к функциональности
прикладных функций и требованиями проектного ограничения на систему (см. 6.1.1.2.1).
Требования к функциям должны быть полностью определены какдля вновь разрабатываемого, так и
для поставляемого системного программного обеспечения.
6.1.1.2 Проектные ограничения
Следующие требования определяют проектные ограничения, которые сужают выбор решений при
проектировании системы и задании функций. Ограничения зависят от класса системы и категории функции и
должны учитываться при разработке спецификации системы и проекта архитектуры для того, чтобы:
- выполнять требования, обусловленные категоризацией прикладных функций:
- обеспечиватьфункционирование системы в соответствии с проектом.
- дать возможность или облегчитьдемонстрацию правильности работы системы.
6.1.1.2.1 Архитектура системы
Архитектура системы определяется категорией функций, которые должны выполняться системой
(см. 5.3.2), и концепцией глубокоэшелоиированной защиты (см. 5.2 и 7.8.1 МАГАТЭ 50-SG-D3).
a) Система может содержать функции высшей категории, соответствующей ее классу (см. 5.3.2), и
функции более низкой категории. Система может включать в себя подсистемы более низкого класса, обес
печивающие выполнение следующих требований:
1) проектные требования к каждой подсистеме не должны быть ниже, чем требования к функциям
наивысшей категории, выполняемым подсистемой:
2) проект системы должен обеспечивать выполнение требований к подсистемам или оборудованию
более высоких классов в случае отказа оборудования более низкого класса.
b
) Проект системы должен предусматривать резервирование и другие свойства, необходимые для
обеспечения устойчивости котказу (см. 6.1.2.2.3) и поддержания прикладных функций, важных для безо
пасности (см. 6.1.2.4).
П р и м е ч а н и е — Система может также включать в себя резервирование для выполнения ряда других
требований. Необходимость в таком резервировании определяется на стадии проектирования системы.
c) Проект системы должен соответствовать каким-либо требованиям независимости (см. 6.1.2.2.2)
с целью:
- предохранить систему от влияния отказов систем с меньшим уровнем влияния на безопасность:
- предохранить систему от взаимного влияния отказов резервированных ветвей оборудования, под
держивающих функции категории А.
d) Проект систем 1-го класса должен предусматриватьдостаточное резервирование, чтобы удовлет
ворить критерию единичного отказа для функций категории А как при эксплуатации, так и при обслужива
нии системы (см. перечисление е) 6.1.2.4).
Приме чание — Отказы из-за программного обеспечения являются систематическими, а не случайными.
Поэтому критерий единичного отказа не может применяться при разработке программного обеспечения систе мы
в том виде, в каком это делается при проектировании оборудования. На уровне каждой системы иархитектуры
33