ГОСТ РМЭК 62061—2013
П р и м е ч а н и я
1 См. также примечание 3 к 6.6.2.1.1.
2 Временные ограничения, применяемые ктестированию подсистемы, выполняющей функции диагностики,
могут отличаться от тех. которые применяются к СБФУ. и в общем случае интервал тестирования должен соот
ветствовать требованиям, применяемым к подсистеме с устойчивостью к отказам аппаратных средств равной 1.
3 Должен быть обнаружен отказ функцией) диагностики и должны быть выполнены соответствующие дей
ствиядля уверенности втом. что вклад функции диагностики в полноту безопасности СБФУостался тем же. Отказ
функции(й) диагностики может быть обнаружен тестированием в неавтономном режиме, перекрестной проверкой
избыточных аппаратных средств и т.д.
6.8.5 Должно быть предоставлено ясное описание функции(й) диагностики СБЭСУ. их способно
сти обнаружить отказ или их реакции на отказ, а также выполнен анализ их вклада в полноту безопас
ности соответствующих СБФУ.
6.8.6 Для выполнения упрощенного подхода при оценке вероятности случайных опасных отказов
технических средств подсистем (67.8.2) применяется следующее:
- если для достижения требуемой вероятности опасного случайного отказа технических средств
необходима функция(и) диагностики СБЭСУ и подсистема обладает устойчивостью к сбоям аппарат
ных средств больше нуля, то обнаружение сбоя и заданная реакция на сбой должны быть выполнены до
наступления опасной ситуации из-за этого сбоя;
- при реализации функции(й) диагностики СБЭСУ должно быть, как минимум, принято, что веро
ятность случайного отказа технических средств и систематическая полнота безопасности одинаковы и
равны значению, заданному для соответствующей(их) СБФУ;
П р и м е ч а н и е —Ограничения архитектуры на полноту безопасности аппаратных средств не применяют
ся при реализации функции(й) диагностики.
- если значение вероятности опасного случайного отказа технических средств на порядок больше,
чем задано для СБФУ, то должна быть выполнена проверка, чтобы определить будет ли работоспособна
функция(и) диагностики или диагностирующие устройства. Предполагается, что такая проверка должна
быть выполнена как минимум 10 раз в промежутке между контрольными проверками подсистемы.
П р и м е ч а н и я
1 Проверка функции(й) диагностики должна, насколько это практически возможно, охватывать на 100 % те
компоненты, которые реализуют функцию(и) диагностики.
2 Если функция диагностики реализуется логическим устройством СБЭСУ. то нет необходимости отдельно
выполнять ев тестирование функции, таккак ее отказ может быть обнаружен, как отказ СБФУ.
3 Проверка можетбыть выполненалибо внешнимисредствами (например, с помощью испьпательногооборудо вания).
либо при помощи внутренних динамических проверок (например, встроенных влогическое устройство) СБЭСУ
6.9 Реализация технических средств СБЭСУ
Необходимо, чтобы СБЭСУ была реализована в соответствии с проектной документацией на СБЭСУ.
6.9.1 Межсоединения в СБЭСУ
6.9.1.1 Межсоединения в СБЭСУ должны быть реализованы так, чтобы удовлетворять соответ
ствующим частям спецификации требований к безопасности СБЭСУ. а также требованиям, относящим ся
к применению проводников, кабелей, проводов, представленным в МЭК 60204-1.
6.9.1.2 Меры по предотвращению и контролю отказов в соединительных проводах и кабелях
должны быть реализованы в соответствии с п. 6.4.1 и п. 6.4.2.
6.10 Спецификация требований к безопасности программного обеспечения
6.10.1 Общие положения
Если программное обеспечение должно использоваться в каком-либо части СБЭСУ. реализующей
СБФУ. то необходимо разработать и документально оформить спецификацию требований к безопас
ности программного обеспечения.
6.10.2 Требования
6.10.2.1 Спецификация требований к безопасности программного обеспечения должна быть раз
работана для каждой подсистемы на основе спецификации и архитектуры СБЭСУ.
6.10.2.2 Спецификация требований к безопасности программногообеспечениядля каждой подсистемы
должна быть получена из (1) требований к безопасности, заданных для СБФУ. (2) требований, вытекающих из
архитектуры СБЭСУ. и (3) любых требований к планированию функциональной безопасности (см. п. 4.2). Эта
информация должна быть доступна для разработчика прикладного программного обеспечения.
35