MapReduce作为一种重要的编程思想，在互联网开发特别是分布式开发中得到了广泛的应用，MES通常是集中式开发系统，但是MapReduce的方法论也可以予以借鉴，本文以三个实际应用的例子来进行探讨。
应用一：动态工艺参数下载
在MES中，动态工艺参数下载是一个很常见的场景，即在生产的过程中，需要从系统下载得到一些动态工艺参数，比如一些工单的属性、BOM中的特殊零件物料号、在某工位测试的次数等。
最简单的应对方法是写一个专门的程序，把所有可能的逻辑都包含进去，这样带来的问题是：
1)这个程序的逻辑非常复杂。
2)每次增加工位都需要对程序进行升级，并且升级时可能需要系统停线。
现在我们用MapReduce的方法论对它化繁为简。
首先我们认识到，这个程序的核心是一个函数，输入产品序列号和工位，输出工艺参数，其中工艺参数是若干个工艺变量的组合。而工艺变量的生成方法是：
1)常数
2)工单属性
3)正则表达式
4)数据库查询
现在我们分别进行Map和Reduce的操作。
首先我们建立一个Map表，把所有工艺参数的变量在数据库中进行配置：
2.Reduce
然后我们分两步进行Reduce：
1)分别得到各个工艺变量的值。
2)将多个工艺变量的值进行规范处理，并组合得到完整的工艺变量。
其中对于第1步，分别对每一种工艺变量类型定义一个Reduce函数，如：
1)常数直接从内存中提取Map查询得到的值。
2)正则表达式则进行运算处理。
3)对于数据库查询，则运行对应的数据库函数，并配合输入的产品序列号和工位，经过计算得到对应的变量值。
这样处理的好处是：
应用二：通过物化视图同步数据
常见的做法是通过SQL把原始数据映射到物化视图，然后另建一个SCHEDULEDJOB去定期刷新。
但是问题在于，这个SQL的业务逻辑非常复杂，要关联多张表，并且要进行分组统计、递归等较消耗资源的计算。
下面我们看看怎样用MapReduce的方法论来进行简化。
首先我们列一个表，看看最终输出字段的计算逻辑。
从上表中我们可以看到要查询很多的历史记录表，而这些表在设计时并没有针对统计进行优化。
首先有一个额外的因素要考虑：数据同步的时机。
场景一：数据同步和MES生产是错开的，比如生产在下午结束，而同步在晚上进行，那么即使同步时消耗了大量的数据库资源也不会对生产造成影响。
场景二：生产和同步同时进行，那么就必须排除同步作业时数据库查询对MES实时生产作业的影响。
下面我们分别针对各字段进行Reduce的优化说明。
1)产品序列号
由于序列号属性表是一个主表，结构较简单，一般直接查询即可。
针对场景二，如果数据量特别大(比如小型数码产品的生产，一天可能多达近100万的数据量)，那么可以这样处理：
这样我们就得到了一个数据量较小的表，而且同步所需的许多数据直接查询此表就可以得到。
2)工单信息
直接从序列号属性表查询就可以得到了。
针对场景二，工单和序列号一起进行复制作业。
针对场景一，我们可以直接在查询SQL调用此函数得到输出字段。
4)上线工位
编写一个查询上线工位的数据库函数FFS，根据序列号检索，得到第一次经过上线工位的工位名称。
针对场景二，我们可以让触发器T调用此函数得到上线工位然后输出到表N。
6)下线工位
编写一个查询下线工位的数据库函数FLS，根据序列号检索，得到最后一次经过下线工位的工位名称。
针对场景二，触发器T直接更新表N的下线工位属性。
7)关键零部件批次号
由于BOM存在层级结构，零部件的追溯记录存在一定的递归关系，做递归查询较消耗资源。
但是由于要同步的关键零部件的结构关系是较固定的，因此我们可以编写一个视图VG来复制关键的业务数据。
针对场景二，如果结构特别复杂，我们可以针对每个关键零部件分别编写函数FG1/FG2/FG3来进行数据抽取，然后利用触发器进行调用后复制数据到表N。
8)关键检测工位检测次数
编写函数FTC来计算检测次数。
针对场景二，利用触发器进行调用后复制数据到表N。
9)是否一次性通过
编写函数FTT来计算是否一次性通过。
下表列出了新增的Reduce操作：
然后再辅助以下的操作，以方便将来的维护、调整：
2)把物化视图的SQL更新为：SELECT*FROMVW;这样做的好处是，如果需要做一些调整，我们可以直接在视图VW里进行更新，而不需要重新编译物化视图。
3)新建一个存储过程SPW，用于执行刷新物化视图的操作。
4)在SCHEDULEDJOB里直接调用存储过程SPW，实现定期刷新。
通过以上的Map-Reduce操作，我们就把一个业务逻辑非常复杂的物化视图查询逻辑，转换成许多个业务逻辑相对简单、耦合性弱、查询效率高的数据库操作，简化了逻辑，增强了性能。
应用三：与PLC通讯
在许多工厂，用PLC控制设备，然后通过OPC与MES建立通讯。
OPC是一个广泛使用的工业标准，开发和部署都非常方便，而.NET对OPC的集成支持也非常好。
通常的做法是，在MES服务器上部署一个OPCCLIENT，建立与OPC的通讯，而MES对OPC的读写可直接映射成对PLC的读写操作。
而这样做的缺点是：
1)MES和PLC的耦合性太强，一旦MES停止响应则PLC也无法指导设备工作。
2)MES里集成了很多和PLC握手的控制逻辑，和MES的业务逻辑交织在一起，增强了逻辑的复杂度，降低了问题诊断的效率。
这里有一个前提，就是所有握手逻辑都在PLC里实现，OPC中间层只转换业务数据。
更进一步地，我们可以建立一个ITPLC，专门处理控制层的逻辑，并且为OPC中间层准备特定格式的数据。这样就形成了设备PLC-ITPLC-OPC-MES服务器这4层结构。
下面举一个汽车装配工厂车辆识别模块的例子。
下图是传统交互式握手的示意：
我们可以看到在MES服务器上需要编写握手的逻辑。
下图是增加ITPLC后，以请求/应答方式进行握手的示意图：
我们用MapReduce的方法论对它进行分析：
我们可以看出，经过MapReduce处理后，在每个层面上的逻辑复杂度都得以减少，更加专注于业务的实现。