Товары в корзине: 0 шт Оформить заказ
Стр. 1 

267 страниц

Купить Р 4761 — бумажный документ с голограммой и синими печатями. подробнее

Цена на этот документ пока неизвестна. Нажмите кнопку "Купить" и сделайте заказ, и мы пришлем вам цену.

Распространяем нормативную документацию с 1999 года. Пробиваем чеки, платим налоги, принимаем к оплате все законные формы платежей без дополнительных процентов. Наши клиенты защищены Законом. ООО "ЦНТИ Нормоконтроль"

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

Способы доставки

  • Срочная курьерская доставка (1-3 дня)
  • Курьерская доставка (7 дней)
  • Самовывоз из московского офиса
  • Почта РФ

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

 Скачать PDF

Оглавление

1 Область применения документа

2 Вспомогательные сведения

3 Процесс оценки безопасности

4 Аналитические методы оценки безопасности

5 Задачи и интервалы обслуживания, связанные с безопасностью

6 Ограниченная по времени отправки в рейс

Приложение А. Оценка функциональной опасности

Приложение В. Предварительная оценка безопасности системы

Приложение С. Оценка безопасности системы

Приложение D. Анализ дерева неисправности

Приложение Е. Анализ логических схем

Приложение F. Марковский анализ

Приложение G. Анализ видов и последствий отказа

Приложение Н. Сводка видов и последствий отказа

Приложение I. Зонный анализ безопасности

Приложение J . Анализ специфического риска

Приложение К. Анализ общего режима

Приложение L. Сопровождающий пример процесса оценки безопасности

 
Дата введения01.01.2021
Добавлен в базу01.01.2021
Актуализация01.01.2021

Этот документ находится в:

Организации:

УтвержденМежгосударственный авиационный комитет
Стр. 1
стр. 1
Стр. 2
стр. 2
Стр. 3
стр. 3
Стр. 4
стр. 4
Стр. 5
стр. 5
Стр. 6
стр. 6
Стр. 7
стр. 7
Стр. 8
стр. 8
Стр. 9
стр. 9
Стр. 10
стр. 10
Стр. 11
стр. 11
Стр. 12
стр. 12
Стр. 13
стр. 13
Стр. 14
стр. 14
Стр. 15
стр. 15
Стр. 16
стр. 16
Стр. 17
стр. 17
Стр. 18
стр. 18
Стр. 19
стр. 19
Стр. 20
стр. 20
Стр. 21
стр. 21
Стр. 22
стр. 22
Стр. 23
стр. 23
Стр. 24
стр. 24
Стр. 25
стр. 25
Стр. 26
стр. 26
Стр. 27
стр. 27
Стр. 28
стр. 28
Стр. 29
стр. 29
Стр. 30
стр. 30

МЕЖГОСУДАРСТВЕННЫЙ АВИАЦИОННЫЙ КОМИТЕТ АВИАЦИОННЫЙ РЕГИСТР

РУКОВОДСТВО 4761

по методам оценки безопасности систем и бортового оборудования воздушных судов гражданской авиации

СОДЕРЖАНИЕ

1.    Область применения документа..................................................................................................1

2.    Вспомогательные сведения.........................................................................................................2

3.    Процесс оценки безопасности......................................................................................................6

4.    Аналитические методы оценки безопасности..........................................................................11

5.    Задачи и интервалы обслуживания, связанные с безопасностью.........................................15

6.    Ограниченная по времени отправки в рейс..............................................................................16

ПРИЛОЖЕНИЕ А. Оиенка функциональной опасности..............................................................22

ПРИЛОЖЕНИЕ В. Предварительная оиенка безопасности системы .......................................30

ПРИЛОЖЕНИЕ С. Оценка безопасности системы ......................................................................34

ПРИЛОЖЕНИЕ D. Анализ дерева неисправности ......................................................................38

ПРИЛОЖЕНИЕ Е. Анализ логических схем .................................................................................76

ПРИЛОЖЕНИЕ F. Марковский анализ .........................................................................................79

ПРИЛОЖЕНИЕ G. Анализ видов и последствий отказа...........................................................100

ПРИЛОЖЕНИЕ Н. Сводка видов и последствий отказа ...........................................................109

ПРИЛОЖЕНИЕ I. Зонный анализ безопасности........................................................................112

ПРИЛОЖЕНИЕ J Анализ специфического риска .....................................................................116

ПРИЛОЖЕНИЕ К. Анализ общего режима ................................................................................118

ПРИЛОЖЕНИЕ L. Сопровождающий пример процесса оценки безопасности ......................125

Содержание Стр. 1/2

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

PSSA является итерационным анализом, входящим во все этапы разработки системы. Процесс PSSA начинается на ранних фазах проекта, когда функции уровня самолета и требования к ним распределяются на уровень систем. Требования уровня системы затем распределяются на составляющие ее объекты и. наконец, требования к объектам распределяются между аппаратным обеспечением и программным обеспечением. Распределение риска между объектами будет формировать требования к надежности аппаратного обеспечения и требования к гарантии разработки для аппаратных средств и программного обеспечения (смотри Руководство 4754). Эти требования и уровни гарантии вносятся в спецификации блоков.

PSSA должна выявлять отказы, приводящие к отказным состояниям определенным в FHA системы. Возможные содействующие факторы, приводящие к отказным состояниям, могут определяться применением FTA. DD. МА или других аналитических методов. Отказы аппаратных средств и возможные ошибки в аппаратных средствах/программном обеспечении, также как и отказы вызываемые общими причинами, должны быть включены в PSSA для выяснения их последствий и определения необходимых требований по безопасности к системе или объекту. Следует обратить внимание на возможные скрытые отказы и связанные с ними времена их воздействия.

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

В левой части Схемы оценки безопасности, приведенной на рис. 3 показана рекомендуемая последовательность этапов в процессе PSSA. Не все показанные этапы обязательны в каждой оценке, но необходимость каждого из них должна быть рассмотрена. Ниже описывается левая часть рис. 3. Отметим, что там. где указан FTA. его можно заменить эквивалентным анализом, таким как DD или МА.

У PSSA имеется две основные части исходных данных: данные FHA системы и данные FTA самолета. FHA системы раскрывает отказные состояния и их классификацию, необходимые для последующих этапов. FTA самолета определяет функциональные отказы, приводящие к этим состояниям. FTА самолета дополняется Анализом общих причин для разработки необходимых для FHA системы последствий отказов верхнего уровня. ССА также устанавливает требования к системе, которые необходимо реализовать в ее конструкции, такие как надежность, разделение и независимость функций.

ССА на уровне системы дополняет результаты FTA системы по формированию последствий отказа верхнего уровня для выполнения FTA на уровне блока системы. ССА блока аналогично дополняет FTA блока для дальнейшего установления требований к конструкции, уровню гарантии разработки, к аппаратным средствам и программному обеспечению. Полученные таким образом требования используются для описания проектных требований к аппаратным средствам, программному обеспечению отдельных объектов системы. Результаты PSSA будут определять последствия отказов аппаратных средств, последствия ошибок разработки аппаратных средств и программного обеспечения, показатели надежности и уровни гарантии разработки. В PSSA следует сформировать стратегии защиты и архитектуры, особенности необходимые для соответствия требованиям по безопасности.

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

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

Более подробно выполнение PSSA описано в Приложении В.

3.4 Оценка безопасности системы

Оценка безопасности системы является методической, всесторонней оценкой созданной системы для демонстрации соответствия относящимся к ней требованиям по безопасности. Процесс анализа системы подобен действиям PSSA. но отличается по назначению. Отличия между PSSA и SSA в том, что PSSA является методом оценки предполагаемых архитектур и разработки требований по безопасности к системе/объекту. тогда как SSA является верификацией того, что реализованный проект соответствует как качественным, так и количественным требованиям по безопасности, определенным в FHA и PSSA.

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

a.    Перечень одобренных ранее вероятностей внешних событий.

b.    Описание системы.

c.    Перечень отказных состояний (FHA, PSSA).

d.    Классификацию отказных состояний (FHA. PSSA).

e.    Качественный анализ отказных состояний (FTA, DD. FMES).

Г Количественный анализ отказных состояний (FTA. DD. МА. FMES).

д. Анализ общих причин.

h.    Связанные с обеспечением безопасности задачи и интервалы времени (FTA, DD. МА. FMES).

i.    Уровни гарантии разработки для аппаратных средств и программного обеспечения (PSSA).

j.    Верификацию того, что требования по безопасности из PSSA учтены в конструкции и/или в процессе испытаний.

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

В правой части Схемы процесса оценки безопасности (см. рис. 3) показана рекомендуемая последовательность этапов процесса SSA. Не все этапы могут потребоваться для каждой оценки, но каждый из них должен быть рассмотрен на применимость. Далее описывается показанное в правой части рис. 3. Отметим, что там, где показан FTA. он может быть заменен на эквивалентный аналитический метод оценки безопасности, такой как DD или МА.

Движение процесса SSA представлено последовательными уровнями верификации. Поднимаясь по этим иерархическим уровням верификации на соответствие требованиям по безопасности определенным в процессе выполнения PSSA, проверяются надежность элементов аппаратных средств, архитектурные требования, уровни гарантии разработки аппаратных средств и программного обеспечения. Нижний уровень конструкции оценивается также на соответствие производным требованиям. Для проверки соответствия реализации программного обеспечения требуемым, для определения того, что реализация программного обеспечения отвечает требуемым уровням гарантии разработки, следует использовать процедуры, изложенные в КТ-178. Заявителю следует установить соответствующие процедуры гарантии разработки аппаратных средств и согласовать их с Авиарегистром. Уровень гарантии разработки аппаратных средств проверяется на соответствие процедурам, изложенным в Руководстве 254.

Для расчета интенсивности отказов, видов отказов рассматриваемых в FTA/CCA уровня блока. выполняется FMEA уровня блока, результаты которого излагаются в FMES. Результаты FMEA уровня системы суммируются в FMES системы для подтверждения интенсивностей отказов видов отказов, которые рассмотрены в FTA системы. Система оценивается с использованием FTA/CCA

для выявления видов отказов и вероятностей, использованных в FTA уровня самолета. FTA’CCA уровня самолета применяется для установления соответствия отказным состояниям и вероятностям уровня самолета сравнением с результатами FHA уровня самолета. Как только объект введен в систему, а система внесена в конструкцию самолета, последствия отказов сравниваются с отказными состояниями, определенными в FHA. Это сравнение называется «перекрестная проверка интеграции».

Подробности выполнения SSA приведены в Приложении С.

3.5 Методы верификации, применяемые при сертификации самолетов

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

4 АНАЛИТИЧЕСКИЕ МЕТОДЫ ОЦЕНКИ БЕЗОПАСНОСТИ

4.1    Анализ дерева неисправности/Анализ логической схемы Марковский анализ

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

После определения отказных состояний в FHA, FTA/DD/MA могут использоваться как часть PSSA для определения тех единичных отказов или комбинаций отказов (если имеются) на нижних уровнях, которые могут вызывать каждое конкретное отказное состояние. При проведении FTA’DD/MA следует выполнять проверки, для гарантии того, что все отказные состояния со значащими последствиями рассматриваются в качестве базовых событий в FTA’DD/MA. Базовые события FTA’DD/MA получают их интенсивности отказов из FMEA и/или FMES.

Подробности выполнения FTA приведены в Приложении D. Подробности выполнения DD приведены в Приложении Е. Подробности выполнения МА приведены в Приложении F.

4.1.1    Применение FTA/DD/MA

Завершенности FTA/DD/MA содействуют технические и организационные оценки и рассмотрения. потому что в них определены только отказы, которые могут в отдельности или совместно приводить к возникновению нежелательного события верхнего уровня В противоположность этому FMEA рассматривает только единичные отказы, включая даже те. которые могут не иметь отношение к рассматриваемому состоянию.

FTA/DD/MA содействуют распределению событий уровня системы на события нижнего уровня для упрощения анализа.

FTA/DD/MA могут использоваться для:

a.    Назначения величины вероятности для события верхнего уровня.

b.    Оценки предполагаемых атрибутов архитектуры системы для установления бюджетов надежности аппаратных средств и уровней гарантии разработки для аппаратных средств и программного обеспечения в процессе PSSA.

c.    Рассмотрения влияния изменений конструкции.

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

e.    Доказательства соответствия качественным и/или количественным целям безопасности при выполнении SSA.

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

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

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

DD для демонстрации связи отказов заменяет на схеме логические символы FTA на трассы. Параллельные трассы эквивалентны И-символу, а последовательные трассы эквивалентны ИЛИ-символу.

МА рассчитывает вероятность нахождения системы в различных состояниях как функцию времени. Состояние в модели представляет статус системы в качестве функции дерева отказа, поврежденных компонент и резервирования систем. Переход из одного состояния в другое происходит с заданной скоростью перехода, которая определяет интенсивности отказов компонент и резервирование. Система изменяет состояние вследствие различных событий таких, как отказ компоненты, реконструкция после обнаружения отказа, завершения восстановления и т.д. Каждое изменение состояния является случайным процессом, который представляется отдельным функциональным уровнем. Дифференциальная природа модели ограничивает в ходе анализа вычисления 8 любой точке до вероятности перехода из одного определенного состояния в другое состояние. Вероятность достижения определенного конечного состояния может быть вычислена по комбинации переходов, необходимых для достижения этого состояния.

4.1.2    Программное обеспечение в FTA DD МА

Применяемое в некоторых системах и объектах программное обеспечение может в качественной форме рассмотрено в FTA'DD/MA В частности FTA'DD/MA может быть необходимым для обеспечения адекватной аналитической видимости проблем безопасности ПО в сложных системах, особенно когда доверие основано на следующих атрибутах безопасности:

a.    Системы и объекты, которые обеспечивают необходимую защиту при ошибках ПО (Защита может обеспечиваться как с помощью другого ПО или только аппаратурой).

b.    Системы и блоки, в которых ПО обеспечивает необходимую защиту от ошибок в аппаратных средствах и при отказах в аппаратуре.

c.    Системы и блоки, в которых ПО обеспечивает защиту от скрытых отказов аппаратуры.

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

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

4.1.3    Вероятность среднего времени воздействия

При проведении количественного FTA'DD/MA вероятности оцениваются по интенсивностям отказов и времени воздействия событий. Расчеты вероятности при сертификации гражданских самолетов основываются на средних вероятностях рассчитанных для всех самолетов одного типа. Для цели таких анализов обычно предполагается, что интенсивность отказов постоянная во времени и определяется по достаточно надежным интенсивностям отказов после начальной тренировки до наступления износа. Если рассматриваются интервалы, включающие износ и начальную «тренировку», то следует использовать другие методы, например, ограничение

ресурса или улучшение производства. При этом следует применить другие функции распределения (например. Вейбула) или использовать моделирование методом Монте-Карло. Но это остается за пределами целей настоящего документа. В этих анализах (FTA/DD/MA) следует рассчитывать среднюю вероятность возникновения отказного состояния за час полета, при типовой средней продолжительности полета и рассматривая относящие времена воздействия и риски. Более подробное обсуждение точного определения времени воздействия и риска содержится в Приложениях D и F.

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

4.2    Анализ видов и последствия отказов

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

Назначение FMEA следует координировать с использующим его потребителем. Анализ может быть поэлементным или функциональным. Если интенсивность отказов, полученная при использовании функционального FMEA, обеспечивает соответствие бюджету вероятностей PSSA, то поэлементный FMEA может не потребоваться. Обычно FMEA содержит следующую информацию:

a.    Определение компоненты, сигнала и/или функции.

b.    Виды отказов и соответствующие интенсивности отказов аппаратных средств (численные или по категориям).

c.    Последствия отказа (непосредственные или на следующий более высокий уровень).

d.    Обнаруживаемость и методы обнаружения.

FMEA может также содержать следующую информацию:

a.    Парирующие действия (т е. автоматические или ручные).

b.    Фазы полета на которых возникает отказ.

c.    Серьезность последствий отказа.

FMEA может использоваться совместно с вероятностными методами, такими как FTA и DD. для получения количественного анализа. Кроме того. FMEA может использоваться для дополнения FTADD выявлением, при выполнении его снизу-вверх, дополнительного перечня последствий отказов.

Подробности выполнения FMEA приведены в Приложении G.

4.3    Сводка видов и последствий отказов

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

Кроме того. FMES следует координировать с потребителями для адекватного обращения к необходимым исходным данным для FMES более высокого уровня и/или FTA этапа оценки безопасности системы.

Подробности выполнения FMES приведены в Приложении Н.

4.4 Анализ общих причин

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

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

Анализ безопасности должен особо уделить внимание изучению неисправностей с общей причиной.

ССА подразделяется на три типа:

a.    Анализ зонной безопасности.

b.    Анализ специфического риска.

c.    Анализ общего режима.

4.4.1    Анализ зонной безопасности

Анализ следует выполнять для каждой зоны самолета. Целью анализа является получение гарантий, что размещение оборудования отвечает требованиям по безопасности в отношении следующего:

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

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

c.    Ошибки обслуживания (следует рассмотреть ошибки эксплуатационного размещения и их последствия).

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

Подробности выполнения ZSA приводятся в Приложении I.

4.4.2    Анализ специфического риска

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

Типичные риски включают, но не ограничиваются следующим:

a.    Пожар.

b.    Устройства с высокой энергией.

c.    Утечка жидкости.

d.    Град. снег, дождь.

e.    Столкновение с птицей.

1. Обрыв протектора от шины.

д. Разрыв обода колеса.

Руководство 4761_

h.    Удар молнии.

i.    Радио поля высоких энергий.

j.    Расцепление валов.

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

Целью анализа является получение гарантии, что любой связанный с безопасностью эффект устраним или его риск {вероятность) приемлем.

Подробности выполнения PRA приведены в Приложении J.

4.4.3 Анализ общего режима

Анализ выполняется для проверки того, что И-события в FTA'DD и МА являются независимыми в существующей реализации. Анализируются воздействия ошибок проектирования, производства, обслуживания и отказы компонент систем, которые разрушают такие независимости. Следует рассматривать независимость функций и их средств контроля. Объекты с одинаковыми аппаратными средствами и/или программным обеспечением могут быть чувствительны к возникновению отказов, которые могут вызывать нарушения функций во многих объектах.

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

a.    Ошибка в аппаратуре.

b.    Ошибка в ПО.

c.    Отказ в аппаратуре.

d.    Брак производства/ремонта.

e.    Нагрузки, связанные с ситуацией (т е. аномальные условия полета или аномальные конструкции системы).

f.    Ошибка размещения.

д. Ошибка в требованиях.

h.    Факторы внешней среды (т.е. температура, вибрация, влажность и т.д.).

i.    Каскадные отказы.

j.    Отказы общего внешнего источника.

Подробности выполнения СМА приводятся в Приложении К.

5 ЗАДАЧИ И ИНТЕРВАЛЫ ОБСЛУЖИВАНИЯ. СВЯЗАННЫЕ С БЕЗОПАСНОСТЬЮ

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

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

Интервалы времени и задачи обслуживания, которые определяются в ходе PSSA и SSA с использованием РТА. DD. МА или других подобных анализов, являются предполагаемыми сертификационными требованиями обслуживания. Когда выявление отказов связано с задачей обслуживания самолета, интервалы времени для соответствия цели безопасности должны быть направлены в соответствующее подразделение обслуживания для реализации требуемых процедур и периодов времени. Некоторые проверки обслуживания, связанные с удовлетворением требований по безопасности, могут быть назначенными сертификационными требованиями

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

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

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

В процессе разработки CMR могут проверяться пути проявления отказа с использованием критерия «следующий отказ» (т.е., что наиболее серьезное может произойти, если произойдет первый отказ).

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

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

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

6 ОГРАНИЧЕННАЯ ПО ВРЕМЕНИ ОТПРАВКИ В РЕЙС

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

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

Ниже рассмотрен пример применения этой концепции к двигателю. В принципе это может применяться к любой системе, которая проектируется с использованием резервирования.

6.1 Применение к FADEC

Концепция применяется в двухканальной системе FADEC с позиций отказного состояния в виде потери тяги одного двигателя.

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

Более подробно о методах для определения интервалов времени, в течение которого самолет может быть отправлен в рейс указано в соответствующем документе SAE. Этот документ будет описывать использование МА и аналитических расчетов для определения периодов времени в течение которых самолет может вылетать с известными неисправными блоками системы управления двигателем. (Примечание. Методы описаны в документе ARP 5W7A от 2005 01).

Типоной цикл разработки

I роГмилип»    Прчхлпфондиис

IknUIVIM


Концепции разработки

Уровень СИСГСМЫ

Детальное

■ ‘ ВеркниН уровень

Функции системы

‘проекткропание

Самоястмыс функции

Архитектура системы

Уровень полсмстемм

Самолеты арчиiскора Самолетные требовании

< истеммие требования

1 Кирибмые ф> пинии Подробные требования

1 т

.

Валидация и п*<’“

верификации

конструкции

План HOtMiaMiiA'ana.iiti

опетм


FIIA самолета

FIIA системы

-функции

- функции

- опасность

- опасность

последетьми

последствия

- классификация

- классификация


FSSAs


SSA#


FTА самолета

качестнемими

-    6КДО0СТ снс теми

-    внутрисистемные елям»


FHAs системы

-    я-ячсствсиный

-    бюджет системы

-    опеке» бетоюсиосга системы


FMEAl/FMES

системы


ТТЛ» т метены

- количественный частота откатал


SSAs


Анализ специфического риска

Анализ общего режима

Анализ зонной безопасности


Процесс оценки безопасности


Обзор процесса оценки безопасности Рис. 1


Таблица 1 Последствия отказных состояний в зависимости от величины вероятности и уровня гарантии качества разработки

1 ОБЛАСТЬ ПРИМЕНЕНИЯ ДОКУМЕНТА

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

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

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

1.1    Назначение документа

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

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

1.2    Ожидаемая аудитория

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

1.3    Как применять этот документ

Инструктивные материалы и методы документа предназначены для использования с другими руководящими документами, к которым относятся P-4754. КТ-178В. РМ-25.1309 (для изделий применяемых в двигателях и винтах следует обращаться к соответствующим Рекомендательным Материалам).

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

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

Примечание: Приложения не являются отдельными документами. Они предназначены для использования вместе с основной частью документа. Читателям не рекомендуется использовать приложения независимо от основной части документа. Более того,

Пример взаимосвязи FHA и FTATMEA

Рис. 2

Руководство 4761



примеры в приложении L "Сопровождающий пример..." не следует использовать без обращения к соответствующим приложениям и основной части этого документа.

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

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

1.4 Отличия данного документа от ARP 4761

Настояший документ следует рассматривать как технический перевод документа SAE ARP 4761 “Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment”.

В документе сохранены все разделы и подразделы документа ARP 4761.

Раздел 1 дополнен настоящим подразделом.

Подраздел 2.1 содержит ссылки на документы, аналогичные указанным в ARP 4761.

Подраздел 2.2 содержит ряд определений гармонизированных с применяемыми в Руководстве 4754 и Руководстве 254.

Подраздел 2.3 сохранил оригинальную аббревиатуру ряда терминов.

В таблице 1 основной части документа указаны термины и определения АР МАК.

2 ВСПОМОГАТЕЛЬНЫЕ СВЕДЕНИЯ

2.1    Применимые документы

Следующие документы расширяют здесь изложенное:

Руководство 4754 (рабочее название документа).

Руководство 254 (рабочее название документа).

Рекомендательный материал 25.1309 (рабочее название документа). Квалификационные требования КТ-178В.

2.2    Определения

Примечание: Приведенные ниже определения распространяются на термины, используемые в этом документе.

Авиарегистр (Certification authority) - Компетентный орган Межгосударственного авиационного комитета.

Анализ (Analysis) - Оценка, основанная на разложении на простые элементы.

Анализ общих причин (Common cause analysis) - Родовой термин, охватывающий Анализ безопасности зон. Анализ специфического риска и Анализ общего режима.

Аппаратное обеспечение (Hardware) - Физически существующий объект. Применяется, в основном, в отношении блоков, плат, источников питания и т.д.

Валидация (Validation) - Определение того, что требования к продукту достаточно полны и точны.

Верификация (Verification) - Оценка реализации для определения соответствия предъявленным требованиям.

Вид отказа (Failure mode) - Признак проявления отказа объекта.

Власть (Authority) - Организация или лицо уполномоченное Государством для проведения сертификации на соответствие применяемым требованиям.

Время воздействия (Exposure time) - Интервал времени между наиболее поздним моментом. когда было известно о правильном функционировании и моментом, когда снова будет известно о правильном функционировании.

Гарантия (Assurance) - Планируемые и систематические действия, необходимые для обеспечения достаточной степени доверия к тому, что продукт или процесс удовлетворяет данным требованиям.

Гарантия разработки (Development assurance) - Все те планируемые и систематические действия, которые используются для доказательства адекватного уровня доверия к тому, что ошибки разработки выявлены и исправлены так. что система удовлетворяет применимому сертификационному базису.

Доступность (Availability) - Вероятность того, что объект находится в работоспособном состоянии в данном месте в данное время.

Демонстрация (Demonstration) - Метод доказательства соответствия характеристик через наблюдение.

Интервал риска ("At risk" time) - Период времени, в течение которого объект может отказать с возникновением интересующих последствий отказа. Это обычно связано с конечной неисправностью в последовательности неисправностей, ведущей к конкретному отказному состоянию.

Интенсивность отказов (Failure rate) - Производная функции распределения вероятности отказа деленная на функцию распределения надежности к моменту времени t. A(t)=F (t)/(1-F(t)). Если функция распределения вероятности отказа является экспоненциальной, то интенсивность отказов является константой и интенсивность отказов может быть приблизительно определена как отношение числа отказов в рассматриваемом множестве аппаратных объектов на общее число часов эксплуатации. Отметим, что интенсивность отказов может также выражаться в таких единицах, как вероятность на час полета или вероятность на цикл.

Инструктивные материалы (Guidelines) - Рекомендуемые процедуры для достижения соответствия нормативам.

Инспекция (Inspection) - Проверка объекта на соответствие определенному стандарту.

Интеграция (Integration) - (1) Действие, позволяющее элементам объекта работать вместе. (2) Действие по объединению нескольких отдельных функций в одну реализацию.

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

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

Летная годность (Airworthiness) - (1) Характеристика образца авиационной техники, которая обеспечивается реализацией норм летной годности в его конструкции, параметрах и летных качествах. (2) Состояние объекта (самолета, системы самолета или его компонента) в котором он безопасно работает, выполняя назначенные функции.

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

Неисправность (Fault) - Нежелаемая аномалия объекта или системы.

Независимость (Independence) - (1) Подход к проектированию, который гарантирует, что отказ одного объекта не вызовет отказ другого объекта. (2) Разделение ответственности, которое гарантирует надлежащую объективность оценки.

Неправильное выполнение функции (Malfunction) - Возникновение условий, когда действия выполняются за установленными пределами.

Новизна (Novelty) - Применяется к системам, использующим новые технологии или к системам. в которых используется обшепринятая технология ранее не использованная в отношении решения конкретного вопроса.

Оценка функциональной опасности (Functional hazard assessment) - Систематическая всесторонняя проверка функций для определения и классификации отказных состояний.

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

Ошибка разработки (Development error) - Ошибка в определении требований или в проекте.

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

Общая причина (Common cause) - Событие или отказ, которые обходят или делают недейственными резервирование или независимость.

Отказ общего режима (Common mode failure) - Событие, которое воздействует на несколько элементов, которые в других отношениях рассматриваются независимыми.

Одобрение (Approval) - Акт формального разрешения применения, который выполняется Авиарегистром.

Одобрено (Approved) - Принято Авиарегистром как годное для конкретного использования.

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

Отказное состояние (Failure condition) - Состояние, возникающее вследствие прямого или косвенного воздействия на самолет или пассажиров в результате одного или более отказов, неправильной эксплуатации или воздействия окружающей среды. Отказное состояние приводит к возникновению особой ситуации, классифицируемой по серьезности ее последствий в соответствии с КТ-178В.

Объект (Item) - Один или несколько аппаратных или программных элементов рассматриваемых как целое.

Оценка (Assessment) - Определение характеристик, основанное на техническом здравом смысле.

Отделение (Segregation) - Обеспечение независимости средствами физического барьера между двумя аппаратными компонентами.

Оценка безопасности системы (System safety assessment) Систематическая, всесторонняя проверка реализованной системы для установления удовлетворения относящихся требований по безопасности.

Предположения (Assumption) - Выражения, принципы и/или предпосылки, предлагаемые без доказательства.

Повреждение (Defect) - Состояние объекта, в котором имеется невыполнение заданных требований к характеристикам объекта. Повреждение может, но не обязательно, приводить к отказу.

Производные требования (Derived requirements) - Дополнительные требования, возникающие при проектировании или реализации решений во время процесса разработки. Производные требования не являются прямо трассируемыми к требованиям более высокого уровня Несмотря на это. производные требования могут воздействовать на требования более высокого уровня.

Проект (Design) - Результат процесса проектирования.

Процесс проектирования (Design process) - Процесс создания системы или объекта из набора требований.

Последствие отказа (Failure effect) - Описание работы системы или блока после возникновения отказа, то есть указание последствий вида отказа на режим, функцию или состояние системы или объекта.

Предварительная оценка безопасности системы (Preliminary system safety assessment) -Систематическая оценка предполагаемой архитектуры и реализации системы, основанная на Оценке функциональной опасности и классификации отказных состояний, для определения требований по безопасности ко всем объектам.

Продукт (Product) - Объект, создаваемый на основе определенного набора требований.

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

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

Процесс оценки безопасности системы (System safety assessment process) - Полный процесс. применяемый при проектировании системы для установления целей безопасности и демонстрации соответствия требованиям параграфа 25.1309 и другим связанным с безопасностью требованиям.

Реализация (Implementation) - Действия по созданию физической сущности на основе спецификации.

Разделение (Separation) - Обеспечение независимости средствами физического удаления двух аппаратных компонентов.

Резервирование (Redundancy) - Множество независимых средств объединенных для выполнения данной функции.

Риск (Risk) - вероятность возникновения и связанный уровень опасности.

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

Сложность (Complexity) - Атрибут систем или объектов, который делает трудным понимание их работы. Увеличение сложности системы часто вызвано такими объектами, как нечетко определенные компоненты и множественные взаимосвязи.

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

Согласованность (Conformity) - Взаимное согласие физической реализации объекта и определяющим реализацию документом.

Событие (Event) - Происшествие, которое имеет свою исходную причину вне самолета, такую как атмосферные условия (например, порывы ветра, изменение температуры, обледенение. удары молнии), состояние ВПП. пожар в салоне или в багажном отсеке. Это определение, как оно дано здесь, описывает «внешнее событие». Имеются другие использования термина «событие», которые рассматривают другие аспекты.

Скрытый отказ (Latent failure) - Отказ, который при возникновении не обнаруживается и/или не сигнализируется.

Спецификация (Specification) - Набор требований, когда берутся вместе, то устанавливают критерии, определяющие функции и атрибуты системы или объекта.

Система (System) - Набор взаимодействующих объектов, предназначенный для выполнения конкретных функций.

Требование (Requirement) - Отдельный элемент спецификации, который может быть подтвержден и на соответствие которому может быть проверена реализация.

Уполномоченный орган (Authority) - Организация или лицо уполномоченной Государством для проведения сертификации на соответствие применяемым требованиям.

Функция (Function) - Внешнее проявление свойств какого-либо объекта в данной системе отношений.

Функция обмена (Exchanged function) - Взаимозависимость между функциями.

Примечание: Термины и определения в области надежности приведены в ГОСТ 27.002-89.

2.3 Сокращения

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

PSSA    Предварительная оценка безопасности системы

SSA    Оценка безопасности системы

FTA    Анализ дерева неисправности

DD    Анализ логической схемы

FMEA    Анализ видов и последствий отказа

FMES    Сводка видов и последствий отказов

ССА    Анализ общих причин

ZSA    Анализ зонной безопасности

PRA    Анализ специфического риска

СМА    Анализ общего режима

РМ    Рекомендательный материал

МА    Марковский анализ

CMR    Сертификационные требования по обслуживанию

FADEC    Полностью цифровая система управления двигателем

TLD    Ограниченная по времени отправка в рейс

3 ПРОЦЕСС ОЦЕНКИ БЕЗОПАСНОСТИ

3.1 Обзор оценки безопасности

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

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

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

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

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

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

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

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

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

Оценка безопасности системы является упорядоченной, подробной оценкой реализованной системы для демонстрации того, что цели безопасности определенные в FHA и производные требования по безопасности определенные в PSSA удовлетворяются. SSA обычно основана на FTA, рассматриваемом при выполнении PSSA (может быть использован DD или МА) и использует численные значения, полученные из FMES. В SSA следует проверить, что все значимые проявления отказов, содержащиеся в FMES. рассмотрены на предмет включения в качестве первичных событий в FTA. FMES обобщает отказы, выявленные в FMEA. группируя отказы с учетом их последствий. SSA должна включать относящиеся результаты Анализа общих причин.

Архитектура любой системы устанавливает ее структуру и ограничения, в пределах которых реализуется конкретный проект системы. Анализ общих причин помогает разработать архитектуру конкретной системы и архитектуру сопряженных систем с использованием оценки чувствительности всех архитектур к событиям общей причины. Такие события общей причины оцениваются при выполнении следующих видов анализа: Анализа специфического риска. Анализа зонной безопасности и Анализа общего режима. Результаты Анализа общей причины выполняемого на уровне самолета, рассматриваются в PSSA и SSA каждой системы.

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

Анализ логических схем принципиально эквивалентен FTA и выбор одного из них определяется предпочтением выполняющего анализ специалиста. Методы Марковского анализа часто применяются при рассмотрении различных сценариев обслуживания. В Приложениях D, Е и F перечисляются преимущества использования FTA, DD и МА соответственно.

В процессе оценки безопасности используются не только количественные показатели. В нем рассматриваются такие качественные вопросы как уровни гарантии качества разработки.

поля радиопомех высокой энергии, удары молний и т.п. Многое из этого включено в Анализ общих причин (Приложения I. J и К).

Процесс анализа безопасности завершается, когда результаты SSA верифицированы с материалами FHA уровня системы и самолета.

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

Оценка функциональной опасности определяется как упорядоченное всестороннее исследование функций для выявления и классификации их отказных состояний в соответствии со степенью опасности. FHA обычно выполняется на двух уровнях. Эти два уровня анализа известны как FHA уровня самолета и FHA уровня системы.

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

FHA уровня системы также является качественной оценкой, которая выполняется итерационно и становится более точной и основательной с развитием системы. В ней рассматриваются отказы и комбинации отказов системы, которые влияют на функции уровня самолета. Оценка любого конкретного объекта программного или аппаратного обеспечения не является задачей FHA уровня системы. Однако если в отдельных системах используются подобные архитектурные решения или одинаковые сложные компоненты, а также если вводятся дополнительные отказные состояния уровня системы, то FHA следует видоизменить для выявления и классификации таких новых отказных состояний. Уровень гарантии разработки функций уровня самолета зависит от степени опасности видов отказов или ошибок разработки этих функций для самолета. экипажа или пассажиров. Уровень гарантии разработки каждого объекта зависит как от архитектуры системы, так и от конечных отказных воздействий объекта на выполняемые системой функции.

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

Результаты FHA уровня самолета и/или уровня системы являются отправной точкой для создания и распределения требований по безопасности. Средством создания требований более низкого уровня может служить FTA (DD или МА) на основании материалов FHA (дерево неисправности уровня самолета на основе FHA уровня самолета и дерево неисправности PSSA на основе FHA системы). Эти производные требования следует взять в качестве требований в спецификации самолета и систем. Рис. 2 показывает обшую взаимосвязь между FHA/FTA/FMEA. На рисунке показан пример того, как FHA создает события верхнего уровня для FTA. Рисунок поясняет как количественные результаты из FMEA и FTA возвращаются в FTA уровня системы и уровня самолета для демонстрации соответствия численным значениям требований по безопасности из FHA.

Детали выполнения FHA приведены в Приложении А.

3.3    Предварительная оценка безопасности системы

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