Машиностроительное предприятие №1 С Т А Н Д А Р Т О Р Г А Н И З А Ц И И

О Р Г А Н И З А Ц

И И

С И С Т Е М А М Е Н Е Д Ж М Е Н Т А К А Ч Е С Т В А
 
Менеджмент риска.
Метод анализа видов и последствий отказов.
Инструкция

МЭК 60812:2006 "Методы анализа надежности систем. Метод анализа видов и

последствий отказов (FMEA)" (IEC 60812:2006 "Analysis techniques for system reliability - Procedure for failure mode and effects analysis (FMEA)") путем внесения технических отклонений, объяснение которых приведено во введении к настоящему стандарту.

Настоящий стандарт устанавливает методы анализа видов и последствий отказов (Failure Mode and Effects Analysis - FMEA), видов, последствий и критичности отказов (Failure Mode, Effects and Criticality Analysis - FMECA) и дает рекомендации по их применению для достижения поставленных целей путем: - выполнения необходимых этапов анализа; - идентификации соответствующих терминов, предположений, показателей критичности, видов отказов; - определения основных принципов анализа; - использования примеров необходимых технологических карт или других табличных форм. Все приведенные в настоящем стандарте общие требования FMEA относятся и к FMECA, так как последний является расширением FMEA.

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

ссылки на следующие стандарты: ГОСТ Р 51901.3-2007 (МЭК 60300-2:2004) Менеджмент риска.

Руководство по менеджменту надежности (МЭК 60300-2:2004 "Менеджмент надежности. Руководство по менеджменту надежности", MOD) ГОСТ Р 51901.5-2005 (МЭК 60300-3-1:2003) Менеджмент риска. Руководство по применению методов анализа надежности (МЭК 60300-3-1:2003 "Управление надежностью. Часть 3-1. Руководство по применению. Методы анализа надежности. Руководство по методологии", MOD) ГОСТ Р 51901.13-2005 (МЭК 61025:1990) Менеджмент риска. Анализ дерева неисправностей (МЭК 61025:1990 "Анализ дерева неисправности (FNA)", MOD) ГОСТ Р 51901.14-2005 (МЭК 61078:1991) Менеджмент риска. Метод структурной схемы надежности (МЭК 61078:2006 "Методы анализа надежности. Структурная схема надежности и Булевы методы", MOD) ГОСТ Р 51901.15-2005 (МЭК 61165:1995) Менеджмент риска. Применение марковских методов (МЭК 61165:1995 "Применение марковских методов", MOD)

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

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

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

быть идентифицированы и описаны. Так как вид отказов может иметь

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

отказов в терминах эксплуатации, функционирования или статуса системы (см. определение

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

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

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

протокол, включающий оценку рисков, описывающий критические риски с предложенными мерами

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