Национальный стандарт РФ ГОСТ Р 53195.3-2009 "Безопасность функциональная связанных с безопасностью зданий и сооружений систем. Часть 3. Требования к системам" (утв. приказом Федерального агентства по техническому регулированию и метрологии от 13 августа 2009 г. N 293-ст) (утратил силу)

Национальный стандарт РФ ГОСТ Р 53195.3-2009
"Безопасность функциональная связанных с безопасностью зданий и сооружений систем. Часть 3. Требования к системам"
(утв. приказом Федерального агентства по техническому регулированию и метрологии от 13 августа 2009 г. N 293-ст)

Functional safety of building/erection safety-related systems. Part 3. Requirements for systems

Дата введения - 1 июня 2010 г.

Введен впервые

ГАРАНТ:

Приказом Росстандарта от 16 сентября 2015 г. N 1345-ст взамен настоящего ГОСТа с 1 июня 2016 г. введен в действие ГОСТ Р 53195.3-2015 "Безопасность функциональная связанных с безопасностью зданий и сооружений систем. Часть 3. Требования к системам" для добровольного применения в РФ

Введение

Современные здания и сооружения - объекты капитального строительства, представляющие собой сложные системы и включающие в свой состав систему конструкций и ряд систем в разных сочетаниях, в том числе инженерные системы жизнеобеспечения, реализации технологических процесссов, энерго-, ресурсосбережения, обеспечения безопасности и другие системы. Эти системы взаимодействуют друг с другом, с внешней и внутренней средами.

Объекты капитального строительства жестко привязаны к местности. Рабочие характеристики зданий, сооружений и входящих в них систем могут быть реализованы, проверены и использованы только в том месте, в котором построены объекты и установлены системы.

Безопасность зданий и сооружений обеспечивается применением совокупности мер, мероприятий и средств снижения риска причинения вреда до уровня приемлемого риска и поддержания этого уровня в течение периода эксплуатации или использования этих объектов. К средствам снижения риска относятся связанные с безопасностью зданий и сооружений системы (СБЗС-системы). Эти системы, состоящие из электрических и/или электронных компонентов, и/или программируемых электронных компонентов, в течение многих лет используются для выполнения функций безопасности. Для решения задач обеспечения безопасности зданий и сооружений во все больших объемах используются программируемые электронные (т.е. компьютерные) СБЗС-системы.

Настоящий стандарт входит в комплекс стандартов с наименованием "Безопасность функциональная связанных с безопасностью зданий и сооружений систем" и является третьим стандартом этого комплекса - Часть 3. Требования к системам. Другие стандарты, входящие в этот комплекс:

Часть 1. Основные положения;

Часть 2. Общие требования;

Часть 4. Требования к программному обеспечению;

Часть 5. Меры по снижению риска, методы анализа риска и оценки полноты безопасности;

Часть 6. Внешние средства уменьшения риска и системы мониторинга конструкций;

Часть 7. Порядок применения требований к системам и примеры расчетов.

Структура комплекса стандартов приведена ниже.

1 Область применения

Настоящий стандарт

- применяют совместно с ГОСТ Р 53195.1 и ГОСТ Р 53195.2;

- применяют к электрическим, электронным, программируемым электронным связанным с безопасностью зданий и сооружений системам (далее - Е/Е/РЕ СБЗС-системам), а также к системам, подсистемам и компонентам внутри Е/Е/РЕ СБЗС-систем, которые содержат хотя бы один электрический, электронный или программируемый компонент;

- устанавливает требования к функциональной безопасности аппаратных средств (далее - АС) Е/Е/РЕ СБЗС-систем на стадиях проектирования, планирования и реализации Е/Е/РЕ СБЗС-систем;

- устанавливает требования к действиям и процедурам, которые должны быть выполнены на этих стадиях для обеспечения функциональной безопасности Е/Е/РЕ СБЗС-систем, а также оценки и подтверждения соответствия на стадиях их жизненного цикла, за исключением требований к программному обеспечению (далее - ПО), которые должны быть установлены в нормативных документах на ПО;

- устанавливает минимальный состав информации, необходимой для установки, ввода в эксплуатацию и подтверждения соответствия Е/Е/РЕ СБЗС-систем требованиям безопасности.

Примечание - Области применения настоящего стандарта и нормативных документов на ПО взаимосвязаны. Эта взаимосвязь (рисунок 1) должна учитываться при применении настоящего стандарта. Настоящий стандарт должен применяться совместно с нормативными документами на ПО.

2 Нормативные ссылки

2.1 В настоящем стандарте использованы нормативные ссылки на следующие стандарты:

ГОСТ Р 52507-2005 Совместимость технических средств электромагнитная. Электронные схемы управления жилых помещений и зданий. Требования и методы испытаний

ГОСТ Р 53195.1-2008 Безопасность функциональная связанных с безопасностью зданий и сооружений систем. Часть 1. Основные положения

ГОСТ Р 53195.2-2008 Безопасность функциональная связанных с безопасностью зданий и сооружений систем. Часть 2. Общие требования

Примечание - При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодно издаваемому информационному указателю "Национальные стандарты", который опубликован по состоянию на 1 января текущего года, и по соответствующим ежемесячно издаваемым информационным указателям, опубликованным в текущем году. Если ссылочный стандарт заменен (изменен), то при пользовании настоящим стандартом следует руководствоваться заменяющим (измененным) стандартом. Если ссылочный стандарт отменен без замены, то положение, в котором дана ссылка на него, применяется в части, не затрагивающей эту ссылку.

3 Термины и определения

В настоящем стандарте применены термины по ГОСТ Р 53195.1 и ГОСТ Р 53195.2, а также следующие термины с соответствующими определениями:

3.1 автоматизированное рабочее место; АРМ (local control station): Рабочее место оператора со средствами контроля и управления автоматизированным оборудованием.

3.2 аппаратная управления (control room): Центральный функциональный объект центра управления кризисными ситуациями вместе с его физической структурой, в котором размещаются автоматизированное рабочее место или автоматизированные рабочие места со средствами централизованного контроля и управления автоматизированным оборудованием.

3.3 время безопасности процесса: Интервал времени между опасным отказом и возникновением опасного события в случае невыполнения функции безопасности.

3.4 безопасный отказ (safe failure): Отказ, который не приводит к переходу связанной с безопасностью системы в опасное состояние или в состояние невыполнения функции безопасности.

3.5 интервал диагностических проверок (diagnostic test interval): Установленный промежуток времени между отдельными проверками, предназначенными для обнаружения отказов в связанных с безопасностью системах.

3.6 комплект помещений управления (control suite): Группа функционально связанных помещений (таких как офисы, технические аппаратные, зоны отдыха, помещения для тренинга и обучения персонала, сопряженных с аппаратной управления и включающая ее), которые обеспечивают реализацию функций эксплуатации и обслуживания аппаратной управления.

3.7 контрольная проверка (proof test): Периодическая проверка, выполняемая для обнаружения отказов в связанных с безопасностью системах с целью последующего восстановления систем до исходного состояния, в случае обнаружения отказа.

3.8 модуль (module): Элемент конструкции или сформированный набор подходящих друг к другу элементов конструкций в зданиях и сооружениях, или стандартная программа, дискретный компонент, или сформированный функциональный набор подходящих друг к другу стандартных программ или дискретных компонентов в электрической, электронной, программируемой электронной связанной с безопасностью зданий и сооружений системе.

3.9 опасный отказ: Отказ управляемого оборудования или системы управления управляемым оборудованием с потенциальной возможностью вызова опасного события и/или невыполнение функции безопасности.

3.10 отказ по общей причине (common failure): Отказ оборудования, вызванный единичным событием в случаях, когда отказ не является следствием другого отказа.

3.11 охват диагностикой (diagnostic coverage): Мера, предпринимаемая для относительного уменьшения вероятности опасных отказов зданий и сооружений, их конструкций, систем, аппаратуры, элементов, связанная с выполнением автоматических диагностических проверок.

3.12 полнота безопасности по отношению к систематическим отказам (systematic safety integrity): Составляющая полноты безопасности связанной с безопасностью зданий и сооружений системы по отношению к систематическим отказам, проявляющимся в опасном режиме.

3.13 программный модуль (software module): Программа или функционально завершенный фрагмент программы, предназначенный для хранения, трансляции, объединения и взаимодействия с другими программными модулями и загрузки в оперативную память.

3.14 систематический отказ (systematic failure): Отказ системы, аппаратного средства или программного обеспечения, связанный с некоторой повторяющейся причиной процесса проектирования, производства, монтажа или пусконаладки, и который может быть изменен только путем модификации этих процессов.

3.15 случайный отказ аппаратного средства, отказ AC (random hardware failure): Отказ аппаратного средства, возникающий в случайный момент времени в результате действия одного или нескольких возможных механизмов ухудшения его характеристик.

3.16 тестовая программа (test harness): Программный продукт, предназначенный для имитации среды, в которой должно действовать разрабатываемое программное обеспечение или аппаратное средство, осуществляемой путем передачи тестовых данных в программу и регистрации ответов.

3.17 остаточный коэффициент потери информации (rate of residual information loss): Отношение числа необнаруженных утерянных сообщений к общему числу отправленных сообщений.

3.18 остаточный коэффициент ошибок (residual error rate): Отношение числа необнаруженных ошибочных сообщений к общему числу отправленных сообщений.

3.19 центр управления кризисными ситуациями, ЦУКС (control centre): Совокупность функционально и территориально объединенных аппаратных управления, комплектов помещений управления и автоматизированных рабочих мест с соответствующим оборудованием для обеспечения централизованного контроля и управления кризисными ситуациями.

4 Обозначения и сокращения

В настоящем стандарте приняты обозначения и сокращения, приведенные ниже:

АРМ	-	автоматизированное рабочее место;
АС	-	аппаратное(ые) средство(а);
ОЗУ	-	оперативное запоминающее устройство;
ПЗУ	-	программируемое запоминающее устройство;
ПО	-	программное обеспечение;
СБЗС-система	-	связанная с безопасностью зданий и сооружений система;
УО	-	управляемое оборудование;
ЦУКС	-	центр управления кризисными ситуациями;
Е/Е/РЕ	-	электрическая и/или электронная, и/или программируемая электронная (в отношении системы);
РЕ	-	программируемая электроника;
SIL	-	обозначение уровня полноты безопасности;
NP	-	непрограммируемое устройство.

5 Требования

5.1 Соответствие требованиям стандарта

Признание соответствия Е/Е/РЕ СБЗС-систем требованиям настоящего стандарта - по ГОСТ Р 53195.2 (5.1).

Требования к конкретным Е/Е/РЕ СБЗС-системам должны быть установлены с учетом: природных факторов, характера опасностей, необходимого снижения риска и последствий, требуемого уровня полноты безопасности, сложности системы, физической среды применения, новизны разработки.

5.2 Требования к документации

Требования к документации Е/Е/РЕ СБЗС-систем - по ГОСТ Р 53195.2 (5.2).

5.3 Требования к управлению функциональной безопасностью

Требования к управлению функциональной безопасностью Е/Е/РЕ СБЗС-систем - по ГОСТ Р 53195.2 (раздел 6).

5.4 Требования к жизненному циклу Е/Е/РЕ СБЗС-систем

5.4.1 Для стадий проектирования, планирования и реализации жизненного цикла Е/Е/РЕ СБЗС-систем цели, которые должны быть достигнуты, требования к АС этих систем и действия, необходимые для выполнения этих требований и достижения целей, устанавливаются настоящим стандартом.

Цели и требования для полного жизненного цикла Е/Е/РЕ СБЗС-систем установлены в ГОСТ Р 53195.2. Цели и требования к программному обеспечению (далее - ПО) Е/Е/РЕ СБЗС-систем должны быть установлены в нормативных документах на ПО.

5.4.2 Для каждой стадии жизненного цикла могут быть установлены необходимые промежуточные стадии (рисунок 2) с указанием для каждой из них области применения, входных данных (входов) и результатов (выходов) стадии.

Промежуточные стадии должны быть установлены на стадии планирования функциональной безопасности (ГОСТ Р 53195.2, раздел 6) и на них должны быть достигнуты все цели и выполнены все требования настоящего стандарта.

5.4.3 Процедуры управления функциональной безопасностью по ГОСТ Р 53195.2 (раздел 6) должны выполняться параллельно рассматриваемым стадиям жизненного цикла Е/Е/РЕ СБЗС-систем.

5.4.4 Входные данные каждой стадии жизненного цикла Е/Е/РЕ СБЗС-систем должны соответствовать определенным для этих стадий целям и требованиям (см. 5.5 - 5.16). Результаты каждой стадии должны быть документированы лицами, ответственными за обеспечение функциональной безопасности на соответствующей стадии жизненного цикла систем.

5.5 Требования к функциональной безопасности Е/Е/РЕ СБЗС-систем

5.5.1 Для каждой Е/Е/РЕ СБЗС-системы на стадии проектирования должна быть разработана спецификация требований к функциональной безопасности, в которой устанавливаются требования к функциям безопасности и требования к полноте безопасности для достижения необходимой функциональной безопасности АС системы.

5.5.2 Спецификация требований к функциональной безопасности Е/Е/РЕ СБЗС-систем должна формироваться на основании распределения требований безопасности в соответствии с 7.6 ГОСТ Р 53195.2 и с учетом требований, определенных в ходе планирования функциональной безопасности в соответствии с требованиями раздела 6 ГОСТ Р 53195.2.

Примечание - Не рекомендуется выполнение Е/Е/РЕ СБЗС-системой каких-либо функций, не связанных с безопасностью.

5.5.3 Требования к функциональной безопасности должны быть реализуемыми, поддающимися проверке и пригодными для тестирования. Они должны быть документированы.

5.5.4 Спецификация требований к функциям безопасности Е/Е/РЕ СБЗС-систем должна:

а) содержать описание всех функций безопасности, необходимых для достижения функциональной безопасности, которое должно:

- устанавливать конкретные требования, достаточные для проектирования и реализации Е/Е/РЕ СБЗС-систем;

- включать в свой состав перечень мер по достижению и поддержанию безопасного состояния управляемого оборудования (далее - УО);

- определять, требуется ли непрерывное управление УО и чем обеспечивается достижение безопасного состояния УО;

- определять, к какому режиму относится функция безопасности Е/Е/РЕ СБЗС-системы (к режиму с низкой частотой запросов либо к режиму с высокой частотой запросов или с непрерывным запросом);

б) содержать характеристики производительности и время реакции системы;

в) содержать сведения об интерфейсах оператора-системы, необходимых для достижения требуемой функциональной безопасности;

г) содержать сведения о стыках Е/Е/РЕ СБЗС-систем с любыми другими системами (внутренними, внешними), с УО;

д) содержать описание всех используемых режимов работы УО, в том числе для:

- подготовки к эксплуатации, включая монтаж и наладку;

- обучения операторов, пуска систем в действие в автоматическом, полуавтоматическом, ручном и стационарном рабочих режимах работы;

- стационарного нерабочего режима, переустановки, останова, технического обслуживания;

- работы при предсказуемых нештатных условиях;

е) содержать подробное описание всех вариантов поведения Е/Е/РЕ СБЗС-систем, в том числе при отказе, и необходимой реакции на него (например тревожный сигнал, автоматический останов и т.п.);

ж) содержать описание значимости всех взаимодействий АС и ПО и любых необходимых ограничений, которые должны быть идентифицированы и документированы;

и) содержать предельные и ограничивающие условия для работы Е/Е/РЕ СБЗС-систем и связанных с ними систем, например временные ограничения;

к) содержать любые специфические требования, связанные с запуском или перезапуском Е/Е/РЕ СБЗС-систем.

5.5.5 Спецификация требований к полноте безопасности Е/Е/РЕ СБЗС-систем должна включать в свой состав:

а) уровень полноты безопасности для каждой функции безопасности и, при необходимости, значение требуемой целевой величины отказов в выполнении функции безопасности;

б) режим работы (с низкой частотой запросов либо с высокой частотой запросов или с непрерывным запросом) каждой функции безопасности;

в) требования, ограничения, функции и возможность проведения периодических испытаний Е/Е/РЕ СБЗС-систем;

г) экстремальные значения всех условий окружающей среды в течение жизненного цикла Е/Е/РЕ СБЗС-систем, включая испытания, установку, ввод в эксплуатацию, эксплуатацию и техническое обслуживание;

д) пределы электромагнитной устойчивости, необходимые для достижения электромагнитной совместимости по ГОСТ Р 52507.

Примечание - При разработке спецификации требований безопасности Е/Е/РЕ СБЗС-систем могут быть использованы методы и средства, приведенные в таблице Б.1 приложения Б.

5.6 Планирование подтверждения соответствия Е/Е/РЕ СБЗС-систем

5.6.1 Подтверждение соответствия АС Е/Е/РЕ СБЗС-систем установленным требованиям должно быть заранее запланировано лицом, ответственным за представление АС для подтверждения соответствия.

5.6.2 План должен содержать последовательность процедурных и технических шагов, необходимых для подтверждения соответствия АС Е/Е/РЕ СБЗС-систем предъявляемым к ним требованиям функциональной безопасности в соответствии с 5.5.

Примечание - Требования к планированию подтверждения соответствия ПО должны быть установлены в НД на ПО.

5.6.3 План подтверждения соответствия Е/Е/РЕ СБЗС-систем должен содержать:

а) требования, установленные в спецификации к функциональной безопасности Е/Е/РЕ СБЗС-систем;

б) процедуры и критерии ("прошла"/"не прошла" система испытания), применяемые для подтверждения правильности выполнения каждой функции безопасности;

в) процедуры и критерии ("прошла"/"не прошла" система испытания), применяемые для подтверждения соответствия требованиям полноты безопасности каждой функции безопасности;

г) условия окружающей среды, при которых проводят испытания, необходимые средства испытаний и испытательное оборудование (в том числе план калибровки и поверки этих средств и оборудования);

д) методы оценки с их обоснованием;

е) процедуры испытаний и критерии, применяемые для подтверждения соответствия заданных пределов электромагнитной устойчивости (в соответствии с ГОСТ Р 52507);

ж) меры по устранению подтвержденных отказов.

5.7 Проектирование и реализация Е/Е/РЕ СБЗС-систем

5.7.1 Проектирование и реализация Е/Е/РЕ СБЗС-систем должны осуществляться в соответствии с требованиями, установленными для функций безопасности и для полноты безопасности в 5.5, и с учетом требований 5.7.2-5.7.15.

5.7.2 Проектирование Е/Е/РЕ СБЗС-систем, включая полные структуры АС и ПО, в том числе сенсорные и исполнительные устройства, программируемую электронику, встроенное программное обеспечение, "зашитое" в программируемые запоминающие устройства (ПЗУ), прикладное ПО и т.п. (рисунок 3), должно осуществляться таким образом, чтобы удовлетворялись требования:

а) к полноте безопасности АС, в том числе:

- требования к структурным ограничениям на полноту безопасности АС (5.8);

- требования к вероятности опасных случайных отказов АС (5.8.2);

б) к полноте безопасности по отношению к систематическим отказам:

- требования по предотвращению отказов (5.9) и требования по управлению систематическими отказами (5.10) или

- требования к подтверждению того, что оборудование "проверено в эксплуатации" (5.12.5 - 5.12.12);

в) к действиям системы при обнаружении ошибок и отказов (5.11).

5.7.3 Для установления необходимой полноты безопасности Е/Е/РЕ СБЗС-систем должен быть применен метод проектирования, обеспечивающий достижение уровня полноты безопасности АС и полноты безопасности по отношению к систематическим отказам, в ходе реализации которого:

- определяют требуемый уровень полноты безопасности функций безопасности (по ГОСТ Р 53195.2);

- устанавливают полноту безопасности АС равной полноте безопасности по отношению к систематическим отказам и равной уровню полноты безопасности (5.10);

- для установленной полноты безопасности АС определяют структуру, соответствующую ограничениям на структуру (5.8.1), и предоставляют доказательства соответствия вероятности отказов функций безопасности из-за случайных отказов аппаратных средств требуемым целевым значениям отказов (5.8.2);

- для установленной полноты безопасности по отношению к систематическим отказам выявляют особенности проектирования, которые приводят к систематическим отказам в реальной работе (5.10) или подтверждают соответствие требованиям "проверено при эксплуатации" (5.12.5 - 5.12.12);

- для полноты безопасности в отношении систематических отказов определяют методы и средства, предотвращающие систематические отказы в процессе проектирования и реализации (5.9), или предоставляют доказательства соответствия требованиям "проверено при эксплуатации" (5.12.5 - 5.12.12).

Примечание - Требования к структуре ПО, тестирования при интеграции ПО, связанные с ними требования к интеграции программируемой электроники должны быть установлены в нормативных документах на ПО.

5.7.4 Во всех случаях, когда Е/Е/РЕ СБЗС-система реализует функции безопасности, а также функции, не относящиеся к безопасности, все АС и ПО должны рассматриваться как связанные с безопасностью до тех пор, пока не будет установлено, что эти функции реализуются достаточно независимо (т.е. отказ какой-либо функции, не относящейся к безопасности, не становится причиной отказа функций, связанных с безопасностью).

Достаточная независимость этих функций доказывается предоставлением доказательств того, что вероятность зависимого отказа между компонентами, не относящимися к безопасности, и компонентами, связанными с безопасностью, достаточно низка по сравнению с самым высоким уровнем полноты безопасности, который относится к выполняемым функциями безопасности.

5.7.5 Функции, связанные с безопасностью, должны быть, по возможности, отделены от функций, не относящихся к безопасности.

Примечание - Совмещение этих функций, допускаемое настоящим стандартом, может привести к значительным сложностям при выполнении работ в процессе жизненного цикла Е/Е/РЕ-системы (например при проектировании, подтверждении соответствия, оценке функциональной безопасности и техническом обслуживании).

5.7.6 Требования к АС и ПО Е/Е/РЕ СБЗС-системы должны определяться уровнем полноты безопасности при выполнении ими функций безопасности с самым высоким уровнем полноты безопасности, если не будет доказано, что выполнение функций безопасности для различных уровней полноты безопасности достаточно независимо.

Достаточная независимость выполнения функций безопасности доказывается предоставлением доказательств того, что вероятность зависимого отказа компонентов, выполняющих функции безопасности для различных уровней полноты безопасности, достаточно низка по сравнению с самым высоким уровнем полноты безопасности, относящимся к рассматриваемым функциям безопасности.

5.7.7 В случае выполнения Е/Е/РЕ СБЗС-системой нескольких функций безопасности должна быть рассмотрена возможность возникновения отказа в выполнении нескольких функций безопасности из-за единственной ошибки. Требования к АС и ПО в этом случае допускается устанавливать, применяя уровень полноты безопасности более высокий, чем уровень, относящийся к выполнению любой из функций безопасности, в зависимости от риска, связанного с таким отказом.

5.7.8 Если функции безопасности должны быть независимыми в соответствии с 5.7.4 и 5.7.6, то в проектной документации должно быть приведено обоснование метода достижения независимости функций.

5.7.9 При разработке Е/Е/РЕ СБЗС-систем должна быть проверена корректность требований к ПО и АС в их сочетании: требования к функциям безопасности, требования к полноте безопасности Е/Е/РЕ СБЗС-системы и требования к интерфейсу между оборудованием и оператором. Результаты проверки должны быть отражены в проектной документации.

5.7.10 В проектной документации должно быть приведено обоснование методов и средств, принятых при проектировании для достижения необходимого уровня полноты безопасности в течение стадий жизненного цикла безопасности Е/Е/РЕ СБЗС-системы, а также методов и средств, выбранных для формирования интегрированного набора компонентов системы, обеспечивающего требуемый уровень полноты безопасности.

Примечание - Альтернативой такому обоснованию могут служить результаты независимой проверки (аудита) с письменным подтверждением правильности выбора Е/Е/РЕ СБЗС-системы и компонентов (включая сенсоры, датчики и т.д.).

5.7.11 Основные взаимодействия АС и ПО, предусмотренные в процессе проектирования и реализации Е/Е/РЕ СБЗС-системы, должны быть идентифицированы, оценены и отражены в проектной документации.

5.7.12 В состав проекта на сложную Е/Е/РЕ СБЗС-систему, в том числе комплексную систему безопасности, должны быть включены также индивидуальные проекты (части проекта) на более простые составляющие системы (подсистемы). Для каждой из них должен быть предусмотрен набор тестов для интеграции (5.14).

Примечания

1 Конкретная подсистема может состоять из одного компонента или группы компонентов. Полная Е/Е/РЕ СБЗС-система может состоять из множества отдельных подсистем, которые при их объединении обеспечивают выполнение предусмотренной функции безопасности. Подсистема может иметь несколько каналов.

2 Следует избегать избыточных функциональных возможностей, пропускной способности или производительности подсистем, если не может быть обеспечена защита от выполнения ими непредусмотренных функций.

5.7.13 Если подсистема имеет многоканальный выход, должно быть определено наличие комбинаций выходных состояний, которые могут быть вызваны отказом самой Е/Е/РЕ СБЗС-системы, способных непосредственно вызвать событие опасного отказа (ГОСТ Р 53195.2, 7.4). При наличии таких комбинаций их предотвращение должно быть расценено как функции безопасности, действующие в режиме с высокой частотой запросов или с непрерывным запросом.

5.7.14 Для любых компонентов Е/Е/РЕ СБЗС-системы в максимальной степени должно быть ограничено их использование в предельных режимах работы или предельных условиях окружающей среды. Обоснование работы на пределах любых компонентов должно быть документировано (ГОСТ Р 53195.2, раздел 5).

5.7.15 При ограничении допустимых значений должен использоваться коэффициент ограничения, равный 0,67.

5.8 Требования к полноте безопасности АС

5.8.1 Структурные ограничения полноты безопасности АС

5.8.1.1 Наиболее высокий уровень полноты безопасности функции безопасности, выполняемой Е/Е/РЕ СБЗС-системой, должен ограничиваться устойчивостью АС к отказам и составляющей безопасных отказов подсистем, которые выполняют эту функцию безопасности (приложение В).

Е/Е/РЕ СБЗС-подсистемы как составляющие более сложных систем подразделяют по этим признакам на подсистемы типов А и Б.

5.8.1.2 Конкретная Е/Е/РЕ СБЗС-подсистема (5.7.12, примечание 1) может быть отнесена к типу А, если для ее компонентов, необходимых для реализации функции безопасности, одновременно выполняются следующие условия:

а) определены виды отказов всех составляющих компонентов;

б) может быть полностью определено поведение системы в условиях отказа;

в) имеются достоверные эксплуатационные данные, показывающие, что частота диагностических проверок, требуемых для обнаруженных отказов и необнаруженных опасных отказов, обеспечивается.

5.8.1.3 Конкретная подсистема должна быть отнесена к типу Б, если для ее компонентов, необходимых для реализации функции безопасности, выполняется одно из условий:

а) не определен вид отказа, по крайней мере, одного составляющего компонента;

б) не может быть полностью определено поведение подсистемы в условиях отказа;

в) нет достоверных эксплуатационных данных по подтверждению требований для частот обнаруженных отказов и необнаруженных опасных отказов (5.12.3 и 5.12.4).

Примечание - Подсистема должна быть отнесена к подсистеме типа Б, если хотя бы один из компонентов подсистемы соответствует условиям, установленным для системы типа Б (см. также 5.7.12, примечание 1).

5.8.1.4 Наибольший уровень полноты безопасности, который может быть установлен для функции безопасности при использовании подсистем, с учетом устойчивости АС к отказам и составляющей безопасных отказов этих подсистем, должен быть таким, как указано в таблицах 1 и 2.

Требования таблиц 1 и 2 должны применяться к каждой подсистеме, выполняющей функцию безопасности, и к каждой части Е/Е/РЕ СБЗС-системы. Применяемость таблиц определяют на основании 5.8.1.2 - 5.8.1.4. Самый высокий уровень полноты безопасности, который может быть установлен для функции безопасности по запросу, определяют на основании 5.8.1.5 и 5.8.1.6.

При использовании таблиц 1 и 2 должны быть учтены следующие условия и допущения:

а) устойчивость АС к отказам N означает, что отказ N + 1 может привести к невыполнению функции безопасности;

Примечание - При определении устойчивости АС к отказам не должны учитываться средства, которые могут управлять влиянием ошибок, например средства диагностики;

Таблица 1 - Зависимость полноты безопасности АС СБЗС-подсистем типа А от устойчивости АС к отказам и доли безопасных отказов

Доля безопасных отказов, %	Уровень полноты безопасности в зависимости от устойчивости АС к отказам (см. примечание 1)
	N = 0	N = 1	N = 2
До 60	SIL1	SIL2	SIL3
От 60 до 90	SIL2	SIL3	SIL4
От 90 до 99	SIL3	SIL4	SIL4
99 и св.	SIL3	SIL4	SIL4
Примечания 1 Расчет доли безопасных отказов - в приложении В. 2 Уровни полноты безопасности SIL1-SIL4 - по ГОСТ Р 53195.2 (7.6.12).

Таблица 2 - Зависимость полноты безопасности АС СБЗС-подсистем типа Б от устойчивости АС к отказам и доли безопасных отказов

Доля безопасных отказов, %	Уровень полноты безопасности в зависимости от устойчивости АС к отказам (см. примечание 1)
	N = 0	N = 1	N = 2
До 60	Не оговаривается	SIL1	SIL2
От 60 до 90	SIL1	SIL2	SIL3
От 90 до 99	SIL2	SIL3	SIL4
99 и св.	SIL2	SIL4	SIL4
Примечания 1 Расчет доли безопасных отказов - в приложении В. 2 Уровни полноты безопасности SIL1-SIL4 - по ГОСТ Р 53195.2 (7.6.12).

б) если одна ошибка непосредственно приводит к одной или более последующим ошибкам, они должны быть учтены как одиночная ошибка;

в) при определении устойчивости к отказам часть ошибок может быть исключена, если вероятность их возникновения очень мала по сравнению с требованиями к полноте безопасности подсистемы. Любые исключения ошибок должны быть обоснованы и документированы [см. примечание 3 к перечислению г)];

г) доля безопасных отказов подсистемы должна определяться, как отношение суммы средних частот безопасных отказов и опасных отказов, обнаруженных тестами, к полной средней частоте отказов подсистемы (см. приложение В).

Примечания

1 Для получения достаточно устойчивой к отказам структуры подсистемы, с учетом уровня ее сложности, должны быть использованы структурные ограничения. Уровень полноты безопасности Е/Е/РЕ СБЗС-системы, полученный в результате учета требований настоящего пункта, - максимальный из заявленных.

2 Структура и подсистема, сформированные для обеспечения соответствия требованиям устойчивости АС к отказам, должны быть такими, какие обычно используются в режиме эксплуатации. Требования устойчивости к отказам могут быть снижены, если Е/Е/РЕ СБЗС-система восстанавливается, находясь под внешним управлением основного оборудования. В этом случае основные параметры подсистемы, связанные с любым ослаблением требований, должны быть предварительно оценены (например среднее время восстановления по сравнению с вероятными интервалами времени между запросами).

3 Если некоторый компонент системы имеет очень низкую вероятность отказа, благодаря присущим ему свойствам, (например механический соединитель привода), то нет необходимости рассматривать на основе устойчивости АС к отказам ограничение полноты безопасности любой функции безопасности, для реализации которой используется этот компонент.

5.8.1.5 Структурные ограничения по доле безопасных отказов (см. таблицу 1 или таблицу 2) должны применяться к каждой подсистеме, выполняющей функцию безопасности так, чтобы:

а) достигались требования устойчивости АС к отказам для полной Е/Е/РЕ СБЗС-системы;

б) для любой подсистемы типа А, составляющей часть Е/Е/РЕ СБЗС-системы, применялись требования таблицы 1.

Примечание - Если Е/Е/РЕ СБЗС-система содержит только подсистемы типа А, то требования, приведенные в таблице 1, следует применять к полной Е/Е/РЕ СБЗС-системе;

в) для любой подсистемы типа Б, составляющей часть полной Е/Е/РЕ СБЗС-системы, применялись требования таблицы 2.

Примечание - Если Е/Е/РЕ СБЗС-система содержит только подсистемы типа Б, то требования, приведенные в таблице 2, следует применять к полной Е/Е/РЕ СБЗС-системе;

г) к Е/Е/РЕ СБЗС-системам, содержащим подсистемы типов А и Б, применялись требования таблиц 1 и 2.

5.8.1.6 В Е/Е/РЕ СБЗС-системах, в которых функция безопасности реализуется одноканальной структурой (рисунок 4), максимальный уровень полноты безопасности АС, который может быть достигнут для функции безопасности, должен определяться подсистемой АС с наименьшим требованием безопасности АС, определяемым по таблицам 1 и 2.

Пример - Система, в которой реализована конкретная функция безопасности, выполнена по одноканальной структуре, состоящей из подсистем 1, 2 и 3, типы которых указаны на рисунке 4, и эти подсистемы удовлетворяют требованиям таблиц 1 и 2 следующим образом:

- для подсистемы 1 уровень полноты безопасности, соответствующий требованиям устойчивости АС к отказам и доле безопасных отказов, равен SIL1;

- для подсистемы 2 уровень полноты безопасности, соответствующий требованиям устойчивости АС к отказам и доле безопасных отказов, равен SIL2;

- для подсистемы 3 уровень полноты безопасности, соответствующий требованиям устойчивости АС к отказам и доле безопасных отказов, равен SIL1.

Для этой структуры каждая из подсистем 1 и 3 имеет уровень полноты безопасности, соответствующий требованиям устойчивости АС к отказам, равный SIL1, а подсистема 2 имеет уровень полноты безопасности, соответствующий требованиям устойчивости АС к отказам, равный SIL2. Поэтому подсистемы 1 и 3 ограничивают уровень полноты безопасности, который может потребоваться для соблюдения устойчивости АС к отказам для рассматриваемой функции безопасности, до значения SIL1.

5.8.1.7 В Е/Е/РЕ СБЗС-системах, в которых функция безопасности реализуется многоканальной структурой (рисунок 5), максимальный уровень полноты безопасности, достигаемый для рассматриваемой функции безопасности, должен быть определен путем:

а) оценки каждой подсистемы в соответствии с требованиями, представленными в таблицах 1 и 2;

б) группирования подсистем в комбинации;

в) последующего анализа этих комбинаций для определения полного уровня полноты безопасности АС.

Пример - Структура, в которой реализуется конкретная функция безопасности, образована либо комбинацией подсистем 1, 2 и 3, либо комбинацией подсистем 4, 5 и 3, (см. рисунок 6). Комбинация подсистем 1 и 2 и комбинация подсистем 4 и 5 имеют одинаковые функциональные возможности в отношении функции безопасности и имеют раздельные входы в подсистему 3. В этом примере комбинация параллельных подсистем, 1, 2 и 4, 5, соответственно, реализует требуемую часть функции безопасности, независимо от другой (параллельной) подсистемы. Функцию безопасности считают выполненной:

- при событии отказа в подсистеме 1 или подсистеме 2 (поскольку комбинация подсистем 4 и 5 позволяет реализовать функцию безопасности) или

- при событии отказа в подсистеме 4 или подсистеме 5 (поскольку комбинация подсистем 1 и 2 позволяет реализовать функцию безопасности).

Каждая подсистема удовлетворяет требованиям таблиц 1 и 2 следующим образом:

- для подсистемы 1 уровень полноты безопасности, соответствующий требованиям устойчивости АС к отказам и доле безопасных отказов, равен SIL3;

- для подсистемы 2 уровень полноты безопасности, соответствующий требованиям устойчивости АС к отказам и доле безопасных отказов, равен SIL2;

- для подсистемы 3 уровень полноты безопасности, соответствующий требованиям устойчивости АС к отказам и доле безопасных отказов, равен SIL2;

- для подсистемы 4 уровень полноты безопасности, соответствующий требованиям устойчивости АС к отказам и доле безопасных отказов, равен SIL2;

- для подсистемы 5 уровень полноты безопасности, соответствующий требованиям устойчивости АС к отказам и доле безопасных отказов, равен SIL1.

Процедура определения максимального уровня полноты безопасности АС, которая может потребоваться для рассматриваемой функции безопасности, следующая:

а) объединение подсистем 1 и 2: устойчивость АС к отказам и доля безопасных отказов, обеспеченная комбинацией подсистем 1 и 2 (каждая в отдельности соответствует требованиям для SIL3 и SIL2), соответствует требованиям SIL2 (определенным подсистемой 2);

б) объединение подсистем 4 и 5: устойчивость АС к отказам и доля безопасных отказов, обеспеченная комбинацией подсистем 4 и 5 (каждая в отдельности соответствует требованиям для SIL2 и SIL1), соответствует требованиям SIL1 (определенным подсистемой 5);

в) дальнейшее объединение комбинации подсистем 1 и 2 с комбинацией подсистем 4 и 5: уровень полноты безопасности АС в отношении устойчивости АС к отказам комбинации подсистем 1, 2, 4 и 5 определяется:

- оценкой, какая из комбинаций подсистем (т.е. комбинация подсистем 1 и 2 или 4 и 5) достигла самого высокого возможного уровня полноты безопасности АС (в показателях соответствия требованиям устойчивости к отказам) и

- анализом влияния другой комбинации подсистем на устойчивость к отказам для комбинаций подсистем 1, 2, 4 и 5.

В настоящем примере комбинация подсистем 1 и 2 имеет максимально допустимое требование SIL2 [см. перечисление а)], в то время как комбинация подсистем 4 и 5 имеет максимально допустимое требование SIL1 [см. перечисление б)]. Однако в случае отказа, встречающегося в комбинации подсистем 1 и 2, функция безопасности могла бы быть выполнена комбинацией подсистем 4 и 5. С учетом этого устойчивость АС к отказам, достигнутая комбинацией подсистем 1 и 2, увеличивается на единицу. Увеличение устойчивости АС к отказам на единицу приводит к увеличению на единицу уровня полноты безопасности АС, которое может потребоваться (см. таблицы 1 и 2). Поэтому комбинация подсистем 1, 2, 4 и 5 имеет максимально допустимый уровень полноты безопасности в отношении устойчивости к отказам и доли безопасных отказов, равный SIL3 (т.е. уровень полноты безопасности АС, достигнутый комбинацией подсистем 1 и 2, составляет SIL2 плюс единица);

г) полная Е/Е/РЕ СБЗС-система: уровень полноты безопасности АС в отношении их устойчивости к отказам, который может потребоваться для рассматриваемой функции безопасности, определяют анализом комбинации подсистем 1, 2, 4 и 5 (которая достигает уровня устойчивости к отказам, равного SIL3 [см. перечисление с)] и подсистемы 3 (которая достигает уровня устойчивости к отказам, равного SIL2). Подсистема, достигшая самого низкого уровня полноты безопасности АС (в данном случае подсистема 3), определяет максимальный уровень полноты безопасности всей Е/Е/РЕ СБЗС-системы. Поэтому максимальный уровень полноты безопасности АС в отношении устойчивости к отказам аппаратных средств, который может быть достигнут для функции безопасности в данном примере, равен SIL2.

5.8.2 Требования к оценке вероятности отказа функций безопасности из-за случайных отказов АС

5.8.2.1 Вероятность отказа каждой функции безопасности из-за случайных отказов АС не должна превышать значение целевой величины отказов, установленное в спецификации требований к функциональной безопасности (5.5.4, 5.5.5).

Примечания

1 Для функции безопасности, выполняемой АС в режиме с низкой частотой запросов, целевая величина отказов, выраженная как средняя вероятность отказов выполнения по запросу предусмотренной функции безопасности (ГОСТ Р 53195.2, таблица 2), не должна превышать целевой уровень полноты безопасности, установленный для функции безопасности Е/Е/РЕ СБЗС-системы (5.5.5). Например, если значение целевой величины отказов (средней вероятности отказов по запросу) для удовлетворения требуемого снижения риска задано равным , то значение вероятности отказа по запросу функции безопасности, вызванного случайными отказами АС, не должно быть более .

2 Для функции безопасности, выполняемой АС в режиме с высокой частотой запросов или с непрерывным запросом, целевая величина отказов, выраженная в вероятности опасного отказа в час (ГОСТ Р 53195.2, таблица 3), не должна превышать целевой уровень полноты безопасности, установленный для функции безопасности Е/Е/ РЕ СБЗС-системы. Например, если целевая величина отказов (вероятность опасного отказа в час) для выполнения требований по снижению риска задана равной , то вероятность отказа в выполнении функции безопасности, вызванного случайными отказами АС, не должна быть более .

3 Для доказательства выполнения данного требования необходимо провести расчет надежности для соответствующей функции безопасности, используя соответствующие средства (5.8.2.2), и сравнить полученный результат с целевой величиной отказов конкретной полноты безопасности для соответствующей функции безопасности (ГОСТ Р 53195.2, таблицы 2 и 3).

5.8.2.2 Вероятность отказа каждой функции безопасности из-за случайных отказов АС должна быть оценена с учетом:

а) структуры Е/Е/РЕ СБЗС-системы каждой рассматриваемой функции безопасности.

Примечание - При этом должно быть определено, какие виды отказов подсистем находятся в последовательной связи (при которой любой отказ вызывает отказ соответствующей выполняемой функции безопасности), а какие виды отказов находятся в параллельной связи (при которой отказ соответствующей функции безопасности происходит при совпадающих отказах);

б) оцененной интенсивности отказов каждой подсистемы в любых режимах, которые могли бы вызвать опасные отказы Е/Е/РЕ СБЗС-системы, но обнаружены в результате диагностической проверки;

в) восприимчивости Е/Е/РЕ СБЗС-системы к отказам по общей причине [см. примечание 5 к перечислению ж)];

г) охвата диагностикой (см. приложение В) и связанного с ним интервала диагностических проверок.

Примечания

1 В модели надежности системы среднее время восстановления принимается как сумма интервала диагностических проверок и последующего времени ремонта. При работе Е/Е/РЕ СБЗС-системы в режиме с высокой частотой запросов или с непрерывным запросом, когда любые опасные отказы каналов приводят к опасным отказам Е/Е/РЕ СБЗС-системы, в модели надежности интервал диагностических проверок должен быть учтен непосредственно (то есть, дополнительно к среднему времени восстановления), если его значение не является значительно меньшим, чем интервал времени между ожидаемыми запросами (см. 5.8.2.5).

2 При установлении интервала диагностических проверок должны быть учтены интервалы времени между всеми испытаниями, которые влияют на охват диагностикой;

д) интервалов времени, на которых реализуются интервалы диагностических проверок для обнаружения опасных ошибок, не обнаруживаемых диагностическими тестами;

е) времени ремонта системы при обнаруженных отказах.

Примечание - Время ремонта составляет часть среднего времени восстановления, включающего в себя также время обнаружения отказа и период времени, в течение которого ремонт невозможен. Для ситуаций, когда ремонт может быть выполнен в течение конкретного периода времени, например, в то время как УО отключено или находится в надежном (закрытом) состоянии, важно, чтобы при полном расчете был учтен период времени, когда ремонт не может быть проведен, особенно если этот период может быть относительно большим.

ж) вероятности необнаруженного отказа любого процесса передачи данных (см. примечание 5 и 5.13.1).

Примечания

1 Для оценки вероятности опасного отказа в выполнении функции безопасности из-за случайных отказов АС и определения возможности аппаратуры обеспечивать требуемое значение целевой величины отказов может быть применен упрощенный метод.

2 Для каждой функции безопасности должна быть определена отдельно количественным методом надежность Е/Е/РЕ СБЗС-системы с учетом влияния разнообразия видов отказов компонентов и изменения структуры (при использовании избыточности) самих Е/Е/РЕ СБЗС-систем.

3 Для осуществления анализа и расчетов вероятности необнаруженных отказов метод моделирования определяется проектировщиком. Могут быть применены следующие методы моделирования:

- анализ последствий причин отказа,

- анализ дерева ошибок,

- марковские модели,

- блок-диаграммы надежности.

4 При определении значения среднего времени восстановления АС, рассматриваемого в модели надежности, следует учитывать интервал диагностических проверок, время восстановления и любые другие задержки до момента восстановления.

5 При анализе отказов по общей причине и процессов передачи данных следует учитывать влияние других факторов, отличных от реальных отказов компонентов АС (например электромагнитную интерференцию, ошибки декодирования и т.п.). Такие отказы в настоящем стандарте рассматриваются как случайные отказы аппаратных средств.

5.8.2.3 Интервал диагностических проверок любой подсистемы с устойчивостью АС к отказам выше нуля должен быть таким, чтобы для Е/Е/РЕ СБЗС-системы обеспечивалась возможность удовлетворения требований к вероятности случайных отказов АС.

5.8.2.4 Интервал диагностических проверок любой подсистемы с устойчивостью АС к отказам, равной нулю, от которой полностью зависит функция безопасности (см. примечание 1) и которая является лишь средством реализации функции или функций безопасности, действующей(их) в режиме с низкой частотой запросов, должен быть таким, чтобы для Е/Е/РЕ СБЗС-системы обеспечивалась возможность удовлетворения требований по вероятности случайных отказов АС.

Примечания

1 В настоящем стандарте принято, что функция безопасности полностью зависит от подсистемы, если отказ подсистемы вызывает отказ этой функции безопасности Е/Е/РЕ СБЗС-системы и если эта функция безопасности не относится к другой СБЗС-системе.

2 Если существует вероятность того, что некоторые комбинации выходных состояний подсистем могут непосредственно привести к опасному событию, и если комбинация их выходных состояний при наличии ошибки в подсистеме не может быть определена (например в подсистеме типа Б), то обнаружение опасных отказов в подсистеме следует рассматривать как функцию безопасности, действующую в режиме с высокой частотой запросов или с непрерывным запросом, и применять требования 5.11.3 и 2.8.2.5.

ГАРАНТ:

По-видимому, в тексте предыдущего абзаца допущена опечатка. Имеется в виду 5.8.2.5

5.8.2.5 Интервал диагностических проверок любой подсистемы с устойчивостью АС к отказам, равной нулю, от которой полностью зависит функция безопасности (см. примечание 1) и которая является лишь средством реализации функции безопасности, действующей в режиме с высокой частотой запросов или с непрерывным запросом (см. примечание 2), должен быть таким, чтобы значение суммарного времени, в которое входит интервал диагностических проверок и время выполнения предусмотренного действия (реакции на отказ), необходимое для достижения или поддержания безопасного состояния, было меньше времени безопасности процесса.

Примечания

1 В настоящем стандарте принято, что функция безопасности полностью зависит от подсистемы, если отказ подсистемы вызывает отказ этой функции безопасности Е/Е/РЕ СБЗС-системы, и если эта функция безопасности не относится к другой связанной с безопасностью системе.

2 Подсистему, осуществляющую конкретную функцию безопасности, для которой отношение частоты диагностических проверок к частоте запросов превышает 100, допускается рассматривать как осуществляющую функцию безопасности в режиме с низкой частотой запросов при условии, что функция безопасности не предотвращает комбинацию состояний выходов, которые могли бы привести к опасному событию (см. примечание 3).

3 Если функция безопасности служит для предотвращения специфической комбинации состояний выходов, которые могут непосредственно вызвать опасное событие, то необходимо расценивать такую функцию безопасности как функцию, действующую в режиме с высокой частотой запросов или с непрерывным запросом.

5.8.2.6 Если для конкретного проекта целевая величина отказов требуемой полноты безопасности для выполняемой функции безопасности не достигается, то следует:

- определить критические компоненты, подсистемы и/или параметры;

- оценить эффект возможных мер усовершенствования критических компонентов, подсистем или параметров (например, применение более надежных компонентов, дополнительных мер защиты от отказов по общей причине, расширенного охвата диагностикой, расширенной избыточности, уменьшения интервала контрольных испытаний и т.п.);

- выбрать и осуществить подходящие меры усовершенствования;

- повторить вычисление нового значения вероятности отказов аппаратных средств.

5.9 Требования по предотвращению отказов*

5.9.1 Для предотвращения внесения ошибок во время разработки и создания АС Е/Е/РЕ СБЗС-системы должна быть использована соответствующая группа методов и средств (таблица Б.2 приложения Б).

5.9.2 В соответствии с требуемым уровнем полноты безопасности системы выбранный метод проектирования должен обладать возможностями, способствующими достижению:

а) прозрачности, модульности и других свойств, позволяющих управлять сложностью проекта;

б) ясности и точности представления функциональных возможностей, интерфейсов между подсистемами, а также информации, устанавливающей последовательность и время, параллельность работы подсистем и синхронизацию;

в) ясности и точности документирования и передачи информации;

г) обеспечения верификации (проверки) и подтверждения соответствия.

5.9.3 Для гарантированного поддержания требуемой полноты безопасности Е/Е/РЕ СБЗС-системы на необходимом уровне требования к техническому обслуживанию должны быть формализованы на стадии проектирования и представлены в проектной документации.

5.9.4 Следует использовать, по возможности, автоматические средства измерения и интегрированные инструментальные средства разработки.

5.9.5 На стадии проектирования должны быть запланированы испытания Е/Е/РЕ СБЗС-систем, в том числе интегрированных комплексных систем безопасности. План должен быть отражен в проектной документации. В нем должны быть указаны:

а) типы проводимых испытаний и сопровождающие их процедуры;

б) условия окружающей среды при испытаниях, испытательные средства, схемы испытаний и программы испытаний;

в) критерии оценки "прошла"/"не прошла" система испытание.

5.9.6 Действия, выполняемые на автоматизированном рабочем месте проектировщика на стадии проектирования, должны отличаться от действий, которые должны быть доступными на автоматизированном рабочем месте пользователя (оператора).

5.10 Требования по управлению систематическими отказами**

5.10.1 Для управления систематическими отказами проектирование Е/Е/РЕ СБЗС-систем должно осуществляться с использованием таких средств проектирования и таким образом, чтобы Е/Е/РЕ СБЗС-системы оказывались устойчивыми:

а) к любым остаточным ошибкам проектирования АС, если вероятность ошибок проектирования не может быть исключена (таблица А.16);

б) к внешним влияниям, включая электромагнитные воздействия (см. таблицу А.17);

в) к ошибкам оператора управляемого оборудования (таблица А.18);

г) к любым остаточным ошибкам в программном обеспечении;

д) к любым ошибкам, возникающим в результате выполнения любого процесса передачи данных.

5.10.2 Для облегчения реализации свойств ремонтопригодности и тестируемости в созданных Е/Е/РЕ СБЗС-системах эти свойства должны быть учтены в процессе проектирования и создания Е/Е/РЕ СБЗС-систем.

5.10.3 При проектировании Е/Е/РЕ СБЗС-систем должны быть учтены способности и возможности человека, а созданные Е/Е/РЕ СБЗС-системы должны быть удобными при эксплуатации и техническом обслуживании. Разработка всех интерфейсов должна осуществляться с учетом человеческого фактора и с ориентацией на возможный уровень специальной подготовки или квалификации операторов.

Примечание - При эксплуатации Е/Е/РЕ СБЗС-систем на объектах массового жилищного строительства оператором может быть человек без специальной подготовки.

5.10.4 Проектирование Е/Е/РЕ СБЗС-систем должно осуществляться таким образом, чтобы предсказуемые ошибки, допущенные оператором или персоналом, осуществляющим техническое обслуживание, не приводили к критическим последствиям, и/или чтобы действия для выполнения операций, могущих повлечь критические последствия, требовали повторного подтверждения.

5.10.5 Размещение органов управления, средств отображения Е/Е/РЕ СБЗС-систем, размещение АС и коммуникаций должно осуществляться на основе эргономического проектирования с учетом конструктивных особенностей здания и сооружения, объемно-планировочных решений, свойств АС, местных условий и окружения систем.

5.11 Требования к действиям системы при обнаружении отказов

5.11.1 Обнаружение опасного отказа (диагностическими тестами, контрольными испытаниями или иным способом) в любой подсистеме Е/Е/РЕ СБЗС-систем с устойчивостью АС к отказам больше нуля должно завершаться:

а) конкретным действием для достижения или поддержания безопасного состояния системы [примечание к перечислению б)] или

б) изоляцией дефектной части подсистемы для обеспечения возможности продолжения выполнения УО защитного действия до завершения ремонта дефектной части. Если ремонт не завершен в пределах среднего времени восстановления, принятого при вычислении вероятности случайных отказов АС, то для достижения и поддержания их безопасного состояния должно быть выполнено конкретное действие.

Примечание - Конкретное действие (реакция на отказ), которое требуется для достижения или поддержания безопасного состояния Е/Е/РЕ СБЗС-системы должно быть определено в требованиях безопасности аппаратных средств Е/Е/РЕ СБЗС-системы. Оно может состоять, например, в отключении УО на подсистеме с дефектом или его части, относящейся к снижению риска.

5.11.2 Обнаружение опасного отказа (диагностическими проверками, контрольными испытаниями или иным способом) в любой подсистеме с устойчивостью к отказам АС, равной нулю, функция безопасности которой является полностью зависимой (примечание 1), в случае, если такая подсистема используется только функцией(ями) безопасности в режиме с низкой частотой запросов, должно завершаться:

а) конкретным действием для достижения и поддержания безопасного состояния или

б) восстановлением дефектной подсистемы в пределах периода среднего времени восстановления, полученного при расчете вероятности случайных отказов аппаратных средств.

В течение этого времени безопасность УО должна обеспечиваться дополнительными мерами и ограничениями. Снижение риска, обеспеченное дополнительными мерами и ограничениями должно, по крайней мере, равняться снижению риска, обеспеченному Е/Е/РЕ СБЗС-системой в отсутствие любых отказов. Дополнительные меры и ограничения должны быть определены в процедурах эксплуатации и технического обслуживания АС Е/Е/РЕ СБЗС-систем. Если восстановление не предпринято в пределах заданного значения среднего времени восстановления, то для достижения и поддержания безопасного состояния должны быть предприняты конкретные действия (примечание 2).

Примечания

1 В настоящем стандарте принято, что функция безопасности полностью зависит от подсистемы, если отказ подсистемы приводит к отказу функции безопасности рассматриваемой Е/Е/РЕ СБЗС-системы, и функция безопасности не предназначена для другой системы, связанной с безопасностью.

2 Для достижения и поддержания безопасного состояния требуется конкретное действие (реакция на отказ), которое должно быть определено в требованиях безопасности АС Е/Е/РЕ СБЗС-систем. Это действие может состоять, например, в безопасном отключении УО в дефектной подсистеме или ее части с целью снижения риска.

5.11.3 Обнаружение опасного отказа (путем осуществления диагностических проверок, контрольных испытаний или иным способом) в любой подсистеме с устойчивостью к отказам, равной нулю, в которой функция безопасности является зависимой (примечание 1), в случае подсистемы, выполняющей любую(ые) функцию(ии) безопасности, действующую(ие) в режиме с высокой частотой запросов или непрерывным запросом (примечания 2 и 3), для достижения и поддержания безопасного состояния, должно завершаться конкретными действиями (примечание 3).

Примечания

1 В настоящем стандарте принято, что функция безопасности полностью зависит от подсистемы, если отказ подсистемы служит причиной отказа функции безопасности рассматриваемой Е/Е/РЕ СБЗС-системы, а также функция безопасности не относится к другой связанной с безопасностью системе.

2 Если имеется вероятность того, что некоторая комбинация состояний выходов подсистемы может стать непосредственной причиной опасного события, и если комбинацию выходных состояний в случае отказа в подсистеме невозможно определить (например для подсистемы типа Б), то детектирование опасных событий в подсистеме следует расценивать как функцию безопасности, действующую в режиме с высокой частотой запросов или с непрерывным запросом, и применять требования 5.11.3 и 5.7.6.

3 Для достижения и поддержания состояния безопасности, которое должно быть определено в требованиях безопасности Е/Е/РЕ СБЗС-систем, необходимо выполнить конкретное действие (реакцию на отказ). Это действие может состоять, например, в безопасном отключении в дефектной подсистеме управляемого оборудования или его части для снижения риска.

5.12 Требования к реализации Е/Е/РЕ СБЗС-систем

5.12.1 Е/Е/РЕ СБЗС-системы должны быть реализованы (изготовлены, установлены) в соответствии с проектом.

5.12.2 Подсистемы, используемые для реализации одной или более функций безопасности, должны быть идентифицированы и документированы как связанные с безопасностью подсистемы.

5.12.3 Для каждой связанной с безопасностью подсистемы в проекте должна быть представлена следующая информация:

а) перечень функций, интерфейсов и стыков подсистемы, которые могут быть использованы при реализации функций безопасности;

б) расчетные или оценочные значения частоты отказов (из-за случайных отказов АС в любых режимах), обнаруживаемых диагностическими проверками, которые могли бы привести к отказу Е/Е/РЕ СБЗС-системы;

в) расчетные или оценочные значения частоты отказов (из-за случайных отказов АС), не обнаруживаемых диагностическими проверками, которые могли бы привести к отказу Е/Е/РЕ СБЗС-системы;

г) ограничения на параметры окружающей среды подсистемы, которые должны быть соблюдены для обеспечения правомерности расчетных (оценочных) значений частот отказов из-за случайных отказов АС;

д) ограничение срока службы подсистемы, который не должен быть превышен для обеспечения правомерности расчетных (оценочных) значений частот отказов из-за случайных отказов АС;

е) требования к контрольным испытаниям и/или техническому обслуживанию подсистемы;

ж) охват диагностикой подсистемы в соответствии с приложением Б (при необходимости, см. примечание).

Примечание - Испытания по перечислениям е), ж) относятся к диагностическим испытаниям, которые являются внутренними для подсистемы. Перечисленная информация необходима, если требуется обеспечение доверия к действиям по проведению диагностических испытаний в подсистемах в модели надежности Е/Е/РЕ СБЗС-систем;

и) интервал диагностических испытаний [при необходимости, см. примечание перечисления ж)];

к) любая дополнительная информация (например время восстановления), необходимая для обеспечения возможности получения значения среднего времени восстановления после обнаружения отказа с помощью диагностических проверок.

Примечания

1 Испытания по параметрам, приведенным в перечислениях б) - к), необходимы для использования их результатов при оценке вероятности отказов функции безопасности по запросу или вероятности отказов в час.

2 Требования перечислений б), в), е), ж), к) необходимы для оценки отдельных параметров подсистем, таких как сенсорные устройства и приводы, которые могут быть объединены в избыточные структуры для улучшения полноты безопасности АС. Для логических решающих устройств, которые обычно не объединяют в избыточные структуры в одиночной Е/Е/РЕ СБЗС-системе, с учетом требований перечислений б), в), е), ж), к) допускается использовать такие характеристики, как вероятность отказов по запросам или вероятность отказов в час. Для логических устройств необходимо также устанавливать интервал контрольных испытаний для необнаруженных отказов;

л) информация, необходимая для обеспечения выделения составляющей безопасных отказов подсистемы, как принято в Е/Е/РЕ СБЗС-системе, в соответствии с приложением Б;

м) устойчивость к отказам подсистемы.

Примечание - Требования перечислений л), м) необходимы для определения самого высокого уровня полноты безопасности, который может потребоваться для функции безопасности в соответствии со структурными ограничениями системы;

н) любые ограничения по применению подсистемы, которые должны быть рассмотрены во избежание систематических отказов;

п) самый высокий уровень полноты безопасности, который может потребоваться для функции безопасности в подсистеме, на основе:

- методов и средств, используемых для предотвращения систематических ошибок, которые вносятся на этапах проектирования и реализации АС и ПО,

- особенностей проекта, которые делают подсистему устойчивой к систематическим отказам.

Примечание - Не требуется, если эти подсистемы расцениваются как "проверенные в эксплуатации";

р) информация, необходимая для идентификации конфигурации АС и ПО подсистемы для обеспечения возможности управления конфигурацией Е/Е/РЕ СБЗС-системы в соответствии с 6.2.1 ГОСТ Р 53195.2.

5.12.4 Расчетные (оценочные) значения частоты отказов подсистем из-за случайных отказов АС [ 5.12.3, перечисления б) и в)] могут быть определены:

а) исследованием видов отказов и анализом влияния подсистем на основе данных по отказам компонентов из признанного промышленного источника по надежности.

Примечания

1 Уровень доверия любых используемых данных о частоте отказов должен быть не менее 70%.

2 Хотя понятие "постоянная частота отказов" подсистемы принято большинством вероятностных оценочных методов, оно применимо лишь при условии, что не превышен срок службы компонентов подсистемы. Поэтому любая вероятностная оценка должна включать в себя спецификацию срока службы компонентов;

б) из предыдущего опыта использования подсистемы в похожих условиях применения и окружающей среды.

5.12.5 Для подсистем, "проверенных в эксплуатации", информация о методах и средствах предотвращения и управления систематическими отказами не требуется.

5.12.6 Ранее разработанная подсистема должна рассматриваться как "проверенная в эксплуатации" только в случае, если ее функциональные возможности явно ограничены, и имеется соответствующее документальное свидетельство, основанное на предыдущей эксплуатации конкретной конфигурации этой подсистемы (в течение которого все отказы были документально зарегистрированы) и учитывающее любые требующиеся дополнительные анализы и тесты. Документальное подтверждение должно свидетельствовать, что вероятность любого отказа подсистемы (из-за случайных и систематических отказов АС) в Е/Е/РЕ СБЗС-системе настолько мала, что достигается(ются) требуемый(ые) уровень(ни) полноты безопасности функции(ий) безопасности.

5.12.7 Документальное свидетельство, в соответствии с 5.12.6, должно подтверждать, что предыдущие условия эксплуатации конкретной подсистемы являются такими же или достаточно близкими к тем, в которых будет эксплуатироваться подсистема в Е/Е/РЕ СБЗС-системе и свидетельствовать, что вероятность любых необнаруженных систематических отказов настолько низка, что достигается требуемый уровень(ни) полноты безопасности функции(ий) безопасности для подсистемы.

Примечание - Условия эксплуатации подсистемы включают в себя все факторы, которые могут повлиять на вероятность систематических отказов АС и ПО подсистемы. Например, условия окружающей среды, виды использования, выполняемые функции, конфигурацию, связи с другими системами, операционную систему, тип транслятора, человеческий фактор.

5.12.8 Если имеются различия между предыдущими условиями эксплуатации подсистемы и условиями, в которых будет эксплуатироваться Е/Е/РЕ СБЗС-система, то такие различия должны быть идентифицированы и с использованием комбинации соответствующих методов анализа и испытаний в проектной документации должно быть представлено доказательство того, что вероятность любой необнаруженной систематической ошибки настолько низка, что достигается требуемый уровень(ни) полноты безопасности для функции(ий) безопасности подсистемы.

5.12.9 Документальное свидетельство по 5.12.6 должно установить, что время предыдущего использования конкретной конфигурации подсистемы (в часах эксплуатации) является достаточным, чтобы статистически рассматривать заявленное значение частоты отказов. Как минимум, требуется достаточное время эксплуатации для установления значения заявленной частоты отказов в одностороннем нижнем пределе доверия, по крайней мере, 70%. При статистическом анализе время эксплуатации любой индивидуальной подсистемы в течение менее одного года не рассматривается как часть полного времени эксплуатации.

Примечание - Требуемое время эксплуатации подсистемы для установления заявляемого значения частоты отказов может быть получено по результатам эксплуатации нескольких идентичных подсистем при условии, что отказы всех подсистем были обнаружены и документированы. Например, если имеется 100 подсистем, каждая из которых проработала без отказов 10000 ч, то полное время эксплуатации без отказов можно считать равным 1000000 ч. В этом случае каждая подсистема должна эксплуатироваться более одного года и действия при расчетах должны быть отнесены к полученному выше полному числу часов эксплуатации.

5.12.10 При проверке выполнения требований к подсистеме по 5.12.6 и 5.12.9 должна быть принята во внимание только предыдущая эксплуатация подсистемы, при которой все отказы подсистем были обнаружены и документированы.

5.12.11 При проверке выполнения или невыполнения требований 5.12.6 и 5.12.9 следует учитывать диапазон охвата и уровень детализации имеющейся информации для следующих факторов: сложность подсистемы, вклад, внесенный конкретной подсистемой в снижение риска, последствия, связанные с отказом системы, новизну проекта.

5.12.12 Термин "проверено в эксплуатации" следует применять к связанной с безопасностью подсистеме в Е/Е/РЕ СБЗС-системе и ограничивать его применение к функциям и интерфейсам подсистемы (5.12.6 - 5.12.10).

Примечание - Требования 5.12.4 - 5.12.12 применимы также к подсистемам, содержащим ПО. В случае применения таких подсистем следует убедиться, что конкретная подсистема выполняет в Е/Е/РЕ СБЗС-системе только те функции, для которых задана требуемая полнота безопасности.

5.13 Требования к передаче-приему данных

5.13.1 При любой форме передачи данных, используемой при выполнении функции безопасности, должна быть оценена вероятность необнаруженного отказа процесса передачи-приема данных с учетом ошибок передачи, повторов, удалений, вставок, повторного упорядочения, искажения, задержки и ошибок идентификации (5.13.2). Эта вероятность должна быть учтена при оценке вероятности опасного отказа функции безопасности из-за случайных отказов аппаратных средств (5.8.2.2).

Примечание - Ошибка идентификации означает, что истинное содержание сообщения идентифицировано неправильно (например, сообщение от компонента, не связанного с безопасностью, идентифицировано как сообщение от компонента, связанного с безопасностью).

5.13.2 При оценке вероятности отказа функции безопасности из-за процесса передачи-приема данных, в частности, должны быть учтены:

а) остаточный коэффициент ошибок;

б) остаточный коэффициент потери информации;

в) пределы и непостоянство скорости передачи информации (битовой скорости);

г) пределы и непостоянство задержки распространения информации.

Примечание - Вероятность опасного отказа в час равна отношению вероятности коэффициента остаточных ошибок к длине сообщения (в битах), умноженному на скорость передачи сообщений в шине, относящихся к безопасности, и на 3600.

5.14 Интеграция Е/Е/РЕ СБЗС-систем

5.14.1 Требования к интеграции и испытаниям должны быть предусмотрены для всех Е/Е/РЕ СБЗС-систем, устанавливаемых и интегрируемых в зданиях и сооружениях.

5.14.2 СБЗС-системы должны быть интегрированы в соответствии с конкретным проектом Е/Е/РЕ СБЗС-систем и испытаны в соответствии с конкретными тестами для интеграции Е/Е/РЕ СБЗС-систем (ГОСТ Р 53195.2, 7.8.3).

5.14.3 В ходе интеграции всех модулей в Е/Е/РЕ СБЗС-системы отдельные Е/Е/РЕ СБЗС-системы должны быть испытаны (5.7). Испытания должны показать, правильно ли взаимодействуют все модули и не выполняют ли непредназначенные для них функции.

Примечания

1 В этом случае испытание всех входных комбинаций не проводится. Достаточно провести испытание всех классов эквивалентности. Для сокращения числа испытаний до приемлемого уровня могут быть применены методы статического анализа, динамического анализа или анализа отказов. Проведение проектирования в соответствии с правилами, приводящими к структурному проектированию или полуформальным методам, облегчает выполнение этих требований.

2 Если при разработке используются формальные методы или формальные доказательства и утверждения, а также статистические методы, то возможности таких испытаний могут быть ограничены.

5.14.4 Для проведения испытаний интегрированных Е/Е/РЕ СБЗС-систем должна быть разработана соответствующая документация, устанавливающая методику испытаний и определяющая достижение целей и критериев, установленных на этапах проектирования и реализации систем. В случае отказа системы должны быть документированы причины и способы его устранения.

5.14.5 В период интеграции и испытаний любые модификации или изменения Е/Е/РЕ СБЗС-систем должны быть проанализированы. При анализе должны быть идентифицированы все компоненты, на которые влияют проведенные модификации или изменения, и все необходимые действия по повторному подтверждению выполнения требований к системам.

5.14.6 При испытаниях интегрированных Е/Е/РЕ СБЗС-систем должна быть документирована следующая информация:

а) конкретное место установки интегрированной Е/Е/РЕ СБЗС-системы;

б) версия спецификации требований к испытаниям интегрированных Е/Е/РЕ СБЗС-систем;

в) критерии оценки испытаний интегрированной Е/Е/РЕ СБЗС-системы: "прошла"/"не прошла" система испытания;

г) версия испытуемой Е/Е/РЕ СБЗС-системы;

д) используемые средства испытаний и оборудование с датой поверки;

е) результаты каждого испытания системы;

ж) любое несоответствие между ожидаемыми и фактическими результатами испытаний интегрированных Е/Е/РЕ СБЗС-систем;

и) проведенный анализ и принятое решение о продолжении испытаний систем или оформлении запроса на их изменение (в случае несоответствия требованиям).

5.14.7 Для предотвращения ошибок во время интеграции Е/Е/РЕ СБЗС-систем должна быть использована соответствующая группа методов и средств, приведенных в таблице Б.3 приложения Б.

5.15 Процедуры эксплуатации и технического обслуживания систем

5.15.1 На этапе проектирования должны быть разработаны порядок действий, процедуры и документы, гарантирующие поддержание необходимой функциональной безопасности Е/Е/РЕ СБЗС-систем во время эксплуатации и технического обслуживания.

5.15.2 Разрабатываемые порядок действий, процедуры и документы по эксплуатации и техническому обслуживанию Е/Е/РЕ СБЗС-систем должны устанавливать:

а) действия, которые должны быть выполнены для поддержания предусмотренной проектом функциональной безопасности Е/Е/РЕ СБЗС-систем, включая замену компонентов с предварительно заданными сроками службы, например батарей электропитания и др.;

б) действия и ограничения, необходимые для предотвращения опасных отказов или уменьшения последствий опасных событий (например, во время установки, пуска в действие, режима эксплуатации, периодических испытаний, прогнозируемых неисправностей, отказов или ошибок, отключений);

в) документацию по отказам системы и частотам запросов Е/Е/РЕ СБЗС-систем;

г) документацию с результатами аудитов и испытаний Е/Е/РЕ СБЗС-систем, подлежащую сохранению;

д) процедуры технического обслуживания, которым необходимо следовать в случае, если происходят отказы и ошибки в Е/Е/РЕ СБЗС-системах, в том числе:

- процедуры диагностики отказов и восстановления (ремонта) Е/Е/РЕ СБЗС-систем, подсистем и компонентов,

- процедуры повторного подтверждения соответствия Е/Е/РЕ СБЗС-систем установленным требованиям,

- требования по поддержанию отчетности;

е) процедуры по поддержанию параметров отчетности, которые должны быть определены, в частности процедуры отчетности: по отказам, по анализу отказов;

ж) инструменты и средства, необходимые для технического обслуживания и подтверждения соответствия, и процедуры для поддержания инструментов и средств в рабочем состоянии.

Примечание - В процедуры эксплуатации и технического обслуживания Е/Е/РЕ СБЗС-систем должны быть включены процедуры модификации программного обеспечения.

5.15.3 Действия по техническому обслуживанию Е/Е/РЕ СБЗС-систем, необходимые для поддержания их проектной функциональной безопасности, должны быть установлены на основе системного подхода, который должен обеспечивать определение необнаруженных отказов всех компонентов, связанных с безопасностью (от сенсорных устройств до оконечных элементов), которые могли бы вызвать снижение достигнутой полноты безопасности.

Примечания

1 Для реализации системного подхода могут быть применены методы, включающие в себя:

- экспертизу деревьев отказов;

- анализ видов отказов и анализ влияния;

- поддержание надежности тщательного технического обслуживания.

2 Должен быть учтен человеческий фактор - ключевой момент в определении требуемых действий и соответствующих интерфейсов между человеком и Е/Е/РЕ СБЗС-системой(ами).

3 Частота проведения периодических испытаний должна быть выбрана такой, чтобы была обеспечена целевая величина отказов.

4 При выборе частоты периодических испытаний, интервала диагностических проверок и времени для последующего ремонта Е/Е/РЕ СБЗС-систем должны быть учтены:

- целевая величина отказов, связанных с уровнем полноты безопасности Е/Е/РЕ СБЗС-систем;

- структура системы;

- охват систем диагностикой;

- ожидаемая частота запросов к системам.

5.15.4 Процедуры эксплуатации и технического обслуживания Е/Е/РЕ СБЗС-систем должны быть оценены на возможность воздействия, которое они могут оказать на УО.

5.15.5 Для предотвращения отказов и ошибок во время процедур эксплуатации и технического обслуживания Е/Е/РЕ СБЗС-систем рекомендуется использовать методы/средства, приведенные в таблице Б.4 приложения Б.

5.16 Подтверждение соответствия Е/Е/РЕ СБЗС-систем требованиям безопасности

5.16.1 Для каждой Е/Е/РЕ СБЗС-системы должно быть получено подтверждение того, что заданная Е/Е/РЕ СБЗС-система полностью соответствует требованиям функциональной безопасности (требованиям к функциям безопасности и требованиям к полноте безопасности).

5.16.2 Подтверждение соответствия Е/Е/РЕ СБЗС-систем требованиям функциональной безопасности должно выполняться согласно разработанному плану подтверждения соответствия.

Примечания

1 Подтверждение соответствия отдельных Е/Е/РЕ СБЗС-систем требованиям функциональной безопасности осуществляется на основании результатов (выходов) стадий жизненного цикла Е/Е/РЕ СБЗС-систем после их установки (например, если разработка прикладного ПО для интегрированных систем еще не завершена, а отдельные системы уже установлены), а подтверждение соответствия интегрированных Е/Е/РЕ СБЗС-систем осуществляется после их интеграции.

В случаях, предусмотренных технической документацией, допускается осуществлять подтверждение соответствия отдельных Е/Е/РЕ СБЗС-систем в составе интегрированной Е/Е/РЕ СБЗС-системы.

2 Подтверждение соответствия программируемой электроники, связанной с безопасностью, включает в себя подтверждение соответствия АС и ПО.

5.16.3 Подтверждение соответствия каждой функции безопасности, указанной в спецификации требований к функциональной безопасности Е/Е/РЕ СБЗС-систем, требованиям безопасности, процедурам эксплуатации и технического обслуживания систем должно осуществляться в результате проведения испытаний и/или анализа.

5.16.4 Должна быть подготовлена необходимая документация по проведению испытаний на подтверждение соответствия Е/Е/РЕ СБЗС-систем требованиям функциональной безопасности, в которой для каждой функции безопасности должны быть указаны:

а) конкретное место установки Е/Е/РЕ СБЗС-систем;

б) версия используемого плана проведения подтверждения соответствия Е/Е/РЕ СБЗС-систем;

в) функция безопасности, подвергаемая испытаниям (или анализу), вместе с ссылкой на указанные в документах конкретные требования по планированию проведения подтверждения соответствия Е/Е/РЕ СБЗС-систем требованиям безопасности;

г) испытательные средства и оборудование, данные об их поверке и аттестации;

д) результаты испытаний систем;

е) несоответствие между ожидаемыми и фактическими результатами испытаний.

Примечание - Для каждой функции безопасности отдельная документация не требуется, но каждая функция безопасности и каждое отклонение по перечислениям а) - е) должны быть отражены в документации.

5.16.5 Если фактические результаты отличаются от ожидаемых результатов более, чем это установлено допусками, результаты испытаний на подтверждение соответствия Е/Е/РЕ СБЗС-систем требованиям безопасности должны быть документированы, включая:

а) описание проведенного анализа,

б) принятое решение о продолжении испытаний или об оформлении извещения об изменении и возвращении к более раннему этапу испытаний на подтверждение соответствия.

5.16.6 Для предотвращения отказов при проведении подтверждения соответствия Е/Е/РЕ СБЗС-систем требованиям функциональной безопасности следует использовать методы/средства, приведенные в таблице Б.5 приложения Б.

5.17 Модификация Е/Е/РЕ СБЗС-систем

5.17.1 Модификация Е/Е/РЕ СБЗС-систем должна осуществляться в соответствии с требованиями и процедурами, установленными в ГОСТ Р 53195.2, 7.17.

5.17.2 Действия по модификации любой Е/Е/РЕ СБЗС-системы должны обеспечивать достижение и поддержание требуемой полноты безопасности после изменения, расширения или адаптации этой системы.

5.17.3 По каждому действию по модификации Е/Е/РЕ СБЗС-систем должна быть разработана и сохранена документация. Документация должна включать в себя:

а) детальный перечень модификаций или изменений системы;

б) анализ влияния действий по модификации на полную систему (включая АС и ПО), на взаимодействие "оператор/система", на окружающую среду и возможные взаимодействия с другими системами;

в) утвержденные изменения системы;

г) порядок проведения изменений;

д) результаты испытаний составляющих модулей, в том числе данные повторного подтверждения их соответствия установленным требованиям;

е) предысторию управления конфигурацией Е/Е/РЕ СБЗС-систем;

ж) отклонения от нормальных действий и условий;

и) необходимые изменения системных процедур;

к) необходимые изменения документации.

5.17.4 Изготовители или поставщики Е/Е/РЕ СБЗС-систем, требующих подтверждения соответствия требованиям настоящего стандарта, должны осуществлять техническую поддержку системы при инициировании изменений в результате обнаруживаемых в АС или ПО дефектов и сообщать пользователям о необходимой модификации в случае обнаружения дефекта, затрагивающего безопасность.

5.17.5 Модификация Е/Е/РЕ СБЗС-систем должна проводиться, по крайней мере, с таким же уровнем экспертизы, автоматизированных средств планирования и управления, какой применялся при разработке Е/Е/РЕ СБЗС-систем.

5.17.6 После модификации Е/Е/РЕ СБЗС-системы должны быть повторно верифицированы, а также должно быть повторно подтверждено их соответствие требованиям функциональной безопасности.

5.18 Верификация Е/Е/РЕ СБЗС-систем

5.18.1 Каждая Е/Е/РЕ СБЗС-система должна быть верифицирована с проверкой и оценкой выходных результатов каждой рассмотренной стадии жизненного цикла этой системы для гарантирования правильности всех действий и соответствия в отношении продукции и требований стандартов, предусмотренных на входах этих стадий.

Примечания

1 Все требования к действиям по верификации объединены в 5.18, но фактически они должны выполняться на всех стадиях жизненного цикла Е/Е/РЕ СБЗС-систем.

2 На стадии разработки проектной (рабочей) документации верификация может быть проведена в форме нормоконтроля. На других стадиях жизненного цикла Е/Е/РЕ СБЗС-систем верификация может осуществляться независимыми лицами, отделами или организациями (в зависимости от жесткости требований, предъявляемых к Е/Е/РЕ СБЗС-системам и объектам, в которых они установлены).

5.18.2 Верификация Е/Е/РЕ СБЗС-систем должна быть запланирована одновременно с разработкой этих систем для каждой стадии их жизненного цикла и документирована.

5.18.3 В плане верификации Е/Е/РЕ СБЗС-систем должны быть указаны критерии, методы/средства, используемые для верификации на проверяемой стадии их жизненного цикла.

5.18.4 При планировании верификации Е/Е/РЕ СБЗС-систем должны быть предусмотрены обязательные действия, обеспечивающие правильность установления соответствия требований к продукции и требований стандартов, примененных на входе каждой стадии их жизненного цикла.

5.18.5 Планирование верификации Е/Е/РЕ СБЗС-систем должно предусматривать:

а) выбор порядка и методов верификации;

б) выбор и использование испытательного оборудования и средств испытаний;

в) выбор и документирование действий в ходе верификации;

г) оценку результатов верификации, полученных непосредственно от оборудования, используемого для верификации, и испытаний.

5.18.6 При проектировании и разработке каждой стадии Е/Е/РЕ СБЗС-системы должно быть показано, что требования к функциям безопасности и полноте безопасности выполняются.

5.18.7 Результат каждого действия по верификации должен быть документирован с указанием о прохождении верификации Е/Е/РЕ СБЗС-системой или причины отказа. Должны быть описаны устройства, не соответствующие:

а) одному или более требованиям жизненного цикла Е/Е/РЕ СБЗС-системы,

б) одному или более требованиям стадии проектирования системы,

в) одному или более требованиям управления функциональной безопасностью системы (раздел 6).

5.18.8 Для верификации требований функциональной безопасности Е/Е/РЕ СБЗС-системы, после того как они были установлены и перед началом следующей стадии (проектирования и реализации), проверка должна обеспечивать:

а) определение адекватности требований функциональной безопасности Е/Е/РЕ СБЗС-систем требованиям, установленным при распределении требований безопасности по Е/Е/РЕ СБЗС-системам для безопасности, функциональных возможностей и других требований, установленных при планировании безопасности;

б) проверку на несовместимость:

- требований безопасности Е/Е/РЕ СБЗС-систем (5.5),

- распределения требований безопасности (ГОСТ Р 53195.2),

- испытаний Е/Е/РЕ СБЗС-систем (5.7),

- документации пользователя и остальной документацией на систему.

5.18.9 Для верификации стадии проектирования и реализации Е/Е/РЕ СБЗС-систем после ее завершения и до начала следующей стадии (интеграции) проверка должна:

а) определить адекватность тестов для стадии проектирования и реализации Е/Е/РЕ СБЗС-систем (5.7);

б) определить связанность и завершенность (до уровня модулей, включительно) стадии проектирования и разработки Е/Е/РЕ СБЗС-систем (5.7) в отношении требований безопасности (5.5);

в) проверить на несовместимость:

- требования безопасности Е/Е/РЕ СБЗС-систем (5.5),

- результат проектирования и разработки Е/Е/РЕ СБЗС-систем (5.7),

- испытания Е/Е/РЕ СБЗС-систем (5.7).

Примечания

1 Методы подтверждения соответствия безопасности, анализа отказов и тестирования, приведенные в таблице Б.5 приложения Б, могут быть использованы также для верификации.

2 При верификации достижения необходимого охвата диагностикой Е/Е/РЕ СБЗС-систем следует учитывать отказы и ошибки, которые должны быть обнаружены (таблица А.1 приложения А).

5.18.10 Для верификации интеграции АС Е/Е/РЕ СБЗС-систем должна быть проверена интеграция Е/Е/РЕ СБЗС-систем для установления выполнения требований подраздела 5.14.

5.18.11 Все проверки и их результаты должны быть документированы.

6 Оценка функциональной безопасности

Требования к оценке функциональной безопасности Е/Е/РЕ СБЗС-систем - по ГОСТ Р 53195.2, раздел 8.

______________________________

* Для подсистемы, соответствующей требованиям, которые расцениваются как "проверено в эксплуатации" (5.12.6 - 5.12.12), требования 5.9.1 - 5.9.6 не применяют.

** Для подсистемы, соответствующей требованиям, которые расцениваются как "проверено в эксплуатации" (5.12.6 - 5.12.12), требования 5.10.1 - 5.10.3 не применяют.

Библиография

[1] ИСО 7240-16-2007

"Системы пожарной сигнализации. Часть 16. Управление звуковыми системами и средства индикации" (ISO 7240-16:2008 Fire detection and alarm systems - Part 16: Sound system control and indicating equipment)