Научная статья на тему 'Управление процессом разработки сложных технических систем и процессов. Особенности применения FMEA-анализа'

Управление процессом разработки сложных технических систем и процессов. Особенности применения FMEA-анализа Текст научной статьи по специальности «Компьютерные и информационные науки»

CC BY
1466
218
i Надоели баннеры? Вы всегда можете отключить рекламу.
Ключевые слова
FMEA-АНАЛИЗ / УРОВЕНЬ РИСКА / ОТКАЗОУСТОЙЧИВОСТЬ / ПОТЕНЦИАЛЬНЫЙ ОТКАЗ

Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Муха Ар А., Муха Ар А.

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

i Надоели баннеры? Вы всегда можете отключить рекламу.
iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.
i Надоели баннеры? Вы всегда можете отключить рекламу.

This article is devoted to the management problem of development process of complex technical systems and processes using FMEA-analysis for preventing critical situations, reducing the number of risks and potential failures and improving their safety

Текст научной работы на тему «Управление процессом разработки сложных технических систем и процессов. Особенности применения FMEA-анализа»

УДК 656.257.004

Ар.А. МУХА

УПРАВЛЕНИЕ ПРОЦЕССОМ РАЗРАБОТКИ СЛОЖНЫХ ТЕХНИЧЕСКИХ СИСТЕМ И ПРОЦЕССОВ. ОСОБЕННОСТИ ПРИМЕНЕНИЯ ЕМЕА-АНАЛИЗА

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

Ключові слова: FMEA-аналіз, рівень ризику, відмовостійкість, потенційна відмова.

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

Ключевые слова: FMEA-анализ^ровеньриска, отказоустойчивость, потенциальный отказ.

Abstract. This article is devoted to the management problem of development process of complex technical systems and processes using FMEA-analysis for preventing critical situations, reducing the number of risks and potential failures and improving their safety.

Keywords: FMEA-analysis, risk level, fault tolerance, potential failure.

1. Введение

Отличительной особенностью управленческих решений современности при разработке сложных систем и проектов является чрезвычайная сложность выбора руководителем разработки или конструктором того или иного варианта реализации проекта. От такого выбора зависят все ключевые показатели эффективности реализации разработки, а также успех проекта в целом. Истории технологического прогресса известно немало случаев, когда принятое руководителем решение проекта приводило к невероятному успеху или полному краху с разного рода тяжелыми последствиями [1]. Именно поэтому целью данной статьи является привлечение внимания научного сообщества к вопросам управления процессами разработки сложных технических систем, а именно принятия управленческих решений при выборе варианта реализации проекта с использованием Failure Mode and Effects Analysis (FMEA-анализа) (анализа видов, последствий и критичности отказов).

FMEA-анализ не является новым способом исследования сложных систем. В странах западного мира метод внедрен в виде стандарта MIL-STD-1629 еще в 1949 году. Метод активно применялся в аэрокосмической отрасли и автомобилестроении. В странах СНГ стандарт FMEA впервые был изложен в 2001 году в виде ГОСТ Р 51814.2-2001 «Системы качества в автомобилестроении» в Российской Федерации. Несмотря на многочисленные научные работы украинских ученых, в нашей стране до сих пор не существует подобного стандарта. Поэтому разработчики и производители продукции вынуждены решать проблемы анализа отказов своими методами и на свое усмотрение.

2. Предотвращение ошибок

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

© Муха Ар.А., 2012

ISSN 1028-9763. Математичні машини і системи, 2012, № 2

производства

Этапы создания системы

Рис. 1. Плотность вероятности возникновения ошибки

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

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

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

Следует обра-

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

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

Рис. 2. Алгоритм проведения FMEA-анализа

3. Порядок проведения ЕМЕА-анализа

Порядок проведения FMEA-анализа четко регламентирован во многих стандартах и представляет собой следующий алгоритм работ (рис. 2):

FMEA-анализ взаимосвязан с диаграммой потоков процесса и планом управления процессом. Поэтому далее будет представлена схема алгоритма проведения анализа с методологической точки зрения (табл. 1).

Описание

системы

Потенциальный отказ/ дефект

Воз-

можные

послед

ствия

При-

чины

отказа

Какие требования к системе ?

/

пгоц

Какие последствия? |

Как это повлия' рцесс?

Насколько это Как часто воз-

\

Рекомен-

дованные

действия

Ответственность и сроки

критично? никает ошибка?

Какие последствия могут возникнуть?

I

Какие отказы могут возникнуть?

Какими будут по-* следствия?

I

Как можно улучшить систему?

Что необходимо предотвратить? і

Какие причины? Что стало причиной отказа/ ошибки?

Насколько эффективны меры обнаружения ?

Как это можно обнаружить?

Кто будет этим заниматься?

I

Когда будут результаты?

При-

нятые

меры

Результаты

изменений

О

Б

Какие измене' ния внесены

ЯР

N

Как это повлияло на систему?

Как это можно__

^предупредить?

Рассмотрим подробнее каждый из этапов анализа, который проводится согласно

рис. 2.

Этап 1. Создание команды проекта

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

На рис. 3 показано пример состава такой команды специалистов.

Работают подобные команды по методам, описанным в табл. 1, по 3-6 часов в день в помещениях и условиях, максимально благоприятных для творческой деятельности.

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

Монтажный персонал

Сервисный персонал

■ профессиональная ответственность

■ постоянные члены

Этап 2. Ознакомление с проектом и сбор информации

"2 - привлекаемые сотрудники Рис. 3. Состав команды FMEA

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

Этап 3. Экспертное определение потенциальных дефектов и отказов системы или процесса

Процесс выявления причин отказов имеет несколько этапов:

• формулирование конкретной проблемы;

• исследование потенциальных причин;

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

• сбор и накопление данных;

• применение статистических методов для отображения причинно-следственных

связей.

Конкретные инструменты определены и приведены в табл. 2.

Таблица 2. Инструменты, применяемые в процессе выявления потенциальных причин отказов

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

№ Инструмент Краткое описание

1 Мозговой штурм Позволяет команде (рабочей группы) генерировать большое количество идей о причинах отказов/ошибок

2 Диаграмма причин и результатов Дает возможность команде (рабочей группе) идентифицировать, исследовать и графически отображать с подробностями все возможные причины отказов/ошибок

3 Планирование эксперимента Метод для одновременного исследования нескольких потенциальных причин несоответствия позволяет команде (рабочей группе) сделать вывод о причинах отказов/ошибок

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

5 Диаграмма Г ранта Дает возможность постоянно отслеживать планы мероприятий

6 Диаграмма Парето Помогает команде (рабочей группе) объективно оценить результаты запланированных мероприятий по улучшению «до» и «после»

7 Цикл PDCA Обеспечивает постоянное улучшение процессов

Этап 4. Создание полного перечня отказов с последствиями и причинами

Установление значимости каждого отказа, построение дерева отказов.

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

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

перечень отказов/ошибок согласно предложенным в работе [1] классам ошибок.

|— Местоположение

— Границы системы

— Область системы

Ошибка —

Феноменологическая

система

Намерение

Постоянство

■£

£

■с

■£

Ошибки, связанные с развитием Ошибки эксплуатации Внутренние Внешние

Ошибки аппаратных средств Ошибки ПО Ошибки системы Ошибки оператора Случайные Ошибки вторжения Постоянные Переходные

Рис. 4. Элементарные классы ошибок

При выявлении потенциальных ошибок определяют и устанавливают условия, в которых они возникают, на какие части распространяются, а также устанавливаются причины их возникновения [1].

активация распространение причина

-► неисправность-------► ошибка ---------► сбой --------► отказ

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

С точки зрения методологии, следует отметить, что для удобства и полноты выявления причин последствий отказов нужно использовать компонентную модель, модель материальных потоков, дерево отказов Fault Tree Analysis (FTA), структурные модели, функциональные модели, диаграммы Исикавы (Анализ возникновения причин отказов). Полученные данные об отказах вносятся в табл. 3 - протокол анализа.

Таблица 3. Протокол FMEA-анализа

Компонентная модель Модель материальных потоков

Ком понент Вид потенциального отказа П ви оследст-я отказа S Потенциаль- наяпричина O Меры по обнару- ,-жению -RPn I ПЧР Рекомендованные действия по минимизации риска S O D RPN I ПЧР

1

Этап 5. Определение комплексной оценки риска КРК

По критериям: 8, О, Б.

Согласно данному методу производится оценка возможных режимов отказов по трем показателям [4]:

- значимость потенциального отказа 8;

- вероятность возникновения дефекта О;

- вероятность обнаружения отказа Б.

Рекомендуемые в работе [5] шкалы для оценки этих показателей приведены в табл.

4-6.

Произведение этих факторов является приоритетным числом риска (ПЧР, ЯРК), то есть количественная оценка отказа с точки зрения его значимости по последствиям, вероятности возникновения и вероятности обнаружения [5, 6]:

ПЧР=8 О Б.

Каждое ПЧР может иметь значение от 1 до 1000. Для ПЧР должен быть заранее ус-

тановлен критерий Я (предельное значение ПЧР).

Согласно рекомендациям [5, 6], предельное значение ПЧР задается в пределах 100 <Я<125. В производстве разработчики давно используют эту методологию, в особо ответственных случаях работают с границей ПЧР 30<Я<50 [7].

Таблица 4. Оценка показателя значимости отказа____________________________________________

Значимость (Severity)

Ранг Эффект Критерий (значимость последствий)

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

2 Очень высокий Отказ влияет на безопасное функционирование - полная потеря контроля

3 Высокий Отказ приводит к полной потере функционирования 100%

4 Средний Отказ приводит к крайней потере функциональности системы <50%

5 Умеренный Отказ приводит к значительной потере функциональности системы <30%

6 Низкий Отказ приводит к частичной потере функциональности системы и значительным изменениям показателей эффективности <10%

7 Очень низкий Отказ не влияет на функциональность, но приводит к изменениям показателей эффективности <5%

8 Малый Отказ не влияет на функциональность, но может быть обнаружен в процессе функционирования

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

10 Незначительный Нет видимых дефектов системы

Таблица 5. Оценка показателя вероятности возникновения отказа

Возникновение (Оссиггеш)

Ранг Вероятность Возможные доли отказов Cpk Ppk

1 Очень высокая Чаще 1 раза в день 300 000 ppm <0,33 <0,55

2 Высокая 1 раз в 3-4 дня 100 000 ppm >0,33 >0,55

3 Высокая 1 раз в неделю 50 000 ppm «0,67 >0,87

4 Высокая 1 раз в месяц 10 000 ppm «0,83 >0,86

5 Средняя 1 раз в 3-4 месяца 1000 ppm «1 >0,84

6 Средняя 1 раз в полгода 500 ppm «1,17 >1

7 Средняя 1 раз в год 100 ppm «1,33 >1,1

8 Низкая 1 раз в 2-3 года 50 ppm «1,67 >1,2

9 Низкая 1 раз в 3-5 лет 10 ppm «2 >1,3

10 Незначительная 1 раз в 5 лет <2 ppm «2 >1,67

Таблица 6. Оценка показателя вероятности обнаружения отказа

Обнаружение (Detections)

Ранг Критерий Тип контроля Определение

A B C

1 Невозможно обнаружить ✓ Наличие дефекта не проверяется или не может быть проверено

2 Не будет обнаружено ✓ Элемент выборочно проверяется и оценивается на основе уровня брака

Продолж. табл. 6

3 Дефект скорее всего не будет обнаружен ✓ Визуальная проверка и оценка на основе отсутствия дефектов

4 Существует вероятность обнаружения ✓ Визуальная проверка в ходе производства

5 Очень низкая вероятность обнаружения ✓ ✓ Визуальная проверка на основе примерного экземпляра

6 Низкая вероятность обнаружения ✓ Процесс производства контролируется статистически

7 Средняя вероятность обнаружения ✓ ✓ Отказ не влияет на функциональность, но приводит к изменению показателей эффективности <5%

8 Высокая вероятность обнаружения ✓ ✓ Процесс статистически управляем

9 Очень высокая вероятность обнаружения ✓ ✓ Вся продукция проверяется автоматически

10 Вероятность обнаружения «100% ✓ Вся продукция проверяется автоматически, и отсутствует вероятность пропуска дефекта

Этап 6. Разработка мер по снижению частоты наступления отказов и повышению их обнаружения

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

К таким мерам относятся:

- изменения в конструкции;

- внесение резервирования;

- повышение надежности элементов;

- изменение алгоритма вычислений;

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

- обновление программного обеспечения и др.

Все изменения должны вноситься с учетом выводов, сделанных на предыдущих этапах анализа (Б), и быть направлены на понижение числа ПЧР (ЯРК).

Этап 7. Проверка достижения заданных значений

Производится перерасчет значения ПЧР (ЯРК).

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

Этап 8. Документирование решений, написание заключения руководителя группы

В течение проведения БМЕЛ-анализа полученные рабочей группой результаты заносятся в табл. 7.

Данный этап предусматривает создание базы документации проекта, а именно:

1. Написание заключения конструктора и руководителя проекта относительно даль-

нейшего использования системы. На основе этого заключения принимается решение о внедрении системы или ее использовании в том или ином проекте.

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

3. Написание инструкций по технике безопасности.

4. Ожидаемый результат

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

5. Автоматизация алгоритма

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

На сегодняшний день существуют множество программ, разработанных специально для создания и ведения FMEA-анализа. Некоторые программные комплексы специализированы конкретно под один из видов FMEA-анализа, другие -содержат множество модулей и подходят для разработки FMEA-анализа как системы, так и процесса. Для примера можно привести следующее программное обеспечение: XFMEA от ReliaSoft; FMEA-Pro от Dyadem; FMEA-Med от Dyadem; FailureModeAnalyst ™ от CCD; Byteworx FMEA Software.

Программное обеспечение, разработанное для проведения FMEA-анализа, обычно содержит набор таблиц, шаблонов, указаний и многих других инструментов, облегчающих создание и внедрение обновлений в систему документации расширенного планирования. Некоторые программы предлагают пакет решений для создания целостного APQP и/или DVP & R.

Специализированное ПО также может содержать ряд других преимуществ по:

- обеспечению безопасности;

- созданию отчетов;

- подготовке диаграмм;

- отслеживанию истории обновлений;

- планированию и управлению корректирующими действиями.

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

Сегодня перспективным является интеграция модулей FMEA-анализа в штатные системы планирования ресурсов предприятия - Enterprise Resource Planning System (ERP) [8] компаний разработчиков, что позволяет использовать методику FMEA-анализа в рабочем режиме.

6. Выводы

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

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

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

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

СПИСОК ЛИТЕРАТУРЫ

1. Avizienis A. Fundamental Concepts of Dependability / A. Avizienis, J.-C. Lnprie, B. Randell // Technical Report: UCLA CSD Report N G1GG2S, LAAS Report N 01-145, Newcastle Report NCS-TR-739. -2GG2. - 31p.; // IEEEComputer. - 2GGG. -N 10. - 145 p.

2. Харрингтон Дж. Управление качеством в американских корпорациях / Харрингтон Дж. - М.: Экономика, 1990. - 43 c.

3. Применение метода анализа видов, причин и последствий потенциальных несоответствий (FMEA) на различных этапах жизненного цикла продукции / В.Е. Годлевский, А.Я. Дмитриев, Г.Н. Изюменко [и др.] / Под ред. В.Я. Кокотова. - Самара: ГП “Перспектива”, 2002. -160 с.

4. Использование анализа видов и последствий потенциальных дефектов (FMEA) для разработки системы предупреждающих мероприятий испытательной лаборатории Заводская лаборатория / С.М. Горюнова, А.Ф. Дресвянников, Н.Г. Николаева [и др.] // Диагностика материалов. - 2006. -Т. 72, № S. - С. 5S.

5. Пономарев С.В. Управление качеством продукции. Инструменты и методы менеджмента качества: учеб. пособие / С.В. Пономарев, С.В. Мищенко. - М.: Стандарты и качество, 2005. - 24S с.

6. ГОСТ Р 51S14.2-2GG1. Системы качества в автомобилестроении. Метод анализа видов и последствий потенциальных дефектов. - М.: Изд-во стандартов, 2001. - 1S с.

7. Багимов И.А. Применение аппарата нечеткой логики для оценки приоритетного числа риска в методологии FMEA [Электронный ресурс] / И.А. Багимов, В.А. Тараненко. - Режим доступа: donntu.edu.ua/russian/ konf/mashinebuild/arhiv/vipusk32_2006.pdf.

S. A study on applying FMEA to improving ERP introduction: An example of semiconductor related industries in Taiwan/Ching-Chow Yang, Wen-Tsaan Lin, Ming-Yi Lin [et al.] // International Journal of Quality & Reliability Management. - 19S4. - 245 p.

Стаття надійшла до редакції 24.02.2012

i Надоели баннеры? Вы всегда можете отключить рекламу.