在制造业信息化这个圈子里泡久了你会发现一个特别有意思的现象几乎每个项目启动会上都有人拿着架构图问——你们这个ERP和MES到底有没有重复MES和PLC又是什么关系为什么数据要从ERP传到MES再传到PLC转这么多道不嫌麻烦说实话我第一次被问到的时候也愣了几秒。这三个词虽然天天挂嘴边但真要一两句话说清边界还真不是那么顺溜。后来我把它们放在一张图里反复给业务、IT、自动化三拨人讲讲多了才总结出一套能和任何人达成共识的拆法。这篇文章没有高深理论就干一件事把ERP、MES、PLC的职责边界和数据流彻底拆开顺便告诉你那张图应该怎么画、怎么用。如果你是制造业企业的IT负责人、刚入行的MES产品经理、搞PLC的电气工程师或者正在做数字化工厂规划但被三层架构搞得头大的人这篇应该能帮你省不少时间。1. 为什么这三套系统总是被搞混先搞懂信息断层在哪发生1.1 一个真实的“催单闭环失败”故事想象一家机加工厂。销售接了张紧急订单录入ERP之后MRP一跑物料需求、生产计划、采购建议全出来了。计划员在ERP里调整了优先级把A客户的货排到最前面。听起来一切正常对吧但真实车间里发生了什么工人看的还是两天前打印出来的纸质工单。计划员在电脑里改的优先顺序根本没有传达到车间现场。结果销售打电话催货车间主任说还没排到计划员说系统里早就插单了三方一对才发现ERP里的计划是个“理想计划”到了车间执行层面完全是另一回事。这个断层的根源就是ERP的计划没有被翻译成产线和设备能执行的东西。中间少了一个执行层的“翻译官”——MES。而更往下的误会通常发生在MES和PLC之间很多人以为上了MES就能直接控制设备实际上MES根本不该下发“具体动作指令”它下发的是“工单工艺要求配方参数”真正让电机转、气缸动、变频器调频的是PLC。所以你发现没有很多人混淆三套系统本质上是因为没搞懂它们处在同一栋楼的不同楼层看得见摸得着的东西完全不一样。1.2 三套系统对应三种“时间尺度”这是最核心的区分维度我后来想通一件事区分ERP、MES、PLC最有效的标准不是功能列表而是“时间尺度”。ERP的节奏是“天、周、月”它回答的是做什么、做多少、什么时候做账怎么算。MES的节奏是“分钟、秒”它回答的是现在正在做什么、做到哪一步了、做得怎么样、这批货能不能追溯。PLC的节奏是“毫秒、十毫秒”它回答的是设备这个瞬间应该怎么动作、当前I/O状态是什么。用个生活类比。开一家餐厅ERP是老板和管理后台定菜单价格、算进货量、盯月营业额一天盘一次账MES是大堂经理每桌菜做到哪一步、哪个厨师快慢、哪桌在催菜按分钟盯着PLC是厨师手上的颠勺动作和灶台温控每一秒都在执行具体操作。三个人各干各的活节奏完全不一样。你把颠勺的动作交给老板去管他管不过来你把每日营业额交给颠勺的厨师去记他也记不住。系统也一样ERP去管毫秒级的设备动作一定会被数据量淹死PLC去管订单和成本它根本没那个算力也没那个数据。层级错位就是混乱的开始。2. ERP管“算账”MES管“现场”PLC管“动作”职责边界一次拆干净2.1 ERP企业资源的“总调度”和“总账房”ERP的核心对象是订单、物料、BOM、库存、供应商、财务。它干的事是把企业层面的资源变成可执行的计划客户下单MRP运算出物料需求采购照着下单仓库照着入库车间照着领料财务最后算成本。但它有个天然边界不关心具体某台设备怎么加工也不关心这个零件目前在哪个工位。ERP里的“生产”是一个计划概念到了什么状态、消耗了多少物料它只能通过“报工”来更新。你问ERP“现在3号机床在跑什么活”它大概率答不上来因为这个问题根本不是它该管的事。很多企业ERP库存账对不上根子就在这里现场的实际消耗没有及时准确地回到ERP里。这不一定是ERP算错了而是边界外的数据没人喂给它是常态。指望ERP通过BOM倒扣算出库存差异前提是现场每一步都准时报工——这恰恰是MES的活。2.2 MES车间现场的“实时督导员”MES的核心对象是工单、工序、批次、SN序列号、设备状态、质检记录。它从ERP接收生产工单拆成工序级任务排到具体的产线、工位再通过终端、看板、扫描枪让人和机器执行起来。MES解决的经典问题工单在哪道工序当前良率多少上批料的追溯批次是什么这个操作工今天做了多少件合格品通过SN能查到哪天哪个班次哪台设备做的、用了哪批物料、当时工艺参数是多少。这些都是ERP答不上来、而车间管理者天天要问的问题。同时强调一点MES通常不直接“控制”设备。它更多是下达期望值比如下发标准节拍、目标温度、配方参数设备按不按这个执行、执行成什么样要靠PLC和传感器反馈回来。MES和PLC典型的分工是MES给“任务和条件”PLC给“动作和结果”中间靠数据接口配合。2.3 PLC设备层的“肌肉与神经”PLC本质上是一台专用工业计算机循环扫描执行梯形图、结构化文本之类的逻辑控制输入输出点。它管的粒度不是工单是I/O点温度传感器读到多少度、气缸是否到位、电机当前电流、变频器输出频率。搞IT的朋友第一次接触PLC最容易懵的三件事扫描周期、寄存器地址、通信协议。PLC程序跑一遍的速度通常在几毫秒到几十毫秒这和MES里秒级的交互完全是两个世界。你要让MES从PLC里读数据就得知道数据放在哪个数据块、哪个寄存器、什么数据类型还要懂得走什么协议——西门子有S7COMM三菱有MC协议罗克韦尔有CIP国产的汇川、台达、信捷也各有各的玩法。很多PLC也支持OPC UA或者Modbus TCP这通常是对上层系统最友好的接口。所以你看PLC不是“被MES管”的对象它是设备层真正的“肌肉和神经”。MES下发一个工单PLC才知道要把某条产线切到哪个生产工艺、跑哪套参数。MES管的是“结果和过程质量”PLC管的是“执行和控制”。2.4 一张对比表核心对象、用户、时间尺度、技术栈边界的对比放在一张表里最直观维度ERPMESPLC核心对象销售订单、物料、BOM、库存、成本工单、工序、批次、SN、质量、设备OEEI/O点、寄存器、扫描周期、设备动作决策时长天/周/月分钟/秒毫秒/十毫秒主要使用者计划员、采购、销售、财务车间主任、班组长、操作工、质量电气工程师、设备维护典型技术栈数据库、MRP、财务模块、API工单引擎、追溯、报工、看板、边缘采集梯形图、ST语言、OPC UA、Modbus回答的问题做什么、做多少、账怎么算正在做什么、做得好不好、能不能追设备该怎样动作、现在是什么状态这张表我建议你直接拿去做项目沟通的挂图。业务方只要一讨论“这个需求该放哪个系统”先摆出时间尺度和使用者两张底牌一大半争论当场就结束了。3. 数据流不是一条直线而是一场有来有回的接力3.1 完整数据链路从订单到工单再到设备动作把三个层级连起来看数据流的完整闭环是这么跑的客户下单ERP创建销售订单跑MRP生成生产计划和采购计划。ERP把生产工单下达给MES带上的内容至少包括物料编码、数量、交期、BOM版本、工艺路线版本。MES把工单拆成工序级任务排产到具体产线和工位通过车间终端或看板告诉人和设备干活把配方参数、工艺要求推给设备层。PLC执行具体动作控制产线运行同时把实际状态和结果——温度、压力、产量、报警信号——通过采集网关实时回传。MES收集、校验这些实时数据完成报工、质量判定、设备OEE计算形成“这个工单实际做了多少、做得好不好”的结论。MES把聚合后的结果回报给ERPERP据此更新库存、订单完工状态和生产成本。向下走的箭头是“翻译降维”订单被翻译成工单工单被翻译成参数和指令。向上走的箭头是“提炼聚合”设备信号被聚合成产量和质量产量和质量再被汇成库存和成本。每跨一层数据都变一次形态这才是数据流的本质。3.2 接口一ERP和MES之间靠的是“语义翻译”ERP和MES的接口方式很多数据库中间表、WebService、REST API、MQ消息队列甚至还有文件导入。技术选型不是最大难题真正难的是字段语义对齐。两边说的是同一种语言但各自的理解必须完全一致。举个例子ERP下达工单给MES时一个典型的接口消息长这样{ orderId: SO20240618001, workOrderId: WO20240618015, materialCode: MP-10086, materialName: 壳体-铝合金, planQty: 5000, dueDate: 2024-06-25 18:00:00, bomVersion: BOM-014, routingVersion: RT-003 }看着简单但每个字段后面都是坑materialCode在ERP里是10位编码在MES要是对不上全乱planQty的单位是“件”还是“箱”不确认清楚就是批量性错误bomVersion和routingVersion如果两边维护的不是同一版MES按旧工艺派工产品直接做错。所以每次接这种接口我第一件事不是写代码而是拉着两边业务坐在一起把字段映射表逐行签字。这个表通常比接口代码重要十倍。ERP侧字段MES侧字段值域/单位传输方向生产工单号workOrderId字符串唯一ERP→MES物料编码materialCode10位编码对应主数据ERP→MES计划数量planQty件不含损耗ERP→MES预计交期dueDateyyyy-MM-dd HH:mm:ssERP→MES完工数量completedQty件合格不合格MES→ERP报工工时laborHours小时精确到0.5MES→ERP还有一条原则ERP永远不应该直接连到PLC做控制级读写。为什么因为两边的时间尺度差了一万倍语言也不通。计划层的指令要经过MES翻译成执行层的任务再从执行层翻译成控制层的参数每一层都做自己擅长的事。3.3 接口二MES和设备之间靠的是“秒级对话”MES和PLC之间的连接方式业界已经比较成熟常见几种OPC UA工业互联的“普通话”西门子、罗克韦尔等主流PLC支持好跨平台能力最强。Modbus TCP通用性好老设备也常支持但数据模型简单复杂对象表达吃力。厂商私有协议三菱MC、西门子S7COMM、欧姆龙FINS、汇川/台达/信捷的私有协议性能和稳定性不错但是每家的接口都不一样。网关/SCADA兜底老设备只有串口或没有网口用远程IO模块或者PLC网关采集上来再统一转成OPC UA或者MQTT给MES。真正决定项目成败的往往不是协议选择而是“点位表”。点位表上每个字段都得写清楚设备编号、通信参数IP、端口、站号、点位名称、寄存器地址、数据类型、读写方向、采集周期。在项目里最常见的坑是等MES项目组进场了才发现PLC程序里根本没有预留数据块连PLC程序里有没有需要采集的变量都要重新改。这类问题前置到设备采购阶段就规划好比后期返工省钱得多。这里顺便回应一个热搜里频繁出现的词——“inproshop怎么设置PLC端口号”。我在现场配合过好几次这种操作。像Inoproshop这类国内PLC品牌常见的编程软件里要给MES取数开绿灯核心就两步先把PLC的以太网端口/IP地址固定好再把Modbus TCP或OPC UA的Server使能打开配置好端口号和寄存器访问范围。很多项目卡壳不是协议写得难而是PLC侧根本没把通信口打开上位机怎么都是白连。另外特别强调MES下发配方和启停命令是可以的但安全联锁必须留在PLC本地。谁都不希望MES网络抖一下产线安全回路跟着崩。工业安全的底线永远在控制层自己手里。3.4 别忽视反向数据报工、再制品、质量追溯很多人画数据流图习惯从订单往下画到设备最后在设备那边画一个向上的粗箭头就算完事。但做了几个项目之后你会发现真正让管理层两眼发光的往往是反向数据。反向数据第一类是报工。每个工单实际做了多少合格品、多少报废、花了多少工时从MES报给ERPERP的库存和成本才算得准。反向数据第二类是质量追溯。客户要追一个产品用了哪炉钢、哪个批次注塑料、当时工艺温度曲线是什么这些数据只可能在现场采集层里ERP永远存不了这么细。反向数据第三类是设备状态和能耗。设备OEE、运行时长、报警统计这些数据从PLC采上来在MES层聚合后既给车间看板用也可以汇给ERP做成本分析。这里要提一嘴高并发。比如注塑车间500台注塑机按每3秒一模计算一天下来就是千万级的事件量。这种数据要是让MES一条条实时打给ERPERP系统直接受不了业务数据库也得跟着遭殃。正确的做法是MES在中间做聚合缓存只把班次、日级的汇总结果回传ERP——产量、合格数、工时、物料消耗而不是每模一个脉冲都上报。这也正是ERP库存高并发场景的常见解法系统分层数据聚合而不是让底层海量数据裸奔到顶层。4. 五类最常见的边界混淆以及一套“边界判断法”4.1 我亲历的五种典型问题第一种把MES当成ERP的车间插件。有人觉得“MES不就是ERP里加个生产车间模块嘛”结果做出来就是一套电子工票系统现场不买账工人该看纸质单还是看纸质单。这不是系统功能问题是边界定位错了。第二种把MES当成设备控制软件。客户跟实施方说“你们MES得帮我把PLC逻辑改了”这非常危险。MES改的是业务参数和流程规则PLC改的是控制逻辑和安全连锁两者必须分开部署、分开权限。让MES直接改PLC的人迟早出事。第三种把PLC数据直接全量上ERP。有些企业采购了设备数据采集软件想着数据越全越好结果ERP里的库存、成本被海量的设备实时数据冲击得乱七八糟。设备信号该进MES/SCADA聚合后才能进ERP。第四种MES上线后发现现场根本没数据采集条件。我去过一些工厂设备是老式机床连网口都没有也没有流量计、电表接口。MES倒是买了数据全是人工扫码、手工录入最后还是变成“电子手工账”离执行层实时化的目标差了十万八千里。第五种一听MES开源就觉得“免费就能搞定”。这个想法很危险。开源MES只是代码不用花钱边界梳理、点位映射、流程重构的工作一个都少不了。我见过好几个项目死在“以为开源能省实施费”的幻觉里。4.2 遇到模糊地带先回答四个问题当业务方提出一个需求不确定该放哪个系统时我一般问四个问题这个数据多久要刷新一次毫秒/秒级往PLC/SCADA放分钟/小时级往MES放天/周级往ERP放。使用者是谁设备本身需要用是PLC车间主任、班组长需要实时盯是MES财务、销售、高层决策需要看是ERP。数据的粒度是什么设备信号点是PLC/SCADA工单、批次、SN是MES订单、库存、成本是ERP。需不需要“现场确认”这个动作如果这个数据必须靠点检、报工、返修确认、放行审批来更新那它天生属于MES如果纯硬件信号不需要人确认就是PLC的活。这套判断法在需求评审会上特别管用。业务方提一个“我希望看车间实时状态大屏”的需求先问“实时到什么程度”要秒级刷新、要显示每台设备状态那数据源一定是从PLC/SCADA来经过MES加工展示的如果只是“每天产量汇总”那ERP报表就够了。4.3 两个项目教训都是“职责越权”的坑教训AMES项目做成了“超级MES”。甲方觉得自己花了大钱要求MES把物流调度、设备维保、人员考勤、能源管理全包了。结果接口数量爆炸主数据在各模块之间反复横跳半年没上线。MES该聚焦的是工单执行、报工、追溯、质量判定这几条主线其他的可以集成但不能让它成为所有系统的替身。教训BERP项目想“一切皆从ERP发起”。有家企业要求车间报工必须在ERP里操作结果操作工根本没权限打开ERP界面每天由班长统一在电脑前录一次数据车间数据质量稀烂。后来改成MES负责现场高频报工ERP只接收班次汇总库存立刻准了不少。这件事让我彻底明白让每层系统做自己最擅长的事是数据流设计的第一原则。5. “一张图”怎么画把三层架构变成团队共识5.1 这张图的基本组成元素开头讲了这张图我用了很多年核心就三层加上下两组箭头但每个要素都得表达清楚图层系统主要职责时间尺度计划/决策层ERP订单、物料、库存、成本天/周/月车间/执行层MES工单派工、报工、追溯、质量分钟/秒设备/控制层PLC传感器网关设备动作、实时状态采集毫秒/十毫秒向下箭头计划与指令。ERP→MES是“订单变成工单”MES→PLC是“工单变成参数和指令”。向上箭头状态与结果。PLC→MES是“设备状态、产量、报警”MES→ERP是“报工汇总、质量结果、成本数据”。画图的时候左右两侧再标注两个信息每个图层的主要使用者是谁每个图层的典型数据接口是什么。这张图就算齐了。5.2 三个最容易画错的细节细节一有人把设备层画成孤零零一个PLC实际上这一层应该是PLC传感器执行机构通信网关的集合体。PLC只是大脑现场还有一堆眼睛和手脚。画图时刻意把“采集”和“控制”两个方向标清楚能避免别人误以为MES是直接连着一根线到设备的。细节二漏掉了边缘采集层。很多老设备根本没有数据出口必须通过远程IO模块或PLC网关才能往上层送数据。如果你画的数据流直接从设备跳到MES现场的人一看就知道你没做过实施。细节三把反向数据画成细线或者虚线。我看过无数张架构图向上的数据流画得又细又虚显得很“次要”。实际上对于成本核算、质量追溯、OEE分析来说向上的状态流才是价值密度最高的数据。画图的人弱化它等于在会议上告诉所有人这东西不重要。5.3 让这张图真正帮到项目推进的几个小建议我习惯把图分成两个层次使用。对内用三层架构图讲清楚“谁在哪个层级”对外在评审会上用“接口清单这张图”的方式讨论需求。每次业务方提新需求先问它落在图里哪个位置、涉及哪一根箭头、谁负责这个箭头的数据正确性。把这个变成评审流程之后项目扯皮率直线下降。再有就是把“时间尺度”直接标注在图上。见过很多次业务方看着三层架构图争论了好久“这个数据到底归谁”结果我一指图右侧的“天/周/月”“分钟/秒”“毫秒/十毫秒”几行字争论当场停了。时间和粒度比任何功能列表都更能说服人。6. 如果要从零开始梳理边界我建议你这样动手6.1 第一步梳理业务对象和现有单据不管你是企业方还是实施方第一步永远是清点业务对象订单、BOM、工艺路线、生产工单、批次、SN、设备台账、物料库存、成本科目。每类对象都标注清楚当前由哪个部门维护、在哪个系统里维护、更新频率是多少。你会发现很多企业的主数据其实是一塌糊涂的物料编码在采购叫A在仓库叫B在财务叫C三个系统三套码后面一切集成全都是无根之木。物料、客户、供应商这三类主数据建议先定标准。没有统一的主数据谈ERP和MES接口就是空中楼阁。6.2 第二步梳理现有数据流向和接口画一张现状清单现在每两个系统之间的数据是怎么走的。是接口自动同步还是人工导出再导入Excel是每天批处理一次有没有数据丢失和滞后我做过很多次现状梳理几乎每家工厂都能找出几个“靠人肉”维护的接口比如每个月底IT同事手动导ERP库存给MES对账。这类现状梳理做完问题的优先级自然就出来了先补影响最大的数据断层比如生产工单没下发、报工全滞后这两条永远是最高优先级的。6.3 第三步按“时间尺度”划分职责重构接口清单当你把每个业务动作重新过一遍的时候先问“它最合适的执行层在哪”再做归属。举几个典型结论业务动作归口系统理由订单接收、MRP运算ERP企业资源计划粒度工单下发与优先级调整MES接收ERP指令需要现场实时可见人员派工、线边物料确认MES高频人机交互设备参数下发MES→PLC参数与工单绑定设备实时状态采集PLC→MES毫秒级信号报工、返修、放行MES需要现场确认库存更新、成本归集ERP接收MES汇总天/周级汇总这样重新梳理一遍你会得到一张比现状干净得多的接口矩阵。注意接口不是越少越好而是每一条都要有明确数据主人、明确实时性要求、明确字段责任人。6.4 实操过程中的几个经验提醒谈技术之前先谈业务规则。数据流不清技术协议再先进也是白搭。我在几个项目里见过最荒唐的会议是双方IT在讨论OPC UA和MQTT哪个好业务侧连“工单BOM版本怎么确认”都没达成一致——这种会开一天没有任何结论。字段映射表一定要逐行确认。物料编码、BOM版本、单位换算、小数位这些看起来鸡毛蒜皮的地方往往就是项目上线后每天报错的源泉。宁可慢一天上线也要把映射表上的每个字段解释清楚。MES和PLC之间的点位映射表要在设备进场前就规划。采购新设备的时候直接在技术协议里写清楚“需要提供标准OPC UA接口数据点位包含设备状态、当前产量、报警、关键工艺参数”比后面再翻PLC程序省钱省事得多。小厂别盲目上全套MES。如果你只有三五条产线几十台设备先做ERP设备数据采集车间看板/报表把底层数据和基础流程理顺比一步到位靠谱得多。系统不在多关键是每一条数据流都真正闭环。最后再分享一个我自己的习惯。每次看一个企业的信息化架构我第一眼先看数据流是断的还是闭环的第二眼看每一根箭头是谁发出的、数据归谁负责第三眼看同一份主数据到底在多少个系统里维护。很多项目做到一半“卡死”卡的不是系统功能而是两边都不愿意让步的字段定义和责任边界。如果你能把ERP、MES、PLC这三层画成一张图并且让业务、IT、自动化三个团队在这张图上签字确认后面省掉的扯皮时间可能比你做项目的总周期都长。这是我做制造业数字化这几年最深的一点体会。
制造业数字化核心：ERP、MES、PLC职责边界与数据流解析
在制造业信息化这个圈子里泡久了你会发现一个特别有意思的现象几乎每个项目启动会上都有人拿着架构图问——你们这个ERP和MES到底有没有重复MES和PLC又是什么关系为什么数据要从ERP传到MES再传到PLC转这么多道不嫌麻烦说实话我第一次被问到的时候也愣了几秒。这三个词虽然天天挂嘴边但真要一两句话说清边界还真不是那么顺溜。后来我把它们放在一张图里反复给业务、IT、自动化三拨人讲讲多了才总结出一套能和任何人达成共识的拆法。这篇文章没有高深理论就干一件事把ERP、MES、PLC的职责边界和数据流彻底拆开顺便告诉你那张图应该怎么画、怎么用。如果你是制造业企业的IT负责人、刚入行的MES产品经理、搞PLC的电气工程师或者正在做数字化工厂规划但被三层架构搞得头大的人这篇应该能帮你省不少时间。1. 为什么这三套系统总是被搞混先搞懂信息断层在哪发生1.1 一个真实的“催单闭环失败”故事想象一家机加工厂。销售接了张紧急订单录入ERP之后MRP一跑物料需求、生产计划、采购建议全出来了。计划员在ERP里调整了优先级把A客户的货排到最前面。听起来一切正常对吧但真实车间里发生了什么工人看的还是两天前打印出来的纸质工单。计划员在电脑里改的优先顺序根本没有传达到车间现场。结果销售打电话催货车间主任说还没排到计划员说系统里早就插单了三方一对才发现ERP里的计划是个“理想计划”到了车间执行层面完全是另一回事。这个断层的根源就是ERP的计划没有被翻译成产线和设备能执行的东西。中间少了一个执行层的“翻译官”——MES。而更往下的误会通常发生在MES和PLC之间很多人以为上了MES就能直接控制设备实际上MES根本不该下发“具体动作指令”它下发的是“工单工艺要求配方参数”真正让电机转、气缸动、变频器调频的是PLC。所以你发现没有很多人混淆三套系统本质上是因为没搞懂它们处在同一栋楼的不同楼层看得见摸得着的东西完全不一样。1.2 三套系统对应三种“时间尺度”这是最核心的区分维度我后来想通一件事区分ERP、MES、PLC最有效的标准不是功能列表而是“时间尺度”。ERP的节奏是“天、周、月”它回答的是做什么、做多少、什么时候做账怎么算。MES的节奏是“分钟、秒”它回答的是现在正在做什么、做到哪一步了、做得怎么样、这批货能不能追溯。PLC的节奏是“毫秒、十毫秒”它回答的是设备这个瞬间应该怎么动作、当前I/O状态是什么。用个生活类比。开一家餐厅ERP是老板和管理后台定菜单价格、算进货量、盯月营业额一天盘一次账MES是大堂经理每桌菜做到哪一步、哪个厨师快慢、哪桌在催菜按分钟盯着PLC是厨师手上的颠勺动作和灶台温控每一秒都在执行具体操作。三个人各干各的活节奏完全不一样。你把颠勺的动作交给老板去管他管不过来你把每日营业额交给颠勺的厨师去记他也记不住。系统也一样ERP去管毫秒级的设备动作一定会被数据量淹死PLC去管订单和成本它根本没那个算力也没那个数据。层级错位就是混乱的开始。2. ERP管“算账”MES管“现场”PLC管“动作”职责边界一次拆干净2.1 ERP企业资源的“总调度”和“总账房”ERP的核心对象是订单、物料、BOM、库存、供应商、财务。它干的事是把企业层面的资源变成可执行的计划客户下单MRP运算出物料需求采购照着下单仓库照着入库车间照着领料财务最后算成本。但它有个天然边界不关心具体某台设备怎么加工也不关心这个零件目前在哪个工位。ERP里的“生产”是一个计划概念到了什么状态、消耗了多少物料它只能通过“报工”来更新。你问ERP“现在3号机床在跑什么活”它大概率答不上来因为这个问题根本不是它该管的事。很多企业ERP库存账对不上根子就在这里现场的实际消耗没有及时准确地回到ERP里。这不一定是ERP算错了而是边界外的数据没人喂给它是常态。指望ERP通过BOM倒扣算出库存差异前提是现场每一步都准时报工——这恰恰是MES的活。2.2 MES车间现场的“实时督导员”MES的核心对象是工单、工序、批次、SN序列号、设备状态、质检记录。它从ERP接收生产工单拆成工序级任务排到具体的产线、工位再通过终端、看板、扫描枪让人和机器执行起来。MES解决的经典问题工单在哪道工序当前良率多少上批料的追溯批次是什么这个操作工今天做了多少件合格品通过SN能查到哪天哪个班次哪台设备做的、用了哪批物料、当时工艺参数是多少。这些都是ERP答不上来、而车间管理者天天要问的问题。同时强调一点MES通常不直接“控制”设备。它更多是下达期望值比如下发标准节拍、目标温度、配方参数设备按不按这个执行、执行成什么样要靠PLC和传感器反馈回来。MES和PLC典型的分工是MES给“任务和条件”PLC给“动作和结果”中间靠数据接口配合。2.3 PLC设备层的“肌肉与神经”PLC本质上是一台专用工业计算机循环扫描执行梯形图、结构化文本之类的逻辑控制输入输出点。它管的粒度不是工单是I/O点温度传感器读到多少度、气缸是否到位、电机当前电流、变频器输出频率。搞IT的朋友第一次接触PLC最容易懵的三件事扫描周期、寄存器地址、通信协议。PLC程序跑一遍的速度通常在几毫秒到几十毫秒这和MES里秒级的交互完全是两个世界。你要让MES从PLC里读数据就得知道数据放在哪个数据块、哪个寄存器、什么数据类型还要懂得走什么协议——西门子有S7COMM三菱有MC协议罗克韦尔有CIP国产的汇川、台达、信捷也各有各的玩法。很多PLC也支持OPC UA或者Modbus TCP这通常是对上层系统最友好的接口。所以你看PLC不是“被MES管”的对象它是设备层真正的“肌肉和神经”。MES下发一个工单PLC才知道要把某条产线切到哪个生产工艺、跑哪套参数。MES管的是“结果和过程质量”PLC管的是“执行和控制”。2.4 一张对比表核心对象、用户、时间尺度、技术栈边界的对比放在一张表里最直观维度ERPMESPLC核心对象销售订单、物料、BOM、库存、成本工单、工序、批次、SN、质量、设备OEEI/O点、寄存器、扫描周期、设备动作决策时长天/周/月分钟/秒毫秒/十毫秒主要使用者计划员、采购、销售、财务车间主任、班组长、操作工、质量电气工程师、设备维护典型技术栈数据库、MRP、财务模块、API工单引擎、追溯、报工、看板、边缘采集梯形图、ST语言、OPC UA、Modbus回答的问题做什么、做多少、账怎么算正在做什么、做得好不好、能不能追设备该怎样动作、现在是什么状态这张表我建议你直接拿去做项目沟通的挂图。业务方只要一讨论“这个需求该放哪个系统”先摆出时间尺度和使用者两张底牌一大半争论当场就结束了。3. 数据流不是一条直线而是一场有来有回的接力3.1 完整数据链路从订单到工单再到设备动作把三个层级连起来看数据流的完整闭环是这么跑的客户下单ERP创建销售订单跑MRP生成生产计划和采购计划。ERP把生产工单下达给MES带上的内容至少包括物料编码、数量、交期、BOM版本、工艺路线版本。MES把工单拆成工序级任务排产到具体产线和工位通过车间终端或看板告诉人和设备干活把配方参数、工艺要求推给设备层。PLC执行具体动作控制产线运行同时把实际状态和结果——温度、压力、产量、报警信号——通过采集网关实时回传。MES收集、校验这些实时数据完成报工、质量判定、设备OEE计算形成“这个工单实际做了多少、做得好不好”的结论。MES把聚合后的结果回报给ERPERP据此更新库存、订单完工状态和生产成本。向下走的箭头是“翻译降维”订单被翻译成工单工单被翻译成参数和指令。向上走的箭头是“提炼聚合”设备信号被聚合成产量和质量产量和质量再被汇成库存和成本。每跨一层数据都变一次形态这才是数据流的本质。3.2 接口一ERP和MES之间靠的是“语义翻译”ERP和MES的接口方式很多数据库中间表、WebService、REST API、MQ消息队列甚至还有文件导入。技术选型不是最大难题真正难的是字段语义对齐。两边说的是同一种语言但各自的理解必须完全一致。举个例子ERP下达工单给MES时一个典型的接口消息长这样{ orderId: SO20240618001, workOrderId: WO20240618015, materialCode: MP-10086, materialName: 壳体-铝合金, planQty: 5000, dueDate: 2024-06-25 18:00:00, bomVersion: BOM-014, routingVersion: RT-003 }看着简单但每个字段后面都是坑materialCode在ERP里是10位编码在MES要是对不上全乱planQty的单位是“件”还是“箱”不确认清楚就是批量性错误bomVersion和routingVersion如果两边维护的不是同一版MES按旧工艺派工产品直接做错。所以每次接这种接口我第一件事不是写代码而是拉着两边业务坐在一起把字段映射表逐行签字。这个表通常比接口代码重要十倍。ERP侧字段MES侧字段值域/单位传输方向生产工单号workOrderId字符串唯一ERP→MES物料编码materialCode10位编码对应主数据ERP→MES计划数量planQty件不含损耗ERP→MES预计交期dueDateyyyy-MM-dd HH:mm:ssERP→MES完工数量completedQty件合格不合格MES→ERP报工工时laborHours小时精确到0.5MES→ERP还有一条原则ERP永远不应该直接连到PLC做控制级读写。为什么因为两边的时间尺度差了一万倍语言也不通。计划层的指令要经过MES翻译成执行层的任务再从执行层翻译成控制层的参数每一层都做自己擅长的事。3.3 接口二MES和设备之间靠的是“秒级对话”MES和PLC之间的连接方式业界已经比较成熟常见几种OPC UA工业互联的“普通话”西门子、罗克韦尔等主流PLC支持好跨平台能力最强。Modbus TCP通用性好老设备也常支持但数据模型简单复杂对象表达吃力。厂商私有协议三菱MC、西门子S7COMM、欧姆龙FINS、汇川/台达/信捷的私有协议性能和稳定性不错但是每家的接口都不一样。网关/SCADA兜底老设备只有串口或没有网口用远程IO模块或者PLC网关采集上来再统一转成OPC UA或者MQTT给MES。真正决定项目成败的往往不是协议选择而是“点位表”。点位表上每个字段都得写清楚设备编号、通信参数IP、端口、站号、点位名称、寄存器地址、数据类型、读写方向、采集周期。在项目里最常见的坑是等MES项目组进场了才发现PLC程序里根本没有预留数据块连PLC程序里有没有需要采集的变量都要重新改。这类问题前置到设备采购阶段就规划好比后期返工省钱得多。这里顺便回应一个热搜里频繁出现的词——“inproshop怎么设置PLC端口号”。我在现场配合过好几次这种操作。像Inoproshop这类国内PLC品牌常见的编程软件里要给MES取数开绿灯核心就两步先把PLC的以太网端口/IP地址固定好再把Modbus TCP或OPC UA的Server使能打开配置好端口号和寄存器访问范围。很多项目卡壳不是协议写得难而是PLC侧根本没把通信口打开上位机怎么都是白连。另外特别强调MES下发配方和启停命令是可以的但安全联锁必须留在PLC本地。谁都不希望MES网络抖一下产线安全回路跟着崩。工业安全的底线永远在控制层自己手里。3.4 别忽视反向数据报工、再制品、质量追溯很多人画数据流图习惯从订单往下画到设备最后在设备那边画一个向上的粗箭头就算完事。但做了几个项目之后你会发现真正让管理层两眼发光的往往是反向数据。反向数据第一类是报工。每个工单实际做了多少合格品、多少报废、花了多少工时从MES报给ERPERP的库存和成本才算得准。反向数据第二类是质量追溯。客户要追一个产品用了哪炉钢、哪个批次注塑料、当时工艺温度曲线是什么这些数据只可能在现场采集层里ERP永远存不了这么细。反向数据第三类是设备状态和能耗。设备OEE、运行时长、报警统计这些数据从PLC采上来在MES层聚合后既给车间看板用也可以汇给ERP做成本分析。这里要提一嘴高并发。比如注塑车间500台注塑机按每3秒一模计算一天下来就是千万级的事件量。这种数据要是让MES一条条实时打给ERPERP系统直接受不了业务数据库也得跟着遭殃。正确的做法是MES在中间做聚合缓存只把班次、日级的汇总结果回传ERP——产量、合格数、工时、物料消耗而不是每模一个脉冲都上报。这也正是ERP库存高并发场景的常见解法系统分层数据聚合而不是让底层海量数据裸奔到顶层。4. 五类最常见的边界混淆以及一套“边界判断法”4.1 我亲历的五种典型问题第一种把MES当成ERP的车间插件。有人觉得“MES不就是ERP里加个生产车间模块嘛”结果做出来就是一套电子工票系统现场不买账工人该看纸质单还是看纸质单。这不是系统功能问题是边界定位错了。第二种把MES当成设备控制软件。客户跟实施方说“你们MES得帮我把PLC逻辑改了”这非常危险。MES改的是业务参数和流程规则PLC改的是控制逻辑和安全连锁两者必须分开部署、分开权限。让MES直接改PLC的人迟早出事。第三种把PLC数据直接全量上ERP。有些企业采购了设备数据采集软件想着数据越全越好结果ERP里的库存、成本被海量的设备实时数据冲击得乱七八糟。设备信号该进MES/SCADA聚合后才能进ERP。第四种MES上线后发现现场根本没数据采集条件。我去过一些工厂设备是老式机床连网口都没有也没有流量计、电表接口。MES倒是买了数据全是人工扫码、手工录入最后还是变成“电子手工账”离执行层实时化的目标差了十万八千里。第五种一听MES开源就觉得“免费就能搞定”。这个想法很危险。开源MES只是代码不用花钱边界梳理、点位映射、流程重构的工作一个都少不了。我见过好几个项目死在“以为开源能省实施费”的幻觉里。4.2 遇到模糊地带先回答四个问题当业务方提出一个需求不确定该放哪个系统时我一般问四个问题这个数据多久要刷新一次毫秒/秒级往PLC/SCADA放分钟/小时级往MES放天/周级往ERP放。使用者是谁设备本身需要用是PLC车间主任、班组长需要实时盯是MES财务、销售、高层决策需要看是ERP。数据的粒度是什么设备信号点是PLC/SCADA工单、批次、SN是MES订单、库存、成本是ERP。需不需要“现场确认”这个动作如果这个数据必须靠点检、报工、返修确认、放行审批来更新那它天生属于MES如果纯硬件信号不需要人确认就是PLC的活。这套判断法在需求评审会上特别管用。业务方提一个“我希望看车间实时状态大屏”的需求先问“实时到什么程度”要秒级刷新、要显示每台设备状态那数据源一定是从PLC/SCADA来经过MES加工展示的如果只是“每天产量汇总”那ERP报表就够了。4.3 两个项目教训都是“职责越权”的坑教训AMES项目做成了“超级MES”。甲方觉得自己花了大钱要求MES把物流调度、设备维保、人员考勤、能源管理全包了。结果接口数量爆炸主数据在各模块之间反复横跳半年没上线。MES该聚焦的是工单执行、报工、追溯、质量判定这几条主线其他的可以集成但不能让它成为所有系统的替身。教训BERP项目想“一切皆从ERP发起”。有家企业要求车间报工必须在ERP里操作结果操作工根本没权限打开ERP界面每天由班长统一在电脑前录一次数据车间数据质量稀烂。后来改成MES负责现场高频报工ERP只接收班次汇总库存立刻准了不少。这件事让我彻底明白让每层系统做自己最擅长的事是数据流设计的第一原则。5. “一张图”怎么画把三层架构变成团队共识5.1 这张图的基本组成元素开头讲了这张图我用了很多年核心就三层加上下两组箭头但每个要素都得表达清楚图层系统主要职责时间尺度计划/决策层ERP订单、物料、库存、成本天/周/月车间/执行层MES工单派工、报工、追溯、质量分钟/秒设备/控制层PLC传感器网关设备动作、实时状态采集毫秒/十毫秒向下箭头计划与指令。ERP→MES是“订单变成工单”MES→PLC是“工单变成参数和指令”。向上箭头状态与结果。PLC→MES是“设备状态、产量、报警”MES→ERP是“报工汇总、质量结果、成本数据”。画图的时候左右两侧再标注两个信息每个图层的主要使用者是谁每个图层的典型数据接口是什么。这张图就算齐了。5.2 三个最容易画错的细节细节一有人把设备层画成孤零零一个PLC实际上这一层应该是PLC传感器执行机构通信网关的集合体。PLC只是大脑现场还有一堆眼睛和手脚。画图时刻意把“采集”和“控制”两个方向标清楚能避免别人误以为MES是直接连着一根线到设备的。细节二漏掉了边缘采集层。很多老设备根本没有数据出口必须通过远程IO模块或PLC网关才能往上层送数据。如果你画的数据流直接从设备跳到MES现场的人一看就知道你没做过实施。细节三把反向数据画成细线或者虚线。我看过无数张架构图向上的数据流画得又细又虚显得很“次要”。实际上对于成本核算、质量追溯、OEE分析来说向上的状态流才是价值密度最高的数据。画图的人弱化它等于在会议上告诉所有人这东西不重要。5.3 让这张图真正帮到项目推进的几个小建议我习惯把图分成两个层次使用。对内用三层架构图讲清楚“谁在哪个层级”对外在评审会上用“接口清单这张图”的方式讨论需求。每次业务方提新需求先问它落在图里哪个位置、涉及哪一根箭头、谁负责这个箭头的数据正确性。把这个变成评审流程之后项目扯皮率直线下降。再有就是把“时间尺度”直接标注在图上。见过很多次业务方看着三层架构图争论了好久“这个数据到底归谁”结果我一指图右侧的“天/周/月”“分钟/秒”“毫秒/十毫秒”几行字争论当场停了。时间和粒度比任何功能列表都更能说服人。6. 如果要从零开始梳理边界我建议你这样动手6.1 第一步梳理业务对象和现有单据不管你是企业方还是实施方第一步永远是清点业务对象订单、BOM、工艺路线、生产工单、批次、SN、设备台账、物料库存、成本科目。每类对象都标注清楚当前由哪个部门维护、在哪个系统里维护、更新频率是多少。你会发现很多企业的主数据其实是一塌糊涂的物料编码在采购叫A在仓库叫B在财务叫C三个系统三套码后面一切集成全都是无根之木。物料、客户、供应商这三类主数据建议先定标准。没有统一的主数据谈ERP和MES接口就是空中楼阁。6.2 第二步梳理现有数据流向和接口画一张现状清单现在每两个系统之间的数据是怎么走的。是接口自动同步还是人工导出再导入Excel是每天批处理一次有没有数据丢失和滞后我做过很多次现状梳理几乎每家工厂都能找出几个“靠人肉”维护的接口比如每个月底IT同事手动导ERP库存给MES对账。这类现状梳理做完问题的优先级自然就出来了先补影响最大的数据断层比如生产工单没下发、报工全滞后这两条永远是最高优先级的。6.3 第三步按“时间尺度”划分职责重构接口清单当你把每个业务动作重新过一遍的时候先问“它最合适的执行层在哪”再做归属。举几个典型结论业务动作归口系统理由订单接收、MRP运算ERP企业资源计划粒度工单下发与优先级调整MES接收ERP指令需要现场实时可见人员派工、线边物料确认MES高频人机交互设备参数下发MES→PLC参数与工单绑定设备实时状态采集PLC→MES毫秒级信号报工、返修、放行MES需要现场确认库存更新、成本归集ERP接收MES汇总天/周级汇总这样重新梳理一遍你会得到一张比现状干净得多的接口矩阵。注意接口不是越少越好而是每一条都要有明确数据主人、明确实时性要求、明确字段责任人。6.4 实操过程中的几个经验提醒谈技术之前先谈业务规则。数据流不清技术协议再先进也是白搭。我在几个项目里见过最荒唐的会议是双方IT在讨论OPC UA和MQTT哪个好业务侧连“工单BOM版本怎么确认”都没达成一致——这种会开一天没有任何结论。字段映射表一定要逐行确认。物料编码、BOM版本、单位换算、小数位这些看起来鸡毛蒜皮的地方往往就是项目上线后每天报错的源泉。宁可慢一天上线也要把映射表上的每个字段解释清楚。MES和PLC之间的点位映射表要在设备进场前就规划。采购新设备的时候直接在技术协议里写清楚“需要提供标准OPC UA接口数据点位包含设备状态、当前产量、报警、关键工艺参数”比后面再翻PLC程序省钱省事得多。小厂别盲目上全套MES。如果你只有三五条产线几十台设备先做ERP设备数据采集车间看板/报表把底层数据和基础流程理顺比一步到位靠谱得多。系统不在多关键是每一条数据流都真正闭环。最后再分享一个我自己的习惯。每次看一个企业的信息化架构我第一眼先看数据流是断的还是闭环的第二眼看每一根箭头是谁发出的、数据归谁负责第三眼看同一份主数据到底在多少个系统里维护。很多项目做到一半“卡死”卡的不是系统功能而是两边都不愿意让步的字段定义和责任边界。如果你能把ERP、MES、PLC这三层画成一张图并且让业务、IT、自动化三个团队在这张图上签字确认后面省掉的扯皮时间可能比你做项目的总周期都长。这是我做制造业数字化这几年最深的一点体会。