ГОСТ РМЭК 62061—2013
перечисления могут использоваться для обеспечения связи (см. таблицы 4 и 5) с требованиями к категориям
из ИС01384&-1 и с точки зренияобнаружения ошибок, и сточкизрения устойчивостик отказам аппаратных средств;
j) любая информация, которая требуется для идентификации конфигурации аппаратных средств
и программного обеспечения подсистемы, чтобы обеспечить управление конфигурацией СБЭСУ в со
ответствии с 6.11.3.2;
k) вероятность опасных ошибок передачи для цифровых процессов передачи данных, когда это
применимо.
6.7.3Требования к выбору существующих (предварительно спроектированных) подси
стем
6.7.3.1 Если поставщик предлагает подсистему для конкретной СБФУ. указанной в спецификации
требований к безопасности, то может быть выбрана заранее разработанная подсистема, а не специ
ально спроектированная, при условии, что она удовлетворяет спецификации требований к безопасно
сти для подсистемы, п. 6.4.3 и n. 6.7.3.2 или п. 6.7.3.3.
6.7.3.2 Подсистемы, включающие сложные компоненты, должны соответствовать МЭК 61508-2
и МЭК 61508-3 в зависимости от требуемого УПБ.
Исключение. Если в проекте подсистемы ее элемент является сложным компонентом, то при
меняется п. 6.7.4.2.3.
6.7.3.3 Подсистемы с компонентами только низкой сложности должны соответствовать 6.7.4.4.1,
67.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 Вторая — в создании архитектуры на уровне совместно работающих элементов под
системы. удовлетворяющей функциональные требования и требования к полноте безопасности всех
функциональных блоков, ею реализуемых.
67.4.2 Общие требования
67.4.2.1 Необходимо, чтобы подсистема была спроектирована в соответствии со спецификацией
требований к системе безопасности.
67.4.2.2 Подсистема должна удовлетворять все следующие требования к;
a) полноте безопасности аппаратных средств, включающие;
- ограничения архитектуры на полноту безопасности аппаратных средств (см. 6.7.6);
- требования к вероятности случайных опасных отказов аппаратных средств (см. 6.7.8);
b
) систематической полноте безопасности, включающие;
- требования к предотвращению отказов (см. 67.9.1), а также к управлению систематическими
отказами (см. 67.9.2);
- подтверждение того, что работа оборудования «доказана на практике». В этом случае подсисте
ма должна отвечать соответствующим требованиям МЭК 61508-2. с 7.47.5 по 7.4.7.12.
c) поведению подсистемы при обнаружении отказа (реакция на отказ) (см. 6.3).
67.4.2.3 Если проект подсистемы включает сложный компонент (в качестве элемента подсисте
мы). который удовлетворяет все соответствующие требования МЭК 61508-2 и МЭК 61508-3. связан
ные с предельным требованием к УПБ. то он может рассматриваться как компонент низкой
сложности в контексте проекта подсистемы, так как известна информация о его соответствующих
режимах отка зов. поведении при их обнаружении, интенсивности отказов, а также другая связанная с
безопасностью информация. Такие компоненты должны использоваться только в соответствии с их
спецификацией и информацией по их применению, предоставляемой поставщиком.
67.4.3 Процесс проектирования и разработки подсистемы
Проектирование и разработка подсистемы должны следовать четко определенной процедуре,
учитывающей все аспекты, охватываемые процессом (он показан на рисунке 4).
67.4.3.1 Проектирование архитектуры подсистемы
67.4.3.1.1 В процессе проектирования архитектуры подсистемы декомпозиция должна привести
к структуре элементов функционального блока, которые полностью представляют функциональные
требования этого блока. Данный процесс нужно применять до того уровня, который позволит
устано вить функциональные требования для каждого элемента функционального блока,
реализуемого эле ментами подсистемы (см. пример на рисунке 5).
23