<pjx class="mwtwvo"></pjx>


PC加拿大官网,加拿大预测

China
  • 021-57675563

当前位置:新闻资讯 / 公司资讯 /

“乘风破浪开新局,筑梦前行扬征帆”--PC加拿大官网集团云年会盛典

发布时间:2022-02-23    浏览人数:100人查看


文 ▎刘用文
 
当封装测试厂决定要实施 EAP 时,Recipe Management (配方管理,RMS) 一定是计划中的一部分。管理层普遍的想法就是,实现了 RMS 以后,我们就再也不会发生生产时选择错误的配方和参数的事件了。有些管理层还甚至认为能够离线的进行配方和参数的修改。
 
实际上,从 197x 年 SECS/GEM 协议开始至今,RMS 在封测厂的应用没有太多的进展。最主要的原因是封测设备厂方不愿意配合。
 
     在 SECS/GEM 中 Recipe 有另外一个名称,Process Program (又称之为 PP),SECS/GEM 中处理 RMS 的S7Fx 指令中就是 Process Program 作为说明。
 
RMS 这个课题大约要分成几个部分说明,以下是一些封测厂相关的 RMS 说明:
 
1)RMS 的相关功能包括了上传,下载和选择。在实现 RMS 功能的时候,最简单的做法就是提供一个功能画面,让操作工扫描 RUN-CARD (跑单或是工单)上的批次号,EAP 再透过接口去向 MES 解析对应的产品和设备,找到对应的配方,然后再下载到设备。实际上,可以做的远比这个复杂,例如从设备上传配方到服务器。
 
2)RMS 只能保障生产时不会选择错误的配方,但不能保证在生产的时候,操作人员修改参数和配方。这也是我们时常告诉客户的,RMS 只是半套,你需要参数监控(Parameter Control and Monitoring, PCM) 才能完整的确保生产时不会出现因为参数不对而造成的问题。
 
3)不是所有的设备都能实现 RMS 。RMS 要实现的最重要因素之一就是 Recipe 的可重复使用性和跨设备能力。例如焊线机 (Wire Bonder),Recipe 是可以从一个机台直接拷贝到另外一个机台,然后经过微调就可以直接使用的。而贴片机 (Die Bonder) 则是传统上不去实现 RMS 的,因为 Recipe 从 A 设备直接拷贝到 B 设备后,必须经过长时间的调试才能使用。一般我们会实现的设备种类包括了划片(Saw),磨片 (Grind),焊线 (Wire Bond),塑封 (Mold),烤箱(oven) 等。
 
4)大部分的封测设备 Recipe 都是黑箱,所谓的黑箱就是不可解析的(更不要说是不是按照 SEMI 标准的 Formatted Recipe )。设备厂商如 KNS,Recipe 是经过两次的压缩的文字档,Disco 则是文字档的格式,ASM 则是必须要有特殊的编译工具。不知道 Recipe 的内容,会让我们无法去实现参数比对 (就是指无法知道 Recipe 的参数被修改成什么了)。
 
以下是RMS 实施中面临的挑战:
 
1)RMS 实施的最大挑战就是命名规则,通俗一点就是如何去命名 Recipe,从而找到其独特性。我们的第一个 RMS 项目,生产部门花了近 3 个月才找到如何建立独特的焊线 (Wire Bonder) 的 Recipe 命名规则,为什么不能直接用产品 (Product 或 Device) 的名称 ?最主要的问题是,产品有时候是因为客户的不同而有独立的命名,但是实际上是同一个东西,也就是包装(或印刷)上不同而已。如果用产品命名,就会出现很多重复的 Recipe 。还会遇到同一类设备,但不同厂商的命名限制不同,有些老旧设备使用 DOS 的设备,还有 8.3 的限制(档案名字 8 个字母,档案类型 3 个字母)。这个准备功夫往往是 RMS 实现时花最长时间的工作。
 
2)RMS 实施的第二个挑战就是如何找到 Golden Recipe (也就是所谓的黄金配方)。第一个 RMS 项目,客户有 1000 多个产品,400 台焊线机,总共大约 40000 多个 Recipe。生产部门的其中一个要求就是先把 400 台设备的 Recipe 都收集回来,当年的设备只有 3.5 寸的磁碟机,而客户又不愿意找操作人员一台一台去拷贝,所以需要写一个程序,透过 SECS/GEM 的方式把 Recipe 收集回来。收完以后,再来的挑战是在众多命名根本没有规则的 Recipe 中找到其中的 Golden Recipe。这又是一个耗时间和心力的工作,这就不是信息部门可以帮忙出力的事,所以 RMS 的成功与否,其实要看的是工艺部门的投入程度。找到 Golden 的正确方式就是到设备上,打开 Recipe ,确认所有的参数设定都是对的。但大部分情况之下,工艺部门会做的就是靠感觉选择一个“好像“是 Golden 的 Recipe,然后希望在实际应用以后再调整。
 
3)第三个挑战就是审批流程了。我们遇到过客户要求了非常复杂的审批流程,四至五层的审批,从工程师至主管,主管至经理,经理至部门经理,他们甚至要求未来如果有可能要审到处长/总监。出发点很简单,多一个人审批,就有多一双眼睛确保不会出事,但事实上,他们想要的是多一个人审批,多一个人担责任。我们当时提出的点是,如果再往下,审批流程(重要的客户的产品),就要副总,甚至是总经理或董事长了。对 RMS 的审批,我们一直推崇的原则就是当年英飞凌年代学到的 “四眼原则“,如果两个人都无法确认是不是有问题,再多人也没有办法。说实话,Recipe 的审批,如果没有法子离线的打开 Recipe来进行参数的比对,其实意义不大。
 
 

最后,我们认为正确的审批流程,应该是一个工程师制作 Recipe,上传,另外一个工程师需要下载至设备进行验证和检查,然后再审批通过。

 

下一篇我们会继续探讨相关的问题和方案,敬请期待。
PC加拿大官网