从故障诊断到寿命预测：用 DolphinDB 构建工业设备的预测性维护管线

摘要

做工业设备运维的人，多半听过状态维修（CBM）的三个递进层次：诊断（现在有没有故障）、评估（一群设备整体多健康）、预测（这台设备还能用多久）。
前两层已经有不少实践------频谱分析能告诉你轴承是不是出了早期点蚀，健康评分能给整厂设备排个名。但真正能把运维从"被动响应"推向"主动排程"的，是第三层：预测设备的剩余使用寿命（Remaining Useful Life，RUL）。知道了某台泵还有多少天会失效，维修排程、备件采购、停机窗口就能提前安排，而不是等故障报警了才手忙脚乱。
但 RUL 预测在工程上一直不好做。难点不在算法，而在管线：原始波形怎么变成建模特征、标签从哪来（设备又不会主动告诉你它还能撑几天）、训练好的模型怎么从离线搬到实时。这条管线一旦要跨 Python 训练 + Flink 推理 + 数据库存储三个系统，光是特征对齐就能耗掉团队大半精力。
本文分享我用 DolphinDB 构建 RUL 预测管线的过程：特征工程、标签构造、库内训练、批量+流式推理，全在一个平台里闭环。重点不在"用了一个多先进的模型"，而在标签怎么构造、管线怎么搭------这两件事是预测性维护工程化的真正难点。

一、诊断、评估、预测：状态维修的三层递进

在动手之前，先把"预测性维护"在整个运维体系里的位置摆清楚，避免和已有实践混淆。

层次	回答的问题	典型手段	时间指向
诊断	现在有没有故障？故障在哪？	频域特征、包络解调	当下
评估	这批设备谁更该关注？	健康评分、群体排名	当下
预测	还能用多久？什么时候会失效？	RUL 回归、失效概率	未来

诊断和评估都是"看当下"，区别只在前者针对单台定位故障、后者针对群体排出优先级。预测则是唯一"看未来"的------它要给出一个量化的剩余寿命数字。

为什么要强调这个区分？因为很多人把"做了健康评分"等同于"做了预测性维护"，其实没有。评分告诉你"这台设备现在状态差"，但没告诉你"它还有多久会彻底失效"。前者是状态快照，后者是时间外推。维护排程需要的恰恰是后者：备件到货要两周，那这台设备至少得撑过两周才有意义。

本文聚焦的就是第三层------用历史数据训练一个能输出 RUL 的模型，并把它接到实时数据流上。

二、预测性维护的四段式管线

把 RUL 预测拆成工程上可落地的四段，后文逐段展开：

Plaintext 复制代码

原始时序数据
   │
   ▼
① 特征工程 ── 滚动窗口从波形里抽出建模特征（时域 + 频域）
   │
   ▼
② 标签构造 ── 用已知的故障时间点，倒推每条历史样本的 RUL 标签
   │
   ▼
③ 模型训练 ── 库内训练回归模型（随机森林回归），验证泛化能力
   │
   ▼
④ 推理打分 ── 批量给历史数据打分 + 流式给实时数据打分

四段里，①特征工程 和②标签构造是真正的难点。模型选什么反而没那么关键------只要特征干净、标签准确，随机森林这种"笨"模型也能给出可用的 RUL 估计；反过来，特征噪声大、标签错了，再花哨的深度模型也是垃圾进垃圾出。所以下文把篇幅主要给前两段。

三、特征工程：从原始波形到建模特征

3.1 一条原则：特征要在"设备 + 时间"维度上滚动计算

RUL 预测的特征不是单点值，而是一段时间窗内的统计特征。设备此刻的健康状态，不取决于某一毫秒的振动幅值，而取决于过去一段时间的振动趋势、峰值、能量分布。

这就要求特征计算必须按设备分组、按时间滚动。DolphinDB 的 context by + 移动函数天然适合这件事，复杂度是增量 O(n)，不会随数据量线性变慢。

3.2 滚动窗口特征表

假设原始振动表已经按八期的方法算出了每秒的振动 RMS（有效值），现在要在它之上滚动计算建模特征：

SQL 复制代码

// 基础表：每台设备每秒一条 RMS（由高频波形聚合而来）
// 字段：ts, deviceId, rms, temperature, rpm

// 滚动窗口特征：过去 10 分钟（600 秒）的统计量
features = select
    deviceId, ts,
    rms                                           as feat_rms,
    mavg(rms, 600)                                as feat_rms_mean,
    mstd(rms, 600)                                as feat_rms_std,
    mmax(rms, 600)                                as feat_rms_peak,
    mmin(rms, 600)                                as feat_rms_min,
    // 峰值因子 = 峰值 / 有效值，反映冲击性故障
    mmax(rms, 600) \ mavg(rms, 600)               as feat_crest,
    // 温度和转速作为工况特征
    mavg(temperature, 600)                        as feat_temp,
    mavg(rpm, 600)                                as feat_rpm,
    // 趋势特征：当前 RMS 相对均值的偏离
    (rms - mavg(rms, 600)) \ mstd(rms, 600)       as feat_zscore
from loadTable("dfs://iot_point", "vibration_1hz")
context by deviceId

几个设计要点：

窗口长度要对齐工况周期。设备一个运行周期可能是几分钟，窗口太短抓不到趋势，太长又把早期故障信号平滑掉了。10 分钟是个起点，具体要结合设备类型调。
峰值因子（crest factor）是好特征。它对早期冲击性故障（轴承点蚀、齿轮断齿）特别敏感，且对转速变化相对稳健，是 RUL 建模的常客。
z-score 趋势特征捕捉"当前值偏离自身常态多远"，比绝对幅值更能反映退化趋势。

3.3 频域特征的接入

八期已经讲过怎么用 fft 算频谱、用 imax 定位主频。在 RUL 管线里，频域特征（主频幅值、特定故障频率的能量）可以作为补充特征拼进来。关键是：频域特征要和时域特征对齐到同一个时间戳上，否则标签和特征对不上，模型就学乱了。

对齐用 aj（asof join）：把每秒级时域特征，关联上同一时刻最近的频域特征。

SQL 复制代码

// 把时域特征和频域特征按时间对齐
model_input = select
    f.deviceId, f.ts, f.feat_rms_mean, f.feat_crest, f.feat_zscore,
    s.feat_bpfo_energy, s.feat_peak_freq
from aj(features as f, freq_features as s, `deviceId`ts)

到这一步，每行就是"某台设备某个时刻的一组特征"，可以喂给模型了。但还差一样东西------标签。

四、标签构造的艺术：倒推 RUL（本文核心）

这是预测性维护工程化里最容易被忽略、又最关键的一步。模型要预测"还能用多久"，可历史数据里的每条记录，并没有一个现成的"剩余寿命"字段。标签得我们自己造。

4.1 核心思路：从已知的故障时间点往回倒推

假设我们从历史记录里知道：设备 PUMP-007 在 2026.04.12 03:15:00 发生了一次故障停机。那么这台设备在故障前任意时刻 t 的 RUL，就是：

Plaintext 复制代码

RUL = 故障时刻 - t

把这条规则套到整段历史数据上，每条特征记录就都带上了 RUL 标签。距离故障越近，RUL 越小；正常运行早期，RUL 很大。

用 SQL 实现，关键是先把每台设备的故障时刻找出来，再 join 回特征表做减法：

SQL 复制代码

// 第一步：找出每台设备最近一次故障（或大修）的时刻
// status=FAULT 表示故障停机记录
fault_times = select
    deviceId,
    max(ts) as faultTime
from loadTable("dfs://iot_txn", "alertTicket")
where status = `FAULT
   and ts between 2026.01.01 : 2026.06.30
group by deviceId

// 第二步：把故障时刻 join 回特征表，倒推每条样本的 RUL（单位：小时）
labeled = select
    f.deviceId, f.ts,
    f.feat_rms_mean, f.feat_crest, f.feat_zscore,
    f.feat_bpfo_energy, f.feat_peak_freq, f.feat_rpm,
    (g.faultTime - f.ts) \ 3600000 as rul   // 毫秒转小时
from model_input as f
inner join fault_times as g on f.deviceId = g.deviceId
where f.ts <= g.faultTime      // 只取故障前的样本

到这一步，labeled 表里每一行就是一个带标签的训练样本：特征 + RUL。这就是监督学习的输入。

4.2 一个坑：远端样本的标签噪声

直接用"故障时刻 - 当前时刻"作为 RUL，会带来一个隐蔽的问题：设备刚投运、状态完全健康时，RUL 标签很大（比如几千小时），但这段时间的特征和"健康"几乎没区别。模型在这些远端样本上学不到退化信号，反而会被大量"健康 + 大 RUL"的样本主导，导致对临近故障的样本预测不准。

工程上常用的处理是分段线性标签（piecewise RUL）：给 RUL 设一个上限，超过上限的统统截断。

SQL 复制代码

// 分段线性 RUL：超过 240 小时的截断为 240
// 含义：设备"还很健康"和"还能用 240 小时以上"，对排程决策没有区别
labeled_capped = select
    deviceId, ts,
    feat_rms_mean, feat_crest, feat_zscore,
    feat_bpfo_energy, feat_peak_freq, feat_rpm,
    iif(rul > 240, 240, rul) as rul
from labeled

这一步看似简单，但对模型效果影响很大。截断上限怎么定？通常结合业务：备件采购周期的 1.5~2 倍是个实用参考------再远的 RUL 对排程没决策价值，不如让模型把精力集中在"临失效区间"。

4.3 数据划分：按设备切，不要按时间切

训练 RUL 模型时，一个常见错误是按时间随机划分训练集/验证集。这会导致同一台设备的样本同时出现在训练集和验证集里------模型记住了这台设备的个性，验证指标虚高，换一台没见过的设备就垮。

正确做法是按设备划分：一部分设备全程数据进训练集，另一部分设备全程数据进验证集。这样验证的是"模型对没见过设备的泛化能力"，才是上线后真实面对的场景。

SQL 复制代码

// 取一批设备做训练集，另一批做验证集（按 deviceId 哈希划分）
train = select * from labeled_capped where hashBucket(deviceId, 100) < 70
valid = select * from labeled_capped where hashBucket(deviceId, 100) >= 70

五、库内训练：随机森林回归 RUL

特征和标签都就绪后，训练这一步反而简单。DolphinDB 内置了机器学习函数，不用把数据导出到 Python 训练再导回模型，整个过程在库内闭环。

5.1 训练

用随机森林回归（randomForestRegressor）做 RUL 预测。选它的原因：对特征量纲不敏感、能处理非线性、可解释性比神经网络好、不易过拟合------对工程落地很友好。

SQL 复制代码

// 训练随机森林回归模型
// 输入：训练集特征列 + RUL 标签列
featCols = `feat_rms_mean`feat_crest`feat_zscore`feat_bpfo_energy`feat_peak_freq`feat_rpm

rulModel = randomForestRegressor(
    ds        = sqlDS(<select * from train>),
    yColName  = `rul,
    xColNames = featCols,
    numTrees  = 80,
    maxDepth  = 16
)

几个工程注意点：

numTrees 和 maxDepth 不是越大越好。树太多训练慢、收益递减；太深容易记住训练集噪声。80 棵树、深度 16 是个保守起点，按验证集指标微调。
特征列里不要混入 deviceId、ts 这类标识列。它们不是退化特征，混进去模型会去记设备编号，泛化直接崩。
sqlDS 把训练集包装成数据源，支持分布式训练，数据量大时能并行。

5.2 验证

在验证集上预测，看误差。RUL 这种回归问题，看平均绝对误差（MAE）比看均方误差（MSE）更直观------MAE 的单位就是"小时"，业务能直接理解。

SQL 复制代码

// 在验证集上预测
pred = predict(rulModel, valid)

// 拼回真实标签，算 MAE（平均绝对误差，单位：小时）
valid_pred = select *, pred as rul_pred from valid
mae = select avg(abs(rul - rul_pred)) as mae_hours from valid_pred

比如 MAE 是 18 小时，含义是"模型预测的剩余寿命，平均偏差约 18 小时"。这个数能不能用，取决于业务对预测精度的容忍度------用于排程参考往往够用，用于精确到小时的停机决策则还需要继续调特征和标签。

六、推理打分：批量 + 流式

训练完的模型，要能同时服务两类需求：离线回溯 （给历史数据批量打分，分析退化曲线）和实时预警（新数据一进来就给当前 RUL）。

6.1 批量打分

对任意一段时间的历史特征批量预测，画出每台设备的 RUL 退化曲线，用于复盘和模型调优：

SQL 复制代码

// 给 2026 年 3 月的特征批量打 RUL 分
scores = select
    deviceId, ts, rul_pred,
    // 按预测 RUL 分档：< 48h 高危，< 120h 关注，其余正常
    iif(rul_pred < 48, `HIGH,
        iif(rul_pred < 120, `WATCH, `OK)) as risk_level
from (
    select *, predict(rulModel, model_input) as rul_pred
    from model_input
    where ts between 2026.03.01 : 2026.03.31
)
order by deviceId, ts

按设备画 rul_pred 随时间的曲线，理想情况下应该看到一条从高位平滑下降、临近故障趋近于 0 的轨迹。如果曲线剧烈抖动，说明特征里还有噪声，回到第三节调窗口和特征。

6.2 流式打分

实时场景下，新特征一算出来就要立刻得到 RUL。把训练好的模型挂到流计算引擎上即可------离线训练用的特征管道，和实时推理用的特征管道是同一套，这是管线闭环的核心价值。

SQL 复制代码

// 实时特征流（由前面的滚动窗口引擎产出，每秒一条）
share streamTable(1:0,
    `deviceId`ts`feat_rms_mean`feat_crest`feat_zscore`feat_bpfo_energy`feat_peak_freq`feat_rpm,
    [SYMBOL, DATETIME, DOUBLE, DOUBLE, DOUBLE, DOUBLE, DOUBLE, DOUBLE]
) as featureStream

// 输出流：实时 RUL 预测
rulOut = table(1:0, `deviceId`ts`rul_pred`risk_level,
               [SYMBOL, DATETIME, DOUBLE, SYMBOL])

// 响应式状态引擎：进一条特征，出一条 RUL 预测
rulEngine = createReactiveStateEngine(
    name        = "rulPredict",
    metrics     = <[
        predict(rulModel, feat_rms_mean, feat_crest, feat_zscore,
                feat_bpfo_energy, feat_peak_freq, feat_rpm) as rul_pred,
        iif(predict(rulModel, feat_rms_mean, feat_crest, feat_zscore,
                    feat_bpfo_energy, feat_peak_freq, feat_rpm) < 48,
            `HIGH, `WATCH) as risk_level
    ]>,
    dummyTable  = featureStream,
    outputTable = rulOut,
    keyColumn   = "deviceId"
)

// 订阅实时特征流
subscribeTable(tableName=`featureStream, actionName="rul",
               handler=tableInsert{rulEngine}, msgAsTable=true)

这样，实时特征一流入 featureStream，引擎就立刻输出当前 RUL 预测和风险等级。下游可以把 HIGH 级别的设备推送给排程系统，触发备件预占和维修窗口预约。

整条管线的价值就在这里 ：训练时算特征的那套 context by + mavg/mstd 逻辑，推理时原封不动地挂在流引擎上跑。没有"离线 Python 特征 + 在线 Java 特征"两套要对齐的代码，特征定义只有一处，不会漂移。

七、写在最后

预测性维护是工业 IoT 里被谈得很多、做出来却很少的场景。原因不在算法多难，而在管线：特征怎么滚动算、标签从哪来、模型怎么从离线搬到实时。这三件事每一件单独看都不复杂，但要在跨系统的架构里保持一致，工程量就会失控。

用 DolphinDB 做这件事的价值，不是"它有个多强的机器学习模型"------随机森林回归是很朴素的算法。价值在于整条管线在一个平台里闭环：

特征用 context by 滚动算，增量更新
标签用 SQL 倒推，分段截断去噪
模型库内训练，数据不出库
推理把训练时的特征管道直接挂到流引擎，离线在线同源

回过头看状态维修的三层：诊断看当下、评估看群体、预测看未来。前两层解决"现在怎么办"，预测这一层才真正回答"接下来怎么办"------而"接下来怎么办"，恰恰是运维从成本中心转向价值中心的关键一步。

落到工程上记住一点：RUL 模型的天花板，由标签质量决定，不由算法决定。把标签构造（倒推 + 截断 + 按设备划分）做扎实，朴素的模型也能给出可排程的预测；标签错了，再复杂的模型也只是过拟合训练集。