|
|
EDA365欢迎您登录!
您需要 登录 才可以下载或查看,没有帐号?注册
x
一、对可靠性的基本认识# m u8 ]$ l- X# o8 a
$ z# X% M b& F' f2 b s1 T可靠性,是质量控制的一个分支。但是把可靠性提升到一个专门技术来看待,是产品不断追求完美的一个必要阶段。我国可靠性研究起步较晚,伴随而来的可靠性分 析技术,可靠性设备相对落后。在质量管理体系的跟进方面,比如ISO9001,中国似乎很快就赶上先进国家了,但是ISO,形式主义严重,不管是大大小小 的公司,几乎都通过了ISO认证,现在我国企业ISO运作的现实是,基本上对质量水平的提升没有突破性的进展。未来企业之间产品实力的竞争,将会是可靠性 水平的竞争。所以,可靠性研究的地位,将会越来越重要。
& |( D! G& z3 `+ r9 Z6 _( v
+ m- A, X x8 Z( P; k8 `9 ^二、关于可靠性研究的架构形式与运作模式5 M4 y! {1 ^; ]$ ~5 c0 P
; v+ [2 j4 m" \. F2 x
可靠性工程师,表面上是一种形式的设置,事实上体现了企业对可靠性的重视程度。2 Q0 N/ S" _9 C0 F* a
9 `! \8 B# q8 s2 B @
传统的产品质量控制,也有一些可靠性控制方面的工作。比如开发部门的DQE(开发测试工程师)、品质部的QA、QE,都有一部分的可靠性工作。但是,这种 模式,以对产品的功能,性能,安全测试为主,失效分析也停留在比较表面的部分。所以,有时即使看起来在控制质量,也有一些措施,但是不良仍然不断在发生, 原因就在于没有分析到本质问题。
( {' g& ] L2 \0 _6 b# H# k3 E/ D
3 y( X; R3 O( E* B) \ 可靠性研究的两大内容就是失效分析和可靠性测试(包括破坏性实验)。两者之间是相互影响和相互制约的。
; Q) _& Y: y3 |
5 h7 F6 D; t8 X/ G9 C; C3 P2 p 不过为了使事前简化,可以把这两大内容分割开来看。把失效分析和可靠性测试当成是可靠性研究的两个境界(严格讲来,这种分法不是非常恰当,此处只是为了简化)。企业可以根据自身的实际作出不同的策略。( W7 y, S6 M- O' a. o
8 C# K5 B6 i. [$ l 以失效分析为主要内容的模式,相对来说是比较被动的模式, 是等问题发生后才去分析问题的。当然,失效分析结果出来之后,可以反过来影响测试、开发、 工艺、流程、筛选标准等。这种模式又可以根据自身情况,把失效分析做到不同的境界。这种模式,即使是简单的境界,也能实现低投入高回报。规模较小时,比如 我们公司开始时可以采取这种模式。9 V: ?2 j5 R( Y5 @4 l
}" v) o) g. Y
以可靠性测试(包括破坏性实验)为主要内容的模式,是从源头上保证可靠性的一种方法。这种模式是一个系统工程,要求的实验设备非常丰富,投入的人力和时间 也多,还有对信息的收集和统计(“只有在统计受控的条件下生产的元器件才会具有高可靠性”)投资非常大。目前我们公司还不能完全满足这个条件。
$ s/ G, N2 f2 G% y3 L$ ~ ~
2 Q9 r# h! D8 w% S# q 下面谈的是我对以失效分析为主要内容的模式时,可靠性研究架构的看法。" y4 X3 }9 b! b+ \+ G) L
: g4 x6 S' }- \% W" z+ A7 X 这种模式,由于规模小,所以不足以成立一个专门部门。但是可 靠性工程师(或失效分析工程师)是一个必要岗位。当然可靠性工程师分在品质部还是开发部 直接影响到失效分析的效率。就像品质部必须脱离生产系统一样,可靠性工程师必须安排在开发部,才能发挥更大的效力。常规的品质问题,还是由品质工程师处 理。而可靠性工程师,主要分析的是返修率高的元器件失效,或对生产影响比较严重的元器件失效。否则就不会有这么多的精力解决重点问题。当然,可靠性工程师 并不是单打独干就能解决问题。所以,在处理某种重要失效时,可靠性工程师必须牵头组织,成立失效分析专案小组,明确专案小组成员的责任,共同分析问题,查 出原因,定位责任,提出改善措施,跟踪实施效果。这方法与品质PDCA循环类似,但必须把失效原因定位更加专业准确,提出的解决方案也必须更加有效果。失 效分析专案小组可以由固定的人员组成,也可以针对实际情况具体指定人员。专案小组成员,除了可靠性工程师,一般都会有开发、工程技术、品质、生产等人员组 成。* K8 \; r1 a" c$ I/ x6 J
- m& l0 f4 `1 r7 X7 x3 D 所谓的“某种重要的失效”,提出方可以是市场客服人员,也可以是生产部,或品质部,甚至开发部自身。
+ F/ b7 C5 k) w8 H5 J
6 E q- _5 j, L7 @/ t2 T+ U三、可靠性工程师的素质要求之我见
3 o) v8 a. I" H1 l1 a* h. Z0 }1 e/ p: e! j) P* w
可靠性问题,基本上都可以归结到元器件失效,(少部分是系统兼容及环境干扰引起)。换句话说,产品出去客户那里使用时不良,基本上都可以归结到元器件(还 有软件)失效引起。所以,失效分析的精华就是元器件失效分析。但是元器件失效,除了元器件件本身可靠性差,还有设计、工艺、人为、环境应力等引起,或者是 由综合因素引起。至于元器件本身问题,按照供应链管理的思路,追溯到供应商那里,同样可以归结为其原材料可靠性差,设计、工艺、人为、环境应力等引起。所 以,可靠性工程师,必定要求对元器件的设计选用、测试、生产工艺熟悉。从我个人角度来看,我认为,可以多与供应商沟通,对于不了解的元器件甚至可以到现场考察交流。1 u/ Q& P; F# p% m4 c4 n& L3 m
5 r9 x7 G2 @ v b. b 其次,必须对电子技术本身非常熟悉,否则,系统的工作原理不了解,就没办法深入地分析失效原因,特别是设计层面的问题。8 |7 K% p: Z# h. C; q4 d
/ L, V+ }0 A. D1 s' ~0 V q 必须熟悉物理化学等知识,因为失效机理的最深层次原因基本上都是物理化学作用引起的。我本人为此还决定重新复习高中和大学的数理化知识。! k! F7 B8 o- i7 O8 G
3 Y* s% r* E+ {7 t必须懂得开发设计原理,否则就找不出设计原因引起的失效。而设计原因引起的失效,又占元器件失效很大的一部分。5 {' `( _7 S' i& l) p" l& t' U, t
( S- |3 ?& i9 \6 n" @ 熟悉生产工艺。+ [* K0 q* t4 B
7 f* t! X x# K E, y 逻辑严密,具有推理能力。同样的失效现象,有可能有不同的原因引起。在失效分析技术中,提出假说(有点像科学研究)是很常用的一种方法,然后拿良品按假说实验,重现失效现象,印证假说。" W% }3 V9 N: N3 t: t- l
8 P5 y) s) ]" Y" L
考虑问题全面,小心谨慎。失效分析其实 不仅仅只“挑刺”。处理问题还必须以企业的实际情况相适应,考虑全局利益。比如不可能拿军用标准来要 求工业用和民用的元器件。不可能不考虑成本因素而无限要求质量。所以发现问题时,可靠性研究必须提出筛选方案,保证能把有隐患的不良品提前暴露出来,又不 会由于不恰当的测试应力增加隐患。而对于某些情况是否可以放行,必须提供数据或理论,以免误放不良品,或者过于谨慎而造成浪费。3 u# @1 X9 O& W+ Y% l
1 K% k% w6 @8 a" j) C 实事求是,数据必须真实可靠。否则会给决策带来失误。9 ]. H X" o" ]1 L3 ?3 {
! A! n3 D$ _9 K! `8 H
其他。
. r# h$ g; n- |( _
6 C' b, i. Q( F; f, _四、关于流程和数据可靠性研究如果是以可靠性测试(包括破坏性实验)为主要内容的模式,可能会有很多规范与流程。不过对于以失效分析为主要内容的模式,我认为程序会简单一点。主要是要制定出失效分析专案小组的工作流程。至于更多的流程,可以在实际工作中根据实际需要,逐步建立。另外,还可以借鉴别人的经验,甚至可以到有可靠性分析的供应商那里取经。另外表格方面,肯定要有比较专业的失效分析及改善报告。失效分析报告在不少国家甚至已经规范化了,可以结合企业的实际情况恰当修改。一份专业的失效分析报告,几乎可以把该考虑的内容都考虑进去了,别人拿到这种报告,基本上可以对分析的来龙去脉知道得一清二楚。数据方面,我认为有以下一些数据必须收集:$ g" K3 V0 V, R3 m' u6 ]
# k8 @; }4 H$ } V关键性的可靠性测试项目和规范。即使可靠性实验不能全部做,也要挑取对产品影响最重要的一些项目来测试。这个主要是针对我司成品或半成品而言的测试。在必要时,要求供应商对其元件测试一些可靠性项目。0 {, u. v9 P# v& q0 j! h; G& \1 ]
4 l& A* ]2 N- R9 t收集公司产品的使用环境情况,为开发的可靠性设计提供依据。* q$ U$ v9 {, h7 P
% K! z e+ A- `6 {& |7 O! I
统计分析返修率高的元器件失效,或对生产影响比较严重的元器件失效。并为改善措施是否有效提供对比数据。如果人力资源充足,甚至可以对所有元件的失效率进行统计。/ |2 ]. O( W# X
5 S* `$ s2 S# n% o! U$ d& [收集各种类型的元器件的失效率允许范围的数据。比如,某个元件,生产时失效率是万分之二,这个失效率能不能接受呢?如果把挑选过后的良品放出去,会有多大隐患呢?后续怎么跟踪呢?这些数据都必须收集。
4 {7 K; C E. W3 R+ k% m. G, k' ]& U8 v ^
五、失效分析的资源配备7 u# V; \' l; w) K- s E6 \
( k9 ?/ |2 k( E) Z5 Y i
硬件方面,一般公司的情况,不足以配备非常完美的失效分析工具和可靠性设备。要根据失效分析的深度和广度来提出相应的配置。我个人的看法是,最基本的失效分析工具应该配备一个显微镜,以便从微观的方面,查清楚失效部位的物理表现。当然,对于显微镜的价位,如果过于昂贵,可以考虑暂时不买。另外,由于冷热循环最容易暴露质量问题,所以有必要时,可以考虑配置冷热循环试验设备。. @* d T+ U5 n. r
8 r7 G" R2 B/ W$ @2 t! l& |% B& m
“软件”方面,需要的支援。包括上层领导对可靠性的重视,还要像全员品质控制一样,使所有人员都有可靠性的意识。可靠性意识方面可以请外训或一些培训机构或失效分析机构来公司培训或开讲座。(开讲座未必一定要钱,如果是一些仪器销售公司,他们为了增加销售机会可能愿意来讲解可靠性方面的知识)。必要时公司和一些外界研究机构建立长期的合作关系。另外,失效分析很重要的一点是分析机器在客户那里的失效。对客户的使用情况和使用环境的信息越丰富,分析起来就越准确。这时,可能需要市场业务人员积极配合,并且有意识地收集相关信息反馈到开发部。必要时可靠性工程师还必须到现场收集信息。
& K4 U- E) k* m2 O! N" N: t6 F! J' i( B# G; T* z2 ]- O* Y3 ^8 f
六、可靠性工程师的定位,以及刚设立可靠性工程师时如何上手
" ^7 P0 B2 F7 m: ~# D0 M( ~) N+ A* h
技术方面,可靠性工程师主要是对失效得出专业的原因分析,把责任定位得非常准确,并提出有效的改善方案,同时,为筛选标准提供专业的理论或数据,为是否可以放行提供专业的理论或数据。有的工作可能与品质工程师重叠,但品质工程师做的可能会有广度,但深度不足。我认为两者主要还是在专业程度方面的区别,可以认为,可靠性工程师必须解决品质工程师解决不了的失效问题。开发工程师,而生产技术工程师,生产管理人员等,主要是为设计或工艺或人为引起的失效负责,并实施改善。如果设置可靠性工程师,我认为近期的工作重点,可以从解决影响生产的失效做起,这是最浅层面上的工作。如果们公司有不少反复发生的不良,问题没有根治,严重影响生产。可靠性工程师有义务去解决这些老大难问题。而考核可靠性工程师的主要标准我认为就是对这些问题的解决效果。更为长远的目标,可靠性工程师必须关注产品在外面的失效,解决其中比较严重的问题。鱼骨图是失效分析的最基本工具,不管表达方式是不是做成鱼骨图,但一定是按此思路来分析问题的。我认为并非一定要按人机料法环之类的归类,不同的环节的失效,鱼骨的主干是有所不同的。所以挂在鱼骨的主干上的相关人员及其责任也会有所不同。我个人倾向于采用灵活的鱼骨图,并且对鱼骨各支对本失效的影响程度作定性的分析。(对于“程度”这个词,比较难以量化。不过或许可以摸索出定量的方法出来)。& Y" ?, L, d' R0 m0 u, D3 f$ s
7 O* G2 P) B% G/ W$ a" s0 c: @
七、可靠性工程师最好应设在开发部的理由" \, H1 b1 k7 r! H7 E- G
8 @: \. F% T7 b5 `0 T# a+ ]" u首先,从技术权威的角度来谈,由于开发部是技术权威,而可靠性工程师必须有技术权威作后盾。其次,解决问题的力度方面。如果可靠性工程师在其他部门,提出改善方案时,特别是与设计有关的问题时,推动开发改进比较难,但是如果把可靠性和失效分析的主要责任放在开发部时,自然会更积极解决问题。其三,如果把可靠性工程师放在其他部门,那么失效控制是后端控制的方式,而把可靠性工程师放在开发部,是源头控制的方式,当然成本更低。最后,说句不好听的话,把可靠性工程师放在品质部,处理问题有可能形式主义比较严重(从我个人的经验来看,品质部一般是形式主义比较严重的部门)。过于重视“政绩”和影响力,而更少从合适的角度考虑问题。而放在开发部,可靠性更像是一种内需,更看重实事求是。% w$ p# O' i8 N( Y( q o( c9 V
+ A5 |4 a" |" N% E+ \8 t& m八、失效分析的一些其他想法
8 Y& s" @8 Y# n, S
3 ^5 S, a* `7 M$ ~- j专业的可靠性实验设备、失效分析仪器以及元器件分解的工具材料种类很多,并且大多仪器非常昂贵。所以,不可能什么都配备。一个可靠性工程师必须考虑企业实际情况,选择成本允许而且是必须的工具。至于有的分析实验,可以到供应商处做,充分利用能够利用的资源。另外一些更复杂而且必要的分析,甚至可以和一些失效分析研究所合作。- c; |7 _) p+ U% w9 @' N
% G( _+ t: f8 ^6 b c! o |
|