Национальный стандарт РФ ГОСТ Р 27.303-2021 (МЭК 60812:2018) "Надежность в технике. Анализ видов и последствий отказов" (утв. и введен в действие приказом Федерального агентства по техническому регулированию и метрологии от 21 сентября 2021 г. N 987-ст)

Национальный стандарт РФ ГОСТ Р 27.303-2021 (МЭК 60812:2018)
"Надежность в технике. Анализ видов и последствий отказов"
(утв. и введен в действие приказом Федерального агентства по техническому регулированию и метрологии от 21 сентября 2021 г. N 987-ст)

Dependability in technics. Failure modes and effects analysis

УДК 62-192:658.51.011:658.562:623:006.354
ОКС 03.120.01,
03.120.30,
21.020

Дата введения - 1 января 2022 г.
Взамен ГОСТ Р 51901.12-2007 (МЭК 60812:2006)

ГАРАНТ:

Курсив в тексте не приводится

Предисловие

1 Подготовлен Закрытым акционерным обществом "Научно-исследовательский центр контроля и диагностики технических систем" (ЗАО "НИЦ КД") на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4

2 Внесен Техническим комитетом по стандартизации ТК 119 "Надежность в технике"

3 Утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 21 сентября 2021 г. N 987-ст

4 Настоящий стандарт является модифицированным по отношению к международному стандарту МЭК 60812:2018 "Анализ видов и последствий отказов (FMEA и FMECA)" (IEC 60812:2018 "Failure modes and effects analysis (FMEA and FMECA)", MOD) путем внесения технических отклонений, которые выделены в тексте курсивом.

Международный стандарт разработан Техническим комитетом МЭК 56.

Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ Р 1.5-2012 (пункт 3.5).

Сведения о соответствии ссылочных национальных стандартов международным стандартам, использованным в качестве ссылочных в примененном международном стандарте, приведены в дополнительном приложении ДА

5 Взамен ГОСТ Р 51901.12-2007 (МЭК 60812:2006)

Введение

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

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

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

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

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

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

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

a) описания принципов анализа;

b) рассмотрения этапов анализа;

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

d) представления примеров применения метода.

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

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

Основными пользователями настоящего стандарта являются руководители и участники анализа.

В настоящем стандарте ссылки на международные стандарты заменены ссылками на межгосударственные и национальные стандарты.

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

В настоящем стандарте приведено описание планирования, выполнения, документирования и поддержки применения метода анализа видов и последствий отказов (FMEA), включая анализ видов, последствий и критичности отказов (FMECA).

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

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

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

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

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

ГОСТ ISO 13849-1-2014 Безопасность оборудования. Элементы систем управления, связанные с безопасностью. Часть 1. Общие принципы конструирования

ГОСТ 27.002 Надежность в технике. Термины и определения

ГОСТ Р 22.0.12-2015 Безопасность в чрезвычайных ситуациях. Международные термины и определения

ГОСТ Р 27.013 Надежность в технике. Методы оценки показателей безотказности

ГОСТ Р 27.302 Надежность в технике. Анализ дерева неисправностей

ГОСТ Р 27.606 Надежность в технике. Управление надежностью. Техническое обслуживание, ориентированное на безотказность

ГОСТ Р 55.0.01 Управление активами. Национальная система стандартов. Общее представление, принципы и терминология

ГОСТ Р 51897 Менеджмент риска. Термины и определения

ГОСТ Р 51901.14 Менеджмент риска. Структурная схема надежности и булевы методы

ГОСТ Р 57273 Устойчивое развитие производственных сетей. Общие положения

ГОСТ Р ИСО 31000 Менеджмент риска. Принципы и руководство

ГОСТ Р ИСО/МЭК 31010 Менеджмент риска. Методы оценки риска

ГОСТ Р МЭК 61165 Надежность в технике. Применение марковских методов

ГОСТ Р МЭК 61508-1 Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 1. Общие требования

ГОСТ Р МЭК 61508-2 Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 2. Требования к системам

ГОСТ Р МЭК 61508-3 Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 3. Требования к программному обеспечению

ГОСТ Р МЭК 61508-4 Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 4. Термины и определения

ГОСТ Р МЭК 61508-5 Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 5. Рекомендации по применению методов определения уровней полноты безопасности

ГОСТ Р МЭК 61508-6 Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 6. Руководство по применению ГОСТ Р МЭК 61508-2 и ГОСТ Р МЭК 61508-3

ГОСТ Р МЭК 61508-7 Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 7. Методы и средства

ГОСТ Р МЭК 62061 Безопасность оборудования. Функциональная безопасность систем управления электрических, электронных и программируемых электронных, связанных с безопасностью

ГОСТ Р МЭК 62502 Менеджмент риска. Анализ дерева событий

ГОСТ Р МЭК 62508 Менеджмент риска. Анализ влияния на надежность человеческого фактора

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

3 Термины, определения и сокращения

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

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

3.1.1 вид отказа (failure mode): Способ и особенности возникновения отказа ¹⁾.

------------------------------

¹⁾_{См. также ГОСТ 27.002.}

------------------------------

Примечания

1 Вид отказа может представлять собой нарушение функции или ее утрату или другое изменение состояния.

2 Видами отказа оборудования могут быть, например: для клапана - "клапан не открывается" или для двигателя - "двигатель не запускается".

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

3.1.2 последствия отказа (failure effect): Результаты воздействия отказа на объект (явления, процессы, события и состояния) внутри или вне границ отказавшего объекта.

Примечания

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

2 Последствия отказа также охватывают последствия внутри или вне границ отказавшего процесса.

3.1.3 система (system): Набор взаимодействующих элементов, сформированный для достижения одной или нескольких поставленных целей ¹⁾.

------------------------------

¹⁾_{См. также [2].}

------------------------------

Примечания

1 Систему иногда рассматривают как объект или как предоставляемые услуги.

2 На практике значение этого термина часто разъясняется с помощью ассоциативного существительного, например система летательного аппарата. Слово "система" часто опускают, используя синоним; например, вместо термина "система летательного аппарата" используют термин "самолет", хотя он не подчеркивает то, что объект является системой.

3.1.4 объект (item): Любая часть, элемент, устройство, подсистема, функциональная единица, аппаратура или система, рассматриваемые самостоятельно.

Примечания

1 Объект может быть отдельной деталью, компонентом, устройством, функциональным блоком, оборудованием, подсистемой или системой.

2 Объект может представлять собой аппаратное обеспечение, программное обеспечение, персонал или любую их комбинацию.

3 Объект часто состоит из элементов, каждый из которых может быть рассмотрен отдельно.

4 В [1] введен в качестве английского синонима термин "сущность", который не всегда может быть применен.

5 Определение в [1] больше похоже на описание. В настоящем стандарте использован термин "объект". Определение термина по [1] приведено в качестве примечания 1.

3.1.5 процесс (process): Совокупность взаимосвязанных и/или взаимодействующих действий, преобразующих входы в выходы.

3.1.6 иерархический уровень (hierarchy level): Уровень деления системы, объекта или процесса на составные части в соответствии с их структурой.

Примечания

1 Иерархический уровень также называют контрактным уровнем (см. [1]).

2 Верхний и нижний иерархические уровни соответствуют верхнему и нижнему уровням структуры системы соответственно. Средний иерархический уровень соответствует одному из уровней между высшим и низшим уровнями.

3.1.7 элемент (element): Неделимая (в соответствии с иерархической структурой) часть системы, объекта или процесса, для которой должны быть идентифицированы виды отказов ²⁾).

------------------------------

²⁾_{См. также ГОСТ 27.002.}

------------------------------

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

Примечания

1 Ситуации и обстоятельства могут включать действия или факторы вне границ исследуемого объекта или процесса, которые могут повлиять на работу объекта или процесса.

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

3 Организационные ситуации и обстоятельства включают такие факторы, как уровень квалификации, физические и психологические нагрузки персонала.

3.1.9 причина отказа (failure cause): Совокупность обстоятельств (явлений, процессов, событий и состояний), приводящая к отказу.

Примечания

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

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

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

3.1.10 механизм отказа (failure mechanism): Процесс, приводящий к отказу.

Примечание - Процесс может быть физическим, химическим, логическим, психологическим или их комбинацией.

3.1.11 правдоподобность (появления события) (likelihood): Характеристика возможности и частоты появления события.

Примечания

1 Термин "правдоподобность" часто используют в качестве характеристики возможности появления события, которая может быть определена или оценена объективно или субъективно, качественно или количественно и описана с использованием терминов общих или математических (вероятность или частота события за заданный период времени).

2 Английский термин "правдоподобность" не имеет прямого эквивалента в некоторых языках; вместо него часто применяют термин "вероятность".

3.1.12 значимость (последствий) (severity): Относительный ранг возможных или фактических последствий отказа или неисправности ¹⁾.

------------------------------

¹⁾_{См. также [3].}

------------------------------

Примечание - Значимость может быть определена для любых последствий.

3.1.13 метод обнаружения (detection method): Способ, позволяющий выявить вид отказа или его зарождение.

3.1.14 средства контроля (control): Предусмотренные конструкцией объекта встроенные устройства или самостоятельное оборудование, которые способны предотвратить отказ, снизить вероятность его возникновения или изменить его последствия.

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

3.1.15 критичность (вида отказа) (criticality): Уровень значимости, определяемый при ранжировании отказов, с использованием установленных критериев оценки.

Примечания

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

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

3 Конкретное значение критичности зависит от метода оценки, определенного при анализе и подробно рассмотренного в настоящем стандарте.

4 Критичность относится к виду отказа, а не к причинам отказа (если последние определены).

3.1.16 обработка (вида отказа) (treatment): Действия, направленные на изменение вероятности и/или последствий вида отказа.

Примечания

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

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

3.1.17 ошибка человека (human error): Несоответствие между действиями человека, предпринятыми или невыполненными, и действиями, выполнение которых предполагается или необходимо.

Пример - Выполнение неверного действия; невыполнение требуемого действия; ошибка в расчетах, неверное прочтение значения.

3.1.18 резервирование (redundancy): Способ обеспечения надежности системы за счет использования нескольких способов выполнения функции ²⁾.

------------------------------

²⁾_{См. также ГОСТ Р 27.002.}

------------------------------

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

3.1.19 отказы по общей причине (common cause failures): Отказы нескольких объектов, возникающие вследствие одного события, которые без рассмотрения причин считались бы независимыми.

Примечания

1 Отказы по общей причине также могут быть "отказами общего вида".

2 Возможность возникновения отказов по общей причине снижает результативность резервирования системы.

3.1.20 отказы общего вида (common mode failures): Отказы различных объектов (внутри системы), характеризующиеся одним и тем же видом отказа.

Примечания

1 У отказов общего вида могут быть различные причины.

2 Отказы общего вида могут быть также отказами по общей причине.

3 Возможность возникновения отказов общего вида снижает результативность резервирования системы.

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

3.2 Сокращения

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

APPN - значение приоритетности альтернативного риска;

CCF - отказы по общей причине;

COTS - покупная продукция;

CSU - компонент программного обеспечения;

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

EMI - электромагнитные помехи;

ЕМР - электромагнитный импульс;

ESD - аварийное отключение;

ЕТА - анализ дерева событий;

FIT - количество отказов в единицу времени;

FTA - анализ дерева неисправностей;

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

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

FMEDA - анализ видов, последствий и выявления отказов;

MTBF - средняя наработка между отказами;

MTTR - среднее время восстановления;

OEM - изготовитель оригинального оборудования;

RBD - структурная схема надежности;

RCM - техническое обслуживание, ориентированное на безотказность;

RPN - ранг приоритетности риска;

SFF - доля безопасных отказов;

SIL - уровень полноты безопасности;

SOD - значимость, возникновение и обнаруживаемость.

4 Общие положения

4.1 Цель и задачи

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

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

- улучшение конструкции и изготовление объекта или процесса экономически эффективным способом за счет улучшений на ранних этапах программы проектирования и разработки;

- идентификацию риска в рамках процесса менеджмента риска (ГОСТ Р ИСО 31000);

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

- основу для применения других видов анализа надежности (в приложении D рассмотрена взаимосвязь FMEA с другими методами анализа надежности);

- разработку и поддержку программы испытаний на безотказность;

- основу планирования программ технического обслуживания и ремонта, таких как техническое обслуживание, ориентированное на безотказность (ГОСТ Р 27.606);

- ключевой процесс системы управления активами (ГОСТ Р 55.0.01).

FMEA - метод анализа последствий единичных отказов. Если FMEA используют для анализа отказов взаимозависимых объектов, то он может быть рассмотрен с ограничениями (5.3.6 и 5.3.7.2).

4.2 Функции, обязанности и компетентность персонала

Метод FMEA требует, чтобы выполняющие его лица (например, команда FMEA) приняли на себя ответственность за следующее:

- управление процессом выполнения FMEA;

- определение формы FMEA и его адаптацию с учетом особенностей применения;

- идентификацию и анализ видов отказов и их последствий для объекта или процесса;

- определение необходимой обработки видов отказов;

- составление отчета об FMEA, включая предложения и рекомендации.

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

а) Аналитик

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

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

б) Специалисты

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

в) Руководитель

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

г) Заинтересованные стороны

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

4.3 Особенности применения использованных терминов

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

Термины "объект" или "процесс" использованы для обозначения объекта анализа FMEA. Объект или процесс могут быть частью более крупной системы, для которой необходимо применение нескольких видов FMEA.

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

Таблица 1 - Примеры терминов, относящихся к иерархическим уровням системы

Исследуемый объект	Верхний уровень	Средний уровень	Нижний уровень
Аппаратные средства	Объект в сборе	Блок, составная часть	Компонент
Программное обеспечение	Пакет программ	Программный модуль	Функция
Процесс	Процесс в целом	Задача	Этап задачи

5 Методология FMEA

5.1 Общие положения

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

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

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

Действия, показанные на рисунке 1, должны быть адаптированы по отношению к области применения FMEA. Это означает, что не все перечисленные действия всегда должны быть выполнены. В приложении А приведены общее руководство и примеры адаптации метода.

Рисунок 1 - Общая методология FMEA (до адаптации)

5.2 Планирование FMEA

5.2.1 Общие положения

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

Результатом этапа планирования является план применения FMEA в конкретных условиях. План FMEA определяет:

- цели и область применения анализа (5.2.2);

- границы объекта анализа и используемые сценарии (5.2.3);

- критерии принятия решений для обработки видов отказов (5.2.4);

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

- способ выделения ресурсов для анализа (5.2.6).

План может также включать описание факторов, влияющих на анализ, таких как:

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

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

- требования контракта;

- предыдущий опыт и доступная информация.

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

5.2.2 Определение целей и области применения анализа

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

Результатом этих действий должно быть следующее:

- установление цели, определяющей причины выполнения анализа.

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

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

Формулировка целей должна быть включена в план FMEA.

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

5.2.3 Идентификация границ и используемых сценариев

5.2.3.1 Общие положения

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

Для больших или сложных систем (например, железная дорога) может потребоваться разделить систему на подсистемы (например, подвижной состав, система сигнализации, диспетчерский пункт), для каждой из которых FMEA выполняют отдельно. Деление системы может соответствовать физическим или функциональным границам и может зависеть от договорных требований или организационных факторов. Деление системы должно быть выполнено так, чтобы объем каждого FMEA был управляемым и каждый FMEA был логически связан со всеми другими, что позволяет учесть влияние подсистем друг на друга и на систему в целом. Особое внимание следует уделять интерфейсам ¹⁾ между подсистемами. Границы подсистем должны быть четко установлены.

------------------------------

¹⁾_{Интерфейс - совокупность средств, методов и правил, обеспечивающих взаимодействие.}

------------------------------

5.2.3.2 Определение уровня применения и подхода FMEA

FMEA может быть применен на всех уровнях иерархии объекта или процесса (таблица 1). Варианты выполнения FMEA могут быть различными в зависимости от цели и стадии жизненного цикла. В приложении А приведены общее руководство и примеры FMEA.

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

5.2.3.3 Определение границ объекта анализа

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

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

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

5.2.3.4 Определение используемых сценариев

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

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

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

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

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

5.2.4 Определение критериев принятия решений для обработки видов отказов

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

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

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

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

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

- значимость влияния отказа на цели и функции системы или высший уровень, относящийся к предмету анализа;

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

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

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

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

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

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

Примечание 2 - Критичность можно рассматривать в соответствии с риском. Руководство по анализу риска приведено в ГОСТ Р ИСО/МЭК 31010.

План FMEA должен включать детали критериев принятия решений и, если необходим анализ критичности, метод определения критичности. Критерии принятия решений также должны быть подробно описаны в отчетах об FMEA.

5.2.5 Определение требований к документации и записям

5.2.5.1 Общие положения

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

- описание способов использования результатов;

- обоснование решений, принятых на основе анализа;

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

- перечень источников информации, используемых при выполнении FMEA, с проверяемыми ссылками на источники;

- свидетельства соответствия нормативным и договорным обязательствам.

Результаты FMEA могут быть входными данными для других видов анализа или представлять собой отдельный отчет FMEA.

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

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

5.2.5.2 Содержание отчета об FMEA

Отчет об FMEA, как минимум, должен включать:

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

- четкое описание области применения и границ с указанием конкретных исключений;

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

- предположения, сделанные в отношении анализируемых объекта или процесса и соответствующих используемых сценариев;

- детальное описание методологии, лежащей в основе анализа;

- идентификацию заинтересованных сторон и вовлеченного персонала;

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

- источники данных и других применимых материалов (с указанием их статуса, даты выпуска/ пересмотра), на которых должен быть основан FMEA;

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

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

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

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

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

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

5.2.6 Определение ресурсов для анализа

5.2.6.1 Информационные ресурсы

Для выполнения FMEA обычно требуется следующая информация:

- исследуемый объект или процесс, его цели и функции в системе в целом;

- элементы объекта или процесса и их характеристики, изготовление и функции;

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

- уровень резервирования и особенности запасного оборудования, резервированные оборудование или процессы, или параллельно работающие составные части;

- положение и значимость объекта или процесса для организации (если это возможно);

- входы и выходы объекта или процесса и их элементов;

- взаимодействия с другими связанными объектами или процессами и с окружающей средой, в которой работает объект;

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

- общие базы данных, содержащие виды отказов, событий, относящихся к их возникновению, и интенсивности отказов;

- данные эксплуатации;

- данные предыдущего анализа FMEA по тем же или аналогичным объектам или процессам, если это необходимо.

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

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

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

5.2.6.2 Персонал

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

Необходимые навыки и компетенции включают в себя:

- умение применять метод FMEA;

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

- навыки фасилитатора (при выполнении анализа командой).

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

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

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

5.2.6.3 Физические ресурсы

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

5.3 Выполнение FMEA

5.3.1 Общие положения

Этапы выполнения анализа установлены в 5.3.2-5.3.9.

5.3.2 Деление объекта или процесса на элементы

Для выполнения FMEA объект анализа подразделяют на элементы в соответствии со следующими правилами:

- систему можно разделить на функциональные блоки;

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

- процессы могут быть представлены в виде последовательности действий, или этапов;

- программное обеспечение может быть разделено на программные модули или функции;

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

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

Примечание 2 - Люди могут являться элементом системы, механизмы возникновения ошибок человека при работе могут быть учтены в анализе причин аппаратного и/или программного отказа.

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

5.3.3 Определение функций и стандартов функционирования каждого элемента

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

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

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

5.3.4 Идентификация видов отказов

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

В зависимости от цели и области применения анализа для определения видов отказов каждого элемента в процессе жизненного цикла объекта рассматривают следующее:

- применение;

- режим работы;

- соответствующие функциональные требования;

- нагрузки, возникающие под воздействием экологических факторов, и тенденции их изменения;

- психологические стрессы и социальные изменения;

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

- нагрузки в процессе утилизации и ликвидации.

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

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

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

- опыта эксплуатации;

- эксплуатационных и экологических испытаний внутри установленных границ или за их пределами;

- контрольных перечней общих видов отказов для установленных типов элементов;

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

- базы данных об инцидентах и авариях;

- знаний, относящихся к области исследований.

5.3.5 Идентификация методов обнаружения отказов и существующих средств контроля

5.3.5.1 Общие положения

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

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

------------------------------

¹⁾_{См. ГОСТ Р 22.0.12-2015 (пункт 2.1.15).}

------------------------------

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

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

5.3.5.2 Методы обнаружения

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

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

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

5.3.5.3 Средства контроля

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

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

5.3.6 Идентификация локальных и конечных последствий видов отказов

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

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

Примечание 1 - Локальный уровень может означать анализируемый объект или его физическое местоположение.

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

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

Примечание 2 - Для идентификации конечных последствий вида отказа может потребоваться использование других видов анализа, например анализа дерева событий (ГОСТ Р МЭК 62502).

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

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

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

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

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

5.3.7 Идентификация причин отказов

5.3.7.1 Общие положения

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

Пример - Идентификация того, что протечка (вид отказа) связана с процессом коррозии, может привести к рекомендации по замене материала.

Примечание - Методы более детального анализа причин отказов приведены в анализе корневой причины (см. [4]).

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

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

5.3.7.2 Отказы по общей причине и отказы общего вида

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

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

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

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

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

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

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

5.3.7.3 Человеческий фактор

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

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

Пример 1 - Вид отказа "действие не выполнено" может произойти потому, что человек отвлекся, сделал ошибочные предположения, или из-за недостатка знаний о последовательности действий. Если какое-либо действие не выполнено по невнимательности или халатности, дополнительное обучение может быть бесполезным или даже контрпродуктивным.

Примечание 1 - Причины ошибок человека и факторы, влияющие на его деятельность, приведены в ГОСТ Р 62508. Таксономия видов, механизмов и причин ошибок человека, а также формальные методы, которые могут быть использованы для анализа ошибок человека, приведены в [4].

ГАРАНТ:

По-видимому, в тексте предыдущего абзаца допущена опечатка. Вместо слов "ГОСТ Р 62508" следует читать "ГОСТ Р МЭК 62508"

Примечание 2 - Человек может совершить как преднамеренную, так и непреднамеренную ошибку.

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

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

5.3.8 Оценка значимости вида отказов

5.3.8.1 Общие положения

В плане FMEA должно быть установлено, следует ли учитывать относительную значимость видов отказов и как это следует делать.

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

5.3.8.2 Определение значимости последствий отказа на высшем уровне системы

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

Пример 1 - Анализ объекта может быть выполнен изготовителем для анализа его конструкции; в этом случае значимость последствий может быть представлена через влияние на характеристики объекта в целом. Этот же объект может быть проанализирован в составе группы объектов; в этом случае значимость последствий связана с влиянием на характеристики группы.

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

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

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

5.3.8.3 Оценка вероятности возникновения вида отказа

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

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

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

Пример - Обычно используемые периоды времени включают: гарантийный период; ожидаемую продолжительность полезного использования объекта; установленный период использования объекта или процесса; продолжительность смены.

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

- данные испытаний компонентов на стойкость или лабораторно рассчитанных интенсивностей ошибок человека;

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

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

- данные мониторинга работы человека;

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

Примечание - Существуют базы данных о видах отказов обычно используемых компонентов оборудования (например, [5], ГОСТ Р 27.013), о видах ошибок человека (например, [6]), методах оценки надежности человеческого фактора (например, ГОСТ Р МЭК 62508), об оценке отказов аналогичных объектов (например, [7]).

5.3.8.4 Оценка других параметров критичности

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

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

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

5.3.9 Идентификация действий

5.3.9.1 Общие положения

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

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

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

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

5.3.9.2 Варианты обработки

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

Как правило, внесение изменений на этапе проектирования менее затратно, особенно в отношении изменения оборудования.

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

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

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

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

Примечание - Процесс разработки таких программ - это техническое обслуживание, ориентированное на безотказность (см. ГОСТ Р 27.606).

Обработка отказа может привести к одному или нескольким из следующих действий:

- устранению вида отказа;

- снижению вероятности возникновения вида отказа;

- устранению или уменьшению последствий вида отказа.

Для определения того, какие виды отказов требуют обработки, должны быть использованы критерии принятия решения (5.2.4).

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

Следует также рассмотреть возможность удаления средств контроля, которые неэффективны или излишни.

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

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

- возникновения новых видов или последствий отказов;

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

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

5.4 Документирование FMEA

Анализ должен быть документирован и представлен в соответствии с планом FMEA (5.2.5) ¹⁾.

------------------------------

¹⁾_{Существуют коммерческие пакеты программ для разработки отчета о результатах FMEA. Для отчета о простом анализе с небольшим количеством участников может быть полезно использование электронных таблиц. Для составления отчета о более сложном анализе с несколькими источниками информации и сложными требованиями к отчету может быть полезна реляционная база данных.}

------------------------------

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

[1]	МЭК 60050-192 Международный электротехнический словарь. Часть 192. Надежность (Dependability management - Part 192: Guidance for management and application)
[2]	ISO/IEC/IEE 15288:2015 Разработка систем и программного обеспечения. Процессы жизненного цикла системы (Systems and software engineering - System life cycle processes)
[3]	EH 13306:2010 Техническое обслуживание и ремонт. Терминология технического обслуживания и ремонта (Maintenance - Maintenance terminology)
[4]	МЭК 62740 Анализ коренных причин (RCA) (Root cause analysis (RCA))
[5]	MIL-HDBK-338B, Electronic reliability design handbook, Defense Quality and Standardization Office (DLSC-LM), Fort Belvoir, Virginia 22060-6221, October 1998
[6]	Bell, J., and Holroyd, J., Review of human reliability assessment methods, Research Report RR 679 for Health and Safety Executive, Sudbury: HSE Books, 2009
[7]	МЭК 61709 Компоненты электрические. Надежность. Стандартные условия для интенсивностей отказов и модели напряжений для преобразования (Electric components - Reliability - Reference conditions for failure rates and stress models for conversion)
[8]	МЭК 62741 Демонстрация требований к надежности. Пример надежности (Demonstration of dependability requirements - The dependability case)
[9]	Braband, J., Improving the Risk Priority Number concept, Journal of System Safety, 3, 2003, p. 21-23
[10]	МЭК 62551 Методы анализа надежности. Метод сети Петри (Analysis techniques for dependability - Petri net techniques)
[11]	Ozarin, N., Understanding, planning and performing Failure Modes & Effects Analysis on software, Tutorial, RAMS Conference, 2016
[12]	Yoshimura, I., Sato, Y., Safety achieved by the Safe Failure Fraction (SFF) in IEC 61508, IEEE Transactions on Reliability, Vol. 57, No. 4, 662-669, Dec. 2008

Ключевые слова: отказ, вид отказа, последствия отказа, критичность отказа, вероятность отказа, анализ видов и последствий отказов; анализ видов, последствий и критичности отказов.