维护按日历安排还是按状态触发，原厂概述怎样区分依据

设施维护资料里既写年度安排，又写按设备状态触发，是否前后矛盾？IBM关于维护调度的概述，将这些说法放在不同的维护类型下。[1] 它们所用的触发依据不同，同一份服务资料出现多个类型名称，并不意味着作者只是在重复一个时间表。

Josh Schneider与Ian Smalley的文章发表于2026年10月6日。它在预防性维护部分说明，维护可按固定日历间隔安排，也可按实际使用量触发。[1] 因而，即使都属于预防性维护，时间经过了多久与设备实际使用了多少，也不是同一项条件。

时间型安排以日历为依据，原文特别说明它不取决于设备用了多少。使用量型则依据运行小时、生产循环等实际使用信息。[1] 本稿采用这个定义差别，不引用示例周期为设施制定检查日历，也不认定使用较少就可以跳过既定要求。

状态维护的完整段落，又将依据转向资产实际状态：传感器或检查关注振动、温度等状态指标，当指标超出可接受范围时安排维护。[1] 这段话解释触发来自什么信息，并没有为本文手头的任何设备给出一个可接受范围。没有实际资料，不能把概述中的名称换成现场告警阈值。

由此看，“什么时候做”可以有不同来历。日历型来自时间安排，使用量型来自累计使用，状态型来自有关设备状态的信息。一个系统都能把这些请求显示成日期，并不意味着日期背后的触发条件已经相同；只看到日历条目，也无法反推出它由哪一类条件产生。

IBM还区分维护计划与维护调度：前者关注需要做什么以及怎样准备，后者关注何时进行、由谁执行。[1] 因此，知道请求因何出现，与知道人员已经排到哪天，也属于不同问题。本稿不把软件生成一条请求当作维护已执行，更不据日历判断设备可以安全运行。

文章指出，组织可能结合多种方法用于不同资产。[1] 本文不把这句概述改成对所有设施的推荐，也不采用其收益、成本或风险效果表述来排名。这里没有资产状态、故障记录或服务合同，不能断言状态型一定更省钱，或固定时间安排一定过度。

本稿只解释原文类型定义及计划/调度的分工，没有提供检修操作、周期、阈值或安全结论。区分日历、使用量与状态，能够让维护服务描述保留触发依据；至于实际设备应该采用哪种安排，不能由一个类型名称直接作答。