3. 停线事件数据基础

做设备告警与停线原因的关联分析,第一步不是建模,而是把停线事件本身记录清楚。如果停线记录只有一句“设备故障停机 2 小时”,那么无论后续用多复杂的算法,都无法把停线准确归因到某条告警、某个部件或某类责任。停线事件数据基础要解决的核心问题是:一次停线在数据上应该长什么样,才能支撑“告警—停线—原因—责任”的完整追溯。

一、停线记录的最小结构

一条可用的停线记录,本质上是一次“有起止时间、有对象、有原因、有责任”的事件。它至少应包含以下字段组:

  • 标识与对象:停线事件ID、产线/工位编号、设备资产编号、产品型号或工单号。对象决定了这条停线属于哪台设备、哪条线,是后续与告警数据关联的键。
  • 时间:停线开始时间、停线结束时间、恢复生产时间。开始与结束用于计算时长,恢复生产时间用于区分“设备恢复”与“产线真正出料”之间的差异。
  • 原因:停线原因代码、原因描述、触发告警ID(若有)。原因代码是分类统计的基础,触发告警ID是关联分析的直接入口。
  • 责任:责任归属部门/岗位、是否本部门责任、处理人、处理措施。
  • 状态与质量:记录状态(草稿/已确认/已关闭)、数据来源(手工填报/系统自动/接口导入)、最后修改时间与修改人。

这些字段中,设备资产编号、停线开始时间、停线原因代码是三个最关键的主键性字段。缺少资产编号,停线无法定位到设备;缺少精确到分钟的开始时间,停线无法与告警时间窗对齐;缺少原因代码,停线只能停留在文字描述层面,无法做分类聚合。

二、停线原因分类:从“一句话”到“可计算”

停线原因分类的目标,是让每一条停线都能被归入一个稳定的类别,从而支持统计、对比和关联。常见的分类维度包括:

  • 按来源:设备故障、工艺异常、物料短缺、人员操作、计划保养、换型调机、外部因素(停电、停气)。
  • 按可控性:本部门可控、本部门不可控、供应商责任、客户原因。
  • 按影响:整线停、单机停、降速运行。

分类设计要遵循“互斥且穷尽”原则:每条停线只能落入一个主分类,同时允许有子分类。例如主分类“设备故障”下可细分“机械故障、电气故障、传感器故障、程序异常”。分类层级不宜过深,一般两级足够;过深会导致填报困难、口径不一,反而降低数据质量。

原因分类表应由设备、工艺、生产三方共同确认,并冻结为版本。分类一旦发布,历史数据不应随意改类,否则前后统计口径会断裂。

三、停线时长:三种口径必须分清

停线时长不是单一数字,至少存在三种口径:

  • 总停机时长 = 停线结束时间 − 停线开始时间。它反映设备或产线处于停止状态的总时间。
  • 净停线时长 = 总停机时长 − 计划内停机(如计划保养、换型)− 等待时间(如等物料、等指令)。它反映真正由异常造成的损失。
  • 影响产量时长 = 从停线开始到恢复出料的时间,用于折算产量损失。

举例说明:某工位 10:00 因传感器误报停机,10:12 操作工确认并复位,10:20 首件合格品产出。则总停机时长为 20 分钟,净停线时长为 12 分钟(若复位后无其他等待),影响产量时长为 20 分钟。三种口径分别用于设备可靠性统计、异常损失统计和产能损失统计,混用会导致指标失真。

四、责任归属:不是追责,而是定位改进点

责任归属字段常被误解为“找人背锅”,但在关联分析中,它的真正作用是区分停线的可控性。一条停线如果归为“设备故障—本部门可控”,那么对应的告警就值得深入分析;如果归为“外部停电—不可控”,则不应纳入设备改善的重点。责任归属应记录到部门或岗位级别,并保留“待确认”状态,避免填报人为了快速关闭事件而随意填写。

五、数据质量要求:关联分析的前置条件

停线数据要能支撑告警关联,必须满足以下质量要求:

  • 完整性:关键字段(资产编号、开始时间、原因代码)不允许为空。缺失率超过 5% 时,关联分析结论的置信度会明显下降。
  • 时间一致性:停线开始时间与告警时间必须来自同一时钟源,或明确记录时区与时钟偏差。跨系统数据若存在分钟级偏差,需在关联前做时间对齐。
  • 分类一致性:同一类现象必须使用同一原因代码。可通过定期抽查和双人复核控制。
  • 可追溯性:每条停线记录应保留修改日志,包括修改人、修改时间、修改前后值。
  • 及时性:停线结束后应在规定时间内(如 30 分钟)完成填报,避免事后回忆造成时间与原因失真。
常见的数据质量问题包括:开始时间只填到小时、原因代码选“其他”、责任归属全部填“设备部”、同一停线被重复录入。这些问题不会让系统报错,但会让关联分析得出错误结论。

六、停线记录与告警的关联入口

停线记录与设备告警的关联,通常通过三个入口建立:资产编号(同一台设备)、时间窗(停线开始前后若干分钟内的告警)、触发告警ID(若停线由某条告警直接触发)。实际分析中,先按资产编号缩小范围,再按时间窗匹配告警,最后用原因代码验证匹配是否合理。时间窗的宽度需要根据设备响应特性设定,例如 PLC 控制设备可取 ±2 分钟,人工上报的停线可取 ±10 分钟。

停线事件数据结构与关联入口 停线记录结构 事件ID / 产线 / 工位 设备资产编号 ★ 开始时间 / 结束时间 ★ 原因代码 / 原因描述 ★ 责任部门 / 处理人 记录状态 / 数据来源 ★ 为关联分析关键字段 停线原因分类 设备故障 工艺异常 物料短缺 人员操作 计划保养 / 换型 外部因素 互斥且穷尽,两级分类 停线时长口径 总停机时长 结束 − 开始 净停线时长 扣除计划与等待 影响产量时长 至恢复出料 关联入口 ① 资产编号匹配 ② 时间窗匹配 ③ 触发告警ID 数据质量要求 完整性 · 时间一致性 · 分类一致性 · 可追溯性 · 及时性

把上述结构、分类、时长、责任和质量要求落实到填报模板中,停线数据才具备与告警数据做关联分析的基础。实际推进时,建议先用一周的停线记录做一次字段完整率抽查,统计资产编号、开始时间、原因代码三项的缺失比例,再决定是先补数据还是先改流程。数据基础不牢,后续的关联规则和模型都只是空中楼阁。