ГОСТ Р МЭК 61513— 2011
ных по ряду систем. Все функции или подфункции являются прикладными функциями систем контроля и
управления (см. 6.1.1.1).
a) Спецификации функциональных требований и требований к характеристикам прикладных функций
должны учитываться вобщих требованиях кФСО. Если функция распределена по более чем одной систе
ме. то взаимосвязанные системы должны быть выстроены так. чтобы они соответствовали требованиям,
определенным в 5.2.
b
) Спецификации функциональных требований и требований к характеристикам прикладных функций
должны включать всебя все вспомогательные функции валидации, блокировки и контроля, которые были
определены при проектировании архитектуры контроля и управления, например состояние и режим работы
взаимосвязанных систем, валидация сигналов, получаемых отдругих систем.
c) Распределение прикладных функций посистемам должно соответствовать принципам, связанным
с классом системы и категорией функции, представленным в таблице 2.
d) Функции категории А назначаются системам, которые соответствуют критерию единичного отказа.
e) При отнесении функций категории А одного и того же комплекса безопасности к системам следует
принимать во внимание меры защиты от отказов по общей причине по 5.3.1.5. Примеры распределения
функций различных категорий приведены на рисунке С.1 приложения С.
f) По результатам распределения прикладных функций по системам необходимо пытаться минимизи
ровать сложность систем класса 1.
П р и м е ч а н и е — Это особенно справедливо для новых АС. В случав замены систем жесткой логики на
компьютерные к последним в отношении прикладных функций обычно предъявляются те же требования, что и к
системам жесткой логики.
д) Требуемая надежность каждой прикладной функции, введенной в системы, должна быть на уров
недостижимых пределов, включая отказ по общей причине.
5.3.3 Анализ
С целью верификации проекта архитектуры контроля и управления и распределения функций по
системам необходимо проводить анализ. Такой анализ является итеративным процессом и осуществляет ся
при выполнении проектных работ (см. раздел 6).
5.3.3.1 Оценка надежности и защиты от отказа по общей причине
a) Должен быть выполнен расчет надежности функций комплекса безопасности категорииА, который
должен учитывать зависимость от источников снабжения энергией (например, электрической и энергией
сжатого воздуха) и устройств вентиляции и теплоснабжения.
b
) Первоначально расчет может опираться на оценку надежности, достижимой для функций различ
ных систем, и должен уточняться впоследствии при проектировании, основываясь на оценках надежности
отдельных систем (см. 6.1.3.1.2).
c)Должна быть проведена оценка эффективности мер. направленных на снижение чувствительности
комплекса безопасности, включающего в себя функции категории А, к отказам по общей причине.
d) Проектную документацию на систему (см. 6.3.3) следует проанализировать с целью найти общие
или идентичные компоненты программного обеспечения или оборудования, которые поддерживают раз
личные функции комплекса безопасности, включающего в себя функции категории А. Если такие
узлы будут найдены в различных эшелонах защиты, необходимо привести подтверждение того, что при
этом достигается низкая вероятность отказа по общей причине.
е) Не существует общепринятого метода количественной оценки вероятности отказа пообщей причи
не. поэтому используют методы, обеспечивающие только качественные оценки (см. приложение С). При
меняемые методы, например метод p-фактора для оборудования, должны быть определены в начале
проектирования.
П р и м е ч а н и е 1— Цель указанных рекомендаций — избежать внесения изменений в планирование и
проект системы при изменении требований, которые могут привести к возникновению отказов по общей причине
вследствие ошибок из-за этих изменений.
П р и м е ч а н и е 2 — Глубина анализа отказов по общей причине может зависеть от категории функций,
поддерживаемых системами, и должна быть обоснована.
П р и м е ч а н и е 3 — Требования к анализу отказов по общей причине вследствие ошибок а программном
обеспечении приведены в 4.1.3 МЭК 60880-2.
Пр и ме ч а н и е 4 — Точность оценки вероятности отказа по общей причине можно улучшить, если системы
контроля и управления имеют модульную структуру, так что при объединении компонентов и систем можно выпол
нить качественнуюоценку с помощью пошаговой верификации и. дополнительно, по возможности количественную.
24