ГОСТ РМЭК 62061—2015
6 Проектирование и интеграция связанной
с безопасностью электрической системы управления (СБЭСУ)
6.1 Цель
Данный раздел устанавливает требования к выбору или проектированию СБЭСУ. удовлетворяю
щей функциональные требования и требования к полноте безопасности, указанные в спецификации
требований к системе безопасности (см. 5.2).
6.2 Общие требования
6.2.1 СБЭСУ должна быть выбрана или разработана с учетом спецификации требований к систе
ме безопасности (см. 5.2) и. где это необходимо, с учетом спецификации требований к программному
обеспечению системы безопасности (см. 6.10) в соответствии с требованиями настоящего стандарта.
6.2.2 Методы выбора или проектирования СБЭСУ (в том числе общей архитектуры аппаратных
средств и программного обеспечения, датчиков, приводов, программируемой электроники, встроенного и
прикладного программного обеспечения и т. п.) должны соответствовать 6.5 или 6.6. Какой бы метод ни
использовался, СБЭСУ должна соответствовать следующим требованиям.
a) к полноте безопасности аппаратных средств, включая:
- ограничения архитектуры на полноту безопасности аппаратных средств (см. 6.6.3.3),
- требования к вероятности опасных случайных отказов аппаратных средств (см. 6.6.3.2);
b
) к систематической полноте безопасности, включая:
- требования к возможности избежать отказы.
- требования к управлению систематическими ошибками;
c) к поведению СБЭСУ при выявлении ошибки (см. 6.3);
d) к проектированию и разработке связанного с безопасностью программного обеспечения (см.
6.10 и 6.11).
6.2.3 Проект СБЭСУ должен учитывать возможности и ограничения человека (в том числе разумно
предсказуемое неправильное использование) и быть пригодным для действий, выполняемых оператора
ми. обслуживающим персоналом и другими, кто может взаимодействовать с СБЭСУ. Необходимо, чтобы
проектирование всех интерфейсов оператором следовало «хорошим практикам» учета человеческого
фактора (см. МЭК 61310). а также учитывало вероятный уровень подготовки или осведомленности опе
раторов. в частности при массовом производстве подсистем, где оператором может быть любой человек.
Примечание — Цель проектадолжна состоять в том. чтобы разуто предсказуемыеошибки, сделанные
операторами или обслуживающим персоналом, были предотвращены или устранены при проектировании. Если
это невозможно, то, чтобы минимизировать возможность ошибок оператора и удостовериться в том, что пред
сказуемые ошибки не приводят к увеличению риска, должны быть также применены другие средства (например,
реализация действия вручную с дополнительным подтверждением перед его выполнением).
6.2.4 В целях содействия реализации этих свойств в ходе разработки и интеграции СБЭСУ долж
ны быть рассмотрены ремонтопригодность и тестируемость СБЭСУ.
6.2.5 Необходимо, чтобы проект СБЭСУ. его диагностические функции и функции реакции на отказ
были документально оформлены. Эта документация должна:
- быть точной, полной и краткой;
- соответствовать предназначенной цели;
- быть доступной и поддерживаемой;
- быть обеспечена управлением версиями.
6.2.6 Данные, полученные в результате проектирования, разработки и реализации СБЭСУ. долж
ны быть верифицированы на соответствующих этапах.
6.3 Требования к поведению СБЭСУ при обнаружении в ней сбоя
6.3.1Обнаружение опасного сбоя в любой из подсистем, которая имеет значение устойчивости к
сбоям аппаратных средств больше чем ноль, влечет за собой выполнение специфицированной функ
ции реакции на отказ.
Такая спецификация может содержать действия по изоляции неисправных частей подсистемы
для продолжения безопасной эксплуатации машины в то время, как происходит ремонт неисправных
частей. Если неисправная деталь не будет восстановлена в течение максимального времени, оценен
ного. как принято из расчета вероятности случайного сбоя в технических средствах (см. 6.7.8). то для
поддержки безопасного состояния должна быть выполнена реакция на второй сбой.
15