China
  • 021-57675563

当前位置:知识中心 / 轩田技术篇 /

技术讲堂 |MES 的开发和接口

发布时间:2023-03-23    浏览人数:1人查看

MES 不是一个部署完就不需要再开发的软件,特别是在精密加工行业,例如半导体。在工艺不断进步的时候,一个可以配合工艺改良,生产效率提升的 MES 才是一个企业成功的关键。当然,成熟的产品,已经可以提供很多现成的功能,但只适合一些需要快速投入生产,跟着领头羊的快速跟进者(也就是行业所说的 FastFollower),要是想要和头部企业进行竞争,那就要走一条不一样的道路,不能只是墨守成规。


MES 的开发是一个很有意思的课题,首先第一个要探讨的问题是,把业务逻辑写在客户端还是服务端 ?


首先差别到底是什么 ?


把业务逻辑写在服务端的好处是,可以回滚 (Rollback),例如同时处理 20 个 IGBT 模组(或 25个 晶圆)的 TrackIn 或 EDC,如果第 X 个物料不成功,每一个物料都不会 TrackIn。反之,写在客户端,只能一个一个的 TrackIn,当第 X 个物料失败时,其他的处理起来就比较麻烦了。这也是一般 MES 都提供 Dispatch Material 和 Dispatch Materials (有 S 代表多个)的原因。


image


那为什么还有人在客户端写业务逻辑呢 ?


当年 FactoryWork 2.X 至 3.X的开发,服务端的代码是用 C 写的,但客户端则是用 VB6 写的。当时就有两个派系,欧美日系都是用 C 来开发的,而亚洲派系则是用 VB6  把业务逻辑写到客户端中。亚洲工厂往往比欧美工厂更快速的上线,因为 VB6 做为 RAD (Rapid Application Development,快速应用程式开发工具,低代码的祖先)是一个最佳的工具,WinForm 到今天依然阴魂不散的在 .NET 世界持续着。但是在实现复杂的逻辑和联动上,客户端的代码是很糟糕的,时常会出现物件的状态在没有做完业务逻辑之前就改变了。


还有一个更现实的原因就是服务端的代码不好除错(Debug),要一个不懂 Unix 的人去用 xdb ,我估计会要他老命。就算是现代不用 Unix 的 MES,例如Camstar,CM 等,要做 Remote Debuging 也不是一件容易的事(把 Visual Studio 挂到一个 Process 上),很多年轻的工程师是很难去接受的。


近年来,大部分客户端都是用 HTML5 + JavaScript/TypeScript 去实现的,这样其实让客户端的代码更加难写(说实话,网页端真心做不了太复杂的业务逻辑)。


一般上实施 MES 要有两组人,一组人做客户端(HTML5),一组人做业务逻辑 (Jave/Python/C#)。


这也是当年 FactoryWork 的用户,很多亚洲用户只用 VB6 的原因,不需要两组人,一组可以了 (其实我觉得是被系统整合商带偏的,VB6 的开发便宜,可以多赚一些)。


不管如何,MES 的开发和 EAP 有很大的关系。EAP 需要用到 MES 的不同接口才能代替人为的操作,把手动的事变自动了。


image


这里要探讨一下第二个问题,什么是好的 MES 接口 ?


早期的 MES 接口都是客制化的,例如 FactoryWork 用了著名的 MBX (或是 DMBX),部分用了 TibcoRV。通常客户一定要使用厂商提供的 DLL,才能和 MES 进行沟通。一直到 WebService 开始流行的时候,大家才能够直接送 XML 格式的资料去和 MES 进行沟通。但实际上,直接用 WebAPI 去和 MES 沟通的其实是很少的,没有人会花时间去建一个 50 个元素的 Json (Json 恶梦,其中 80%的元素是 Null),依然需要厂商提供库(.js, .DLL 等)。


以下是一些典型的 MES 接口的应用(如LoadMaterial和 CreateRecipe).


LoadMaterial:

image

复杂的接口


image

简单的接口


CreateRecipe:

image

复杂的接口


image

简单的接口


大家可以注意到好用的 MES 接口,一行就完成了,但是不好的 MES 接口需要客户写一堆的代码。在如今这个 “家家都有低代码平台“ 的年代,这更是一个很重要的选型考量指标。别意外,依然有厂商提供很难用的接口和使用方式。


我们一直在思考,如何提高开发人员的效率和操作准确率,其中,不断优化接口是我们努力的方向之一。


部分图片来源网络,如有侵权,联系删除。


微信文章底图