- марковские модели (см. МЭК 61508-7, подраздел С.6.4, приложение С);
- блок-диаграммы надежности (см. МЭК 61508-7, раздел С.5, приложение С).
5. Среднее время восстановления (см. МЭС 191-13-08 [3]), рассматриваемое в модели надежности, нуждается в учете времени диагностического испытательного интервала, времени восстановления и любых других задержек до (момента) восстановления.
6. Отказы из-за влияния общей причины и процессов передачи данных могут быть результатом других влияний, отличных от реальных отказов компонентов аппаратных средств (например, электромагнитной интерференции, ошибок декодирования и т.п.). Однако такие отказы рассматривают в настоящем стандарте как случайные отказы аппаратных средств.
7.4.3.2.3. Диагностический испытательный интервал любой подсистемы, обладающей величиной отказоустойчивости аппаратных средств, большей нуля, должен быть таким, чтобы обеспечить возможность Е/Е/РЕ системе, связанной с безопасностью, удовлетворить требования по вероятности случайных отказов аппаратных средств (см. 7.4.3.2.1).
7.4.3.2.4. Диагностический испытательный интервал любой подсистемы с величиной отказоустойчивости аппаратных средств, равной нулю, от которой полностью зависит функция безопасности (см. примечание 1) и которая является лишь средством реализации функции(й) безопасности, действующей(их) в режиме с низкой интенсивностью запросов, должен быть таким, чтобы обеспечить возможность Е/Е/РЕ системе, связанной с безопасностью, удовлетворить требования по вероятности случайных отказов аппаратных средств (см. 7.4.3.2.1).
Примечания
1. Считают, что функция безопасности полностью зависит от подсистемы, если отказ подсистемы вызывает отказ этой функции безопасности Е/Е/РЕ системы, связанной с безопасностью, и эта функция безопасности не относится к другой системе, связанной с безопасностью (см. МЭК 61508-1, подраздел 7.6).
2. Если существует вероятность, что некоторые комбинации выходных состояний подсистем могут непосредственно привести к опасному событию (см. анализ опасностей и рисков в МЭК 61508-1, подпункт 7.4.2.10), и если комбинация выходных состояний в присутствии ошибки в подсистеме не может быть определена (например, в подсистеме типа В), тогда необходимо рассматривать обнаружение опасных отказов в подсистеме как функцию безопасности, действующую в режиме с высокой частотой запросов или с непрерывными запросами, и применять требования 7.4.6.3 и 7.4.3.2.5.
7.4.3.2.5. Диагностический испытательный интервал любой подсистемы (со значением величины отказоустойчивости аппаратных средств, равным нулю), от которой полностью зависит функция безопасности (см. примечание 1) и которая является лишь средством реализации функции безопасности, действующей в режиме высокой частоты запросов или с непрерывными запросами (см. примечание 2), должен быть таким, чтобы суммарное время диагностического испытательного интервала и время выполнения определенного действия (реакции на отказ) для достижения или поддержания безопасного состояния (см. 7.3.3.1, перечисление g)) было меньше времени безопасности процесса. Время безопасности процесса определяется как период времени между отказом, возникающим в управляемом оборудовании или в системе управления управляемого оборудования (с потенциальной возможностью вызвать опасное событие) и возникновением опасного события, если функция безопасности не выполнена.
Примечания
1. Считают, что функция безопасности полностью зависит от подсистемы, если отказ подсистемы вызывает отказ этой функции безопасности Е/Е/РЕ системы, связанной с безопасностью, и эта функция безопасности не относится к другой системе, связанной с безопасностью (см. МЭК 61508-1, подраздел 7.6).
2. Подсистему, осуществляющую конкретную функцию безопасности, для которой отношение частоты диагностических испытаний к частоте запросов превышает 100, допускается рассматривать, как если бы она осуществляла функцию безопасности в режиме с низкой частотой запросов (см. 7.4.3.2.4) при условии, что функция безопасности не предотвращает комбинацию состояний выходов, которые могли бы привести к опасному событию (см. примечание 3).
3. Если функция безопасности служит для предотвращения специфической комбинации состояний выходов, которые могут непосредственно вызвать опасное событие, то необходимо расценивать такую функцию безопасности как функцию, действующую в режиме с высокой частотой запросов или непрерывными запросами (см. 7.4.2.12).
7.4.3.2.6. Если для конкретного проекта целевая мера отказов требования полноты безопасности для выполняемой функции безопасности не достигается, то следует:
- определить критические компоненты, подсистемы и/или параметры;
- оценить эффект возможных мер усовершенствования критических компонентов, подсистем или параметров (например более надежные компоненты, дополнительные меры защиты от отказов по общей причине, расширенный охват диагностикой, расширенная избыточность, уменьшение интервала контрольных испытаний и т.п.);
- выбрать и осуществить подходящие меры усовершенствования;
- повторить вычисление нового значения вероятности отказов аппаратных средств.
7.4.4. Требования по предотвращению отказов
Примечание - Для подсистемы, отвечающей требованиям, позволяющим рассматривать ее как «проверенную в эксплуатации» (см. 7.4.7.6 - 7.4.7.12), требования 7.4.4.1 - 7.4.4.6 не применяют
7.4.4.1. Должна быть использована соответствующая группа методов и средств, предназначенных для предотвращения внесения ошибок во время разработки и создания аппаратных средств Е/Е/РЕ системы, связанной с безопасностью (см. таблицу В.2).
7.4.4.2. В соответствии с требуемым уровнем полноты безопасности выбранный метод проектирования должен обладать возможностями, способствующими:
a) прозрачности, модульности и другим характеристикам, которые управляют сложностью проекта;
b) ясности и точности представления:
- функциональных возможностей,
- интерфейсов между подсистемами,
- информации, устанавливающей последовательность и время,
- параллелизма и синхронизации;
c) ясности и точности документирования и передачи информации;
d) проверке и подтверждению соответствия.
7.4.4.3. Требования к техническому обслуживанию для гарантированного поддержания требуемой полноты безопасности Е/Е/РЕ системы, связанной с безопасностью, на необходимом уровне должны быть формализованы на стадии проектирования.
7.4.4.4. Следует использовать (если применимо) автоматические средства измерения и интегрированные инструментальные средства разработки.
7.4.4.5. В период проектирования должны быть запланированы испытания интеграции E/E/PES. Документация по планированию испытаний должна включать в себя:
a) типы проводимых испытаний и сопровождающие их процедуры;
b) условия окружающей среды при испытаниях, испытательные средства, схему испытаний и программы испытаний;
с) критерии оценки «выдержал»/«не выдержал» испытание.
7.4.4.6. В период проектирования действия, выполняемые на рабочем месте проектировщика, должны отличаться от действий, которые должны быть доступными на рабочем месте пользователя.
7.4.5. Требования по управлению систематическими сбоями
Примечание - Для подсистемы, отвечающей требованиям, которые расцениваются как «проверено в эксплуатации» (см. 7.4.7.6 - 7.4.7.12), требования 7.4.5.1 - 7.4.5.3 не применяют.
7.4.5.1. Для управления систематическими сбоями проектирование E/E/PES должно обладать особенностями проектирования, которые делают Е/Е/РЕ системы, связанные с безопасностью, устойчивыми к:
a) любым остаточным ошибкам проектирования аппаратных средств, если вероятность ошибок проектирования не может быть исключена (см. таблицу А.16);
b) внешним влияниям, включая электромагнитные воздействия (см. таблицу А. 17);
c) ошибкам оператора управляемого оборудования (см. таблицу А.18);
d) любым остаточным ошибкам в программном обеспечении (см. МЭК 61508-3, пункт 7.4.3, таблицы А.2 и В.7);
e) любым ошибкам, возникающим в результате выполнения любого процесса передачи данных (см. 7.4.8).
7.4.5.2. Для облегчения реализации свойств ремонтопригодности и тестируемости в созданных Е/Е/РЕ системах, связанных с безопасностью, эти свойства должны быть учтены в процессе проектирования и создания E/E/PES.
7.4.5.3. При проектировании Е/Е/РЕ систем, связанных с безопасностью, должны быть учтены способности и возможности человека, а созданные E/E/PES должны быть удобны для работы персонала по эксплуатации и технической поддержке. Разработка всех интерфейсов должна следовать «положительному опыту» при учете человеческого фактора и учитывать возможный уровень подготовки или осведомленности операторов, например для Е/Е/РЕ систем массового производства, где оператором является специально не подготовленный человек.
Примечания
1. Цель проектирования должна состоять в том, чтобы предсказуемые критические ошибки, допущенные операторами или персоналом технической поддержки, предотвращались или устранялись проектом везде, где возможно, либо действия для их выполнения требовали повторного подтверждения.
2. Некоторые ошибки, допущенные операторами или персоналом технического обслуживания, могут быть не восстанавливаемыми Е/Е/РЕ системой, связанной с безопасностью, например, если они являются необнаруживаемыми или реально восстанавливаемыми исключительно при непосредственном доступе, например некоторые механические отказы в управляемом оборудовании.
7.4.6. Требования к поведению системы при обнаружении отказов
7.4.6.1. Обнаружение опасного отказа (с помощью диагностических тестов, контрольных испытаний или иным методом) в любой подсистеме с отказоустойчивостью аппаратных средств больше нуля должно завершаться:
a) конкретным действием для достижения или поддержания безопасного состояния (см. примечание к перечислению b)) или
b) изоляцией дефектной части подсистемы для обеспечения возможности продолжения выполнения безопасного действия управляемым оборудованием, пока дефектная часть не будет отремонтирована. Если ремонт не завершен в пределах среднего времени восстановления (MTTR), принятого при вычислении вероятности случайных отказов аппаратных средств (см. 7.4.3.2.2), то для достижения и поддержания их безопасного состояния должно быть выполнено конкретное действие.
Примечание - Конкретное действие (реакция на отказ), которое требуется для достижения или поддержания безопасного состояния E/E/PES, должно быть определено в требованиях безопасности E/E/PES (см. 7.2.3.1). Оно может состоять, например, в отключении управляемого оборудования на дефектной подсистеме или его части, относящейся к снижению риска.
7.4.6.2. Обнаружение опасного отказа (с помощью диагностических тестов, контрольных испытаний или иным способом) в любой подсистеме с отказоустойчивостью аппаратных средств, равной нулю, функция безопасности которой является полностью зависимой (см. примечание 1) в случае, если такая подсистема используется только функцией(ями) безопасности в режиме с низкой частотой запросов, должно завершаться:
а) конкретным действием для достижения и поддержания безопасного состояния либо
b) восстановлением дефектной подсистемы в пределах периода среднего времени восстановления (MTTR), полученного при расчете вероятности случайных отказов аппаратных средств (см. 7.4.3.2.2). В течение этого времени безопасность управляемого оборудования должна обеспечиваться дополнительными мерами и ограничениями. Снижение риска, обеспеченное этими мерами и ограничениями, должно, по крайней мере, равняться сокращению риска, обеспеченному Е/Е/РЕ системой, связанной с безопасностью, в отсутствие любых отказов. Дополнительные меры и ограничения должны быть определены в процедурах эксплуатации и технического обслуживания E/E/PES (см. 7.6). Если восстановление не предпринято в пределах заданного среднего времени восстановления (MTTR), то для достижения и поддержания безопасного состояния должны быть предприняты конкретные действия (см. примечание 2).
Примечания
1. Предполагается, что функция безопасности полностью зависит от подсистемы, если отказ подсистемы приводит к отказу функции безопасности рассматриваемой Е/Е/РЕ системы, связанной с безопасностью, и функция безопасности не предназначена для другой системы, связанной с безопасностью (см. МЭК 61508-1, подраздел 7.6).
2. Конкретное действие (реакция на отказ) требуется для достижения и поддержания безопасного состояния, которое должно быть определено в требованиях безопасности E/E/PES (см. 7.2.3.1). Это действие может состоять, например, в безопасном отключении управляемого оборудования в дефектной подсистеме или его части, предназначенной для снижения риска.
7.4.6.3. Обнаружение опасного отказа (путем диагностического тестирования, контрольных испытаний или иным способом) в любой подсистеме с отказоустойчивостью, равной нулю, в которой функция безопасности является зависимой (см. примечание 1) в случае подсистемы, выполняющей любую функцию(ии) безопасности, действующей(их) в режиме с высокой частотой запросов или непрерывными запросами (см. примечания 2 и 3), для достижения и поддержания безопасного состояния должно завершаться конкретными действиями (см. примечание 3).
Примечания
1. Считается, что функция безопасности полностью зависит от подсистемы, если отказ подсистемы служит причиной отказа функции безопасности рассматриваемой Е/Е/РЕ системы, связанной с безопасностью, а также функция безопасности не принадлежит другой системе, связанной с безопасностью (см. МЭК 61508-1, подраздел 7.6).
2. Если существует вероятность, что некоторая комбинация состояний выходов подсистемы может стать непосредственной причиной опасного события (см. анализ опасностей и рисков 7.4.2.12), и если комбинацию выходных состояний в случае отказа в подсистеме невозможно определить (например, для подсистемы типа В), то детектирование опасных событий в подсистеме следует расценивать как для функции безопасности, действующей в режиме с высокой частотой запросов или непрерывными запросами, и применять требования 7.4.6.3 и 7.4.2.5.
