5.3.2 Распределение функций
При задании функций контроля и управления все требования к ФСО, важные для безопасности, указанные в 5.2, распределяются по отдельным системам полной архитектуры контроля и управления. Если необходимо, одна функция может быть представлена в виде нескольких подфункций, распределенных по ряду систем. Все функции или подфункции являются прикладными функциями систем контроля и управления (см. 6.1.1.1).
a) Спецификации функциональных требований и требований к характеристикам прикладных функций должны учитываться в общих требованиях к ФСО. Если функция распределена по более чем одной системе, то взаимосвязанные системы должны быть выстроены так, чтобы они соответствовали требованиям, определенным в 5.2.
b) Спецификации функциональных требований и требований к характеристикам прикладных функций должны включать в себя все вспомогательные функции валидации, блокировки и контроля, которые были определены при проектировании архитектуры контроля и управления, например состояние и режим работы взаимосвязанных систем, валидация сигналов, получаемых от других систем.
c) Распределение прикладных функций по системам должно соответствовать принципам, связанным с классом системы и категорией функции, представленным в таблице 2.
d) Функции категории А назначаются системам, которые соответствуют критерию единичного отказа.
e) При отнесении функций категории А одного и того же комплекса безопасности к системам следует принимать во внимание меры защиты от отказов по общей причине по 5.3.1.5. Примеры распределения функций различных категорий приведены на рисунке С.1 приложения С.
f) По результатам распределения прикладных функций по системам необходимо пытаться минимизировать сложность систем класса 1.
Примечание - Это особенно справедливо для новых АС. В случае замены систем жесткой логики на компьютерные к последним в отношении прикладных функций обычно предъявляются те же требования, что и к системам жесткой логики.
g) Требуемая надежность каждой прикладной функции, введенной в системы, должна быть на уровне достижимых пределов, включая отказ по общей причине.
5.3.3 Анализ
С целью верификации проекта архитектуры контроля и управления и распределения функций по системам необходимо проводить анализ. Такой анализ является итеративным процессом и осуществляется при выполнении проектных работ (см. раздел 6).
5.3.3.1 Оценка надежности и защиты от отказа по общей причине
a) Должен быть выполнен расчет надежности функций комплекса безопасности категории А, который должен учитывать зависимость от источников снабжения энергией (например, электрической и энергией сжатого воздуха) и устройств вентиляции и теплоснабжения.
b) Первоначально расчет может опираться на оценку надежности, достижимой для функций различных систем, и должен уточняться впоследствии при проектировании, основываясь на оценках надежности отдельных систем (см. 6.1.3.1.2).
c) Должна быть проведена оценка эффективности мер, направленных на снижение чувствительности комплекса безопасности, включающего в себя функции категории А, к отказам по общей причине.
d) Проектную документацию на систему (см. 6.3.3) следует проанализировать с целью найти общие или идентичные компоненты программного обеспечения или оборудования, которые поддерживают различные функции комплекса безопасности, включающего в себя функции категории А. Если такие узлы будут найдены в различных эшелонах защиты, необходимо привести подтверждение того, что при этом достигается низкая вероятность отказа по общей причине.
е) Не существует общепринятого метода количественной оценки вероятности отказа по общей причине, поэтому используют методы, обеспечивающие только качественные оценки (см. приложение С). Применяемые методы, например метод 
-фактора для оборудования, должны быть определены в начале проектирования.
-фактора для оборудования, должны быть определены в начале проектирования.Примечание 1 - Цель указанных рекомендаций - избежать внесения изменений в планирование и проект системы при изменении требований, которые могут привести к возникновению отказов по общей причине вследствие ошибок из-за этих изменений.
Примечание 2 - Глубина анализа отказов по общей причине может зависеть от категории функций, поддерживаемых системами, и должна быть обоснована.
Примечание 3 - Требования к анализу отказов по общей причине вследствие ошибок в программном обеспечении приведены в 4.1.3 МЭК 60880-2.
Примечание 4 - Точность оценки вероятности отказа по общей причине можно улучшить, если системы контроля и управления имеют модульную структуру, так что при объединении компонентов и систем можно выполнить качественную оценку с помощью пошаговой верификации и, дополнительно, по возможности количественную.
5.3.3.2 Оценка человеческого фактора
Верификация архитектурного проекта должна включать в себя анализ требований, связанных с влиянием человеческого фактора, чтобы оптимизировать проект систем человеко-машинного интерфейса.
5.4 Общее планирование
В настоящем подразделе приведены требования к разработке общих планов, обеспечивающих соблюдение требований к функциям контроля и управления, важным для безопасности, распределенным по системам, в течение жизненного цикла систем.
Требования настоящего подраздела согласуются и дополняют планы, рассмотренные в 6.2 для отдельных систем контроля и управления.
Примечание - Приведенные ниже требования к планам не препятствуют тому, чтобы планы оформлялись в виде различного числа документов.
Общие планы должны быть разработаны, прежде чем начнутся предусмотренные в них работы.
5.4.1 Общая программа обеспечения качества
Настоящий стандарт предполагает, что программа обеспечения качества, соответствующая требованиям МАГАТЭ 50-C-QA (Редакция 1), существует как неотъемлемая часть проекта АС и в соответствии с ней осуществляется контроль соответствующей деятельности.
a) Программа обеспечения качества должна разрабатываться и осуществляться по каждому направлению деятельности, связанному с жизненным циклом безопасности контроля и управления [см. раздел 2 МАГАТЭ 50-C-QA (Редакция 1)].
b) Программа обеспечения качества должна охватывать все направления деятельности, необходимые для достижения качества, а также действия, направленные на проверку достижения требуемого качества [см. раздел 102 МАГАТЭ 50-C-QA (Редакция 1)].
c) Деятельность по проверке должна быть определена в планах верификации. Планы верификации включают в себя средства, процесс и результаты на каждой стадии безопасного жизненного цикла контроля и управления и определяют:
- процедуры и способы верификации деятельности;
- записи, которые должны храниться и проверяться;
- подлежащие проверке виды деятельности, связанные с безопасностью;
- процедуры, направленные на выявление ошибок и несоответствий;
- критерии, определяющие полное завершение фазы;
- завершающие отчеты, в которых подтверждается соответствие результатов фазы исходным требованиям и выявляются отклонения.
d) Программы обеспечения качества должны планироваться и включаться в общую программу обеспечения качества при проектировании АС, а входящие в них виды деятельности - учитываться в общем плане действий по проектированию АС.
5.4.2 Общий план защищенности
Для защиты информации, обрабатываемой системами, важными для безопасности, от несанкционированного изменения (сохранность), нарушения доступа (доступность) и несанкционированного вскрытия (конфиденциальность) требуются определенные меры безопасности.
Примечание 1 - В системах контроля и управления АС требования сохранности и доступности превалируют над требованием конфиденциальности.
Программное обеспечение (тексты программ, а также параметры и данные) может быть особенно уязвимым при конструировании и наладке. Угрозы опасного воздействия, которые необходимо рассмотреть, включают в себя умышленные преднамеренные изменения, которые приводят как к полностью ошибочной работе программного обеспечения или сбоям, возникающим в определенное время, так и к искажению данных.
Примечание 2 - Угрозы, возникающие в связи с непреднамеренными изменениями, рассматриваются в перечне системных требований (см. 6.1.1.4).
Общий план обеспечения защищенности содержит следующие организационные и технические меры защиты архитектуры систем контроля и управления от преднамеренных, спланированных действий, которые могут дезорганизовать выполнение функций, важных для безопасности:
а) требования к защищенности функций и систем, важных для безопасности, должны быть отражены в плане защищенности системы (см. 6.2.2);
b) риск от несанкционированного доступа и вмешательства должен систематически отслеживаться на всех фазах жизненного цикла от начала до снятия с эксплуатации;
c) меры по обеспечению защищенности системы не должны заметно отражаться на надежности или эксплуатационных свойствах;