APS 篇把设备日历和已有占用作为排程输入，质量篇又区分了检验通过、放行批准和实际可用。设备故障以后，这些条件会在同一个现场相遇：报警消失了，维修人员提交完工，生产却还没有恢复。
这一篇进入设备管理与现场采集。文中另设一台装配设备的一次停机样本，沿用前文的设备命名，时间和故障事件独立模拟，不补写原风机订单的历史，也不把新故障当成原订单延期的原因。
同一台设备为什么会有几种状态
设备资产和生产资源先建立有效映射
EAM（企业资产管理）关注资产履历、维护计划、维修任务、备件和费用。CMMS 通常更集中于维护作业，APM 则侧重资产状态、可靠性及维护决策支持，实际产品范围会交叠。它们需要与现场控制、生产执行和排程建立对象关系，才能解释设备问题对任务的影响。
一台装配设备可以在 EAM 中使用资产号 AST-ASM-01，在 MES 和 APS 中使用资源号 ASM-01，PLC 或采集系统里又使用另一组设备与点位地址。资产号不一定与资源号一一对应：一条生产线可能由几台设备组成，一台设备也可能支持多种资源能力。
映射需要注明工厂、功能位置、有效时间和关系类型。设备搬迁、改造或控制器更换后，保留旧事件当时的映射。今天资源叫 ASM-01，不能据此把历史上另一台实体设备的报警和维修记录接过来。财务固定资产卡片也可能按不同粒度建账，不能默认每条卡片都能直接对应现场点位。
| 视角 | 本例对象 | 需要回答的问题 |
|---|---|---|
| 现场控制与采集 | 控制器、点位、报警事件 | 采到了什么值，何时产生，数据是否可信 |
| 设备维护 | AST-ASM-01、维修工单 | 哪个部件异常，做了什么，验证是否完成 |
| 生产执行 | ASM-01、工序任务 | 正在执行什么，何时停止，何时实际恢复 |
| 计划排程 | 资源能力、日历和限制窗口 | 哪段时间可安排，条件是否已经落实 |
| 经营核算 | 资产、维修项目与费用归集对象 | 工时、备件与费用归到哪里 |
报警、停机和故障原因分别存证
设备出现报警，可能仍能生产；设备停止，也可能因为缺料、等待质量处置、换型或计划休息。故障原因则需要结合检查、验证与维修结果确认。将所有“未运行”都归为设备故障，会把不同岗位的等待混在一张维修报表里。
PLC 或 DCS 执行现场控制，SCADA 提供监视与操作等能力，Historian 保存过程历史；MES 关联工序任务和产出，EAM 记录维护活动。具体部署可能合并这些角色。系统图应按实际责任画出数据来源，不能只凭产品缩写认定哪套系统知道全部事实。
设备状态也可以同时包含运行、模式、通信质量、维护限制和生产准入条件。例如设备处于手动调试模式、通信正常、维修验证尚未完成，不能压缩成一个绿色“在线”。HMI 上的报警确认、报警消除和业务上的允许复产，也应分别保留。
采集值需要时间和质量信息
一条状态值至少应能够回到来源设备、点位、来源时间、采集接收时间和数据质量。OPC Foundation 的 DataValue 定义区分值、状态码、来源时间戳和服务器时间戳。接入其他协议时，也需要明确哪些字段确实存在，哪些只能由网关补充。
断网后补传的停止事件，接收时间可能晚于发生时间。按接收顺序直接重建区间，就会把停机画错。时钟偏差、重复上报、乱序和点位替换，都应有明确处理规则；来源时间不可信时保留这个限制，不能靠补齐毫秒位数制造精确感。
通信中断表示状态未知。最后一次采到“运行”后失联，不能无限延续为正常生产；也不能直接把整个失联窗口记成设备故障。可以保留未知区间，再用现场记录、任务实绩与恢复后的数据核对，形成有版本的修订。
一次停机怎样进入维修工单
先固定一个独立的时间样本
本例以装配设备 ASM-01 为对象，使用样本工作日的本地时间。生产班次为 08:00 至 16:00，12:00 至 13:00 是预先确定的不安排生产时段，其余条件在这个简化样本中保持不变。维护人员使用独立日历，本次已获安排，可以在生产休息期间继续工作。
停机事件记为 STOP-E01，维修工单记为 MWO-E01。样本只用于说明记录粒度和计量方法，不提供现场维修操作步骤，也没有根据报警代码推导出一项真实故障。
| 时间 | 样本事件 | 记录含义 |
|---|---|---|
| 11:38 | 首次出现异常报警 | 保存报警身份与状态变化，此刻生产尚未停止 |
| 11:40 | 生产停止 | MES 与现场确认本次停止的起点 |
| 11:45 | 维修需求评估后建单 | MWO-E01 关联设备、现象和 STOP-E01 |
| 11:50 | 维修作业开始 | 本次直接维修作业开始计时 |
| 12:15 | 维修作业结束 | 记录完成内容，后续仍需验证 |
| 12:25 | 规定验证完成 | 本例维修侧验证完成，生产准入尚未全部落实 |
| 13:10 | 复产条件核对完成并批准 | 记录批准范围与身份，向目标系统发出动作 |
| 13:20 | 实际恢复生产 | MES 记录实际开工及相关实绩，结束本次停止区间 |
| 14:00 | 工单管理性结案 | 工时、备件与记录补齐后关闭本次工单 |
11:38 的报警、11:40 的停机、12:15 的维修完成、13:20 的实际复产和 14:00 的工单关闭，分别对应不同事实。整张维修工单的存续时间不能直接充当设备停机时长；后续记录补齐也不能把设备恢复时间推迟到管理结案时刻。
维修需求和工单之间保留确认过程
异常可以来自操作员报修、状态监测、点检或计划保养。需求记录保存现象、对象、发现时间、影响范围和证据，由相应岗位评估是否需要维修、如何定级、关联已有工单还是新建工单。报警抖动或连续重复上报，可能属于同一次问题，不宜每条消息都创建一张新维修工单。
预防性维护与故障维修也要区分。前者可由日历、运行计数或其他批准条件触发，后者围绕已发生的异常处理。Microsoft 的工单类型说明展示了预防性与纠正性维护分类，以及工单类型和生命周期模型的关联。这是产品配置实例，企业仍需确定自身的状态、职责与必填证据。
工单至少关联资产、功能位置、维修任务、故障现象、批准范围、人员与工具需求，以及预估工时和备件需求。预计修复时间可以帮助生产安排，但应注明估计来源、更新时间和未落实条件。等备件、等合格人员和正在修理，对预计恢复的影响不同。
作业记录连接备件、验证和费用
维修执行时记录任务实际开始与结束、人员工时、使用备件、拆换件身份和完成证据。设备备件与产品 BOM 里的支架属于不同对象，本例不把维修备件算进前文风机的 162 件支架净消耗。
两名维修人员同时工作半小时，可能形成一小时人工消耗，但设备只经历半小时日历时间。仓库发出一件备件，也不必然表示最终全部消耗；未使用退回、拆下件待修和报废需要各自记录。费用过账与设备状态更新可以有关联规则，仍应保留各自的业务结果。
Microsoft 的维护消耗登记说明列出了维护工时、物料与费用的登记及过账。本文据此保留工单执行与费用记录的连接，不将某套产品的过账步骤当成所有工厂的统一复产条件。
故障现象、已确认的原因、处置措施与验证结果最好分别保存。原因仍待调查时允许明确标记未确认，后续附上修订依据。维修工单结案能够证明哪些记录完成，应以实际状态规则为准，不能单凭“已关闭”三个字认定根因分析和长期纠正措施也已经全部完成。
停机时长和可用率怎样计算
先把区间与生产日历相交
本次生产停止区间为 [11:40, 13:20)，自然经过 100 分钟。其中 [12:00, 13:00) 是事先排除的生产休息时段，与停止区间重叠 60 分钟。按本文口径，落在计划生产时段内的停止损失为 100 − 60 = 40 分钟。
当天计划生产时间为 8 × 60 − 60 = 420 分钟。进一步假定其余计划时段都在正常生产，没有其他停止、未知或降速区间，则运行时间为 420 − 40 = 380 分钟，本样本可用率为 380 / 420 ≈ 90.48%。这项假定只服务于手算，不能据此宣称真实设备当天达到了这个水平。
| 口径 | 本例数值 | 边界 |
|---|---|---|
| 报警到实际复产 | 102 分钟 | 包含报警出现后仍在生产的 2 分钟 |
| 停止自然经过时间 | 100 分钟 | 11:40 至 13:20，未扣休息 |
| 本次直接维修作业 | 25 分钟 | 11:50 至 12:15，单独保存作业记录 |
| 计划生产内停止损失 | 40 分钟 | 与生产日历求交后计量 |
| 工单从创建到管理结案 | 135 分钟 | 11:45 至 14:00，不等于停机 |
| 当天简化可用率 | 90.48% | 按本文事先确定的日历和完整性假定 |
排班、时间区间和原因分类都需要保留版本。实际故障发生后再把这段时间改成“计划不生产”，会使分母和损失同时变化，掩盖原本的偏差。批准的计划维护则应按原先定义参与日历与报表，不能只凭“计划”两个字就认为它在所有指标中都要排除。
Microsoft 的维护停机记录说明明确区分已发生停机登记与计划停机活动，并说明该产品按适用日历计算时长。不同产品和配置可能采用不同日历及原因规则，集成时应把采用的口径写进契约，不能只同步一个没有单位与规则的 duration。
重叠事件按对象核对，原因另行解释
一台设备同时记录故障、缺料和质量等待，区间可能重叠。统计这台设备的总停止时间，应先在同一时间基准上求有效区间的并集，再与适用日历相交。直接累加事件时长，会让一小时内的损失超过一小时。
多种原因如何分摊，需要企业另行定义。可以保留所有并行限制，再明确主要原因或分段规则；不能为了做一张相加等于总量的饼图，就静默删掉次要原因。恢复关键路径也需要事件证据，例如设备已验证，但物料直到更晚才到位，此时后半段等待未必属于故障维修。
多台设备的停机不能直接相加为产线停机。瓶颈设备、缓冲区、并行资源和实际产出都会改变影响。同一停机可能影响多张生产订单，设备损失只统计一次，订单影响则按任务关联分别评估，不能把关联数量再乘回设备时长。
本例从 12:25 验证完成到 13:20 实际复产之间，还包括生产休息及后续准入、执行等待。各段详细原因需要继续查实际记录；时间先后只能支持定位调查范围，无法单独证明某岗位造成了延误。
可用率与可靠性指标各保留分母
OEE 通常还包括性能和质量因素。SAP 的 OEE 配置资料给出了可用率、性能、质量与 OEE 的组合公式。本文只计算简化可用率，没有给出理想节拍与合格产出，不能把 90.48% 写成 OEE。
MTBF 和 MTTR 还涉及故障定义、观察范围和计时口径。另设一个完全独立的统计例子：同一口径下累计运行 6000 分钟、发生 3 次符合定义的功能故障，运行暴露时间除以故障次数得到 2000 分钟。这是一种按运行暴露时间估计 MTBF 的口径，使用独立的多次故障样本；它无法保证未来还能连续运行这么久。
如果这 3 次故障的直接修理时间合计 90 分钟，按直接修理口径求平均是 30 分钟；若企业把诊断、等待或恢复验证计入平均恢复时间，结果会不同。指标名称、计时边界、纳入事件和样本量应一起展示。没有故障样本时，不宜用除零或“无限可靠”来代替尚无估计。
维修完成怎样成为可以安排的产能
复产需要确认设备以外的条件
维修侧完成工作后，按适用流程验证功能并交接。生产还需核对工艺配置、所需质量确认、人员、工装、物料和未结限制。安全与现场准入沿用企业既有流程，这篇文章不把上层软件批准写成对现场保护与操作规程的替代。
本例 12:25 完成维修侧验证，13:10 才完成复产条件核对并批准，13:20 实际生产恢复。批准记录应注明对应设备、可用能力、允许任务范围及仍存在的限制；目标应用成功与实际开始生产分别记录，防止把一条恢复指令当成已经产出。
有些设备修复后只能以受限速度或特定产品范围运行。这时应按批准的能力和有效期更新资源，不能一律恢复到额定满产。受限参数改变还可能影响工艺与质量要求，应通过已有职责核对其适用性。
资源窗口更新要有版本和目标回执
可以将恢复消息表达为下面的概念数据。编号与字段仅用于解释契约，没有对应厂商 API，也没有向真实设备或业务系统发送命令。
{
"action_id": "APPLY-REC-E01-APS-01",
"recovery_id": "REC-E01",
"recovery_revision": 1,
"asset_id": "AST-ASM-01",
"resource_id": "ASM-01",
"mapping_revision": "MAP-ASM-04",
"maintenance_order": "MWO-E01",
"target": "APS",
"capacity_window": {
"time_basis": "sample_local_day",
"available_from": "13:10",
"basis": "approved_readiness"
},
"expected_target_revision": "RES-ASM-19",
"approval_ref": "APP-REC-E01-01"
}
完整接口需要真实日期、时区、能力维度、数量单位、有效结束条件和其他限制；这里用样本时刻避免把虚构实绩写成现实时间。13:10 表示批准确认的可用起点，13:20 的实际恢复仍由 MES 实绩记录，二者分字段存储。
如果只知道预计 13:10 修好，应使用带条件的预计窗口，保留估计依据及有效期，不能发送同样的已确认可用语义。接收方还要核对当前版本，旧恢复消息不能清除后来新增的故障、维护或质量限制。
更新产能以后再核对剩余任务
APS 获知资源恢复，可以重新读取剩余任务、其他占用、物料和日历，形成候选计划。设备空闲不代表旧任务可以原样接着做：在制品状态、暂停点、重新准备与检查要求，以及期间调走的人员和工装，都可能变化。
MES 接受复产动作而 APS 更新失败时，分别保留真实结果。按动作身份查询目标，核实是否已应用；相同身份与内容的重试不能重复创建恢复动作或清除额外限制。目标版本冲突时进入差异处理，修改内容需要相应新版本及授权。
预防性维护安排也按同样的资源映射进入日历。延长维护窗口可能影响生产任务，生产插单也可能与已批准维护冲突；双方需要明确可以调整的范围、批准角色和目标回执。不能让任一系统在后台覆盖另一方已经落实的安排。
接入时怎样验证事件和业务结果
先用一组能核对原始记录的用例
下面的验收从来源时间一直覆盖到目标业务回执。站点只展示设计与模拟数据，没有连接真实控制器、EAM 或生产系统。
| 验收场景 | 需要核实的结果 |
|---|---|
| 报警发生但生产继续 | 保存报警，不凭报警消息直接建立生产停止区间 |
| 点位重复上报或抖动 | 按批准规则聚合，保留原始来源，不重复创建维修工单 |
| 断网补传、乱序和时钟偏差 | 来源与接收时间分别保存，修订有版本，不静默拼错区间 |
| 通信中断、当前状态未知 | 展示未知范围，不冒充运行或故障实绩 |
| 设备改名、搬迁或控制器更换 | 历史事件使用当时有效映射，当前状态使用现行映射 |
| 本文班次与停止区间 | 自然停止 100 分钟，计划生产内损失 40 分钟 |
| 同设备多项停止原因重叠 | 总时长按有效区间并集计算，各原因与分配规则可追溯 |
| 维修结束但复产条件未满足 | 保留生产限制，不将工单状态直接转换为满产可用 |
| 受限能力恢复 | 仅在批准能力与范围内可安排，其他限制仍生效 |
| 旧恢复消息到达新故障之后 | 不覆盖新限制，按版本冲突处理并返回原因 |
| 多目标部分成功或发送超时 | 按目标显示真实应用范围，重试不产生重复副作用 |
| 生产恢复后工单才补齐费用结案 | 停机结束时刻不被管理结案时间覆盖 |
验收需要一起看原始事件、标准化区间、原因修订、维修作业和目标台账。只核对看板上的总分钟数，可能碰巧算对，却仍把设备、任务或日期接错。本文的手算样本可以先作为小规模核对用例，再扩展跨班次、跨日、未结束事件和多资源情况。
Agent 先整理证据与差异
适合先交给 Agent 的任务包括：按资产汇集相关报警、任务和维修记录；列出未知与重叠区间；比较预计恢复与实际恢复；检查工单完成但资源限制仍未落实的差异；为停机报告附上来源、版本和查询时间。
询问“这次停了多久”，可以同时返回自然停止 100 分钟、生产日历内损失 40 分钟和直接维修作业 25 分钟，并说明口径。询问“为什么还不能开”，则继续检查复产条件和目标应用结果，不能只用维修工单已完工就给出“可以开机”。
根因推断需要与证据区分。相似报警和历史维修可以帮助形成调查建议，但不能自动认定当前故障相同，更不能凭预测结果解除现场限制。复产、资源变更和控制动作分别沿用已有权限与受控流程，业务 Agent 的解释权限不等于设备操作权限。
下一篇继续整理主数据、事件与跨系统对账。这里已经出现资产号、资源号、点位、任务、时间区间和版本映射，后续可以沿这些对象把整条制造业数据链上的差异逐项接起来。