ГОСТРМЭК 62061—2013
6.6.1.5 Если СБЭСУ или ее подсистемы реализуют связанные с безопасностью функции управле
ния с различными уровнями полноты безопасности, то требования к аппаратным средствам и программ
ному обеспечению СБЭСУ или ее подсистем должны определяться уровнем полноты безопасности
СБФУ с самым высоким уровнем полноты безопасности, если не будет установлено, что выполнение
СБФУ с различными уровнями полноты безопасности достаточно независимо.
П р и м е ч а н и е —Достаточную независимость выполнения устанавливают демонстрацией того, что веро
ятность зависимого отказа между компонентами, выполняющими СБФУ с различными уровнями полноты безопас
ности. эквивалентна уровню полноты безопасности, достигаемому СБЭСУ.
6.6.1.6 Соединения (например, проводники, кабели), кроме используемых для цифровой переда
чи данных, должны рассматриваться как элементы одной из подсистем, к которой они подключены (см.
также перечисление д) п. 6.4.2).
6.6.1.7 Если система цифровой передачи данных реализуется как часть СБЭСУ. то она должна
удовлетворять соответствующим требованиям МЭК 61508-2 в соответствии с целевыми значениями
УПБ для СБФУ.
6.6.1.8 Информация по применению СБЭСУ должна определять методы и меры, необходимые
для использования в течение проектных стадий жизненного цикла СБЭСУ и обеспечения соответству
ющего уровня полноты безопасности.
6.6.2 Процесс проектирования и разработки
Проектирование и разработка должны выполняться в соответствии с четко определенным про
цессом, учитывающим все связанные с ним аспекты и представленным на рисунке 2.
П р и м е ч а н и е — В настоящем стандарте используется подход, основанный на применении структури
рованного процесса проектирования СБЭСУ. начиная с требований, определенных в спецификации требований к
системе безопасности. На рисунке 2 представлен процесс проектирования и терминология, которая применяется на
разных стадиях.
6.6.2.1 Проектирование архитектуры системы
6.6.2.1.1 Каждая СБФУ. как указано в спецификации требований к безопасности СБЭСУ. должна
быть структурно декомпозирована до функциональных блоков, например, как показано на рисунке 3.
Необходимо, чтобы такая структура была документально оформлена и включала:
- ее описание;
- требования к безопасности (функциональные, к полноте) для каждого функционального блока;
- определение входов и выходов каждого функционального блока.
П р и м е ч а н и я
1 Процесс декомпозиции позволяет сформировать структуру функциональных блоков, полностью описыва
ющую функциональные требования и требования кполноте СБФУ. Этот процесс должен быть применен до уровня,
позволяющегоустановить функциональные и требования к полноте для каждого функционального блока, который
будет реализован в подсистеме, если такое выделение функциональных блоков и полных требований для реали
зации подсистемами возможно. Тем не менее можно реализовать несколько функциональных блоков в одной под
системе, но невозможно один функциональный блок реализовать несколькими подсистемами, каждая из которых
имеет свои функциональные и требования к полноте безопасности. Если это необходимо, то следует выделить
функциональные требования одного функционального блока для их реализации дополнительными элементами
подсистемы, см. 6.7.4.
2 На входах и выходах каждого функционального блока может быть обрабатываемая информация, напри
мер. о скорости, положении, режиме работы и т.д.
3 Функциональные блоки представляют функции СБФУ (см. 3.2.16) и не включают диагностические функ
ции СБЭСУ (см. 3.2.17). Для достижения целей настоящего стандарта диагностические функции рассматриваются
как отдельные, которые могут иметь структуру, отличную от СБФУ (см. 6.8).
6.6.2.1.2 Необходимо, чтобы начальная концепция архитектуры СБЭСУ была создана в соответ
ствии со структурой функциональных блоков.
П р и м е ч а н и е — Должно быть постоянное сотрудничество между разработчиком связанной с безопас
ностью архитектуры (системы) управления, организацией, ответственной за конфигурацию устройств, и разра
ботчиком программного обеспечения. В процессе такого сотрудничества уточняются требования к безопасности
программного обеспечения и возможные его архитектуры, что может повлиять на архитектуру аппаратных средств
СБЭСУ. поэтому такое тесное сотрудничество между разработчиком архитектуры СБЭСУ. поставщиком(ами)
подсистемы, разработчиком программного обеспечения и. по мере необходимости, проектировщиком машины
или пользователем может помочь сократить возможность появления систематических отказов.
18