4. 生产数据建模与采集点定义

在TwinCAT与MES集成的项目中，数据建模不是先写PLC代码，而是先回答三个问题：采什么、从哪采、多久采一次。如果采集点定义不清，后期会出现两类典型问题：一是MES侧数据字段缺失，报表无法闭环；二是高频采集把PLC周期和网络带宽拖垮，导致设备响应变慢。因此，本节把生产数据分为五类核心对象，并给出采集频率的设计方法。

一、五类生产数据的语义与边界

设备状态描述设备当前处于什么运行模式，典型取值包括：运行、待机、故障、换型、停机。状态量是离散量，变化不频繁，但必须记录状态切换时刻和持续时长，否则无法计算OEE中的时间开动率。在TwinCAT中，状态通常由PLC内部逻辑综合得出，而不是直接读一个物理输入点。

产量是累计计数类数据，分为总产量、合格品数、废品数。产量必须与工单绑定，否则MES无法判断这批产品属于哪个订单。产量采集的关键是增量计算：PLC侧维护一个累计计数器，MES按周期读取后做差分，避免重复计数。

节拍是单件产品从进入到完成的时间间隔，单位通常为秒或毫秒。节拍分为理论节拍和实际节拍，实际节拍由相邻两件产品的完成时间戳相减得到。节拍数据对分析产线瓶颈、判断设备是否降速运行非常关键。

报警是事件型数据，具有明确的开始和结束。报警建模必须包含报警代码、报警级别、触发时间、恢复时间、持续时长。报警不能只记录“发生了”，还要记录“是否已确认”，否则MES无法区分未处理报警和历史报警。

工艺参数是连续量或设定值，例如温度、压力、扭矩、速度、配方号。工艺参数与产品质量直接相关，采集时通常需要同时记录设定值和实际值，用于判断设备是否按配方执行。

二、采集频率的设计原则

采集频率不是越高越好，而是由数据变化速度和业务用途共同决定。状态和报警属于事件型数据，采用变化触发或上升沿触发，只在状态切换或报警产生时上报一次，既保证实时性，又不占用周期通信资源。产量属于累计量，变化频率取决于生产节拍，通常1～5秒采集一次即可满足工单进度显示。节拍数据在每件产品完成时产生，属于事件触发，不需要周期轮询。工艺参数中，温度、压力等慢变量可以100～500毫秒采集一次；扭矩、位置等快变量如果用于质量追溯，需要与产品序列号绑定后按件存储，而不是持续高频上传。

在TwinCAT中实现时，建议把采集任务与PLC控制任务分开。控制任务保持1毫秒或2毫秒周期，采集任务可以设置为10毫秒或100毫秒，通过ADS或Tc3_IoT把数据推送到MES。这样即使MES侧网络抖动，也不会影响设备控制逻辑。

三、采集点定义表（示例）

下面给出一份可直接参考的采集点定义表。表中参数为教学示例，实际项目需根据设备手册和MES接口规范调整。

四、从采集点到MES数据结构的映射

采集点定义完成后，需要把PLC变量映射为MES可识别的数据结构。以产量为例，PLC侧只提供累计值，MES侧需要的是“某工单在某时间段内的产量”。因此，在TwinCAT中应增加一个工单上下文变量，记录当前工单号和批次号。MES读取产量时，同时读取工单号，按工单做差分，才能得到正确的工单产量。

报警数据同样需要上下文。一条报警记录至少包含：设备编号、报警代码、报警级别、触发时间、恢复时间、确认状态。在TwinCAT中，可以用结构体数组缓存最近若干条报警，MES按时间戳增量拉取。这样即使网络短暂中断，报警记录也不会丢失。

五、常见错误与检查要点

• 状态量只读当前值，不记录切换时间。MES无法计算状态持续时长，OEE时间开动率会失真。正确做法是在PLC中检测状态变化，记录变化时刻并写入环形缓冲区。
• 产量用瞬时值而不是累计值。瞬时值在采集周期内可能被覆盖，导致漏计。应使用累计计数器，由MES做差分。
• 报警只记录触发，不记录恢复。报警持续时长无法计算，MTTR失去意义。应在报警恢复时写入恢复时间戳。
• 工艺参数采集频率过高。例如把扭矩以10毫秒周期持续上传，会造成网络和数据库压力。正确做法是按件触发，与产品序列号绑定后存储。
• 时间戳不统一。PLC本地时间与MES服务器时间不一致，会导致数据错序。建议统一使用UTC时间戳，或在TwinCAT中通过NTP同步。