Часть 1    |    Часть 2    |    Часть 3

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

Примечания

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

     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.

Приложение А

(справочное)

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

А.1  Общие положения

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

Перечислить  каждую индивидуальную физическую причину отказов в сложных АС не представляется возможным по двум основным причинам:

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

-  при использовании сложных АС и ПО характер отказов изменяется в широком диапазоне - от случайных до систематических отказов.

Отказы  в Е/Е/РЕ СБЗС-системах могут быть разделены на две категории в зависимости от времени их возникновения:

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

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

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

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

По  аналогии таблицы А.16-А.18 содержат рекомендуемые меры (методы/средства) для управления систематическими отказами для каждого уровня полноты безопасности. В таблице А.16 рекомендуются полные меры для управления систематическими отказами. В таблице А.17 даны рекомендуемые меры по управлению отказами из-за влияния окружающей среды. В таблице А.18 приведены меры (методы/средства) по управлению ошибками при эксплуатации. Большинство этих мер по управлению систематическими отказами может быть структурировано в соответствии с таблицей А.19.

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

-  последовательность выбранных методов/средств и то, как они будут дополнять друг друга,

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

А.2  Полнота безопасности АС

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

Таблица А.1 - Ошибки и отказы, которые должны быть обнаружены в период эксплуатации или должны быть проанализированы при определении доли безопасных отказов

Таблица А.2 - Уровень охвата диагностикой электрических подсистем в зависимости от применяемых методов/средств диагностики

Таблица А.3 - Уровень охвата диагностикой электронных подсистем в зависимости от применяемых методов/средств диагностики

Таблица А.4 - Уровень охвата диагностикой устройств обработки в зависимости от применяемых методов/средств диагностики

Таблица А.5 - Уровень охвата диагностикой неизменяемых областей в зависимости от применяемых методов/средств диагностики

Таблица А.6 - Уровень охвата диагностикой переменных областей памяти в зависимости от применяемых методов/средств диагностики

Таблица А.7 - Уровень охвата диагностикой устройства входа/выхода и интерфейсов (внешняя связь) в зависимости от применяемых методов/средств диагностики

Таблица А.8 - Уровень охвата диагностикой маршрутизаторов данных (внутренняя связь) в зависимости от применяемых методов/средств диагностики

Таблица А.9 - Уровень охвата диагностикой источников питания в зависимости от применяемых методов/средств диагностики

Таблица А.10 - Уровень охвата диагностикой в зависимости от применяемых методов/средств диагностики последовательности выполнения программ (дежурного таймера)

Часть 1    |    Часть 2    |    Часть 3