China
  • 021-57675563

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

技术讲堂 |MES 的底层技术

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

MES 这套软件已经存在了许多年,我们曾经写过一个介绍半导体 MES 发展的短文,这篇要介绍的是现代 MES 使用的底层技术。在过去多年的销售经验中,很多客户在招标需求中都会列出一堆相关的要求,这里希望可以提供他们一些更好的参考资料。


在过去的二十几年,不同的软件发展技术改变了软件的生态,其中主要包括了面向对象(Object Oriented ),对象关系映射(Object Relationship Mapping),Java,容器等这些技术影响了MES 的发展,以下就是一些说明。


image


面向对象 (Object Oriented)


面向对象的概念是由 Alan Kay 在 1969年提出的,在美国 APRANET (国防研究院)的赞助下开始了研究。Alan 在 1981年加入了 Xerox (伟大的技术公司)后完成了全世界第一个面向对象语言 Smalltalk-80。面向对象改变了软件开发的方式,不管是UML 还是设计模式都是基于面向对象的概念,提高了软件的重用性。在 2000年 过后,国外的 MES 都是基于面向对象来开发的,不管是 Fab300(SmartFactory),FactoryWork4.0,CriticalManufacturing,Camstar 等。

这种方式提升了客户在二次开发的可能性。很多客户会在招标的时候问厂商能否提供源代码,其实我们认为更应该问的是,能否用面向对象的方式来进行二次开发。好的面向对象设计能让客户进行针对性的二次开发,例如从 Lot 物件继承大部分的功能创建新的 Batch 物件,但在过站(TrackIn)这个功能的时候,利用覆写 (Overwrite)改变所需要的功能。


image


对象关系映射 (Object Relationship Mapping)


这也是面向对象的延伸,把整个数据库物件化了。早期有两种做法,第一种就是直接使用物件为主的数据库(OODBMS,面向对象数据库,以物件的方式储存资料),但是这条路最后没有走的太好,不好的 OO 设计直接就会毁掉一个项目。目前最主流的方式就是使用 ORM 的技术,把关联性数据库 (RDBMS)封装成物件的方式。ORM 的好处就是能够让程序员使用最熟悉的方式来撰写功能,在代码上比较干净,不需要出现可怕的 SQL 语句,而是以物件的方式来处理资料。当然,使用ORM 是有代价的,资料库的架构造成了报表的开发不是那么的直接。但好处是,可以很大程度上保证了底层更换不同数据库的可能性。


image


Java


为什么要单独提 Java ?很多客户都会在招标书中,指定使用 Java。但实际上这不是重点

,因为他们所谓的 Java 其实指的是 J2EE (Java 2 Enterprise Edition)而不是单纯的 J2SE (Java 2 Single Edition)。1995 年提出的 Java 和 C# 一样,提供了用户开发 Console 和 GUI 的主要功能,而 J2EE 则是在 1998 年提出另外一套技术,从单纯的语言延伸到了整个企业软件需要的架构,早期的 J2EE 没有开源的部分,Sun 当时也只提供一个参考架构,一直到 2002 年 Spring 等开源项目的崛起。J2EE 被大量的应用在日常的系统包括了电商网站,人事系统,OA 等。


image


J2EE 适合 MES 这种应用吗?我个人是抱有疑问的,因为 MES 的应用需求和传统的应用需求是有差别(有空写一篇来分析一下 MES 软件的需求是什么)。这也是过去的 20 年,没有主流的半导体 MES 使用了 J2EE 的架构来开发,特别是高效能要求的 12寸工厂(有个案子尝试使用了 J2EE,其中在效能上没有满足客户的要求,最终失败收场)。原因很简单,要能高效的使用 J2EE 架构,需要很清楚的了解整个系统的设计,而不是只有会开发服务的程序员 (Programmer)。


对于 MES 的开发,最简单直接有效(粗鲁爆力直接有效)的方式就是直接撰写服务,前端直接呼叫。当然另外一个原因是,Oracle 收购 Sun 以后,Java不再是免费的了(使用有法律风险),虽然有众多的免费开源版,在贸易战的这个年代,难保这不会是一个很大的风险。

Java 是必须使用 VM (虚拟机)来执行的,C# 也是(.NET Framework),在调优和系统开发是有很多学问的。例如如果团队不知道如何处理 Java 的 OutOfMemory 错误,其实就已经是风险了。因为Out Of Memory 错误和堆栈有关,就算系统有 128G 的内存,在启动时不足够的堆栈依然无法解决。

 

想象一下,用 Java 实现 Recipe Server,100 台设备同时上传 50MB 的 Recipe 做分析,需要多少的堆栈。


容器


如果有天我做回甲方,去当 IT,我的其中一个技术需求一定是 MES 要支持容器的部署。这里指的不是什么 Sprint 中的容器,而是 Docker 类似的技术。我在上一家公司的时候,时常和客户开玩笑说,其实我们的软件是不需要保护的,因为在没有专家的情况之下,你是装不起来的,微软坑爹的 AD 和 SQLServer 的各种设定都是可怕的,没有花费几天根本搞不定。


image

 

想象一下,硬件崩了(或是要移植硬件时),装都装不起来的情况。别说 4 个小时的硬件恢复,4 天都装不起来,我可不愿意是那一个要和老板解释工厂为啥跑不起来的人。Docker 的技术让客户可以快速在任何硬件的基础上把系统跑起来。最近和团体完成了快速和简易部署的方案,可以实现 5 分钟在任何硬件的基础上,把一个复杂的高可用性环境(4 AP,2 DB)快速的搭起来,其中还包括了数据恢复。

 

这个技术可以快速的让厂商在远程重现整个实际环境,不再需要客户提供缓慢的 VPN 连接。客户也可以快速搭建环境来测试开发的功能。


当然还有很多其他的技术,如时序性数据库,下次我们再谈。