第四章：数据采集模块——诊断数据源接入与处理
好，咱们进入数据采集模块。这一章，我打算聊聊诊断数据怎么来、怎么洗、怎么存。
说实话，很多团队在搭建诊断工具链时，最容易忽略的就是数据采集层。大家总觉得「不就是读个CAN报文嘛」，结果项目一跑起来，数据乱得像一锅粥。
我个人习惯把数据采集拆成三个环节：接入、解析、存储。咱们一个一个说。
4.1 诊断数据源接入：CAN/LIN/以太网
诊断数据从哪来？目前主流就三种：CAN、LIN、车载以太网（DoIP）。
CAN总线，最常用。UDS诊断报文走的是CAN ID，比如物理寻址用0x7DF，功能寻址用0x7E0。我记得刚入行时，有个项目死活连不上ECU，查了半天发现是CAN终端电阻没焊——嗯，这种低级错误我犯过一次就记住了。
LIN总线，成本低，速度慢，常用于车窗、座椅这类节点。诊断走LIN的话，主节点负责调度，从节点响应。说实话，LIN诊断现在用得少了，但老车型上还有。
车载以太网（DoIP），这是趋势。100BASE-T1或者1000BASE-T1，走TCP/IP协议栈。诊断端口默认13400。我建议新项目直接上DoIP，带宽够，调试也方便。
接入方式对比
| 总线类型 | 物理层 | 典型速率 | 诊断协议 | 我推荐场景 |
|---|---|---|---|---|
| CAN | 双绞线差分 | 500kbps | UDS on CAN | 动力域、底盘域 |
| LIN | 单线12V | 20kbps | LIN诊断 | 车身低速节点 |
| 以太网 | 单对差分 | 100Mbps+ | DoIP | 域控、OTA、大数据量 |
接入硬件方面，我常用的是Vector VN1640或者PCAN-USB。开源方案也有，比如用SocketCAN + USB2CAN，但稳定性嘛……你懂的，做产品还是建议用商业硬件。
4.2 数据解析与清洗
原始报文拿到手，不能直接用。为什么？因为CAN报文里可能混着错误帧、重复帧、甚至乱序帧。
解析流程，我一般分三步：
- 帧过滤：只保留诊断相关的CAN ID。比如UDS物理请求ID是0x7E0，响应ID是0x7E8，其他的一律扔掉。
- 协议拆包：CAN报文一次最多传8字节。如果诊断数据超过8字节，就得用ISO-TP协议做多帧传输。这里要注意，有些ECU的连续帧间隔时间不标准，我曾经遇到过某供应商的ECU，连续帧间隔只有5ms，差点把我们的接收缓冲区撑爆。
- 数据提取：从CAN数据场里提取出SID、DID、DTC、子功能等字段。说白了，就是把二进制流翻译成人能看懂的东西。
避坑指南：我曾经在解析一个OEM的私有诊断协议时，发现对方把DID的高字节和低字节反着放。查了三天，最后发现是文档写错了。所以，拿到任何诊断规范，先拿一个已知的请求/响应做验证，别盲目相信文档。
数据清洗，我习惯做这几件事：
- 去重：同一时刻收到的重复报文，只保留一条。
- 时间戳对齐：不同总线的时间戳可能来自不同时钟源，需要统一换算到系统时间。
- 异常值剔除：比如CAN报文里出现全0或全F的数据场，大概率是总线错误，直接丢弃。
代码示例（Python伪代码，实际项目建议用C++或Rust）：
def parse_can_diagnostic(frame):
if frame.arbitration_id not in [0x7E0, 0x7E8]:
return None # 非诊断帧，丢弃
if frame.data[0] == 0x00 and frame.data[1] == 0x00:
return None # 异常帧，丢弃
# 提取UDS服务ID
sid = frame.data[0] & 0x3F
# 提取DID（假设是2字节）
did = (frame.data[1] << 8) | frame.data[2]
return {"sid": sid, "did": did, "timestamp": frame.timestamp}4.3 数据存储策略
数据解析完了，存哪里？这是个好问题。
我见过有人把所有诊断报文直接写进文本文件，结果一天下来文件几十个GB，查个历史数据要翻半天。也见过有人用MySQL存时序数据，查询慢得让人崩溃。
我的建议：
- 实时数据：用内存数据库，比如Redis。只保留最近1小时的数据，用于实时监控和仪表盘展示。
- 历史数据：用时序数据库，比如InfluxDB或TimescaleDB。按时间分区存储，压缩率高，查询快。
- 诊断事件：比如DTC触发、会话切换、安全访问失败等，存到关系型数据库（SQLite或PostgreSQL），方便做统计和报表。
注意：千万不要把所有原始报文一股脑全存下来。你想想看，一条CAN报文才8字节，但加上时间戳、总线ID、帧类型等元数据，一条记录可能膨胀到50字节以上。一天几百万条报文，存储成本会失控。我建议只存解析后的关键字段，原始报文如果非要保留，可以压缩后归档到冷存储。
存储策略的决策树，我一般这么走：
| 数据类型 | 存储引擎 | 保留周期 | 用途 |
|---|---|---|---|
| 实时诊断流 | Redis Stream | 1小时 | 实时监控、告警 |
| 历史时序数据 | InfluxDB | 30天 | 趋势分析、回放 |
| 诊断事件/日志 | PostgreSQL | 永久 | 问题追溯、合规审计 |
| 原始报文（可选） | Parquet文件 | 7天 | 深度调试、复现 |
嗯，这里要注意：存储策略不是一成不变的。我有个项目，客户要求所有诊断数据保留3年，结果我们不得不上了Hadoop集群。但说实话，99%的场景用不到那么久。先按30天设计，后续再扩展，这是比较务实的做法。
好了，数据采集模块的核心就这些。下一章咱们聊诊断流程的编排与自动化执行——那才是真正让工具链「自动化」的关键。