Настоящий подраздел определяет требования к жизненному циклу безопасности системы. Данные требования охватывают свойства, относящиеся к:
- конкретным функциям, назначенным системе в процессе распределения функций;
- основным характеристикам, которые в соответствии с системой классификации делают систему пригодной для выполнения функций, важных для безопасности, определенных категорий.
Примечание - Раздел 8 МЭК 61226 содержит основные требования к ФСО и особые требования к различным категориям ФСО. Эти требования соответствующим образом учтены в настоящем стандарте, когда формируются требования к системам и функциям.
6.1.1 Спецификация требований к системе
Целью данной фазы является выполнение основополагающего описания требований к системе, не связанного с возможным использованием конкретных технических решений.
Выходная документация, описывающая архитектуру контроля и управления и распределение функций (см. 5.5), является исходной для создания спецификации требований к системе.
На выходе этой фазы должен быть создан базовый документ, используемый для установления связи между документами, описывающими постановку задачи, и документами, которые представляют собой техническое решение.
Спецификация требований к системе должна определять:
- функции системы;
- ограничения на проектные решения;
- границы и связи с другими системами;
- интерфейсы пользователей;
- условия окружающей среды;
- требуемую квалификацию.
6.1.1.1 Функции
Должны быть рассмотрены требования к каждой прикладной функции и сервисным функциям системы. Предъявляются следующие требования:
6.1.1.1.1 Прикладные функции
Спецификации требований к прикладным функциям, важным для безопасности, определяются при распределении функций (см. 5.5.2).
a) Спецификация требования к каждой прикладной функции должна устанавливать:
1) функциональность, включая диапазоны входных и выходных величин и уставки. Для пороговых функций спецификация определяет границы между уставками и допустимыми значениями (т.е. значениями величины, включающими в себя неопределенности вследствие калибровки или дрейфов приборов);
2) характеристики, включающие в себя точность и время отклика. Если необходимо, требования к характеристикам определяют для различных исходных условий на АС и постулированных исходных событий.
Примечание - МЭК 61069-2 (6) может быть использован при идентификации и определении характеристик.
b) Спецификация требований к каждой прикладной функции должна устанавливать ее категорию и ограничения со стороны других функций комплекса безопасности (если они существуют). Эти требования неявно, в качественном виде, определяют требуемую надежность функции.
При процедуре распределения функций для каждой категории функций определяется минимальный класс системы контроля и управления. Вместе с требованиями к независимости функций одного и того же комплекса безопасности (критерий единичного отказа, проектная защита от отказа по общей причине) такие факторы позволяют проводить качественную оценку надежности функции или ряда функций комплекса безопасности.
Количественная оценка надежности прикладных функций может потребоваться при верификации проекта системы и общего проекта энергоблока (см. МЭК 60880). Эту оценку обычно проводят при проектировании оборудования системы, т.к. уже имеется накопленный опыт, однако метода, пригодного для количественной оценки надежности программного обеспечения, не существует (см. 6.1.3.1.2).
6.1.1.1.2 Сервисные функции
Сервисные функции, в отличие от прикладных, напрямую не связаны с выполнением действий, связанных с процессом, но относятся к специальным действиям, включающим в себя функции, необходимые для конфигурирования, валидации, квалификации, внедрения, приемки, эксплуатации, периодических испытаний, обслуживания, введения модификаций проекта и обеспечения защищенности системы.
Спецификации требований к сервисным функциям определяются разработчиком системы. Точность требований к этим функциям определяют в разные периоды проектирования системы. В некоторых случаях они могут быть окончательно сформулированы в спецификациях на систему и на фазе разработки проекта архитектуры после выбора подходящего технического решения в отношении оборудования и программного обеспечения.
Требования к сервисным функциям должны принимать во внимание взаимодействия и ограничения, которые могут возникать при планировании системы (см. 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).