- 1、本文档共80页,可阅读全部内容。
- 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
- 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
汽车行业质量体系系列培训教材;一、基本概念;二、什么是FMEA;三、为什么进行FMEA;四、FMEA分类;五、什么时候进行DFMEA;六、什么时候进行PFMEA;七、FMEA中顾客定义;由于一般的工业倾向是要尽可能持续地改进产品的过程的质量,所以将FMEA作为专门的技术应用以识别并帮助最大程度地减少潜在的隐患一直是非常重要的。
对车辆召回的研究结果表明,全面实施FMEA项目可能会防止很多召回事件的发生。
成功实施FMEA项目的最重要因素之一是时间性。其含义是指“事件发生前”的措施,而不是“事实出现后”的演练。为实现最大价值,FMEA必须在产品或过程失效模式被纳入到产品或过程之前进行。
;事先花时间很好地完成FMEA分析,能够最容易、低成本地对产品或过程进行更改,从而最大程度地降低后期更改的危机。FMEA能够减少或消除实施可能会带来更大隐患的预防/纠正性更改的机会。应在所有FMEA小组间提倡交流和协作。
图1描述了进行FMEA的顺序。这并不是简单地填写一下表格,而是要理解FMEA的过程,以便消除风险并策划适宜的控制方法以确保顾客满意。
;;虽然FMEA的编制责任通常都指派到某个人,但是FMEA的输入应是小组的努力。小组应由知识丰富的人员组成(如设计、分析/试验、制造、装配、服务、回收、质量及可靠性等方面有丰富经验的工程师)。
即使产品/过程看起来完全相同,将一个小组FMEA的评分结果与另一个小组FMEA的评分结果进行比较也是不适宜的,因为每个小组的环境是不同的,因而各自的评分必然是不同的(也就是说,评分是带有主观性的)。;初始
FMEA;
设计中的
潜在失效模式和后果分析
(设计FMEA)
;分析;都是DFMEA所要考虑的对象,但
最主要的是针对最终使用者。;建立DFMEA工作小组;
收集必要的资料
设计意图
车辆要求
质量功能展开图
已知的产品要求、制造要求、装配要求
类似的DFMEA资料
准备DFMEA表格;设计FMEA的标准表;1)FMEA编号
填入FMEA文件编号,以便查询。
注:1-22项的举例。
2)系统、子系统或零部件的名称及编号
注明适当的分析级别并填入被分析的系统、子系统或部件的名称及编号。FMEA小组必须为他们特定的活动确定系统、子系统或部件的组成。划分系统、子系统和部件的实际界限是任意的并且必须由FMEA小组来确定。下面给出了一些说明,具体示例见附录F。
;系统FMEA的范围
一个系统可以看作是由各个子系统组成的。这些子系统往往是由不同的小组设计的。一些典型的系统FMEA可能包括下列系统:底盘系统、传动系统、内饰系统等。因此,系统FMEA的焦点是要确保组成系统的各子系统间的所有接口和交互作用以及该系统与车辆其他系统和顾客的接口都要覆盖。
子系统FMEA的范围
一个子系统FMEA通常是一个大系统的一个组成部分。例如,前悬挂系统是底盘系统的一个组成部分。因此,子系统FMEA的焦点就是确保组成子系统的各个部件间的所有的接口和交互作用都要覆盖。
部件FMEA的范围
部件FMEA通常是一个以子系统的组成部分为焦点的FMEA,例如,螺杆是前悬挂(底盘系统的一个子系统)的一个部件。
;设计FMEA框图示例:系统名称:闪光灯;22;3)设计责任
填入整车厂、部门和小组。如适用,还包括供方的名称。
4)编制者
填入负责编制FMEA的工程师的姓名、电话和所在公司的名称。
5)车型年/项目
填入所分析的设计将要应用和/或影响的车型年/项目(如已知的话)。
6)关键日期
填入初次FMEA应完成的时间,该日期不应超过计划的生产设计发布日期。;7)FMEA日期
填入编制FMEA原始稿的日期及最新修订的日期(如下图)。
8)核心小组
列出有权确定和/或执行任务的责任部门的名称和个人的姓名(建议所有参加人员的姓名、部门、电话、地址等都应记录在一张分发表上。);填入被分析项目的名称和编号。
用尽可能简明的文字来说明被分析项目要满足设计意图的功能。
项目有多种功能,且有不同的失效模式,应把所有的功能单独列出。
;所谓潜在失效模式是指部件、子系统或系统有可能会未达到或不能实现项目/功能栏中所描述的预期功能的情况(如预期功能失效)。
这种潜在的失效模式可能会是更高一级的子系统或系统的潜在失效模式的起因或者是更低一级的部件的潜在失效模式的影响后果。
对于特定的项目及其功能,列出每一个潜在的失效模式。前提是这种失效可能发生,但不一定发生。推荐将对以往TGW(运行出错)研究、疑虑、报告和小组头脑风暴结果的回顾作为起点。
只可能出现在特定的运行条件下
文档评论(0)