Необходимые навыки от Хэппи Хольдена: Анализ типов нарушений и их эффектов (FMEA). Часть 7.

Что такое FMEA?

Анализ типов нарушений и эффектов (FMEA) – это системный процесс оценки типов нарушений и причин, связанных с процессами разработки и производства нового продукта. Это немного похоже на фазу анализа потенциальных проблем в программе Кепнера-Трегоу. Вот список шагов для FMEA:

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

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

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

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

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

Сравнение с FTA

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

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

Преимущества FMEA

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

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

FMEA поддерживает процесс разработки за счет:

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

Польза от отчета FMEA включает в себя:

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

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

Теория

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

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

Процедура

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

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

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

Процесс FMEA

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

Требования к выполнению FMEA

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

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