2026年5月产品更新

迄今为止，DataPortal中的维护任务都是根据使用情况（通常是运行小时数）触发的。这种方式对于持续运行的设备效果良好，但对于季节性设备、备用机组和利用率较低的资产而言，却存在疏漏。 一台每年仅运行 80 小时的设备仍需进行年度检查。若仅依赖运行小时计数器，这些维护服务便会被遗漏。

借助 Maintenance 2.0，您现在可以基于日历安排维护——每 6 个月、每年或任何自定义间隔——作为使用触发机制的补充或与其结合使用。 当两种模式同时配置时，平台会在首个阈值触发时发出维护事件。这对产品线多元化的原始设备制造商（OEM）尤为重要，因为其部分设备持续运行，而另一些设备仅在特定季节或运营时段使用。

由此制定的维护计划能够持续覆盖整个设备安装基数，而不仅仅是那些恰好运行时长累积较快的机器。对于 OEM 和服务机构而言，这意味着计划性维护收入更加可预测，并且能更有信心确保设备保持运行状态——包括那些原本可能被维护计划遗漏的季节性设备及备用设备。

现在，每项维护任务都可以附带相应的文档——包括分步操作指南、扭矩规格、零件编号或备件链接。技术人员在“Machine Companion”应用中执行任务时，可直接在工作流中查看这些信息。

其目的非常明确：减少操作失误，缩短经验尚浅的技术人员正确完成任务所需的时间，并消除现场与车间之间的反复沟通。对于原始设备制造商（OEM）而言，这还能在经销商网络中实现服务活动的标准化。

在设备维护工作中，一直存在一个难题：如何确认计划内的维护工作确实已执行，而不仅仅是系统中标记为已完成。为此，我们在“Machine Companion”应用中新增了任务确认功能。

技术人员完成维护任务后，可直接在设备上向设备所有者或操作员请求确认。设备所有者需提供基本身份信息，并在技术人员的屏幕上签名。签名、身份信息和时间戳将与维护记录一同存储，且已确认的任务会连同完整的审计轨迹一起显示在DataPortal中。

对于原始设备制造商（OEM）而言，这意味着拥有了可验证的服务交付记录。对于经销商而言，这消除了与客户产生纠纷的常见根源。对于设备所有者而言，服务历史记录真实反映了其设备上实际发生的情况。

对于已经运行成熟服务管理系统的原始设备制造商（OEM），Maintenance 2.0 的设计初衷是与现有工具并行使用，而非取代它们。由机器数据生成的维护事件可通过 REST API 推送至外部工单系统，同时工单状态也可同步回传——包括根据机器信号或外部更新自动关闭工单。

在仅需数据层的环境中，相同的 API 会提供运行小时数和状态数据，供 OEM 用于自身的维护工作流，而无需采用完整的 DataPortal 维护功能集。