为什么工厂里IT的地位不高

这两年随着互联网的广泛渗透，IT从业人员受到越来越多人的认可，IT工程师被许多人看成天之骄子。
但是作为一个从事制造IT十多年的工程师，我的感受是，在制造领域，IT工程师的地位较低。
那么为什么会有这个差异呢？
首先我们看看制造IT的业务方：工艺工程师、设备工程师、质量工程师，通常在这些领域，一个有十年行业经验的工程师才能称为资深专家，而在IT行业，3年从业经验就是资深了，30出头的总监比比皆是。
再来看看费用支出：通常设备建设会占用工厂投资额的一半，而IT费用少得可怜，外资企业少于3%，民营企业一般少于1%。
再来看看流程授权：通常所有IT项目都需要业务部门签字，而业务方即使是与IT有关联的事务，通常不会让IT参与签字，能及时通知到IT就很不错了。
在招标的过程中也可以看出明显的差异。在设备招标前，设备供应商会准备详细的技术方案，包括全套的AUTOCAD图纸、关键设备的型号和报价，通常由中年老工程师讲标。而IT讲标主要看PPT，讲标的顾问通常在30岁出头。
再来看商务条款的差异：通常工厂会要求设备供应商签署严格的赔付条款，当生产停线时会赔付大笔费用；而IT供应商的赔款则非常有限。
综合以上信息，我们不难看出为什么工厂对设备供应商和相关从业人员更为放心，而对IT不太信任。

那么为什么同样作为IT从事人员，BAT那么牛逼，而工厂IT怎么就这么苦逼呢？
一个很重要的原因是：在互联网行业，IT工程师是生产力工具，与企业的效益直接相关；而在制造行业，IT通常是辅助系统，IT的投入产出都是间接性的，IT的领导往往会汇报给人事、财务、物流等领导，而不是汇报给CEO。
在开发模式上，互联网应用通常采用敏捷开发模式，快速迭代、分次发布、快速上线。而在制造领域，主要还是采用传统的瀑布式开发交付模式，一次开发、一次发布，这其中的主要原因是，IT项目的节点不是独立的，通常都是依附于业务方的项目节点。
在制造领域，作为一个IT工程师，一定要摆正自己的位置，调整好自己的心态，严谨务实，脚踏实地，才能得到更多人的尊敬和认可。

来来来，MES大数据了解一下

“Big data is like teenage sex: everyone talks about it, nobody really knows how to do it, everyone thinks everyone else is doing it, so everyone claims they are doing it...”

“大数据就象青少年性爱：每个人都在谈论它，没有人真的知道它是怎么一回事，每个人都以为别人都在做，于是每个人都声称他们也做了。。。。。。”

这是网上广为流传的一个大数据段子。

这两年随着互联网应用的广泛普及和推广，各类IT术语层出不穷，犹如雨后春笋：互联网+、物联网、万物互联、智能制造、大数据、人工智能、区块链、神经网络，PPT中增加一些新名称，仿佛泥菩萨贴上了金身，逼格一下子就提升不少。

但是网络是有记忆的：

大约十年前，IBM大力推广商业智能BI，花数倍的钱做同样的报表，后来IBM因为专注于高端客户而裁员了。。。

大约两年前，GE誓言进军工业互联网，打造工业软件帝国，后来GE也裁员了。。。

相反，老老实实做自动化和MES的ROCKWELL活得很好。

别的不说，至少在MES领域还是相当务实的，或者说MES的客户(各制造工厂)是相当务实的。

其实从技术的角度而言，MES大数据需求利用传统的数据库技术完全可以实现。

这两年内存的价格很低，SSD的技术也已经成熟，所以利用SSD存储、分配大量SGA的ORACLE数据库完全可以满足大部分制造企业的存储和查询需求。

以年产20万台车的整车工厂MES为例，通常64GB SGA即可满足要求。

本人曾经在一个电子制造工厂实施项目，该工厂有100多道工艺，每天生产80多万件产品，MES最大的一张表每天新增1亿条记录，每个月建1个分区，用ORACLE管理轻而易举、非常稳定。

以汽车制造为例，MES采集的数据确实可能会比较多，如BOM信息、装配关系信息、工艺追溯数据等，但通常数据量也在亿这个级别。所以用ORACLE存储是不成问题的。

关键是在设计时需要对表结构进行认真的规划。

这两年用JAVA的程序员比较多，而JAVA基于面向对象的思想，通常仅仅把数据库作为一个存储工具，而数据库本身的强大工具，如ORACLE的物化视图、动态游标等神器很少得到发挥。

MES作为一个“执行”系统，有大量的“写”存储设备的操作，这些操作通常基于关系型数据库实现，很难通过内存优化得到本质上的改进。

而所谓大数据，往往是针对数据的统计分析需求。

关系型数据库针对统计查询，有一个简单的优化法则：所有过滤条件(WHERE)、分组字段(GROUP BY/MIN/MAX)、排序字段(ORDER BY)必须使用整型数据。因此我们在设计数据库表结构时，必须思考哪些字段需要做统计分析，如果需要则建立对应的字段映射。或者建新的表，专门用于存储整理后的数据，然后编写计划任务和存储过程，将业务数据转移到利于统计的新表中。

与其花大量时间、精力、费用在不知所谓的新技术上，不如老老实实地了解业务、分析数据结构、编写数据处理算法。制造是个苦活、累活，老老实实做事并不丢人，犯不着和互联网公司比，肯花心思的话老工具也能玩出新花样。

PLC编程再思考(5) – 高级语言编程

在PLC的编程语言中，梯形图最常用，同时也会结合STL、SCL等语言使用。

梯形图LAD语言，由于其简单、直观、方便逻辑表达，使用最为广泛，但也有一定的限制。

比如在AVI和防错系统中，需要在PLC中存储车辆的实时队列，通常以数组的形式保存在数据块中。当车辆移动时，我们可以使用SCL语言，通过FOR循环对数组进行移动操作，非常方便。此时用LAD会让人抓狂。

此外，由于SCL语言是纯文本格式，因此我们可以非常方便地利用SVN工具进行版本控制。

因此，在AVI、ANDON、EPS等IT高度参与的系统中，会在PLC中交叉使用LAD、SCL语言。

我们可以针对不同的语言分别编写FC，然后在程序段中进行调用。

但有时我们希望用同一个FC完成所有相关的逻辑，这时我们可以适当地将LAD转换成SCL格式，以方便理解和调试。

本文举几个常见例子予以说明。

1.     直接赋值

LAD格式：

SCL格式：

需要说明的是，SCL只能通过变量的符号名进行运算。

2.     上升沿处理

LAD格式：

SCL格式：

我们可以看出，上升沿的处理原理是：通过两个地址，分别存储信号在上一个扫描周期值、当前扫描周期值；当上一次值为0且当前值为1时，则定义为上升沿触发。

用SCL表达略显繁琐，但是也很好理解。

3.      串并联逻辑判断

LAD格式：

SCL格式：

我们可以看出，当有多个条件需要进行组合逻辑判断时，用LAD表达非常简洁直观，SCL需要将串、并联转换成AND/OR条件，而电路的闭/合也要转换成1/0值，因此不够直观。但是对于写惯了VB等高级语言的工程师，SCL格式上手还是相当简单的。

MES在汽车制造中的应用之实施篇(2) -- 计划管理

由于汽车制造工艺和业务的特殊性，MES系统实施的计划管理也和普通的软件系统实施存在较大不同，下面具体予以说明。

1.    上线节点

汽车工厂的建设有几个关键节点：

-          TT，Tool Tryout，或Tooling Trial，是指设备调试阶段，MES在此阶段上线。

-          PP，Pilot Production，是指试生产，物流系统在此阶段上线。

-          SOP，Start Of Production，量产开始，ERP在此阶段上线。

对于ERP等系统，一般都是先搭建测试环境，准备主数据，进行配置、测试，然后把数据导入生产环境，然后在SOP上线。

但是MES由于要和设备高度集成，因此必须利用TT的时间窗口进行调试，甚至一些工厂要求MES在TT之前一个月上线。

一般来说，TT时的调试车辆较少，一个车间只有数台，并且出现问题时可以随时停线。但是从PP开始，每天的计划量会渐渐增加，不适合处理重大的设备接口问题。

而TT和SOP之间往往会有数月的时间差，因而这里就存在一个项目管理的问题：MES和ERP往往作为同一个信息化项目群管理，但是两个系统的上线时间差距较大，因而给项目计划、资源调度等都带来一定的挑战。

2.    开发模式

MES在TT上线还带来一个开发模式的问题。

近年来，受互联网开发的影响，敏捷式开发的理念广为流传，但在汽车制造MES领域，恐怕还是瀑布式+模块化开发的模式更为合适。

比如设备集成模块在TT发布，ERP接口在SOP发布，并且每个模块在发布时必须是功能完整、性能可靠的。

由于设备集成模块上线早，而MES完整实施周期又很长，因此为了节省开发资源，必须将功能点按照模块发布顺序进行开发。

MES还有一个特殊点是：通常在搭建好生产环境后，直接在生产环境上进行开发和配置。原因有2点：1是OPC调试的结果只针对实际配置的服务器，如果用测试环境调试OPC成功，未必就能保证生产环境调试OPC成功；2是在生产环境下应用服务器和数据库有冗余设计，网络服务器有负载均衡设计，而测试环境非常简单，这些高性能设计无法在测试环境下得到验证。

3.    设备调试过程

本章节重点谈谈设备调试过程。

由于MES设备调试在TT阶段就开始，而此阶段工厂还在建设之中，比如某些区域供电和网络还没有正式完成，需要临时供电、供网等，因而许多工位需要做多轮调试。

就功能而言，一个业务功能点可能需要经历这些调试过程：

-          供电和网络调试。工位上线后检查操作系统、客户端、网络等基础设施和配置。

-          通信调试。又称心跳调试，从设备PLC端发出心跳信息，MES接收后发回反馈信息，主要检查通信和双方的基础握手逻辑，以及耦合器等通信设施是否正确配置。

-          虚拟业务调试。在实车到来之前，从PLC/HMI上发出虚拟的业务信号，MES根据业务逻辑和握手协议返回处理信息。这是因为在TT阶段车辆较少，而调试的工位多，MES工程师要尽可能利用OEM电气工程师的时间来调试逻辑。

-          实车调试。在虚拟业务调试完成之后进行，主要是验证物理设施如传感器、编码器是否正确配置。

在调试阶段，不同工位的不同调试过程是穿插进行的。比如在焊装车间，OEM电气工程师有十多人，而MES控制工程师只有1人，那么有可能MES工程师上午调试某工位的心跳，下午可能去调试另一工位的虚拟业务。

具体到时间计划方面，一般而言，第1个工位需要预留1周的完整调试时间(从供电和网络调试到实车调试)，这是因为第1个工位面临的许多问题是所有工位通用的，如OPC配置、网关配置等。此后，第2、第3个工位需要预留3天的完整调试时间。之后每个工位预留1天的完整调试时间，2周后每个工位预留半天。

MES在汽车制造中的应用之实施篇(1) -- 沟通管理

在汽车制造领域，MES是一个高度复杂的系统，涵盖了计划、生产、工艺、设备、质量等诸多功能模块，要定义的业务流程非常多，要对接的业务部门也非常多。

此外，对于大型汽车集团公司来说，还要处理好集团公司职能部门与工厂职能部门之间的关系，因此沟通管理非常重要。

图4.1-1是一个典型的汽车集团公司某工厂MES项目的组织架构图：

图4.1-1 MES相关组织架构示意图

我们可以看出，MES作为一个执行系统，直接服务的对象是生产部人员即一线工人，而工厂的职能部门为生产部门提供辅助，此外集团的各职能部门又为工厂提供信息和指导。

此外，一个新工厂的建设，是一个循序渐进的过程，工厂各职能部门的人员是慢慢到位的，因此，往往在项目的前期，由集团的职能部门进行规划，而在后期由工厂的职能部门明确细节，而集团和工厂之间对一些流程和需求的理解也常常存在偏差。

因此，我们在实施MES的过程中，往往存在以下两个挑战。

挑战一：怎么理解业务？

这两年随着工业4.0、中国制造2025等概念的推广，以及互联网造车企业的扎堆进场，MES市场不断扩大，MES行业从业人员也迅速增加，但是不可否认的事实是，真正懂造车流程、懂业务需求的人员还是太少了。

因此不可避免的，在项目实施过程中，存在着业务部门和IT部门在需求理解上的偏差。

为了达成双方理解上的充分一致，我们可以在组织架构上做一些创新。

下面我介绍一个业界最佳实践的例子：康明斯MES案例。

康明斯MES是一个全集团通用的系统，由同一个团队开发，由同一个团队实施，由同一个团队运维。

其中，开发团队位于总部，由来自于IT部门的架构师、技术专家、供应商人员，以及来自于工程部门的业务专家、控制专家组成，以虚拟团队的方式运作。其中，业务专家是从业十多年的发动机专家，精通发动机制造工艺、流程、质量规范，控制专家熟悉生产现场相关设备的运行机制与控制逻辑。业务专家会在新功能开发前，与工程部门、质量部门的技术人员充分沟通，也会了解各工厂的具体细节，在此基础上，汇集形成统一的流程和需求。控制专家会和设备制造商、工厂设备工程师沟通交流，汇集各方信息后制订统一的控制标准。来自于业务专家和控制专家的需求非常有代表性，而开发团队内部沟通又非常透明顺畅，因此整体的沟通成本较小，实践证明效果非常好。

挑战二：怎么统一业务？

现在不少汽车制造商都是大型的集团公司，而工厂则分布在各地，即使是实施统一的MES系统，具体部署到工厂的时候也多少会存在差异。

而从集团的角度而说，MES系统的规划要尽可能地做到标准化，尽量用一套系统，用一个团队进行开发、实施、运维。

那么，怎样来平衡集团的标准化和工厂的个性化呢？

这里介绍一个方法供参考。

首先建立两个专家委员会：MES业务专家委员会、MES控制专家委员会。成员由集团工程院、质量部的专家代表，和各工厂的专家代表组成。每个专家有一定的投票权，其中集团专家有更多的权重。

当某个需求无法达成一致时，由专家委员会进行投票，形成得分最高的方案。开发团队根据此方案进行设计开发，作为标准解决方案的功能模块。如果工厂依然坚持个性化方案，则开发团队作为工厂订制化需求另行开发，但是优先级较低，可在实施时开发和部署。

MES在汽车制造中的应用之架构篇(7) -- 松耦合与紧耦合

MES作为一个执行系统，和车间现场的设备、控制系统有密切的集成关系，这是和一般的IT系统有较大区别的地方。

比如ERP下工单是以天为单位的，库存也以天为单位进行结算。

但是MES在需要和PLC等现场设备集成的地方，通常要求系统以秒级单位进行响应。

因此，车间对MES的可用性就提出了很高的要求。

但是另一方面，与PLC相比，MES系统的设备在成本、稳定性、防护等级等方面又有较大差距，因此，业务方对MES的可用性往往抱着怀疑的态度。一些情况下，业务方要求MES高可用，另一方面又要项目组做出“MES当机怎么办”的预案。

在这种情况下，就形成了所谓松耦合的设计。

所谓松耦合，是比较紧耦合而言的。

紧耦合，有点类似同步通信，当一方系统出现异常时，另一方也无法正常工作。象康明斯NGMES、福特NGAVS、沃尔沃ANDON等系统都采用了紧耦合的设计。

而松耦合，类似于异步通信，当一方系统出现短暂异常时，不会影响另一方的正常工作。

下面我们举几个松耦合的例子。

案例一：通过条码缓存数据。

挑战：某整车厂总装车间，混线生产轿车、SUV、MPV，并且生产节拍达到61JPH(61台车/小时)，要怎么保障生产线上设备的防错？

方案：在装车单上打印各设备的防错条码。

当车辆出PBS时，MES系统打印装车单，并为各设备生成防错条码。防错条码由事先定义的字符串组成，包含车型、工艺参数等数据，并且合成一个长字符串。此过程由MES根据工艺配置自动完成，不需要和PLC交互。

当车辆进入防错工位时，工人扫描装车单上的防错条码，设备PLC经由扫描枪识别条码对应的字符串，再对字符串进行拆分、反向解析，得到所需的防错指令。此过程由PLC根据配置自动完成，不需要和MES交互。

案例二：通过RFID缓存数据。

挑战：某发动机装配车间，变型机较多，且工艺经常调整，因此需要MES能够灵活地处理工艺变更，并且对现场生产的影响要尽可能小。

方案：在大容量RFID TAG上存储工艺数据。

首先，在MES系统设计一个工艺管理模块，可以通过界面灵活地定义各机型在各工位的工艺。

其次，当发动机上线时，MES查询机型的工艺配置数据，得到此发动机在各工位的工艺参数，并且通过PLC写到64KB RFID TAG上。

第三，当发动机到达装配工位，PLC读取RFID TAG上本工位对应的工艺参数，指导设备进行对应的装配、拧紧、检测等作业。作业完成后，PLC把追溯需要的数据追加到RFID TAG上。

最后，当发动机到达下线工位，PLC把RFID TAG上追加的数据上传给MES。

我们可以看到，仅仅在上线、下线工位，PLC需要和MES实时交互；而在大部分的装配工位，作业仅仅通过PLC进行。

此外，由于工艺配置维护在MES系统里，配置数据存储在MES中，可以通过MES客户端界面，非常方便地进行工艺变更的配置。

图3.7-1显示了相关流程：

图3.7-1 通过RFID缓存数据

案例三：通过IT PLC缓存数据。

挑战：某整车厂调度系统，能够自动将订单下发给线体PLC，也能够自动从线体PLC同步车辆过站记录。现要求系统提供2个小时的缓存，当系统或网络出现短暂异常时，不会影响现场作业。

方案：通过IT PLC缓存数据。

IT PLC作为现场管理的关键设备，能够和线体PLC实时通信、交换数据。同时，IT PLC提供一定容量的数据存储功能，可以缓存2小时的订单数据和离线过站记录。

每天的生产作业开始之前，计划员在MES中提前“锁定”订单，系统自动将订单数据下发给IT PLC，并缓存在IT PLC内部数据块中。

当生产开始时，线体PLC向IT PLC请求订单，IT PLC检索本地缓存的数据，并转发给线体PLC；当IT PLC本地缓存小于安全值时，则自动向MES请求下发新的订单。当MES系统异常时，由于IT PLC和线体PLC的通信正常，且IT PLC向线体PLC下发的是本地缓存的数据，现场作业短时期内不会受到影响。

在过站记录工位，线体PLC采集RFID TAG信息，并上传给IT PLC。IT PLC判断MES是否在线，如在线则将数据上传给MES；如不在线则将数据缓存在IT PLC本地数据块中；当MES恢复在线后，IT PLC将本地缓存的离线过站记录上传给MES。