如何记录和分类设备停机

设备停机记录结合了由状态变化定义的区间、该区间在生产计划中的位置，以及确认后的原因。这些事实并非都来自同一个传感器。应把自动检测与操作人员解释分开，让系统显示哪些已知、哪些仍待评估。

定义区间

什么条件表示设备停止？运行位、停止增加的计数器或故障码可能有用，但各有局限。计数器静止可能表示停机、长周期或等待物料。需根据真实工艺验证解释。

开始和结束时间必须遵循相同的已记录规则。信号抖动可能形成大量短暂停机。如果采用过滤或区间合并，应一致定义。不同画面使用不同过滤，会导致同一班次总量相互矛盾。

先记录事件。原因未知时，应保持未知，直到合适的操作人员或维护流程确认。强制给每个事件分配默认原因，只会制造表面完整，而不会得到可靠信息。

原因字典应短到便于使用，也应具体到能够支持决策。过宽代码价值有限，数百个相似选项又容易导致不一致。字典变更需要明确与历史报告的关系。

假设机器10:15进入等待，10:27恢复生产。系统初始记录未知原因，操作人员随后确认缺料。应分别保存12分钟区间与稍后的确认时间，不能暗示开始时就已自动知道原因。

如果同时失去通信，需要评估边界的确定性。仅在这两个时刻各有一次读数，不能证明中间所有状态。没有可靠事件缓冲时，缺乏证据的部分仍然未知。

迟到事件可能改变区间边界。应规定是否重算报告，以及用户如何看到更新。补传事件保留身份，避免产生另一个停机区间。去重属于处理模型，而不只是画面筛选。

修正权限应按角色控制，保留修改者、原值和原因。为了让总数看起来正确而静默删除原始事件，会使后续争议难以解决。应保留证据，同时允许有依据的修正。

测试计划休息、短暂等待、真实故障、缺失数据和跨班次停机。将计算总量与刻意准备的事件时间线比较。观察操作人员是否一致使用原因代码，以及能否找到未分类事件。

可靠停机跟踪来自可解释记录和实用确认流程。一个漂亮的百分比，无法证明底层区间或原因正确。

假设机器10:12停止上报，采集器10:18重连后读到停机状态。仅凭这些观测，不能证明10:12就已停止；它可能在部分缺口期间继续运行。除非可靠事件来源或有记录的人员观察提供更多证据，否则这六分钟应标为未知。最新观测状态不能支持改写整个缺口。

操作人员以后确认停止时间时，应同时保留原始缺口，以及附有作者和时间的新增解释。区分自动观测与人工确认，有助于审阅者了解证据强度，也让应用可以重算报告，而不使旧版本变得无法解释。

对于重叠原因也应主动定义。例如机器等待物料的同时进行维护。报告策略可以指定一个主原因并保留辅助说明，也可以采用有记录的层级。若把两个完整区间都累计，可能夸大总停机时长。应与报告使用者约定方法，并测试多个条件重叠的示例。

初始代码清单应反映团队能够做出的判断。过宽代码指导性不足，大量近似选项又容易造成不一致。定期审查未分类项：它们可能表明缺少代码、证据不足，或流程在生产期间耗时过长。原因未知时，不要强迫操作人员编造精确原因。

实用验收演练应将一次短停、一次计划休息和一次较长故障，从源信号追到班次报告。检查所选时段起止边界的处理。测试跨两个班次的停机是否在两边正确显示，同时不会各自重复计入完整时长。记录显示时间代表源事件，还是轮询发现时刻。

最后明确谁处理暂定区间，以及何时认为报告时段已经审阅。未知原因不断积压，会削弱原本可靠的自动采集系统。调研时带上实际分类例子、样例信号和当前班次评审流程。目标是一条帮助团队解释停机的时间线；证据不能确定精确原因时，不确定性应保持可见。