MES中的松耦合设计一例

 

在不少领域，MES深入地参与现场作业，如将防错、配方等指令下发给工位和设备PLC，以指导现场作业。

通常这种MES与设备PLC的交互是实时通过OPC进行的，并且伴随不少的握手互锁逻辑。

但是在一些工厂，业务部门出于对IT系统的不信任，明确要求在MES服务器宕机的情况下不影响现场作业，从而实现所谓的松耦合设计。

以发动机拧紧防错为例，通常拧紧防错的方法是在MES里配置的，比如将机型在各工位的防错方法分配到拧紧枪号，并定义方向、次数、套筒号、扭矩等参数，但是拧紧的实现操作是由工位PLC配合拧紧枪控制器实现的。

因此对于工位PLC来说，有两种执行防错的方式：

方式一：每次当发动机到达拧紧工位时，工位PLC从MES下载拧紧防错参数，然后执行拧紧作业，此谓与MES的紧耦合设计，依赖与MES的实时通讯。

方式二：每次当发动机到达拧紧工位时，工位PLC从MES之外的某个介质获取拧紧防错参数，然后执行拧紧作业，此谓与MES的松耦合设计，不需要与MES进行实时通讯。

方式二的介质主要有两种：RFID与条码。

如下图所示，防错配置数据通过MES服务器>>OPC服务器>>IT PLC>>工位PLC>>RFID进行传递，在上线工位由工位PLC写到RFID上，并可在实际上线作业发生之前提前下载并缓存到IT PLC上，从而实现上线工位的松耦合。

当发动机到达装配工位时，工位PLC从RFID中提取防错配置数据，然后与拧紧枪控制器一起执行拧紧作业，因此拧紧作业发生时也不需要与MES进行实时交互。

利用条码进行防错也非常类似，在上线工位为每个拧紧工位打印一张拧紧参数条码，然后张贴到随车单上，当发动机到达拧紧工位时，操作工扫描对应工位的条码，即可将拧紧参数传递给工位PLC。

 

前面提到的IT PLC可以起到一个关键的数据缓存作用，即在上线作业实际发生之前，提前将上线所需的工单和防错配方等数据下载到IT PLC，这样在上线时，工位PLC直接从IT PLC获取数据，从而绕开了MES上层应用环境。

此外，IT PLC还可以起到数据上传的缓存作用，即设备PLC将业务数据(如过站记录和追溯数据)同步给IT PLC(工位PLC在普通作业工位将数据写到RFID，然后在同步工位将数据提取出来同步给IT PLC)，然后由IT PLC在MES系统可用时同步到MES服务器，这样对于工位PLC而言，它无须与MES服务器进行通讯，更加专注于装配作业本身。

 

 

 

MES案例研究3 – 质量门检查

某发动机工厂的总装下线工位成为一个瓶颈工位，平均操作时间近2分钟。

该工位有一些简单的附件装配作业，并且配置了质量门检查。

由于业务逻辑较复杂，首先从数据库的层面进行检查，发现此工位的一个关键查询SQL查询时间较长，用了近86秒。于是先对硬件进行升级，把SGA从4G升到8G，结果查询时间降低了18秒，略有改进，但还不能达到业务设定的节拍时间。

接下来进一步分析业务逻辑。

最终下线质量门是一个综合检查站，要检查：

1)       发动机的工单状态是否正常。

2)       发动机的质量状态是否正常。

3)       发动机是否被质量扣留。

4)       发动机的检测结果是否正常。

5)       发动机是否有未清除缺陷。

6)       发动机的AUDIT结果是否正常。

7)       发动机是否经过所有的关键工位。

8)       发动机是否存在少装或多装零件。

这其中，逻辑最复杂、最消耗资源的是最后一步少装检查。

少装检查的逻辑是：

少装/多装物料 = 应装物料(BOM) – 已装物料 + 实时替代件转换

技术方面的困难主要是因为：

1)       BOM是一个动态的结构，需要根据工单上线时间、结构有效时间、零件有效时间进行动态地计算。

2)       存在分装，并且BOM也有层级结构，这样计算BOM时需要进行递归查询。

为了减少动态计算BOM的时间，从技术上可以采取以下方法：

1)       建立一个视图，字段包含所有总成件、分装件、零件等对应的所有信息，用上线时间作为计算的依据。

2)       建一个物化视图，对应此视图的结构。

3)       定期刷新物化视图，从而提前得到需要的数据。

这个改进有效减少了实时递归查询所消耗的时间。

另一方面，对业务流程进行改进：把该工位拆分为两个工位，第一工位做装配，第二工位做检查，这样就减少了装配作业所占用的时间。

经由上述改进，终于把工位节拍减少到58秒，满足了生产的要求。

test

just a test...

 

MES案例研究2 – OPC网络阻塞

  

某工厂使用OPC SERVER作为协议转换层，实现MES SERVER与现场PLC的通讯。

现场有2个车间，约有近20个工位需要和MES SERVER通讯。

等到所有工位都调试通过，系统也上线运行了一段时间之后，突然发现一个很妖的问题：OPC响应会越来越慢，最后造成一些工位完全没有响应。

一开始我们怀疑是网络的问题，于是把两个车间的网络隔离观察，发现问题仍然没有解决。

后来我们怀疑是应用的问题，于是在后台查看OPC CLIENT通讯的日志，依然毫无头绪。

接着我们怀疑是OPC客户端配置的问题，于是把所有工位的OPC配置按照手册重新设置了一遍。

这样下来，我们几乎折腾了半个多月，但是问题依然象幽灵一般存在，搞得业务部门非常不满。

后来我们想到试着去看OPC SERVER的事件日志，因为每次OPC通讯建立连接时，客户端是作为一个远程用户登录到服务器的，所以服务器应该会记录登录验证的信息。于是我们按照这个方向去查，也确实发现了不少登录的日志，但并没有显示IP地址、HOSTNAME等有用的信息。

后来我想到我们是用域帐户作为OPC远程用户进行登录管理的，那么理论上每次登录验证都需要通过域控制器进行。于是赶紧联系域管理员，从域控制器上导出最近一个月的事件日志，然后把此日志经过处理，筛选得到所有指向OPC SERVER的登录验证信息。经过这样处理，果然大有发现：有2台PC异常频繁地请求访问OPC SERVER，于是抄下这2台PC的机器名和IP 地址，到现场了解情况，很快地真相大白：原来这2台PC是用于HMI的，安装了XP操作系统，然后运行WINCC RUNTIME，由于PLC工程师不断地通过U盘拷贝程序和文件，结果感染了病毒，因此这2台PC不断地申请访问OPC SERVER，进而形成类似DDOS攻击的效果，从而造成OPC网络瘫痪。于是我们将此2台PC断网杀毒，车间的OPC网络马上恢复正常运行。

这个案例给我的教训是：

1.       一定要做好生产网络的隔离。首先务必要将生产网络从办公网络隔离，其次不同车间之间最好也划分VLAN进行隔离。

2.       不仅是运行MES客户端的PC要安装杀毒软件，HMI、测试机台等也都要安装杀毒软件，从而防止病毒的入侵。

3.       由于早期版本OPC采用DCOM进行远程通讯，在典型配置时OPC服务器的安全等级非常低，容易被入侵，此时条件允许的话，要考虑配置用域账户管理OPC远程登录，这样可以通过域控制器的事件日志回溯每次的登录请求，方便日后追查分析。