2. 生产数据与MES集成需求分析

在TIA Portal项目中谈MES集成，最容易犯的错误是“先建连接、再想数据”。正确的顺序恰好相反：先回到车间现场，弄清楚MES到底要回答哪些业务问题，再反推设备层需要提供什么数据、以什么频率提供、由谁负责。本节以一条典型的汽车零部件机加工与装配混合产线为例，说明如何完成需求分析，并输出可执行的集成范围、数据流与KPI定义。

一、从业务问题倒推数据需求

需求分析的起点不是PLC，而是MES侧的业务场景。常见场景可以归为四类：生产进度跟踪、质量追溯、设备效率统计、物料与工单防错。每一类场景都会对设备层提出不同的数据要求。

以生产进度跟踪为例，MES需要知道“某工单当前完成了多少件”。这要求设备层提供：工单号（或批次号）、当前产量计数、设备运行状态。若只提供累计计数而不提供工单切换信号，MES无法判断计数属于哪张工单，进度就会错乱。因此，工单号与计数的绑定关系，是这一场景的核心数据需求。

质量追溯场景要求更细。MES需要把每一件产品与加工参数、检测结果、操作时间关联起来。设备层至少要提供：产品序列号或载具ID、关键工艺参数（如拧紧扭矩、压装力、加工节拍）、检测判定结果（OK/NG）、时间戳。若追溯要求到“单件级”，则数据必须逐件产生，不能只给班次汇总值。

设备效率统计场景关注OEE。MES需要设备状态（运行、待机、故障、换型）、故障代码、停机起止时间。这里的关键是状态切换必须带时间戳，否则无法计算停机时长。很多项目只上传“当前状态”，MES只能靠轮询猜测切换时刻，精度差且易丢事件。

物料与工单防错场景要求设备层能接收MES下发的工单配方，并在换型时校验物料是否正确。这属于双向数据流：MES下发工单与配方参数，设备层回传校验结果与首件确认信号。

二、定义集成范围：先划边界，再谈细节

集成范围不是“所有数据都传”，而是明确哪些设备、哪些数据、哪个方向、什么频率。建议用一张范围表来锁定，避免后期无限扩张。

范围表确定后，还要明确“不做什么”。例如本示例中，刀具寿命管理由设备本地HMI负责，不纳入本期MES集成；能耗数据由能源系统单独采集，也不进入本接口。把排除项写清楚，能显著减少联调阶段的争议。

三、数据流设计：从信号到MES的完整链路

数据流设计要回答三个问题：数据在哪里产生、经过哪些环节、最终以什么形式到达MES。下图展示了本示例产线的数据流与集成边界。

图中红色虚线是IT/OT分界。设备层与PLC属于OT侧，MES属于IT侧，集成网关承担协议转换与数据缓存。这样划分的好处是：OT侧改动不影响MES接口，MES升级也不直接触碰PLC程序。上行数据以生产结果和状态为主，下行数据以工单和配方为主，方向清晰。

四、KPI定义：让数据可被验证

需求分析的最后一步是把业务目标翻译成可计算的KPI，并明确每个KPI依赖哪些数据字段。否则接口做完，MES仍然算不出有意义的指标。

以OEE为例，它由可用率、性能率、合格率相乘得到。可用率需要设备状态与停机时间；性能率需要实际产量与理论节拍；合格率需要总产量与合格数。对应到设备层，必须提供：状态字（含故障码）、状态切换时间戳、每件计数、理论节拍参数、OK/NG判定。若缺少状态时间戳，可用率只能按班次估算，误差可能超过10%。

再以一次合格率（FPY）为例，它要求区分“返修后合格”与“一次合格”。设备层若只上传最终OK/NG，MES无法区分返修件。因此需要在检测工位增加“是否返修”标志位，或由MES根据序列号历史自行判断。这个细节必须在需求阶段确认，否则追溯数据不完整。

五、输出物与落地建议

完成上述分析后，应形成三份可交付文档：集成范围表（含排除项）、数据流图（含方向与频率）、KPI-数据字段对照表。这三份文档是后续TIA Portal编程、网关配置和MES接口开发的共同依据。

在实际项目中，建议先选一条产线或一个工位做试点，把工单下发、产量回传、状态上报、单件追溯四条链路跑通，再横向复制。试点阶段重点验证三件事：数据是否逐件到达、时间戳是否一致、异常状态是否被正确标记。这三项通过后，KPI才有可信度，MES集成才算真正落地。