机床一旦停机，车间里的损失是按分钟算的。我在现场见过一次主轴报警，操作工围着设备干着急，维修师傅赶过来，排查完已经过去三个小时，当班产量直接砍掉三成。数控领域故障诊断专家系统，要解决的就是这类"靠人、靠经验、靠运气"的诊断难题。它把维修专家脑子里的判断逻辑沉淀成知识库，再把传感器数据、历史故障记录、设备运行状态全部整合进来，最终输出的是故障原因排序、维修建议和检查步骤。这篇文章基于我参与过的一套面向数控磨床的故障诊断系统，把融合多种技术时的整体设计、核心实现和实际踩过的坑拆开讲。

1. 数控机床故障诊断，为什么非要"专家系统"不可

1.1 车间现场的诊断困境

数控机床的故障类型，比很多人想象的要杂。机械侧有轴承磨损、丝杠间隙、导轨爬行，电气侧有伺服报警、I/O信号丢失、电源波动，液压侧有油温过高、压力不稳，还有CNC系统本身参数被改错、电池掉电导致程序丢失。同一个"主轴异响"的现象，可能是轴承缺油，可能是电机转子不平衡，可能是联轴器不对中，也可能是刀具夹持松动。修起来往往就是换个轴承的事，可找到这个轴承、锁定是这个原因，偏偏要花掉大半天。

维修经验全在大脑里，知识不沉淀，老师傅带新人全靠手把手。车间也积累了不少故障记录，但多数是"哪台设备、报了什么警、换了什么件"这种流水账。真正关键的判断过程——当时为什么怀疑这个原因、怎么排除的干扰项——很少被记下来。这种状态持续久了，问题会越积越重：同类故障反复排查、同批备件反复误换、新维修工三年才能独当一面。

而这些恰恰是专家系统的用武之地。它把诊断经验从人脑转移到知识库，让诊断逻辑可以被复用、被审计、被持续修正。不是要替代老师傅，而是把老师傅的判断能力放大到每一台设备、每一个班次。

1.2 专家系统的定位：辅助诊断，不是替代人

很多人在启动这类项目时，对专家系统的预期是"输入故障现象，输出唯一答案"。这个定位从一开始就不对。真实的车间诊断是一个不断缩小怀疑范围的过程，现场人员要的是参考，不是判决书。

我理解的系统定位应该有这么几条：

• 输入：报警代码、传感器信号特征、操作者描述的现象。
• 输出：按置信度排序的故障原因列表，每个原因附上排查建议和检查步骤。
• 底线：宁可多给几条检查项，也不能漏掉会造成二次损伤的严重故障。
• 责任边界：系统给的是建议，最终决策和操作责任在维修人员。

这个定位直接决定了后面的技术选型。比如为什么知识表示一定要可解释，为什么不能只丢一个黑盒模型，为什么输出要做置信度排序而不是单一结论——都是因为系统要辅助人做高风险决策，人必须能理解它为什么给出这个结论。

2. 融合技术怎么选：知识、数据与算法的分工

2.1 技术选型思路：各管一段，不是堆模型

"融合多种技术"最容易被理解成把一堆算法堆在一起，哪个发热用哪个。实际做下来，正确的思路是让每种技术解决它最擅长的那一段问题，各管一段，接口清晰。

我对整个系统的分工是这样划分的：

规则负责"确定性的因果"，模型负责"数据里的规律"，案例负责"经验复用"，图谱负责"关系联想"。四个模块各自输出中间结果，最后统一汇入推理引擎做综合判定。

如果一上来就追求大而全的融合，项目大概率会死在数据标注和知识整理上。更合理的路径是先跑通规则引擎，再逐步接数据层和模型层。

2.2 知识层：规则库、案例库与知识图谱的配合

知识层是整个系统的地基，也是最花时间的地方。

规则库我建议用产生式规则，就是最朴素的 IF-THEN 结构。比如主轴轴承故障，可以写成：

IF 主轴轴承座振动有效值 > 4.5 mm/s AND 频谱中轴承外圈故障特征频率处幅值突出 AND 该特征频率随转速线性变化 THEN 故障原因 = 主轴前轴承外圈点蚀 CONFIDENCE = 0.85 RECOMMEND = 停机检查，查看轴承润滑脂是否劣化，计划更换轴承

规则的好处是任何维修工都能看懂、能提出修改意见。它的坏处是维护成本会随着条数增加而上升，规则之间可能冲突，所以后面必须配版本管理。

案例库做的是案例推理（CBR），属性包括设备型号、故障现象文本、报警码、停机时长、维修结果。遇到新故障时，按属性相似度检索历史案例。数值属性用欧氏距离，文本属性用词向量加余弦相似度。匹配度超过0.8，直接给出历史维修方案；0.6到0.8，给出参考并建议再用规则或模型验证一遍。

知识图谱补的是关联检索能力，把设备组件、故障模式、故障原因、征兆、维修动作建模成三元组：

(主轴轴承, caused_by, 润滑不良) (主轴轴承, has_symptom, 高频振动异响) (主轴轴承, repaired_by, 更换轴承并检查润滑系统)

图谱的价值在于多跳推理。比如系统发现主轴轴承振动异常，图谱里关联出润滑不良、保持架磨损、轴承游隙过大几个原因，还能继续关联出"润滑不良"上游的"油泵压力低"和"油路堵塞"，把诊断视野从单点拓宽到链路。

2.3 数据层：传感器选型与特征工程

规则和人脑能处理的，都是已经暴露出来的故障。很多故障在报警之前就有苗头，比如轴承早期磨损的振动能量会逐步爬升，这时候就需要数据层介入。

传感布置上，主轴前后轴承座是必测点，用 IEPE 加速度传感器，频响1Hz到10kHz，灵敏度100mV/g。电机电流、温度测点视设备结构补充。数据采集器要支持多通道同步采样，我用的是采样率25.6kHz、每5分钟采一段2秒数据的方式。采样率太高数据量扛不住，太低又会丢掉高频故障特征，25.6kHz对于分析到10kHz足够了。

原始信号不能直接喂给模型，必须做特征提取。我常用的特征分四组：

• 时域统计：均值、有效值、峰值、峰峰值、峭度、波形因子。
• 频域特征：1倍频到4倍频幅值占比、轴承特征频率（外圈、内圈、滚动体）幅值、高频段能量占比。
• 电流特征：三相电流有效值、峰值、谐波畸变率。
• 温度特征：轴承座温度、绕组温度、冷却液温度与环境温度差值。

举一个实际的例子。一台正常的主轴，振动有效值在1.2mm/s左右，峭度在3.1附近。轴承早期磨损时，有效值会爬到2.8mm/s，峭度升到4.6，同时高频段能量占比从正常时的不到10%抬升到20%以上。这些数字变化在原始波形里肉眼不容易看出来，但量化成特征之后，规则和模型都能明确感知。

2.4 算法层：机器学习与推理引擎的衔接

机器学习在这套系统里扮演的角色是"新故障探测器"。规则库能覆盖的，是已经被理解和整理的故障模式。但数控机床的故障演化是动态的，总会遇到规则库里没有的情况，这时候就要靠模型从数据里发现线索。

我在实际项目里的选型经验是：

• 故障分类首选随机森林，采样500棵树、树深度限制在10以内。它对特征尺度不敏感，不容易过拟合，还能输出每个特征的重要性，方便后期排查。
• 需要给出概率化解释时，用贝叶斯网络。它能把故障原因和征兆之间的依赖关系显式表达出来，置信度计算自然，适合做规则库的补充。
• 时序趋势预测用LSTM，但只有在积累了足够长的正常运行数据之后才建议上。样本太少时，LSTM只会给你一个看起来很准的错误预测。

模型输出和规则输出不是并列的。我的做法是两层结构：模型先给出"疑似故障类型和概率"，专家系统再用规则去验证这些候选故障是否满足特定场景下的前提条件。模型说可能是轴承故障，规则检查频谱特征、温度特征、转速工况这些前提，满足了才把置信度往上调。这个衔接逻辑让系统既保留了模型的敏感性，又保留了规则的可解释性。

3. 核心实现拆解：知识表示、推理机与置信度

3.1 知识表示：产生式规则怎么写才不"翻车"

产生式规则看似简单，写的时候有很多细节。

第一，规则前提必须是可判定的。像"主轴振动较大"这种描述，不同人对"较大"的理解不一样，必须量化。写成"主轴轴承座振动有效值 > 4.5mm/s"，任何人、任何时间执行都是同一个标准。

第二，每条规则必须区分故障类型和故障原因。故障类型是"振动异常"，故障原因是"轴承磨损"，前提特征是支撑两者之间因果链条的证据。我在规则结构里除了 IF、THEN 之外，还加了 CONFIDENCE 和 RECOMMEND 两个字段。CONFIDENCE 是这条规则本身的可信度，RECOMMEND 是给维修人员的具体建议。这两个字段在后期维护时会被高频修改，建议一开始就作为独立字段存在，别硬编码在推理逻辑里。

第三，规则必须带工况约束。同一台机床，精磨和重切削时的振动水平完全不同。不加工况约束的规则，很容易把正常加工误判成故障。我这边给规则统一加了"当前加工阶段"这个前提字段，比如砂轮修整阶段的振动信号不参与故障诊断。

规则库的结构建议做成这样：

故障现象（主键） → 故障类型 → 故障原因 → 检查步骤 → 维修动作

节点之间用置信度连接，原因节点可以有多个，每个原因带自己的置信度和建议动作。

3.2 推理机设计：正向、反向与混合推理

推理机是执行规则的地方。三种推理方式，我分别说它们的适用场景。

正向推理从已知征兆出发，不断匹配规则前提，直到得到结论。适合故障现象明确、信息比较多的情况。比如已经拿到振动频谱特征和温度数据，正向推理能快速收敛到几个候选原因。

反向推理先假设某个故障原因存在，再反查支撑这个原因的证据是否满足。适合做验证，"既然怀疑轴承磨损，那就去检查频谱里有没有外圈特征频率"。反向推理还有个好处，能指导维修人员按顺序采集证据，避免盲目检查。

实际项目里单独用哪一种都容易出问题。纯正向推理在有多个征兆时，激活的规则会非常多，推理路径发散，输出一堆无关结论。纯反向推理如果假设目标设错了，会漏掉真正的故障。我最后用的是混合策略：正向推理生成候选原因列表，反向推理逐一对候选原因做证据验证，验证不过的就降权或剔除。

推理顺序上还要做冲突消解。多条规则同时被触发、结论互斥时，优先选择置信度高的，再选前提被更多证据支持的，最后选维修成本低的。置信度相同的情况下，把成本低、容易验证的检查项排在前面，现场师傅对这个排序逻辑非常认可。

3.3 不确定性处理：置信度怎么算、阈值怎么定

诊断过程充满不确定性：传感器信号有噪声，专家描述有模糊成分，同一个现象背后有多种可能。这块我用的是可信度因子（CF）体系。

每条规则有自己的 CF，前提证据也有一个确认度，综合可信度是两个值的乘积。比如：

• 规则A：主轴温升过高且振动持续上升 → 轴承润滑不良，CF=0.8。
• 当前证据确认度是0.7，那么这条规则对"轴承润滑不良"的支持度就是0.8×0.7=0.56。

如果多个独立规则指向同一个结论，需要做信任合成。我用的是经典的MYCIN合成公式，写成代码是这样的：

def combine_cf(cf1, cf2): if cf1 >= 0 and cf2 >= 0: return cf1 + cf2 * (1 - cf1) if cf1 <= 0 and cf2 <= 0: return cf1 + cf2 * (1 + cf1) return (cf1 + cf2) / (1 - min(abs(cf1), abs(cf2)))

举个例子。规则A和规则B分别计算出对"轴承润滑不良"的支持度0.56和0.56，合成后的可信度是0.56+0.56×0.44=0.8064。

阈值上我有几个经验值：

• 综合置信度大于0.7，作为推荐结论输出，附完整的检查步骤。
• 0.4到0.7，作为疑似结论输出，提示"建议优先排查"。
• 小于0.4，只作为线索保留，不进结论列表。

宁可系统多给几条疑似项，也不能漏掉真正的故障原因。误报顶多是维修师傅多看一眼，漏报可能导致损伤扩大，两者代价完全不对等。

4. 落地实录：一套数控磨床诊断系统的诞生

4.1 知识获取：怎么和老师傅聊出规则

知识获取是这套系统里最耗时、也最体现功力的环节。直接问"您诊断故障的规则是什么"，老师傅很难回答。真正有效的方法是场景化提问。

我先准备一份故障现象清单，然后逐个现象问三个固定问题："遇到这个现象你的第一反应是检查哪里？""什么情况下你会排除掉这个原因？""你过去处理这个故障，最后确认的根因是什么？"

比如问主轴异响，老师傅回答"先听声音、再摸温度、最后看振动数据"。这句话不能直接变成规则，要加工成结构化描述：

IF 异响报告成立 AND 轴承座温度 > 60℃ AND 振动高频段能量占比 > 20% THEN 优先检查主轴轴承润滑情况

再一个来源是维修记录。老师傅手里有大量记录，但写得很简略。有一台设备故障记录只写了"更换主轴轴承"，具体判断依据完全没有。我就追问当时怎么确定的，才得到"声音是金属摩擦声、频率很高、振动值逐日递增"这些关键信息。这些细节才是规则库真正的原料。

这阶段的教训是：访谈要录下来，当天整理。拖延一天，细节就会损失一半。访谈对象至少要覆盖两位维修经验不同的师傅，把他们的判断依据交叉比对，取交集才能进规则库。

4.2 数据采集与特征计算

数据层部署在主轴前轴承座和后轴承座各装一个振动传感器，磁座安装，不动设备的原结构。主轴电机电流信号从驱动器的输出端取，温度信号从机床原有的温度传感器读。

采集参数如下：

特征计算直接用离线脚本处理。时域特征用滑动窗口计算，频域特征用FFT加窗函数防止频谱泄漏。每台设备每个采样周期生成一组24维的特征向量，写入时序数据库。

从正常状态到故障状态的过程，在特征上是有迹可循的。那台磨床的主轴从正常到轴承磨损，振动有效值从1.2mm/s涨到2.8mm/s，峭度从3.1涨到4.6，这个过程持续了大约两周，正好给预测性维护留出了窗口。

这部分最大的坑是传感器的一致性问题。两台同型号磨床，传感器安装方式不同（一个磁座、一个胶粘），频谱特征会有差异。需要在系统里给每台设备做特征基线校准，否则训练好的模型换一台设备就失效。

4.3 融合模型训练与规则修正

模型训练的数据来自三个渠道：历史维修记录整理出的带标签样本、实验室模拟故障注入的数据、正常运行的负样本。一共凑了480条样本，但类别不平衡，正常样本占了七成。对于少数类，用SMOTE做人工过采样。随机森林用500棵树、深度限制10层，10折交叉验证的F1值在0.85左右。

训练完模型，真正的工作才刚刚开始。把模型跑在历史数据上，逐条看误报案例，对比误报中出现的特征与规则前提的差异。这是模型与规则互相修正的过程。

当时有个典型的案例：模型把"砂轮修整时的振动"误判为轴承故障。修整时高频能量大，特征和轴承磨损确实很像。后来处理办法，一是增加工况特征"正在进行砂轮修整"作为输入，二是新加一条屏蔽规则：IF 当前动作=砂轮修整 THEN 暂停振动诊断。这个双保险效果很好，误报率立刻降下来了。

新规则上线不直接替代旧规则，我让新规则先跑"影子模式"，和旧规则并行记录命中结果。统计一段时间，新规则准确率超过旧规则再正式切换。这套机制避免了规则维护过程中常见的"越改越乱"。

4.4 现场验证与迭代

系统上线后的验证分成两步。第一步用历史故障记录盲测，拿来最近半年的20条真实故障记录，系统输出的前3个候选原因覆盖了其中18条，覆盖率达到90%。第二步做现场试运行，跟踪3个月，系统给出36次诊断建议，维修师傅认可31次。5次误报集中在砂轮主轴与工件主轴模型混用的问题上。后来把两个主轴的模型分开训练、分开部署，误报问题基本消失。

迭代机制比初始准确率更重要。我在诊断结果页面加了一个"此建议是否有效"的一键反馈按钮。维修师傅处理完故障后顺手点一下，系统就多一条标注样本。三个月下来，有效反馈率超过70%，数量远超初期人工标注的数据量。反馈数据再定期汇入训练集，模型的准确率是越用越高的。

5. 常见问题与排查技巧速查

5.1 高置信度误报

现象是模型给出"主轴轴承严重磨损，CF=0.86"，但拆机检查轴承完全正常。排查后发现这台设备切削液泵故障，管路振动传导到了主轴座上，特征和轴承故障高度相似。这提醒我，特征识别不能只用单一敏感特征，一定要加区分性特征和配套条件。后来在规则里加了前提"切削液泵电流正常"，再没出过同类误报。

5.2 规则库越维护越乱

规则数量超过两百条后，重复、冲突、过时的规则开始变多。我的解决方案是给每条规则加五个管理字段：来源设备型号、录入人、录入时间、启用状态、最后验证日期。每次修改规则都走版本记录，启用新规则前先跑影子模式。这比单纯靠流程约束有效得多，因为它把规则审计落实到了数据层面。

5.3 模型漂移与样本分布变化

车间设备不是一直不变的，几年后会改造、会换型。旧设备上训练的模型，在新型号上准确率必然下降。我的处理是定期按设备型号分组评估模型表现，一旦发现某台设备的准确率明显低于其他设备，就把这台设备的数据独立出来重新训练或微调。一个很实际的指标是，平均每三个月轻量评估一次，半年做一次全量评估。

5.4 什么时候别硬上"融合"

不是所有场景都适合全套融合技术。故障样本不足50条、设备还在保修期内由厂家负责维护、车间没有基础的数字化记录体系，这些情况下直接上大数据模型大概率是失败。可以先做一个轻量级的规则查询工具，把报警代码、故障现象和对应的维修手册检索做通，这本身已经能提升现场效率。等数据积累到一定程度，再逐步加模型、加图谱。

我在实际项目里最深的体会是：这类系统最后拼的不是算法多先进，而是知识能不能被持续沉淀和验证。数控故障诊断专家系统最难的部分从来不是写代码，而是知识从人脑转移到规则库的过程，以及转移完之后被现场不断修正的机制。别一上来就追求融合技术有多新，先把规则写准、把反馈闭环打通，系统的价值自然会被老师傅认可。

如果你也在做类似的东西，我的建议是从一台设备、三类典型故障、五十条规则起步，跑通之后再逐步加数据、加模型、加图谱。每次增加一个模块，都先用历史数据验证它确实带来了增量收益，而不是让系统变得越来越花哨、越来越难维护。这个方向后续可以跟设备的健康度评估、备件预测更紧密地联动起来，但每一步都得踩实了再往前走。