前言
大家好，我是wacky。上一篇我们聊了下位机和固件，前面几期概念篇聊的都比较"底层"：实时性、扫描周期、下位机、固件。这一期我们往上走一层，聊一个工程里绕不开、但很多人一直没理清的概念：SCADA、MES、ERP 系统的边界。
为什么要聊这个？因为在日常交流时，我发现一个很普遍的现象：刚入行的.NET开发者，被问到"SCADA、MES、ERP 分别是什么"时，能背出三个英文全称，但说不清它们到底管什么。更尴尬的是在项目里：老板说"让ERP看下设备温度"，你一头扎进ERP里写Modbus轮询，结果把财务模块都搞卡了；或者MES团队和上位机团队互相甩锅："数据不对是你的锅！不对，是你的接口有问题"。
这三个系统经常被混为一谈，但它们各自负责的领域其实泾渭分明。理清边界，不只是为了面试能答上来，更是为了你在做架构决策、跨部门协作时，知道什么事该你管、什么事不该你揽。
先说结论：三个系统管的是不同层面的事
我们在谈细节之前，先给出一个总览——把工厂想成一座金字塔，从下到上分三层，这三个系统恰好各占一层：
最底下是设备层：机器、产线、传感器在那儿轰隆隆转。SCADA 管这一层，它是设备的"眼睛和耳朵"，负责看见设备、听见设备、偶尔指挥设备一下。
中间是执行层：车间里的人在排产、在报工、在追良率。MES 管这一层，它是车间的"调度员"，决定先干哪单、用哪条线、谁来做。
最上面是企业层：老板、财务、采购在那儿看报表。ERP 管这一层，它是企业的"大管家"，管钱、管料、管人。
一句话概括：SCADA 看设备，MES 管生产，ERP 管企业。层级越低越靠近物理设备，层级越高越靠近经营决策。你写的.NET程序，绝大多数时候站在最底下那层，我们继续往下看。
SCADA是什么：设备的"眼睛和耳朵"
SCADA 是 Supervisory Control And Data Acquisition 的缩写，直译是"数据采集与监视控制系统"。名字唬人，干的事很朴素：把下位机(PLC等设备)的数据读上来，显示给人看，顺带做点轻量的控制和报警。
如果你读了我前面的概念篇，会发现 SCADA 跟你一路学来的东西直接挂钩：它读的就是 PLC 扫描周期里更新的那些数据，走的是 Modbus 或 OPC UA，碰到的固件版本问题也会在这里冒头。
举个具体例子。你做一个反应釜监控系统（经典案例重现）：汇川EVO系列PLC做下位机，你的.NET程序做上位机，通过OPC UA把温度、压力等数据读上来，画成实时曲线，温度超标了弹个窗、记条日志。这套东西，本质上就是一个 SCADA 系统，也就是SCADA的客户端。
注意 SCADA 的边界：它管的是"怎么把设备数据呈现出来、怎么把操作下发到设备"，不管"生产什么、生产多少"。反应釜温度到120度报警，这是 SCADA 的活；但"今天该生产A产品还是B产品"，不归 SCADA 管。
MES是什么：车间的"调度员"
MES 是 Manufacturing Execution System，制造执行系统。如果说 SCADA 是眼睛和耳朵，MES 就是大脑的执行中枢——它决定生产怎么排、活怎么分、进度怎么追。
MES 关心的典型问题：今天有哪些工单要生产？每条产线排什么产品？哪个工序用哪台设备？操作工是谁？这一炉良率多少？工时花了多少？
关键区别来了：MES 不直接控制设备。它不会去写PLC的寄存器、不会去发Modbus指令让电机转。它管的是"计划和执行"：把生产任务拆解成工序，再把工序下发给下面的执行层（SCADA 或 PLC 去真正驱动设备）。
还是反应釜的例子。ERP 说"今天就生产500公斤A产品"。MES 接到这个任务，拆成工序：配料→升温→反应→冷却→包装，分配到具体产线和设备，派给操作工，然后盯着 SCADA 回传的数据，看每一道工序完成了没、良率达标没、超没超时。MES 是"生产过程的指挥官"，但它自己不动手，动手的是下面的设备。
ERP是什么：企业的"大管家"
ERP 是 Enterprise Resource Planning，企业资源计划。它是金字塔最顶层的系统，管的是企业级的资源：财务、库存、采购、销售、人力资源、成本核算。
ERP 的特点是：它完全不关心设备怎么转。它只知道"客户下了500公斤A产品的订单，BOM里需要多少原料，原料库存够不够，交期是哪天，这单能赚多少钱"。至于这500公斤是在1号反应釜还是2号反应釜生产的、温度是120度还是130度，ERP根本不关心。
ERP 和车间之间是隔着一层的。它通过 MES 间接了解生产进度，MES 再把汇总后的产量、良率、工时数据喂回 ERP，ERP 据此更新库存、核算成本、确认交付。ERP 的世界里没有"寄存器D100"、"IO地址IX9.9"，只有"库存数量"、"订单状态"、"会计科目"。
三者怎么配合：一条订单的旅行
光说定义还是抽象，我带你跟着一条订单走一遍，看看数据到底怎么在这三层之间流转：
第一步，客户下单500公斤A产品。ERP 接单，算BOM（物料清单）、查库存、排交期、算成本，但此时车间里什么都没发生。
第二步，ERP 生成生产计划，把工单下发给 MES。注意，ERP 下的是"生产什么、多少量、哪天交"，不是"怎么生产"。
第三步，MES 排产。它把工单拆成具体工序，分配产线、设备、操作工，生成作业指令。
第四步，MES 通过接口（或经过 SCADA）把指令下发给 PLC。下位机开始真正驱动设备干活：升温、投料、反应。
第五步，设备运转，SCADA 实时采集温度、压力、产量这些数据，回传给 MES。
第六步，MES 汇总执行结果（实际产量、良率、工时），再回传给 ERP。ERP 更新库存、标记订单进度、核算这单的真实成本。
看到没有？数据从顶上往下派指令，从底下往上回流结果，三层各管一段，接力把活干完。SCADA 在最底，负责跟物理设备"交流"；MES 在中间，把上边的意图翻成下边的动作、把下边的数据翻成上边的语言；ERP 在最顶，管经营层面的资源和决策。
为什么 MES 已经采了数据，上位机还要单独采一遍
之前在群聊中碰到一个有意思的问题：MES 不是也连着设备、也读 PLC 的数据吗？那上位机为什么还要再采一遍？这不重复了吗？
不重复。因为它们采的"数据"根本不是一回事——频率不同、粒度不同、目的也不同。
先说频率。MES 的采集是事件级、事务级的：一个工单开工了、一炉反应结束了、这批良率算出来了——它是按"业务事件"触发的，可能几分钟甚至几小时才落一条记录。而上位机对温度、压力、流量的采集是连续、高频的：100 毫秒一个点，一天就是 86 万条。MES 不可能、也没必要存这么细的原始波形——那是 SCADA 写进时序数据库（比如 InfluxDB）干的事，用来画曲线、做趋势、查报警历史。
再说粒度。MES 关心的是"业务事实"：这一批产了多少、良率多少、谁操作的、几点干的。它要的是聚合之后的结果。上位机关心的是"物理信号"：寄存器 D100 里的原始温度值、模拟量模块的实时读数。MES 拿到的是"结论"，上位机拿到的是原始数据，而结论是从原始数据中算出来的，而这个"算"的过程得有人做，这个人就是上位机 / SCADA 采集层。
还有解耦。前面踩坑案例里说过，把设备通信直接塞进业务系统（ERP / MES）是一种灾难。MES 不应该紧耦合到 PLC 的寄存器地址和扫描周期上，一旦PLC 改个地址、升个固件，MES 就跟着崩。所以现实里更稳的架构是：上位机把 PLC 原始数据采上来、清洗好、换算成物理量，再通过接口（REST API 或中间表）喂给 MES；MES 在这个基础上做业务聚合，而不是直接去跟设备"交流"。
所以准确地说，MES 不是"替代"了上位机的采集，而是消费了上位机采集层加工过的数据。两者是上下游，不是替代关系。你写的 .NET 程序干的，正是中间这个"采集 + 清洗 + 换算"的苦活，这活 MES 做不了，也不该做。
你写的.NET程序站在哪
这是最关键的——前面都是铺垫，这一节才是你最该铭记的。
你写的.NET工控程序，绝大多数情况下站在最底下的那层：就是 SCADA 层，或者更准确地说，是 SCADA 与 MES 之间的数据采集层。你的日常工作是这样的：
往下，你通过 Modbus/OPC UA协议读 PLC 里扫描周期更新的数据，处理固件版本兼容性带来的坑，把原始寄存器值换算成有意义的物理量。
往上，你把清洗好的、结构化好的数据，提供给 MES，或者 MES 通过你的接口来主动获取。你也可能接收 MES 下发的生产指令，翻译成 PLC 能执行的动作。
这就是你的主战场：把 PLC 数据变成 SCADA 能用的数据，把 MES 指令变成 PLC 能执行的动作。你在设备和生产系统之间做"翻译"和"搬运"。
边界也要看清：你一般不直接碰 ERP，那是另一套体系，可能是Java写的，也可能是SAP那种商业套件，你跟它最多是接口对接（REST API 或中间数据库表），不会进去写业务。你也不写 MES 核心（除非你是全干工程师），排产算法、作业调度那是 MES 团队的活。
所以当你被问"你做的系统属于哪一层"时，答案很清楚：我做的是 SCADA / 数据采集层，负责设备数据接入和上层系统对接。
后记
SCADA、MES、ERP 的边界，表面看是三个名词解释，背后其实是工程里的分工契约。理清它，你就不会在架构设计时不该自己管的揽过来（比如去 ERP 里写 Modbus），也不会在多团队协作排查问题时搞不清责任："设备数据不对是谁的锅？"你一听就知道：是 SCADA 采集层的问题，还是 PLC 固件的问题，还是 MES 汇总的问题。
前面几期概念篇，我们从实时性、扫描周期，聊到下位机、固件，再到这一期的三层系统边界——一条从设备底层到企业顶层的认知链路就打通了。下一篇我们做一个收束，把前面所有的概念串起来，画一张.NET工控项目的典型架构全景图。诸君共勉。
本文首发于我的公众号【wacky的碎碎念】，欢迎关注追更！
浙公网安备 33010602011771号