Р 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).

FSSAs

SSA#

SSAs

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<о

примеры в приложении 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 рассмотрение все предъявляемые

From Wikipedia, the free encyclopedia

Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment

Abbreviation	ARP4761
Latest version	December 1996
Organization	SAE International
Domain	Aviation Safety
Website	www.sae.org/technical/standards/ARP4761

ARP4761, Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment is an Aerospace Recommended Practice from SAE International.^[1] In conjunction with ARP4754, ARP4761 is used to demonstrate compliance with 14 CFR 25.1309 in the U.S. Federal Aviation Administration (FAA) airworthiness regulations for transport category aircraft, and also harmonized international airworthiness regulations such as European Aviation Safety Agency (EASA) CS–25.1309.

This Recommended Practice defines a process for using common modeling techniques to assess the safety of a system being put together. The first 30 pages of the document covers that process. The next 140 pages give an overview of the modeling techniques and how they should be applied. The last 160 pages give an example of the process in action.

Some of the methods covered:

• Functional Hazard Assessment (FHA)
• Preliminary System Safety Assessment (PSSA)
• System Safety Assessment (SSA)
• Fault Tree Analysis (FTA)
• Failure Mode and Effects Analysis (FMEA)
• Failure Modes and Effects Summary (FMES)
• Common Cause Analysis (CCA), consisting of:
  • Zonal Safety Analysis (ZSA)
  • Particular Risks Analysis (PRA)
  • Common Mode Analysis (CMA)

Safety life cycle[edit]

The general flow of the safety life cycle under ARP4761 is:

1. Perform the aircraft level FHA in parallel with development of aircraft level requirements.
2. Perform the system level FHA in parallel with allocation of aircraft functions to system functions, and initiate the CCA.
3. Perform the PSSA in parallel with system architecture development, and update the CCA.
4. Iterate the CCA and PSSA as the system is allocated into hardware and software components.
5. Perform the SSA in parallel with system implementation, and complete the CCA.
6. Feed the results into the certification process.

The Functional Safety process is focused on identifying functional failure conditions leading to hazards. Functional Hazard Analyses / Assessments are central to determining hazards. FHA is performed early in aircraft design, first as an Aircraft Functional Hazard Analysis (AFHA) and then as a System Functional Hazard Analysis (SFHA). Using qualitative assessment, aircraft functions and subsequently aircraft system functions are systematically analyzed for failure conditions, and each failure condition is assigned a hazard classification. Hazard classifications are closely related to Development Assurance Levels (DALs) and are aligned between ARP4761 and related aviation safety documents such as ARP4754A, 14 CFR 25.1309, and Radio Technical Commission for Aeronautics (RTCA) standards DO-254 and DO-178B.

Hazard Classification	Development Assurance Level	Maximum Probability per Flight Hour
Catastrophic	A	10−9
Hazardous	B	10−7
Major	C	10−5
Minor	D	—
No Effect	E	—

FHA results are normally shown in spreadsheet form, with columns identifying function, failure condition, phase of flight, effect, hazard classification, DAL, means of detection, aircrew response, and related information. Each hazard is assigned a unique identifier that is tracked throughout the entire safety life cycle. One approach is to identify systems by their ATA system codes and the corresponding hazards by derivative identifiers. For example, the thrust reverser system could be identified by its ATA code 78-30. Untimely deployment of thrust reverser would be a hazard, which could be assigned an identifier based on ATA code 78-30.

FHA results are coordinated with the system design process as aircraft functions are allocated to aircraft systems. The FHA also feeds into the PSSA, which is prepared while the system architecture is developed.

The PSSA may contain qualitative FTA, which can be used to identify systems requiring redundancy so that catastrophic events do not result from a single failure (or dual failure where one is latent). A fault tree is prepared for each SFHA hazard rated hazardous or catastrophic. Fault trees may be performed for major hazards if warranted. DALs and specific safety design requirements are imposed on the subsystems. The safety design requirements are captured and traced. These may include preventive or mitigation strategies selected for particular subsystems. The PSSA and CCA generate separation requirements to identify and eliminate common mode failures. Subsystem failure rate budgets are assigned so that hazard probability limits can be met.

The CCA consists of three separate types of analyses which are designed to uncover hazards not created by a specific subsystem component failure. The CCA may be many separate documents, may be one CCA document, or may be included as sections in the SSA document. The Particular Risk Analysis (PRA) looks for external events which can create a hazard such as a birdstrike or engine turbine burst. The Zonal Safety Analysis (ZSA) looks at each compartment on the aircraft and looks for hazards that can affect every component in that compartment, such as loss of cooling air or a fluid line bursting. The Common Mode Analysis (CMA) looks at the redundant critical components to find failure modes which can cause all to fail at about the same time. Software is always included in this analysis as well as looking for manufacturing errors or «bad lot» components. A failure such as a bad resistor in all flight control computers would be addressed here. The mitigations for CMA discoveries is often DO-254 or DO-178B components.

The SSA includes quantitative FMEA, which is summarized into FMES. Normally FMES probabilities are used in quantitative FTA to demonstrate that the hazard probability limits are in fact met. Cutset analysis of the fault trees demonstrates that no single failure condition will result in a hazardous or catastrophic event. The SSA may include the results of all safety analysis and be one document or may be many documents. An FTA is only one method for performing the SSA. Other methods include dependence diagram or reliability block diagram and Markov Analysis.

The PSSA and CCA often result in recommendations or design requirements to improve the system. The SSA summarizes the residual risks remaining in the system and should show all hazards meet the 1309 failure rates.

The ARP4761 analyses also feed into Crew Alerting System (CAS) message selection and the development of critical maintenance tasks under ATA MSG3.

Future changes[edit]

In 2004, SAE Standard Committee S-18 began working on Revision A to ARP4761. When released, EUROCAE plans to jointly issue the document as ED–135.

See also[edit]

• ARP4754
• DO-254
• DO-178B
• Safety engineering
• avionics

References[edit]

Дата актуализации: 01.01.2021

Р 4761

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

Обозначение:	Р 4761
Обозначение англ:	R 4761
Статус:	Информационный документ
Название рус.:	Руководство 4761 по методам оценки безопасности систем бортового оборудования воздушных судов гражданской авиации
Дата добавления в базу:	01.01.2021
Дата актуализации:	01.01.2021
Область применения:	Документ содержит инструктивные материалы по проведению принятой в авиационной отрасли оценке безопасности, которая включает этапы Оценки функциональной опасности, Предварительной оценки безопасности системы и Оценки безопасности системы. В этом документе представлены инструктивные материалы, методы проведения оценки безопасности в обеспечение сертификации гражданского самолета. Методы, изложенные в нем, определяют упорядоченные способы, но не единственные способы, для достижения заданного.
Оглавление:	1 Область применения документа 2 Вспомогательные сведения 3 Процесс оценки безопасности 4 Аналитические методы оценки безопасности 5 Задачи и интервалы обслуживания, связанные с безопасностью 6 Ограниченная по времени отправки в рейс Приложение А. Оценка функциональной опасности Приложение В. Предварительная оценка безопасности системы Приложение С. Оценка безопасности системы Приложение D. Анализ дерева неисправности Приложение Е. Анализ логических схем Приложение F. Марковский анализ Приложение G. Анализ видов и последствий отказа Приложение Н. Сводка видов и последствий отказа Приложение I. Зонный анализ безопасности Приложение J . Анализ специфического риска Приложение К. Анализ общего режима Приложение L. Сопровождающий пример процесса оценки безопасности
Утверждён:	Межгосударственный авиационный комитет
Расположен в:	Техническая документация Экология АВИАЦИОННАЯ И КОСМИЧЕСКАЯ ТЕХНИКА Авиационные и космические аппараты в целом Строительство Справочные документы Директивные письма, положения, рекомендации и др.
Нормативные ссылки:	ГОСТ 27.002-89 «Надежность в технике. Основные понятия. Термины и определения»

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

Последняя версия	декабрь 1996 г. (1996-12)
Организация	Международный
Домен	Авиация
Аббревиатура	ARP4761
Веб-сайт	www .sae .org / Technical / стандарты / ARP4761

ARP4761, Руководящие указания и методы проведения процесса оценки безопасности гражданских бортовых систем и оборудования— это рекомендованная практика для аэрокосмической отрасли от SAE International. В сочетании с ARP4754, ARP4761 используется для демонстрации соответствия 14 CFR 25.1309 в правилах Федерального управления гражданской авиации США (FAA) летной годности для транспортной категории. самолет, а также согласованные международные правила летной годности, такие как Европейское агентство по безопасности полетов (EASA) CS – 25.1309.

Настоящая Рекомендуемая практика определяет процесс использования общих методов моделирования для оценки безопасности собираемой системы. Первые 30 страниц документа посвящены этому процессу. На следующих 140 страницах дается обзор методов моделирования и способов их применения. Последние 160 страниц представляют собой пример процесса в действии.

Некоторые из рассмотренных методов:

• Оценка функциональной опасности (FHA)
• Предварительная оценка безопасности системы (PSSA)
• Оценка безопасности системы (SSA)
• Анализ дерева отказов (FTA)
• Анализ видов и последствий отказов (FMEA)
• Сводка видов и последствий отказов (FMES)
• Анализ общих причин (CCA ), состоящий из:
  • анализа зональной безопасности (ZSA)
  • анализа особых рисков (PRA)
  • анализа стандартного режима (CMA)

Содержание

• 1 Безопасность жизненный цикл
• 2 Будущие изменения
• 3 См. также
• 4 Ссылки

Жизненный цикл безопасности

Общая последовательность жизненного цикла безопасности в соответствии с ARP4761:

1. Выполнение уровня воздушного судна FHA параллельно с разработкой требований к уровню воздушного судна.
2. Выполните FHA системного уровня параллельно с назначением функций воздушного судна системным функциям и инициируйте CCA.
3. Выполните PSSA параллельно с системой разработка архитектуры и обновление CCA.
4. Повторяйте CCA и PSSA как систему i s распределены между аппаратными и программными компонентами.
5. Выполняйте SSA параллельно с внедрением системы и завершайте CCA.
6. Внесите результаты в процесс сертификации.

Процесс функциональной безопасности сосредоточены на выявлении условий функционального отказа, ведущего к опасностям. Функциональные анализы / оценки опасностей имеют ключевое значение для определения опасностей. FHA выполняется на ранней стадии проектирования самолета, сначала как анализ функциональных опасностей самолета (AFHA), а затем как анализ функциональных опасностей системы (SFHA). Используя качественную оценку, функции воздушного судна, а затем и функции системы воздушного судна систематически анализируются на предмет условий отказа, и каждому условию отказа присваивается классификация опасности. Классификации опасностей тесно связаны с уровнями обеспечения разработки (DAL) и согласованы между ARP4761 и соответствующими документами по безопасности полетов, такими как ARP4754A, 14 CFR 25.1309 и стандарты Радиотехнической комиссии по аэронавтике (RTCA) DO -254 и DO-178B.

Классификация опасностей	Уровень обеспечения разработки	Максимальная вероятность на час полета
Катастрофическая	A	10
Опасная	B	10
Большая	C	10
Незначительное	D	—
Без эффекта	E	—

Результаты FHA обычно отображаются в форме электронной таблицы со столбцами, определяющими функцию, состояние отказа, фазу полета, последствия, классификацию опасности, DAL, средства обнаружения, реакции экипажа и сопутствующей информации. Каждой опасности присваивается уникальный идентификатор, который отслеживается на протяжении всего жизненного цикла безопасности. Один из подходов — идентифицировать системы по их системным кодам ATA, а соответствующие опасности — по производным идентификаторам. Например, система реверса тяги может быть идентифицирована по ее коду ATA 78-30. Несвоевременное развертывание реверсора тяги было бы опасностью, которой можно было бы присвоить идентификатор на основе кода ATA 78-30.

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

PSSA может содержать качественный FTA, который может использоваться для идентификации систем, требующих избыточности, чтобы катастрофические события не возникали в результате единичного отказа (или двойного отказа, если один из них является скрытым). Дерево отказов подготовлено для каждой опасности SFHA, классифицированной как опасная или катастрофическая. Если это необходимо, деревья отказов могут быть построены для основных опасностей. К подсистемам предъявляются DAL и особые проектные требования безопасности. Требования к конструкции безопасности фиксируются и отслеживаются. Они могут включать превентивные или смягчающие стратегии, выбранные для конкретных подсистем. PSSA и CCA генерируют требования к разделению для выявления и устранения общих отказов. Бюджеты интенсивности отказов подсистем назначаются таким образом, чтобы можно было соблюдать пределы вероятности опасности.

CCA состоит из трех отдельных типов анализа, предназначенных для выявления опасностей, не связанных с отказом конкретного компонента подсистемы. CCA может состоять из множества отдельных документов, может быть одним документом CCA или может быть включен в качестве разделов в документ SSA. Анализ особых рисков (PRA) ищет внешние события, которые могут создать опасность, например, столкновение с птицей или взрыв турбины двигателя. Анализ зональной безопасности (ZSA) изучает каждый отсек самолета и выявляет опасности, которые могут повлиять на каждый компонент в этом отсеке, такие как потеря охлаждающего воздуха или разрыв линии жидкости. Анализ общего режима (CMA) рассматривает избыточные критические компоненты, чтобы найти режимы отказа, которые могут вызвать сбой всех примерно в одно и то же время. Программное обеспечение всегда включается в этот анализ, а также в поиск производственных ошибок или компонентов «плохой партии». Здесь будет рассмотрен сбой, такой как неисправный резистор во всех компьютерах управления полетом. Смягчением для открытий CMA часто являются компоненты DO-254 или DO-178B.

SSA включает количественный анализ FMEA, который обобщается в FMES. Обычно вероятности FMES используются в количественном FTA, чтобы продемонстрировать, что пределы вероятности опасности действительно соблюдаются. Разрезанный анализ деревьев отказов показывает, что ни одно состояние отказа не приведет к опасному или катастрофическому событию. SSA может включать результаты всего анализа безопасности и представлять собой один или несколько документов. FTA — это только один из методов выполнения SSA. Другие методы включают диаграмму зависимости или блок-схему надежности и Марковский анализ.

. PSSA и CCA часто приводят к рекомендациям или проектным требованиям для улучшения системы. SSA суммирует остаточные риски, остающиеся в системе, и должен показать, что все опасности соответствуют 1309 интенсивностям отказов.

Анализ ARP4761 также используется для выбора сообщений системы оповещения экипажа (CAS) и разработки критических задач обслуживания в рамках ATA MSG3.

Будущие изменения

В 2004 году комитет по стандартизации SAE S-18 начал работу над редакцией A ARP4761. После выпуска EUROCAE планирует совместно выпустить документ как ED-135.

См. Также

• ARP4754
• DO-254
• DO-178B
• Техника безопасности
• авионика

Справочная информация