ks分析

K现阶段主要关注两个部门，一个是刀具使用，一个是人员管理，包括OP和技术员。

一 ,刀具

1，一个刀具示意图如下：

a,刀具由刀柄跟刀盘及刀立组装而成;

b,一个刀盘上可以装N个刀立；

c，一个刀立坏了或者刀具寿命到了，这个刀盘上的所有刀立都要换下来，因为无法知道是哪一个刀立坏掉了,换下的刀立可以

     可以翻转一下再装一次，以后就报废了；

d,这样设计的目的是换刀具时只需要换刀立，节省成本；

 

1.1 刀具总仓：

刀具由多个部分组成，进料可能就会有各个部门的材料来自不同的厂商，为方便讨论，把刀具分为刀头(也叫刀具)和刀柄两部分。

a,刀具编码

每个刀柄和刀具上有进料料号  和 二维码，

如 刀柄料号：BT30-D14-80-N

     二维码：  AaBT0150002  （Aa厂商号，BT01刀柄识别码，50002:刀柄流水号），以后就根据这个二维码来追踪刀柄和刀具；

刀具料号又不一样。

b,总仓12小时报表：

总仓可以对进料进行刀具，刀柄二维码编码，绑定工作，但是每天需要进行多大量的绑定，绑定那种类型的刀具刀柄，是不知道的。

传统的做法：根据CNC机台数目，根据所生产的产品不同(产品生产周期一般较为固定且周期较长)提前一天备好前一天两个班次 

                        的刀具刀柄。中间遇到刀不足或者多备了刀，进行多次补充，总结经验，形成自己的总仓备刀公式。

现有做法：根据系统统计的刀具寿命预测表，生成一个未来12-24小时的表格，总仓根据此表格来备刀。

总刀仓组装绑定好刀后，根据他们自己掌握好的机种位置信息来把这些刀送到不同楼层的不同分仓里去，摆在分仓的料架上。

b,总刀仓流程：

iqc ：刀具，刀柄 检测外观---》尺寸测量---》zoller检测-------》二维码检测----》

         刀具，刀柄 绑定 -------》刀粒安装----》入库

c，刀库号：

     每个cnc设备有多把刀，每把刀的类型可能不一样，每种类型的刀总仓备在每一个库中,这里就形成了刀库，每个刀库就有刀库号；

e，分仓6小时报表:

    分仓根据6-12小时的报表，把料架上的刀装到小车上，每个小车对应一个cell，等某一个技术员来推车的时候，把技术员绑定在车上，以后技术员就负责这个小车。

f，移动换刀及追踪

技术员负责小车后，就可能对一个cell里的设备进行换刀，这里分为正常换刀和异常换刀。

正常换刀：假设刀具理论寿命为100，当前刀具计数器由99->100后会触发换刀报警，技术员对此刀换刀就是正常换刀。

异常换刀：当前刀具计数器还没有到理论寿命的换刀，比如出现的断刀，或者别的情况引起的换刀。                 

不管哪种换刀，技术员换刀前，清零 刀具寿命当前值，扫描机台号----》扫描旧刀号(根据这两个号可以查询到此刀的寿命，可以知道此次换刀的原因，  ，扫描新刀号，并知道此新刀跟哪台设备绑定了。 这里要根据换刀原因，要把换刀原因写入数据库，应该是技术员在做完换刀动作后，输入换刀原因到数据库。 若换刀原因为异常换刀，还要追踪从旧刀上机到旧刀下机这段时间所做的产品有哪些，并把这些产品抓出来。

g ，首件报警及处理

     换刀流程后，必须做首件，首件运行完后，刀具计数器由0---1,会触发首件报警

     首件报警-----》技术员开门把产品拿到qc那里进行检测，此机台原则上是不进行产品生产的，但是ks会继续在此机台生产，等待qc把首件结果给到数据库时，才会知道首件的结果。跟石课的讨论是：在计数右0变成1后，不断的读取ipqc的那张表的结果，知道读取到ok后，标识没问题，如果有问题，等此台设备加工完当前产品后进行锁机，并根据时间点进行追溯不良品。这么操蛋的流程，不知道谁定义出来的。 而且要根据qc的结果，看此次首件失败的原因，如果是刀尺寸没调整好，调整好尺寸，清零刀具计数器，继续首件，如果是刀的原因还要设计到换刀流程；这里就是异常换刀。

二，人员管理

  1，op: 上下料时间，待料时间 （在连个G之间找这两个时长，其中可能包括多个YOYO,或者只有一个Y,一个O,或者连个G之间的存在）

                标准情况： GYOG ，上下料时间，待料时间很好区分

                只有两个G的情况： 目前观测的结果是：连个G之间漏了一个时间断，可能是采集服务突然停止服务了

                                                  此时把这个空档期的一部分变成带料，一部分变成上下料统计（1/2）

               多个YOYO的情况： 累计Y左为带料，累计O作为上下料

                GYG 或者GOG：  这种情况，目前还是会记录并显示在散点图中(是否有必要显示?)，这应该是另外一种异常，可能是

                                              采集状态的遗漏(变化太快没有统计到)，或者其他异常。

  2，技术员：

   a 正常换刀时间统计：

       换刀报警：  刀具计数器变成刀具理论寿命值

                     待刀时间： 换刀报警开始时间 ------开门时间

                     换刀时间 ：换刀报警开门时间开始时间 -----下一次正常运行的时间；

  b,异常换刀：刀具计数器突然从非0值变成0： 这种情况是否要单独讨论？怎么监测异常换刀？采集端监测，若有这种变换就生                         成一条记录?这里涉及到刀具寿命的统计的正确性，很复杂；

c，其他系统报警： 等待解决报警时间：从报警开始到开门时间   ，  处理报警时间： 从开门到 下一次正常运行时间

d,   调试时间：调试开始到开门时间，开门时间到下一次运行正常时间

那这样抽象出来，对于技术员的时间统计就是：1，发出报警到开门时间的统计； 2，从开门到下次运行的时间的统计；

3，ipqc时间： 首件报警对首件的处理时间 ；  首件完成后的开们时间 + 到ipqc把记录写到数据库的时间

 

三，系统对接

要做到满足ks的需求，这里会设计到3个系统的对接(3个数据库的对接,也有api),包括dms,客户系统，trace;

1,客户进料总仓的刀具信息，抓取二维码唯一标识，也贯穿刀具的使用周期。

2，移动换刀时，ipqc的首件检测结果的轮询查询，来确定换刀是否成功，这里需要读取客户表；最好方法是与客户建立通信连接，首件成功后，由客户主动发送结果过来，而不是我们无限轮询结果；

3，首件不成功或者断刀，异常换到的的产品追踪，要根据时间点追踪生产的产品的流向，简单的就是查询到哪些产品用不好的刀生产的。

4，需了解trace现在做了哪些功能，按这些描述，刀具追踪的这些事情应该放在trace中去做，而我们需提供查询刀具寿命的api或者数据库；

 

四，总结

1，客户的需求确实跟他们产线的问题以及管理层想要解决的问题高度相关；

2，满足客户需求需十分熟悉他们的业务作业流程，而每个客户的作业流程又不一致，存在的问题就成了到底是根据客制化需求来做产品，还是抽象出通用需求，把客制化挡在外面的做法；

3，ks的需求越来越具体，我们的产品也越来越像项目，我们想做成什么样的产品，要有明确定位,但是为了生存，做项目也不可避免，可以从第一个项目中越来也熟悉业务；通过中间层屏蔽客制化差异，来适配大部分项目，这是不是就是产品？只是中间层会越来越大。