MES的任督二脉

1.       任脉：系统集成

关键词：制造、系统

MES作为一个IT系统，与ERP/PLM/WMS等其它系统有着高度集成。

这是因为，制造不是一个孤立的生产活动。

首先，从产品生命周期来看，立项、研发、制造、销售、售后组成完整的产品生命周期，而产品的特性需要在整个产品周期的各个环节中进行传递，这其中最重要的特性就是来自于PLM的产品BOM，因为BOM决定了产品的成本、加工流程、工艺设备等生产因素。

其次，从一次制造活动来看，典型的生产过程由订单触发，完整的制造流程包括：销售订单à采购订单à生产工单à发运单。这些单据对应于ERP中的现金流动和物料流动，而对于MES来说，来自于ERP的生产工单成为关键的生产因素。

因此，MES非常重要的两个集成需求是：与PLM集成BOM，与ERP集成工单。

下面我们举一个例子予以说明。

汽车行业，通常通过配置和颜色区分车型，如白色低配、红色高配等。汽车制造厂为每个颜色+配置组合分配一个总成件物料号，然后将对应的零件、配置件挂在总成件下面，形成制造BOM。工厂按照标准的配置制造产品，然后发往4S店。但是4S店通常会额外储备一些配置件，并在交付给用户时安装一些额外的配置件。

比如说某款车，低配版没有全景影像，只有高配版有。那么通常的做法是：制造厂按照低配版造车，然后发给4S店；4S店安装全景影像并刷软件。这是因为制造厂的BOM里面没有低配+全景影像的结构，因为无法按照这种订制方式进行生产。而4S店做了一些额外的工作，相当于在原BOM的结构上额外增加了一层选配件，因而可以更加灵活。4S店等同于一个虚拟的辅件装配车间，作业内容对应于选配件材料的虚拟BOM。因此这种模式，在某种程度上对4S店形成了依赖。

这是因为传统的做法，把物料BOM、工程BOM、工艺BOM都挂在总成件下面。

这种制造模式对应的物料BOM结构形式类似下表：

层级	物料号	消耗工位	物料描述
1	Z10010010		XX运动型低配红色手动版轿车
2	C40010011	T050	仪表盘
2	C40010016	T080	中控屏
2	C40020021	T120	左前座椅
2	C40030021	T250	1.8T发动机
2	C40040021	T340	ECU软件，版本V1.01

4S选装件对应的BOM为：

层级	物料号	物料描述
1	C40010018	全景影像
1	C40040021	ECU软件，版本V1.02

当4S店下订单时，根据车型、颜色等信息锁定了车辆的总成件号，并作为订单的属性予以绑定。

当ERP把订单传递给MES时，同时也把车辆总成件料号传给MES。

由于MES中的物料BOM和工艺都是定义在总成件料号下的，因此订单下发的时候已经决定了车辆的生产工艺。

假如某汽车厂想要抛开4S店系统，希望客户直接在网上下单、选择配置，然后在制造完成后直接从汽车厂发给客户，那么传统的BOM结构和加工流程就不适用了。

新的流程，要求为每个订单生成一个总成件号，其对应的物料BOM、工程BOM、工艺BOM是基于订单的临时组合，其结构类似下表：

层级	物料号	消耗工位	物料描述
1	S1008601		订单号S1008601，XX运动型轿车
2	P401207		低配手动仪表盘选配件
3	C40010011	T050	运动型仪表盘
2	P402402		低配手动中控屏选配件
3	C40010016	T080	中控10’高清屏
2	P410201		低配运动型座椅选配件
3	C40020021	T120	左前座椅无纺布
2	P420103		1.8T L4发动机
3	C40030021	T250	1.8T发动机
3	C40030021	T280	1.8T涡轮增压器
2	P430320		低配运动型含全影影像ECU
3	C40040021	T340	ECU软件，版本V1.02

当客户下达订单时，ERP把订单及选配件清单发给MES。

而MES的工艺基于选配件定义，因此MES在接收到订单的时候，也知道了工艺过程也就是所有选配件的加工的组合。

这种BOM结构可以允许工厂完全按照客户的订制进行生产，而无须4S店的额外订制作业。

2.       督脉：控制集成

关键词：执行

MES与其它IT应用系统的一个重大区别是，MES与现场设备关系紧密。

根据ISA95的定义，MES介于ERP等企业业务系统与现场作业层之间：

级别	典型系统/设备	核心业务	作业范围	响应时间
4	ERP	现金流、物流	集团/工厂/车间	月/周/天
3	MES	工艺流	工厂/车间/工位	天/班次/小时/分/秒
0/1/2	电机/机器人/PLC	机械、电气、逻辑控制	区域/工位/设备	分/秒/毫秒

近几年来随着智能设备和工业物联网的兴起，似乎设备和IT系统联网是轻而易举的事情，但仔细分析的话，其实和工业现场的需求还是有很大距离。

象大家所熟悉的智能家电设备，采用安卓、树莓派等轻量型操作系统，通过互联网协议进行数据传输，但是这种方式的最大缺点是：速度慢(响应时间在秒级)、数据安全无法保证。

而象无人驾驶汽车的激光雷达等设备，由于算法都封装在芯片，采用专有数据传输协议，因此稳定可靠，但是价格昂贵，因此没有被广泛使用。

在车间现场，多年来被广泛应用的形式是采用PLC作为设备的逻辑控制中间层，然后通过OPC实现与MES的数据交换。

有了PLC/OPC的逻辑通道，MES能够向车间现场设备下发工单、BOM、工艺指令、防错指令等，此外也能够从设备收集状态信息、异常信息、操作结果、过程数据等。

这样一来，能够使工艺的执行更加灵活，同时也能够更快地对问题进行响应处理。

举例来说，一个较传统的汽车工厂，MES与设备没有深入集成，这样的话，工厂通常会按照车型进行小批量生产，每次换车型时，则需要集中在设备上进行相应的切换操作。

这种方式的工单顺序类似下表：

工单序号	车型
1	XX运动型低配红色手动版轿车
2	XX运动型低配红色手动版轿车
3	XX运动型低配红色手动版轿车
4	XX运动型低配红色手动版轿车
…
21	XX运动型高配银色自动版轿车
22	XX运动型高配银色自动版轿车
23	XX运动型高配银色自动版轿车
…

而如果MES实现了与设备的深入集成，则可以将工单混排，当车辆到达工位时，设备会根据车型信息自动进行运动、取料、加工、测量。

这种方式允许计划员尽可能按照客户订单的顺序安排生产，工单顺序类似下表：

工单序号	车型
1	XX运动型低配红色手动版轿车
2	XX运动型高配银色自动版轿车
3	XX舒适型中配灰色自动版轿车
4	XX精英型高配黑色自动版轿车
5	XX运动型高配红色自动版轿车
6	XX舒适型高配蓝色自动版轿车
7	XX运动型中配蓝色自动版轿车
8	XX运动型中配红色自动版轿车

前文描述了MES的2个关键集成点：应用系统集成，与控制系统集成。

其实从一流MES供应商的分布，我们也可以看出这一点。

比如达索公司开始的核心业务是CAD设计，产品主要是应用于汽车和航空业的CATIA/SOLIDWORKS，后来从IBM收购了PLM产品，又从APRISO收购了MES产品，从而实现了CAD/CAM/CAE/PLM/MES的系统整合。

而象西门子/洛克威尔/GE是做电气产品(PLC/传感器/伺服系统)起家的，后来又从HMI/SCADA开始慢慢与应用系统集成，再辅以收购，实现较全面的MES方案，再通过PLM实现与CAD/ERP的集成。

简单地总结一下，MES在ERP/PLM/WMS等应用系统中起到承前启后的作用，并在应用系统与现场设备之间起到承上启下的作用。

PLC编程再思考之三：面向过程

现在的高级语言基本上都是面向对象的，但是PLC编程象较早的BASIC/FORTRAN语言一样，是面向过程的。

PLC逻辑处理的基本过程为：

1)       将外部设备输入的数据写入输入映像区(I)。

2)       逻辑处理，包括读I区、写Q区。

3)       将输出映像区(Q)的数据输出到外部设备。

其中，1)和3)是PLC内部处理的，所有的PLC用户程序只处理第2)部分。

PLC的这种处理方式带来了下面2个特点。

特点1：OB1调用的程序不存在并发

我们知道，PLC用户程序主要运行在2个地方：中断和OB1。

一般而言，能够在一个扫描周期里完成的逻辑处理，通常我们会在OB1中进行调用，而OB1中的程序是按照严格的调用顺序进行处理的。

比如CPU扫描周期是20ms，那么在某个ns，CPU只会处理某个特定的FC/FB/NW。

举个例子，1工位的工人同时按个2个按钮，而在PLC层面，对这2个按钮的事件处理是有先后顺序的。

因此，严格地说起来，PLC不存在真正的并发。

有效利用这一特点，可以让编程变得更轻松。

比如1条线有30个工位要进行呼叫处理，而每个工位的呼叫处理逻辑是一样的，那么我们可以建立一个临时DB，存储任意一个工位的所有中间变量。

OB1按照工位的顺序进行处理，当执行到第N个工位时，临时DB的变量值就记录了第N个工位的中间变量值。当执行到下一工位时，临时DB被重写，以用于下一工位业务处理。

由于PLC在任意一个瞬间只处理一个特定的工位，因此临时DB的值和此工位有严格的对应关系，因此我们无需在FC里声明变量，因为所有的变量都已定义在临时DB中。

这样处理可以让程序更加简洁通用、变量少，可以用FC变相地实现FB的功能。

特点2：后面赋值覆盖前面赋值

高级语言在符合条件的时候就会输出，而PLC只会在所有逻辑处理完成以后才会输出，并且只输出最后写入的值。

比如在同一个扫描周期，先执行了Q0.0=0，后执行了Q0.0=1，由于在执行的过程中，数据仍然存储于输出映像区，这2步操作相当于在同一个扫描周期内对Q0.0的映像区进行了2个赋值操作，并用后一次赋值覆盖前一次赋值，因此OB1最终将Q0.0赋值为1，然后将此值输出到外部设备。

我们在编程的时候利用这一特点，可以减少一些比较的运算处理。

比如某工位按下按钮1则亮黄灯(红灯灭)，按下按钮2则亮红灯(黄灯灭)，同时按下则红灯亮(黄灯灭)。

也就是说从业务上来说，按钮2的级别较高。

相对的，我们可以先写按钮1的处理逻辑，再写按钮2的处理逻辑，当2个按钮都按下时，根据PLC的特点，CPU只输出按钮2的处理结果，因此我们无需写比较的程序。

PLC编程再思考之二：SOA

随着AMAZON云服务的成功，许多人知道了BEZOS在AMAZON内部推广WEB SERVICE的故事，从而佩服他的技术眼光和执行力。

如果说AMAZON.COM的成功是因为长尾理论，是对万货商店的技术实现，那么从某个层面来说，AWS(AMAZON WEB SERVICE)是另一种形式的长尾，只不过它销售的是IT服务而不是物理产品。

BEZOS基于SOA的思想，通过网络接口和服务打通了AMAZON内部的各种子系统，他把基础设施的接口进一步对外开放，从而形成了AWS的基础功能。

那么，SOA的思想，对于PLC编程有没有借鉴意义呢？

我认为是有的，尤其是对于具备MES复杂功能的IT PLC。

本文以ANDON功能为例予以说明。

比如说1条线有20个工位，每个工位有1个拉绳、1个灯，每条线对应1套音乐播放系统。

那么基本逻辑过程应包含：

1)       用FOR循环遍历每个工位，找到每个工位拉绳/灯/喇叭对应的I/Q地址。

2)       在工位逻辑里，找到拉绳的状态，并触发亮灯和播放音乐。

调用结构为：

FC-LINE                                // 线FC ---- FC-ST[1..20]                  // 工位FC

由于在工位FC里，I/Q寻址和读/写操作混杂在一起，因此工位FC没有和拉绳/灯/喇叭的处理逻辑实现接口隔离。

如果我们分别针对拉绳/灯/喇叭封装成3个服务接口FC：

接口	输入变量	输出变量	说明
FC-I-ROPE	ROPE_ID	ROPE_FLAG	通用拉绳FC
FC-Q-LAMP	LAMP_ID		通用灯FC
FC-Q-SPEAKER	MUSIC_ID SPEAKER_ID		通用喇叭FC

我们可以看到，对这3个FC的调用不涉及I/Q的地址，从形式上看起来更象是逻辑服务函数，而对I/Q的寻址是FC内部的逻辑，不需要暴露在接口中。

经过上述转换后，程序的调用结构为：

FC-LINE                                                                               // 线FC ---- FC-ST[1..20]                                                                // 工位FC -------- FC-I-ROPE(ROPE_ID, ROPE_FALG)                   // 拉绳FC -------- FC-Q-LAMP(LAMP_ID)                                        // 灯FC -------- FC-Q-SPEAKER(MUSIC_ID, SPEAKER_ID)       // 喇叭FC

我们可以看到，工位FC更加专注于业务过程，拉绳/灯/喇叭FC更加专注于I/Q读/写处理。

这样处理以后，不仅程序结构清晰容易理解，而且开发和维护都更加方便。

因此我们在开发PLC程序时，也要有SOA的意识，在开发一些功能或功能块时，要思考能不能将功能写成可供外部调用的FC，以及输入输出变量要怎么设置。

下面是AMAZON的WEB SERVICE法则：

Amazon Web Service Laws: 1) All teams will henceforth expose their data and functionality through service interfaces. 2) Teams must communicate with each other through these interfaces. 3) There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network. 4) It doesn’t matter what technology they use. HTTP, Corba, Pubsub, custom protocols — doesn’t matter. 5) All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions. 6) Anyone who doesn’t do this will be fired. 7) Thank you; have a nice day!