DFMEA

小马混迹汽车零部件行业6年有余,主要从事娱乐系统硬件设计。就这段工作经验里我所接触到的公司里,能认真分析设计DFMEA的硬件工程师确实比较少。虽然在外企,硬件设计流程中都有需要DFMEA的文档输出以及跟客户主机厂之间的评审,但是国内员工对DFMEA不管是在熟悉度,重视度上都不及国外员工。可能是因为国内主机厂客户本身对于这方面的失效分析也并没有足够的重视?小马没有去做太多的调查,不敢随便断言。这几天小马在做一个项目时候利用机会研究了一下DFMEA,有一点感想和理解,在这里稍微做点分享,如果有理解错误的地方,烦请指正。

我只从我理解的几个方面做如下介绍:

 

1, 什么是DFMEA

下面引用一下度娘百科的内容.

在设计和制造产品时,FMEA是一种可靠性设计的重要方法。它实际上是FMA(故障模式分析和FEA(故障影响分析)的组合。它对各种可能的风险进行评价、分析,以便在现有技术的基础上消除这些风险或将这些风险减小到可接受的水平。及时性是成功实施FMEA的最重要因素之一,它是一个“事前的行为”,而不是“事后的行为”。为达到最佳效益,FMEA必须在故障模式被纳入产品之前进行。

DFMEA则是Design Failure Mode and Effects Analysis的缩写,是在设计前期对设计上可能存在的失效模式和原因的分析。

 

2,为什么要设计DFMEA

这里从功能上开始阐述。我们设计一款产品,最终是要流向市场面向用户,用户所关心的显示功能是否能实现。一款产品如果连最基本的共能实现都做不到,我想已经没有必要再称之为产品了。

既然有功能,那必然会存在功能实现不了的时候,我们称之为功能失效。

功能失效的原因是什么?

产品功能是由各个模块的功能堆叠而成,而各个功能模块又是由模块里的各个原件组成。顺着这个思路,从功能失效分析>模块失效分析>组成元件分析,一步一步找出失效的根本原因。

分析失效原因的目的是什么?

这就要回到我们为什么要设计DFMEA这个问题上了。DFMEA的主要目的是:

一, 为了在产品功能失效时有理论和实际的文档可以查询用以得知功能失效的根本原因,从一定程度上,对于生产过程钟出现的失效项可以快速排查维修以节省单件分析时间。

二, 为了实现设计和生产过程成中对潜在失效的预防并对各个失效项做出相应的预防措施以降低失效率和不良率。

从这两点上,设计一个完整可靠的DFMEA将可以为企业节省很大的质量管控成本。

 

3,DFMEA的结构,如何设计DFMEA

分析DFMEA, 就是从功能角度去头脑风暴产品功能可能存在哪些失效项,进而分析功能失效的原因。

从层级上分,产品有失效影响,失效模式,失效原因。失效影响主要针对功能来讲,而失效模式则是失效的现象,失效原因则是引起失效模式的深层次根源。DFMEA设计一般从失效模式分析,因为它描述的时现象,进而容易去分析这个现象会产生什么影响,是因为什么原因产生。

从表达顺序上一般有:

a, 失效模式>失效影响>失效原因

b, 失效影响>失效模式>失效原因

下面分享的实例将会按照第二种表达顺序来设计DFMEA的树形结构。

按照b表达顺序设计的树形结构如下:

分析的正向思路如下:

I,设计评审,根据图纸去分析每个元件和相关电路

II,评估可能存在的失效模式并列出

III, 针对b项可能存在的失效模式,列出可能影响到b项失效模式的影响

IV, 评估每个失效项的发生度(occurance),可检测度(detection)以及因为失效项和失效模式产生影响的严重度(severity),计算RPN(Risk Priority Number, RPN=S*O*D)

V, 根据d项里的SOD和失效项确定预防和检测措施

简化成2个步骤:

第一步,分析产品功能,产品的功能(function of product...)是由哪些子模块功能(function of part A,B...)堆叠?子模块功能由哪些元件(design of part A,B...)设计而成?

第二步,产品的功能会产生哪些失效(function failure1, function failure2...function failure x), 这些功能失效是因为子模块哪些功能的失效(function of part A failure A1,  function of part A failure b1, function of part B failure A1...),子模块失效是因为哪些设计导致(Design part A failure A2, Design part A failure B2...)

然而作为硬件工程师,在做DFMEA过程中经常会采用逆向分析来设计DFMEA,原因在于,硬件工程师对底层的电路设计和元件特性更了解,从这些特性去分析可能存在的失效项逆推出可能存在的失效模式,再而推出上一层的功能失效和失效影响。

4,简单的实例分析:

以汽车安全气囊控制器的flexray电路为例:

Flexray在汽车安全气囊控制器内部的功能主要是与车上其他ECU通信,硬件图如下

 

 

其DFMEA 草稿如下:

 

 

 a, 功能和失效项如下(影响):

 

 b ,子功能模块和失效(模式,现象):

c, 底层硬件设计和失效(原因):

  I, 硬件层次1

  II, 硬件层次2

 

 

  III, 硬件层次3(根本原因)

 

 

这些失效影响,模式,原因需要构成一个网络,来阐明是什么原因引起的失效模式和失效影响。 以静电防护为例

D115 为防静电TVS,如果TVS损坏则会带来防护ESD不利的影响,失效网络关系图如下:

按照底层往上层的思路分析,会得到如下一条网络:

产品不满足客户EMC,ESD要求<Flex ray 不满足客户EMC,ESD要求<Flexray硬件无法防护ESD<Flexray电路TVS 损坏断开。

当然不满足客户需求的原因由很多,这需要工程师对每个元件都做到详细的分析。当无法满足客户ESD,EMC需求是,可以对着DFMEA的思路顺向查找失效原因。

 

以上是小马这几天对DFMEA的浅薄理解,文字水平有限,也没有先理好思路再下笔,纯粹想到哪写到哪,各位看官如果有不同的意见和建议,望指正。

 

posted on 2018-11-16 16:49  Jeanco  阅读(5639)  评论(2编辑  收藏  举报

导航