定义
RUL（Remaining Useful Life）即剩余使用寿命，基于设备 Telemetry 与 Time Series DB 数据，通过机器学习或统计模型预测设备或部件剩余可用寿命。是 Predictive Maintenance 的核心输入。
建模方法与数据需求
RUL 预测方法包括物理模型（基于失效机理）、数据驱动（如 LSTM、Transformer、生存分析）及混合方法。数据需求涵盖正常运行数据、退化数据及失效样本；特征可包括振动、温度、电流等传感器时序及运行时长、启停次数等。设备管理平台需从 Time Series DB 时序库拉取历史遥测，经特征工程后输入模型；模型可部署于平台侧或边缘侧，支持批量或实时预测。
与 DMP 的集成
RUL 输出可驱动 Predictive Maintenance 预测性维护工单创建、备件采购计划、Maintenance Schedule 维护计划调整。与 Device Health Score 设备健康分结合，形成「健康分 + 剩余寿命」的综合评估；低 RUL 设备可优先安排巡检或更换。平台可提供 RUL 可视化、阈值告警及与 EAM/CMMS 的工单联动接口。
应用场景
适用于轴承、电池、电机等关键部件的寿命管理；工业设备、风电、轨道交通等领域的预测性维护。RUL 可优化维护策略，从定期维护转向按需维护，降低非计划停机与维护成本。
剩余寿命输出的是区间而不是日期承诺
剩余使用寿命估计的是：按当前退化轨迹，部件到达事先定义的失效阈值还要多久。输出应包含区间和置信说明，例如更可能落在某一段运行时间之内，而不是一个精确到天的到期日。失效阈值必须先定义清楚，是振动超过工艺限值、容量降到不可用，还是厂家给出的报废条件。没有阈值，模型只是在延伸曲线，谈不上寿命。
这个数描述的是部件，不是整机的所有故障。轴承的剩余寿命不能用来预测同一台设备的电源故障或通信模块故障。展示时应写明部件、所用测点和阈值，避免看板把一个部件的估计当成整机还能运行的承诺。估计会随新数据更新，变长或变短都正常；把第一次输出锁定成维护合同日期，之后就不再重算，结果会脱离后来的工况。
模型可用之前要有退化样本
数据驱动的估计要有从正常到接近失效的轨迹，最好还有已确认失效或已更换的结局，用来核对阈值是否真的对应不可用。只有几台新设备的平稳读数时，模型看不到退化斜率，输出会虚长。物理模型则要求测点能反映所声称的失效机理，例如用温度代替并未测量的磨损，就缺少使用条件。两种做法都不能用“有遥测”代替“有与该部件失效相关的遥测”。
上线前应把历史轨迹留出一段做核对：用前半段估计，看后半段是否在区间内走到阈值。对不上就不要拿来自动开工单。工况切换也会使旧轨迹失效，例如负载等级变了，应分段或重新积累，而不是把两种工况串成一条斜率。边缘侧若只上传经过大幅抽稀的点，平台侧再计算寿命会漏掉短时冲击，抽稀策略要和模型一起评审。
用健康分直接代替寿命估计
健康分通常是当前状态的加权，回答“现在像不像异常”。剩余寿命回答“按这个趋势还要多久越阈”。当前分很低可能是一次冲击，趋势未必短；当前分尚可，斜率已经很陡，剩余时间可能更短。把分数线性换算成天数，会在冲击当天给出极短寿命，第二天又跳回去，维护计划无法执行。
自动动作应绑在“区间上沿已经低于准备周期”这类条件上，并通过规则引擎限制重复开单，而不是每次重算都新建任务。缺少结局核对的模型不能单独作为更换依据，它只能提示提前检查。更换之后应把实际拆检结果写回，用于看阈值是否过严或过松。没有这层回写，估计会一直沿用最初的假设，看起来稳定，其实没有被现场验证过。
向维护人员展示剩余寿命时，同时给出所用测点、阈值、最近一次重算时间和区间，而不是只给一个天数。天数会被抄进计划后脱离模型单独存在。若新数据不足以更新，明确显示沿用上一次结果及其时间，禁止把旧结果刷新成“刚刚计算”。部件更换后重置该部件的轨迹，并把更换时刻记入序列，避免新部件继承旧部件的斜率。没有更换记录却看到轨迹突然变好，应先核对是换件还是传感器被替换，再决定是否相信新的估计。区间宽到无法安排备件时，结论应是继续观察而不是给出一个中间天数应付报表。中间天数会让人以为精度已经足够。宽区间本身就是结果，说明数据还没把失效时间收窄。