车载Linux 系统问题定位方法论与实战系列 - 车载 Linux 平台问题定位规范

车载 Linux 平台问题定位规范

本规范用于指导车载 Linux 平台在开发、集成、量产、路测与售后 阶段，对系统异常进行可复用、可证据化、可还原的问题定位。

目标不是"快速猜问题"，而是在不可复现条件下仍能还原系统真实状态。

1. 适用范围与设计目标

1.1 适用范围

车载域控制器 / 区域控制器（DCU / ZCU）
基于 Linux 的 IVI / ADAS / 车身域平台
使用 systemd 的量产系统
支持以太网（SOME/IP / DDS / UDP/TCP）通信架构

1.2 设计目标

问题可还原：即使问题无法复现
证据可关联：跨内核 / 系统 / 中间件
成本可控：不显著影响实时性与性能
流程可复制：新项目可直接落地

2. 问题定位的基本原则（Methodology）

2.1 四个核心问题

任何系统问题定位，必须回答以下四个问题：

发生了什么（现象）
什么时候发生（时间线）
谁导致的（责任层级）
为什么会发生（根因机制）

工具只是手段，时间线才是核心。

3. 分层问题定位模型（工程视角）

复制代码

┌──────────────────────────────┐
│ 应用 / 功能服务层            │  ADAS / IVI / Control Apps
├──────────────────────────────┤
│ 中间件层                     │  SOME/IP / DDS / RPC
├──────────────────────────────┤
│ OS & 系统服务层              │  systemd / cgroups / watchdog
├──────────────────────────────┤
│ 内核层                       │  scheduler / mm / net / irq
├──────────────────────────────┤
│ 硬件 / 平台层                │  SoC / PHY / PMIC / WDT
└──────────────────────────────┘

问题定位必须自底向上、再自顶向下验证，禁止直接从应用层下结论。

4. 事故类型分级与首要证据

事故类型	一级证据	二级证据	说明
Reset / Reboot	reset reason	dmesg / trace	一级事故信号
Kernel Panic	panic log	kdump	必须保留
OOM	oom log	meminfo / perf	多为慢性问题
Hang	trace	sched / irq	log 通常不足
网络异常	link / vlan	tcpdump / trace	易拖垮系统

5. 日志（Log）规范

日志是问题定位的第一入口，但在车载系统中，必须明确其能力边界与工程约束。

5.1 基本要求（强制）

系统必须统一使用 systemd journal，禁止多套日志系统并存
内核日志与用户态日志必须使用同一时间基准（RTC / monotonic）
关键系统服务（systemd、watchdog、中间件、网络管理）必须具备：
- 启动日志
- 退出 / 异常日志
- 重启原因记录

5.2 日志内容规范

日志必须包含：
- 模块名
- 进程 / 线程 ID
- 严重级别（INFO / WARN / ERROR / FATAL）
严禁在高频路径打印 INFO 级日志（如调度、数据面循环）

5.3 使用边界（重要）

日志不得作为调度、性能、资源耗尽问题的唯一依据
在 reset / hang / OOM 场景下，默认认为日志：
- 不完整
- 存在丢失
- 可能被异常本身破坏

📌 结论：

log 用于"确认已知问题"，而不是"发现未知问题"。

6. Reset / Reboot 定位规范

Reset / Reboot 是车载系统中的一级事故信号，任何一次 reset 都必须可追溯。

6.1 必须记录的 Reset 信息（强制）

硬件 reset reason（PMIC / SoC / MCU）
watchdog 触发源（硬件 / 软件 / 外部）
软件触发路径（reboot / panic / assert）

以上信息必须在下次启动早期即可获取。

6.2 Reset 前证据保留要求

最近 N 秒内核 trace（ring buffer）
最近一次系统 load / CPU / memory 快照
关键 RT 线程的调度状态

6.3 工程禁止项

reset 仅记录"系统重启"
reset 原因依赖人工复现
reset 后直接覆盖关键证据

📌 原则：

Reset 是结果，定位必须发生在 reset 之前。

7. OOM 与资源耗尽规范

在车载系统中，OOM 往往不是孤立事件，而是系统长期失衡的最终表现。

7.1 基本认知

OOM 是结果，不是根因
很多 reset 并未触发 OOM，但早已有内存异常迹象

7.2 必须记录的信息

OOM killer 触发日志
被 kill 进程及其内存占用
触发前的内存水位变化趋势

7.3 OOM Kill 白名单（强制）

以下进程禁止被 OOM kill：

watchdog / supervisor
systemd
核心通信中间件（SOME/IP / DDS）
平台级健康监控进程

通过 cgroup / oom_score_adj 强制保障。

7.4 工程建议

关注 memory leak 的演化过程，而非 OOM 瞬间
将 OOM 与 reset / WDT 统一分析

8. Trace / ftrace / perf 使用规范

Trace 是车载平台中唯一可在不可复现条件下还原现场的工具链。

8.1 Trace 使用原则

常态：低频、关键 trace 点长期开启
异常：允许动态提升 trace 等级
使用 ring buffer，允许覆盖，禁止停写

8.2 车载必开 Trace 点（推荐）

sched_switch / sched_wakeup
irq / softirq
mm / oom
net_dev_queue / netif_receive_skb

8.3 perf 使用规范

perf 仅用于慢性问题、性能退化分析
支持火焰图（Flame Graph）生成
禁止作为常驻在线监控工具

📌 原则：

trace 看"发生过程"，perf 看"资源归属"。

9. 启动阶段问题定位规范

启动阶段是问题最容易被忽视、但影响最大的阶段。

9.1 启动阶段必须保留的信息

early dmesg（前 200~500 行）
initcall 耗时信息
systemd critical-chain / blame

9.2 常见风险

driver probe 阻塞
systemd unit 隐式依赖死锁
中间件启动过早抢占资源

9.3 工程禁止项

启动阶段关闭日志
启动失败仅凭"经验判断"修复

10. 网络问题定位规范

在车载系统中，网络问题极易跨层扩散，最终演变为系统级事故。

10.1 标准定位顺序（强制）

PHY / Link 状态
VLAN / IP / QoS / TSN
Socket / 中间件（SOME/IP / DDS）
系统调度与负载影响

10.2 必须关注的系统影响

网络 IRQ / softirq 占用 CPU
RT 线程是否被网络负载饿死
网络异常是否触发 watchdog

10.3 工程提示

tcpdump 需评估对实时性的影响
网络问题必须结合 trace 一起分析

11. Watchdog / Supervisor 协同规范

Watchdog 不是"最后一刀"，而是系统自我保护机制的一部分。

11.1 设计原则

Watchdog 必须可追溯触发原因
Supervisor 不得成为 OOM kill 对象

11.2 Reset 前协同机制（推荐）

WDT 即将触发前：
- 冻结 trace buffer
- 记录关键系统状态（CPU / memory / load）

11.3 Reset 后复盘流程（强制）

读取 reset reason
导出 trace / perf
关联资源状态
还原完整时间线

📌 原则：

Watchdog 负责"保护系统"，平台负责"解释原因"。

12. 问题定位流程（标准作业）

复制代码

现象
 ↓
事故分级
 ↓
证据收集（log / trace / perf）
 ↓
时间线还原
 ↓
跨层验证
 ↓
根因确认

13. 工程成熟度评估

等级	特征
初级	靠 log + 经验
中级	trace 定位问题
高级	reset 前证据完整
成熟	系统可自证

14. 结语

问题定位不是技巧，而是平台能力。

一个成熟的车载 Linux 平台，应当具备：

即使问题无法复现
即使现场条件不可控

仍能通过系统自身留下的证据，
回答"发生了什么、为什么发生"。

这，才是工程的终点。