WikiDer > Обзор проекта на основе режима отказа
Тема этой статьи может не соответствовать Википедии общее руководство по известности. (Май 2013) (Узнайте, как и когда удалить этот шаблон сообщения) |
Анализ проекта на основе режима отказа (DRBFM) - это инструмент, изначально разработанный Toyota Motor Corporation. Этот инструмент был разработан на основе философии, согласно которой проблемы проектирования возникают при внесении изменений в существующие технические проекты, которые уже оказались успешными.
Методология
Методология DRBFM была разработана Тацухико Йошимура, экспертом по качеству и профессором Японского Университет Кюсю. Йошимура знал, что проблемы проектирования возникают, когда изменения вносятся без надлежащего уровня сопроводительной документации. Используя философию превентивных мер (Mizenboushi), он создал свою собственную философию DRBFM. Тацухико Йошимура поддерживал разработку и использование DRBFM во многих компаниях. Он считает, что компании, внедряющие DRBFM, будут лучше. Он считает, что внедрение DRBFM требует дисциплины и заинтересованности всех в достижении единой цели - повысить ценность клиента за счет удовлетворения технических функциональных требований и ожиданий клиентов.
Философия DRBFM основана на трех концепциях:
- Хороший дизайн
- Хорошее обсуждение
- Хорошее рассечение
Методология DRBFM в настоящее время является признанным документированным процессом SAE (Общество автомобильных инженеров), а также AIAG (Группа действий в автомобильной промышленности). SAE J2886[1] Рекомендуемая практика DRBFM была опубликована в 2013 году, а Справочное руководство AIAG DRBFM было опубликовано в сентябре 2014 года. Билл Хоги является председателем комитетов SAE и AIAG для обеспечения последовательного применения процесса DRBFM в обоих документах.
Хороший дизайн
Основа для надежность не менять дизайн; поэтому г-н Ёсимура считает, что если дизайн меняется, то изменения должны происходить небольшими приращениями. Нарушение дизайна вызвано прерыванием реализации изменений, влияющих на интерфейсы между частями и взаимодействия между системами. Дизайн не следует изменять в двух разных местах одновременно, потому что слишком быстрое внесение слишком большого количества изменений может привести к сбоям быстрее, чем наша способность их обнаруживать. Один из ключей к успешному изменению - сделать изменения видимыми.
Хорошее обсуждение
В обсуждениях мы должны сосредоточиться на предлагаемых изменениях в дизайне. Если к будущим изделиям применяется проверенная хорошая конструкция, то риск отказа невелик; однако, если в существующую конструкцию вносятся изменения, то вероятность отказа увеличивается.
Г-н Йошимура советует людям работать, чтобы понять изменения, а не упрощать их. Он также сообщает, что валидационное тестирование может помочь выявить слабые места дизайна; но он также заявляет, что хорошие обсуждения, проводимые на предварительных обзорах проекта, могут дать тот же результат. Хорошее обсуждение, о котором говорит здесь г-н Йошимура, также известно как DRBFM (анализ проекта на основе режимов отказа).
Анализ для DRBFM моделируется на основе связи между хорошим анализом проекта и FMEA. Комплексный, хорошо выполненный FMEA можно рассматривать как один из входов (плюс многие другие подготовительные листы, определенные в методологии) для определения объема DRBFM, но FMEA НЕ требуется, поскольку фокус основан на изменениях и интерфейсах. DRBFM реализуется на основе новизны изменений на любом уровне продукта (дизайн, процесс, поставщик и т. Д.). Цель DRBFM - сделать эти изменения видимыми, подробно обсудив их, а также все возможные проблемы с ошибками, которые могут потенциально произойти - все, что влияет на качество, стоимость или доставку.
Хорошее рассечение
Третья часть GD3 концепция. Одна из целей хорошего обзора проекта - изучить результаты валидационного тестирования, сделав видимыми все слабые стороны продукта. Этот экзамен предполагает применение другого GD.3 концепция, анализ проекта по результатам испытаний (DRBTR). Применяя DRBTR, мы должны по возможности наблюдать за тестированием продукта до, во время и после завершения. DRBTR ищет инженера по валидации (тестирования), который возглавит обзор обзора DRBTR для проверки тестируемой части и поиска зародышей проблем, которые вот-вот произойдут (сбои тестов очевидны). DRBTR побуждает проектировщика и инженера по тестированию обсуждать потенциальные проблемы (наблюдения) или слабые места на основе кросс-функционального многопрофильного подхода и делиться этой информацией. В DRBTR разработчик наблюдает за фактическими тестовыми образцами и обсуждает результаты тестов в открытых обсуждениях, таких как анализ проекта. Кроме того, при анализе результатов испытаний необходимо учитывать производственные вариации, профиль испытаний и ожидаемые целевые показатели качества и надежности продукта. Этот процесс подробно описан в электронной книге Билла Хоги.[2].
Смотрите также
Примечания и ссылки
- ^ J2886: «Анализ проекта на основе режимов отказа (DRBFM)». SAE. 2013-03-05. Получено 2020-09-08.
- ^ Хоги, Билл (30 апреля 2012 г.). Руководство по процессу анализа проекта на основе режимов отказа (DRBFM) и анализа проекта на основе результатов испытаний (DRBTR). SAE. п. 85. ISBN 978-0-7680-7642-4. Получено 2020-09-08. PD251136