大多数维护策略仍然停留在两个常见的极端之间：设备坏了再修，或者按照固定周期进行维护。这两种方式已经沿用了几十年，但都无法反映现代建筑和设备的实际运行方式。随着建筑系统越来越多地被数字化、数据化，这种脱节变得越来越明显。基于状态的维护正是在这样的背景下出现。
事后维修的局限
从理论上看，事后维修很简单：设备坏了，就去修。但在实际中，它会带来一系列可预见的问题。停机往往是突发且具有干扰性的。维修通常是在压力下进行，成本更高，对结果的掌控也更弱。团队花更多时间在应对故障，而不是预防问题。资源也容易被错配。关键设备可能缺乏足够监测，而一些优先级较低的问题却因为拖延升级，最终变成紧急任务。
结果是，团队长期处于被动应对的状态，对接下来会发生什么缺乏清晰判断。
计划性维护的不足
计划性维护的初衷是让维护工作更可控、更可预测，通过固定周期、预设任务和标准流程来实现。这种方式在稳定、变化较小的环境中有效，但现代建筑系统并非如此。使用模式在变化，负载在波动，设备老化也不均衡。同一栋楼里的两台相同设备，可能因为使用方式不同而表现出完全不同的状态。固定周期无法反映这种差异。
结果是，一部分设备被过度维护，而另一部分设备却在两次检查之间发生故障。长期来看，这既增加了成本，也降低了整体运行效率，却未必提升可靠性。
维护触发方式的变化
基于状态的维护从另一个前提出发：维护应当依据设备的实际状态来决定。在连接系统的建筑中，这种状态可以被持续测量。在 Akila 平台中，这来自于对楼宇系统数据的整合，包括 BMS、IoT 传感器以及设备控制系统。系统会识别运行状态的变化，从中判断磨损、效率下降或早期故障的迹象。
维护不再依赖固定周期或等待故障发生，而是在数据表明有需要时触发。这也改变了维护规划的方式。减少对周期的预测，更多依据实际运行信号进行响应。
在实际中的运作方式
基于状态的维护只有在数据能够转化为行动时才有意义。这意味着要从原始传感数据，走向可执行的维护流程。
在一个连接的系统中，通常包括：
- 持续监测振动、温度、运行时间和能耗
- 基于设备类型、使用情况和历史数据设定阈值
- 当运行状态超出正常范围时自动生成工单
- 将任务直接分配到维护流程中
关键在于，把数据转化为工单。维护团队不再只是被动响应零散告警，而是基于对设备运行状态的整体认知开展工作，无论是在单体建筑还是整个资产组合层面。
对运营的影响
当维护依据实际状态执行时，其效果是明确的。
响应速度提升。问题在演变为故障之前就被发现。
非计划停机减少。设备在早期信号出现时就被处理，而不是等到故障发生。
维护效率提升。资源集中在真正需要关注的设备上，从而减少不必要的干预，并延长设备使用寿命。
在实际项目中，通常可以看到：
- 故障响应速度提升约 40%
- 非计划停机减少约 40%
- 设备使用寿命延长最高可达 20%
- 维护成本降低约 20%
为什么现在尤为重要
大多数建筑已经具备所需的数据基础，问题不在于是否有数据，而在于如何在日常维护中使用这些数据。如果缺乏对资产和系统的统一视图，数据仍然分散在不同平台和团队之间。即使信号已经存在，维护决策仍然依赖人工判断。基于状态的维护依赖于将这些信号连接起来，让团队能够理解、排序并执行相应的工作。
Akila 如何实现这一点
Akila 将楼宇系统、设备数据和运行信号整合到同一个平台中，使团队能够从固定周期维护转向基于设备实际运行状态的维护方式。在实践中，维护工作不再依赖于零散的告警或定期检查，而是基于对资产随时间和使用情况变化的性能进行持续跟踪。
结语
维护常常被视为成本中心，但它同样反映了一个建筑在多大程度上被理解和有效运营。随着建筑与系统的连接不断深入，关键在于如何更精准、更及时地利用这些数据。基于状态的维护，是一个现实且可落地的起点。
