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

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

面向对象 （Object Oriented）

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

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

对象关系映射 （Object Relationship Mapping）

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

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 等。

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 的各种设定都是可怕的，没有花费几天根本搞不定。

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

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

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