OEE数据采集与看板：字段口径、校验和损失追溯

OEE数据采集需要把生产时间、设备运行、加工计数和首次质量结果对齐到同一设备、产品与统计窗口。一个可信的设备效率看板，应能解释百分比怎样算出、哪些记录尚未完成，以及损失发生在哪个时段。

落地时可沿着“字段约定—原始采集—窗口校验—指标计算—事件追溯”推进。下面给出适用于单设备、单工序试点的数据结构和教学验算。基础公式可参阅设备综合效率OEE。

计算OEE与解释三因子，需要哪些数据？

在单产品、理想周期固定且首次质量已判定的条件下，OEE简式需要计划生产时间、理想周期和一次合格数三个量。但要分别解释可用率A、性能率P、质量率Q，还需要运行时间和总加工数。因此，只接入一个运行信号，不能得到完整的OEE诊断。

核心输入	来源与口径约定
计划生产时间	来自排程、班次及实际生效的生产窗口；明确时区、起止和排除时段。
运行时间	由设备状态区间形成；明确何时运行、何时停机及短停处理规则。
理想周期	对应设备、产品与工艺；统一为秒/件，并保留版本和生效时间。
总加工数	来自同一工序的完成计数；说明是累计读数还是本次增量，单位是件、模次还是批。
一次合格数	来自对应加工记录的首次质量判定；区分合格、不合格和待判定。

例如，AWS IoT SiteWise的OEE示例使用设备状态、成功计数和失败计数流，说明采集必须覆盖状态与产出两个方面。它是一个具体示例；不能直接把示例状态码、时间定义或成功计数含义当成所有工厂的默认规则。

机台“通电”“自动模式”“正在加工”是不同状态；完成脉冲也可能只代表完成一次加工，并没有质量判定。应由生产、设备和质量人员核对信号对应的现场事件，再确定字段来源。若检验发生在后续工位，需要通过零件、批次或工单标识关联到本工序，不宜直接用当天入库数代替首次合格数。

原始记录怎样保存，后续才查得回来？

建议将“设备发生了什么”和“系统何时收到信息”分开保存。每条记录应能识别设备与工序、产品或工单、来源系统、事件标识、发生时间、接收时间、原始值和数据状态。涉及规则的记录再关联理想周期版本、原因码版本及修订记录。

设备状态宜保留起止区间，或保留可还原区间的状态变化事件；区间边界采用一致规则，例如包含开始时刻、不包含结束时刻，避免跨班交界被两边同时累计。发生在班次边界前、持续到边界后的停机，应按各窗口实际重叠时长分摊，不把整个事件只归到开始班次。

使用OPC UA时，OPC Foundation对DataValue的说明区分源时间戳、服务器时间戳和StatusCode。源时间反映数据来源端的时间，服务器时间反映服务器获知该值的时间；状态码用于判断数据是否可用。这里的Good、Uncertain、Bad描述的是数据质量，不是产品的合格或不合格。

跨工厂汇总时，可用统一的时间基准保存事件，并保留工厂时区供班次切分与显示。设备时钟、网关时钟和业务系统时钟需要可核对；不能直接把网络延迟变成停机时长。若现场无法提供可信源时间，应记录采用了什么替代规则及其局限。

计算之前，怎样处理计数、缺失与迟到数据？

累计计数与增量计数采用不同算法

如果计数器在窗口开始为10000、结束为10900，期间连续有效且没有复位，总增量是900件，不能把每次读到的累计值直接相加。若源端上报的是每个事件的新增件数，则应去重后求和。批量上传与重传也不能让同一个加工事件计两次。

发生复位或回绕时，应按已识别的计数段分别计算，并保留复位证据与边界；负差不能直接改成0后继续当完整数据。还应确认每个脉冲代表一件、多个模穴的产品，还是一次循环，并统一到对应理想周期的单位。

断网不自动等于停机，旧值不自动等于新值

采集连接断开，只说明系统暂时没有可靠新数据。设备可能仍在运行，也可能已经停机。建议将这段时间标为数据未知，显示覆盖缺口，并按既定规则决定是否暂缓最终OEE；有现场缓存补传时，再按事件发生时间补齐。

若使用最后一次状态延续区间，应明确新鲜度和连接状态条件，避免把很久以前的“运行”无限延长。OPC UA的Bad值不应用作有效生产测量；Uncertain值应保留其状态并按项目约定处理。产品质量率Q和采集有效覆盖率应分别显示，不能用一个“质量百分比”同时表达二者。

迟到的检验结果回到对应加工窗口

质量晚于生产到达时，先显示待判件数及暂未完成状态。结果到达后，关联回对应加工批次和窗口，生成可追溯的新版本；不要把上一班的检验结果直接算进接收消息时所在的新班次，也不要把待判件默认当成合格。

A、P、Q也必须对应同一统计窗口和版本。按窗口聚合指标有助于明确范围；AWS的OEE示例还提醒，简单组合不同输入的“最新值”可能产生意外结果。因此，看板应能区分正在更新的临时值与窗口数据齐备后的最终值。

用一小时原始记录，怎样验算出73.5%？

以下为单设备、单产品的教学数据，统计窗口为工厂本地时间08:00至09:00，时区已记录。60分钟全部计划生产，08:20至08:30停机，其余50分钟为运行；原始状态记录连续有效。理想周期3秒/件，累计计数由10000增至10900，期间无复位、无重复，总加工900件。

09:00时，882件已经首次判定合格，18件仍待判，质量和OEE保持“待完成”标识。09:06收到这18件的首次不合格结果，确认它们属于08:00至09:00的加工批次；此时该窗口的最终结果为882件一次合格、18件一次不合格、待判0件。

• A：50÷60＝83.3333…%。
• P：900×3÷（50×60）＝90%。
• Q：882÷900＝98%。
• OEE：A×P×Q＝73.5%。

简式复核为882×3÷（60×60）＝73.5%。时间应满足50＋10＝60分钟，件数应满足882＋18＝900件。09:06只是判定信息到达时间，不会把这900件自动搬到09:00至10:00的生产窗口。

这个例子还说明了采集验收的顺序：先确认窗口与状态闭合，再核对计数语义和单位，最后确认首次质量结果是否齐备。只看屏幕最终显示73.5%，无法判断系统是否曾错误忽略18件待判，或将晚到信息记入另一个窗口。

设备效率看板怎样支持损失追溯？

建议按读者的排查路径分层，避免一个屏幕堆满相互没有联系的仪表。

1. 概览层：显示设备、产品、统计窗口、OEE与A/P/Q，并保留计划生产、运行、总数和一次合格数。旁边显示待判件数、数据覆盖与更新时间，明确临时或最终状态。
2. 损失层：按一致范围展示停机、性能和质量损失，支持查看时间趋势与主要原因。尚不能区分的小停和降速保留待归因，具体分析方法见OEE六大损失分析与改善顺序。
3. 事件层：从某项损失进入对应时段，查看设备状态、产品、现场现象、原因确认、质量批次及处置记录。
4. 原始层：进一步核对源数据、发生与接收时间、计数段、数据状态和修订版本。解释分数变化时，应能辨认是生产改变还是数据补齐。

报警规则也要结合场景：没有排产时不宜因为OEE无值就报“设备效率异常”；数据断开应提示采集异常；已排产且状态有效的长停机，才进入相应生产事件处理。报警负责让人采取行动，不能只靠统一的红黄绿阈值代替判断。

试点上线如何验收，怎样分工维护？

可先选择一个计数位置清楚、产品与周期容易确认、质量结果能够关联的工序试点。与现场记录逐项对照，验证典型场景后再扩展到更多设备；多产品与整线汇总还需要单独确定统计规则，不能简单平均所有设备百分比。

验收场景	应观察到的行为
正常生产与停机	运行和停机区间与现场一致；主状态不重叠，时间窗口闭合。
重复上传或计数复位	同一事件只计一次；复位被识别并保留计数分段，不能静默丢产量。
断网及补传	明确未知时段与有效覆盖；补传按发生时间归位，不直接把断网算作停机。
跨班次或产品切换	按窗口切分事件；产品、理想周期与计数在切换点对应，历史版本可追溯。
质量迟到与返工	待判状态可见，首次判定回到原加工记录；后续返工不冒充原批一次合格。
零分母或异常比例	无计划生产显示不适用；P超过100%等异常触发输入核查，不截顶掩盖问题。

生产团队负责排程与状态含义，设备团队核实信号和计数行为，工艺与质量团队确认理想周期及首次判定，信息化人员负责采集、关联和版本追溯。每次改规则都应有生效时间，并复查受影响的窗口。

验收完成的标志，是现场人员能用原始记录复算一个窗口、解释一次损失，并看见未知和修订状态。采集接口连通、看板能够刷新，是必要环节，但不能单独证明设备效率数据已经可信。