ГОСТРМЭК 62061—2015
стандарте представлена методология для применения, а не разработки подсистем и их элементов, являющихся
частью СБЭСУ.
6.7.3.3Подсистемы с компонентами только низкой сложности должны соответствовать 6.7.4.4.1,
6 7.6.2. 6.7.6.3, 6.7.7, 6.7.8 и 6.8.
6.7.4Проектирование и разработка подсистем
6.7.4.1 Цели
6.7.4.1.1 Первая цель заключается в разработке подсистемы, отвечающей требованиям к без
опасности для реализуемого(ых) фуикционального(ых) блока(ов).
6.7.4.1.2 Вторая — в создании архитектуры на уровне совмеспчо работающих элементов под
системы. удовлетворяющей функциональные требования и требования к полноте безопасности всех
функциональных блоков, ею реализуемых.
6.7.4.2 Общие требования
6.7.4.2.1 Необходимо, чтобы подсистема была спроектирована в соответствии со спецификацией
требований к системе безопасности.
6.7.4.2.2 Подсистема должна удовлетворять все следующие требования:
a) к полноте безопасности аппаратных средств, включающие:
- ограничения архитектуры на полноту безопасности аппаратных средств (см. 6.7.6):
- требования к вероятности случайных опасных отказов аппаратных средств (см. 6.7.8);
b
) систематической полноте безопасности, включающие:
- требования к предотвращению отказов (см. 6.7.9.1). а также к управлению систематическими
отказами (см. 6.7.Э.2);
- подтверждение того, что работа оборудования «доказана на практике». В этом случае подсисте
ма должна отвечать соответствующим требованиям 7.4.10 МЭК 61508-2;
c) поведению подсистемы при обнаружении отказа (реакция на отказ) (см. 6.3).
6.7.4.2.3 Если проект подсистемы включает сложный компонент (в качестве элемента подсисте
мы). который удовлетворяет все соответствующие требования МЭК 61508-2 и МЭК 61508-3. связан
ные с предельным требованием к УПБ и использует Способ 1н (см. 7.4.4.2 МЭК 61508-2), то он может
рассматриваться как компонент низкой сложности в контексте проекта подсистемы, так как известна
информация о его соответствующих режимах отказов, поведении при их обнаружении, интенсивности
отказов, а также другая связанная с безопасностью информация. Такие компоненты следует использо
вать только в соответствии со спецификацией и информацией по их применению, предоставляемой их
поставщиком.
Примечание — В настоящем стандарте предполагается, что проектирование сложных программиру
емых электронных подсистем или их элементов удовлетворяет соответствующим требованиям МЭК 61508 и ис
пользуется Способ 1н (см. 7.4.4.2 МЭК 61508-2). Считается, что Способ 2Н(см. 7.4.4.3 МЭК 61508-2) не подходит
в общем случае для машинного оборудования, поэтому настоящий стандарт не рассматривает Способ 2Н. В на
стоящем стандарте представлена методология для применения, а не разработки подсистем и их элементов,
явля ющихся частью СБЭСУ.
6.7.4.3 Процесс проектирования и разработки подсистемы
Проектирование и разработка подсистемы должны следовать четко определенной процедуре,
учитывающей все аспекты, охватываемые процессом (он показан на рисунке 4).
6.7.4.3.1 Проектирование архитектуры подсистемы
6.7.4.3.1.1 В процессе проектирования архитектуры подсистемы декомпозиция должна привести к
структуре элементов функционального блока, которые полностью представляют функциональные тре
бования этого блока. Данный процесс нужно применять до того уровня, который позволит установить
функциональные требования для каждого элемента функционального блока, реализуемого элемента
ми подсистемы (см. пример на рисунке 5).
Примечание — Структура процесса проектирования показана на рисунке4.
6.7.4.3.1.2 Архитектура подсистемы должна быть описана в терминах ее элементов и их взаи
мосвязей. В случае необходимости это описание должно также включать информацию об элементах
функциональных блоков, которые реализуются элементами подсистемы.
6.7.4.4 Требования к выбору и проектированию элементов подсистемы
6.7.4.4.1Необходимо, чтобы элементы подсистемы были пригодны для их предполагаемого ис
пользования и соответствовали определенным стандартам, если таковые существуют.
24