架构设计：产线故障智能诊断系统

摘要：本文围绕制造业产线老化测试场景，设计了一套从数据采集到智能决策的故障诊断系统方案。采用分层架构，以规则引擎快速起步、机器学习持续提升、数据闭环不断进化为核心思路，覆盖系统架构、技术选型与分阶段实施路径。

背景

产线老化测试环节每天产生大量测试 Log、维修记录和复测记录，目前对故障的判定高度依赖人工经验。希望构建一套智能诊断系统，能根据测试 Log 自动给出"复测"或"刷维修"的建议，降低对人工经验的依赖，提升产线效率与一致性。

整体思路是：用规则引擎快速起步，用机器学习持续提升，用数据闭环不断进化。先让产线用起来，再逐步变聪明。

系统整体架构

建议采用分层架构，从下到上分为五层：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


┌─────────────────────────────────────────────────┐
│              前端展示层（产线操作员界面）             │
├─────────────────────────────────────────────────┤
│              后端服务层（API + 业务逻辑）            │
├─────────────────────────────────────────────────┤
│              智能分析引擎层（核心决策）              │
├─────────────────────────────────────────────────┤
│              数据存储与处理层                       │
├─────────────────────────────────────────────────┤
│              数据采集与接入层                       │
└─────────────────────────────────────────────────┘

各层详细设计与技术选型

1. 数据采集与接入层

这一层负责从产线各系统获取原始数据，是整个系统的基础。

需要采集的数据源：

老化测试上抛 Log：测试程序产出的原始日志文件（包含测试项、错误码、错误描述、时间戳等）
维修记录：维修工站的操作记录（维修动作、更换部件、维修结果、维修人员等）
复测记录：复测的通过/失败结果、复测次数
设备配置信息：机型、BIOS 版本、固件版本、硬件 BOM 等
产线环境数据（可选）：温度、湿度、老化架位置等

技术方案：

通过消息队列（如 RabbitMQ / Kafka）对接测试系统，实时接收上抛 Log
通过数据库同步（如 Canal / Debezium）或 API 对接 MES 系统，获取维修记录和复测记录
对于历史存量数据，通过批量导入工具一次性灌入

2. 数据存储与处理层

数据库选型：

数据类型	推荐数据库	说明
结构化业务数据（工单、设备信息、维修记录）	PostgreSQL / MySQL	主数据库，存储核心业务数据
测试 Log 原文及全文检索	Elasticsearch	支持 Log 的全文搜索、关键词匹配、相似度检索
特征化后的 Log 数据	ClickHouse / PostgreSQL	存储经过解析、结构化后的 Log 特征字段，用于统计分析
缓存与实时状态	Redis	缓存热点查询结果、设备实时状态

数据处理流程：

Log 解析：将非结构化的测试 Log 解析为结构化字段（错误码、失败测试项、错误关键词等）
特征提取：从 Log 中提取关键特征（如失败模块、错误类型、错误频次等）
数据关联：将同一台设备的测试 Log、复测记录、维修记录通过设备序列号（SN）关联起来，形成完整的"故障-处置"链路

3. 智能分析引擎层（核心）

这是系统的"大脑"，建议采用规则引擎 + 机器学习模型双轨并行的策略。

第一阶段：基于规则引擎（快速上线）

先基于资深工程师的经验，建立判定规则库。规则示例：

1
2
3
4
5
6
7
8
9


IF 错误码 = "BATTERY_COMM_FAIL" AND 复测次数 < 2
   → 建议：复测（电池通信偶发失败，复测通过率 85%）

IF 错误码 = "GPU_ARTIFACT_DETECTED" AND 出现次数 >= 2
   → 建议：刷维修（GPU花屏，硬件故障概率 95%）

IF 错误码 IN ["WIFI_TIMEOUT", "BT_PAIRING_FAIL"]
   AND 固件版本 < "V2.3.1"
   → 建议：刷维修（已知固件Bug，需升级固件）

规则引擎推荐：Drools（Java 生态）或自研轻量规则引擎
规则以配置化方式管理，工程师可在后台新增、修改、启停规则，无需改代码

第二阶段：引入机器学习模型（持续优化）

在积累了足够的"Log → 处置动作 → 最终结果"数据后，训练分类模型：

输入特征：错误码、失败测试项、错误关键词、机型、固件版本、历史故障次数、老化时长等
输出：建议动作（复测 / 刷维修）+ 置信度
推荐算法：XGBoost / LightGBM（表格数据效果好、可解释性强）
模型服务：通过 ONNX Runtime 或 TorchServe 部署为 API

第三阶段（进阶）：引入大语言模型辅助分析

对于规则覆盖不到的长尾 case，可以接入 LLM（如私有化部署的开源大模型），结合 RAG（检索增强生成）技术，从历史维修案例库中检索相似 case，生成诊断建议。

4. 后端服务层

推荐技术栈：

语言/框架：Java（Spring Boot）或 Python（FastAPI），取决于团队技术栈

职责：

提供 RESTful API 供前端调用
接收测试系统上报的 Log，触发分析引擎
管理规则库、模型版本
记录每次判定结果及人工反馈（用于模型持续优化）
权限管理（操作员、工程师、管理员不同权限）

核心 API 设计示例：

1

POST /api/v1/diagnose

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


// 请求
{
  "sn": "设备序列号",
  "log_content": "原始log内容",
  "test_stage": "aging"
}

// 响应
{
  "suggestion": "RETEST",
  "confidence": 0.87,
  "reason": "电池通信偶发失败，历史同类case复测通过率85%",
  "similar_cases": [],
  "rule_matched": "RULE_003"
}

5. 前端展示层

推荐技术栈：

框架：Vue 3 + Element Plus 或 React + Ant Design
部署形态：Web 应用，产线工位通过浏览器或工控机访问

核心功能页面：

诊断查询页：扫码/输入 SN → 自动拉取最新 Log → 展示诊断建议（复测 or 刷维修）
历史记录页：按 SN、时间、故障类型查询历史诊断记录
规则管理页（工程师用）：新增/编辑/启停判定规则
统计看板：故障类型分布、复测通过率、模型准确率趋势、各机型良率等
反馈页：操作员可标记"建议是否正确"，形成闭环数据

实施路径建议

建议分三期推进，控制风险。

第一期：数据打通 + 规则引擎（1~2 个月）

打通测试系统 Log 上报通道，接入数据库
整理历史维修记录，与 Log 做关联分析
与资深工程师一起梳理高频故障场景，编写判定规则（先覆盖 70%~80% 的常见 case）
开发基础的前端查询页面

目标：产线操作员可通过系统查询，系统给出规则建议，但人工仍做最终确认。

第二期：模型训练 + 闭环优化（2~3 个月）

积累第一期运行数据（系统建议 vs 人工最终决策）
训练分类模型，与规则引擎结果做加权融合
增加反馈机制，持续优化规则和模型

目标：系统建议准确率达到 90% 以上，逐步减少人工复判。

第三期：智能化升级（持续迭代）

引入 LLM + RAG 处理长尾 case
对接产线自动化设备，实现建议自动执行（如自动触发复测流程）
构建知识图谱，实现故障根因分析

目标：减少人工干预，提升产线效率。

关键注意事项

数据质量是生命线：Log 格式要标准化，维修记录要结构化录入，垃圾数据进垃圾数据出。
先规则后模型：不要一上来就搞 AI，先把规则引擎跑通，让产线先用起来，积累数据后再上模型。
保留人工兜底：系统给出建议 + 置信度，低置信度的 case 仍交给人工判断，避免误判造成损失。
可解释性很重要：每条建议必须附带理由（命中了哪条规则、参考了哪些历史 case），产线人员才能信任系统。
与现有系统集成：需要考虑与 MES、测试程序、维修工站的对接方式，尽量减少产线操作人员的额外操作。

技术栈总结

层级	推荐技术
前端	Vue 3 / React + Element Plus / Ant Design
后端	Spring Boot (Java) 或 FastAPI (Python)
关系数据库	PostgreSQL / MySQL
搜索引擎	Elasticsearch
缓存	Redis
消息队列	RabbitMQ / Kafka
规则引擎	Drools / 自研轻量引擎
机器学习	XGBoost / LightGBM + scikit-learn
模型服务	ONNX Runtime / FastAPI 封装
大模型（进阶）	私有化部署开源 LLM + RAG（LangChain）

下一步计划

与产线工程师对齐高频故障场景，输出首版规则清单
搭建数据采集通道，完成 Log 与维修记录的 SN 关联
搭建最小可用前端，跑通"扫码 → 诊断 → 建议"主流程
建立反馈闭环，为后续模型训练积累标注数据

文章目录

背景