2. 汽车电子与ECU基础
在诊断测试自动化工程中，所有测试脚本最终都要落到具体的电子控制单元（ECU）上。理解ECU的内部组成、它如何通过车载网络通信、诊断接口如何接入、以及OBD与UDS各自扮演什么角色，是设计自动化测试框架的前提。本节从硬件到协议逐层展开，帮助建立一张完整的“被测对象地图”。
一、ECU的组成：从传感器到执行器的闭环
ECU（Electronic Control Unit）是嵌入式控制器，其本质是一个带实时操作系统的微型计算机加上功率驱动与通信外设。典型组成包括：
- 微控制器（MCU）：包含CPU、Flash、RAM、定时器，负责控制策略运算与任务调度。
- 输入处理电路：对模拟传感器信号做滤波、分压、AD转换，对数字/开关信号做去抖与电平匹配。
- 输出驱动电路：通过继电器、MOSFET、H桥等驱动喷油器、电机、灯组等执行器。
- 通信外设：CAN/CAN FD、LIN、FlexRay、以太网控制器，是诊断报文进出的物理通道。
- 电源与监控：稳压、看门狗、复位与欠压/过压保护，保证车规环境下的可靠性。
- 诊断与存储：故障码（DTC）存储区、冻结帧、标定数据与刷写引导程序（Bootloader）。
诊断测试关注的正是最后两项：DTC如何写入、会话如何切换、刷写如何进入Bootloader。测试用例设计必须与ECU的软件状态机对齐，否则会出现“报文发出但ECU不响应”的假失败。
二、车载网络与诊断接口
现代车辆是多个网络的集合。动力与底盘多用CAN/CAN FD，车身舒适多用LIN，域控之间逐步引入车载以太网。诊断仪通常不直接挂在所有总线上，而是通过OBD诊断接口（常见为16针J1962）接入，再由网关（Gateway）路由到目标ECU。
OBD接口的关键引脚包括：4/5脚为车身地与信号地，6脚CAN High，14脚CAN Low，16脚常电B+。诊断测试台架搭建时，必须确认引脚定义、终端电阻（CAN两端各120Ω）与电源时序，否则通信层就会不稳定。
三、OBD与UDS概述：法规诊断与通用诊断
OBD（On-Board Diagnostics）起源于排放法规，强调标准化：统一故障码读取、就绪状态、冻结帧与排放相关数据流。UDS（Unified Diagnostic Services，ISO 14229）则是面向整车全生命周期的通用诊断协议，覆盖读取、写入、例程控制、刷写、安全访问等能力，是自动化测试的主战场。
两者关系可以理解为：OBD是法规要求的“最小公共子集”，UDS是功能完整的“通用工具箱”。UDS报文由服务ID（SID）+子功能+参数构成，常见服务如下表。
| 服务ID | 名称 | 典型用途 |
|---|---|---|
| 0x10 | DiagnosticSessionControl | 切换默认/编程/扩展会话 |
| 0x27 | SecurityAccess | 种子密钥解锁，刷写前置 |
| 0x22 | ReadDataByIdentifier | 按DID读取版本、VIN、数据流 |
| 0x2E | WriteDataByIdentifier | 写入配置与标定 |
| 0x19 | ReadDTCInformation | 读取与清除故障码 |
| 0x31 | RoutineControl | 启动/停止自检例程 |
| 0x34/0x36/0x37 | RequestDownload/TransferData/RequestTransferExit | 刷写数据传输 |
| 0x3E | TesterPresent | 保持非默认会话不超时 |
UDS的响应分为肯定响应（SID+0x40）与否定响应（0x7F+SID+NRC）。自动化断言必须同时校验响应码与NRC，例如0x78表示“响应挂起”，需要继续等待而非判失败。
四、核心原理图解：从测试脚本到ECU内部
下图把测试主机、诊断接口、网关、目标ECU以及ECU内部软件层次串成一条完整信号链，便于理解自动化脚本的作用位置与数据流向。
五、典型应用场景与自动化切入点
ECU诊断在整车生命周期中有多个高频场景，也是自动化测试的主要落点：
- 产线EOL下线检测：批量读取DTC、写入VIN与配置、执行例程自检，要求节拍快、并发高。
- 售后诊断与远程诊断：读取冻结帧、数据流，结合车联网上传，脚本需兼容多车型变体。
- OTA与刷写验证：0x34/0x36/0x37流程、校验和、断点续传与回滚，是自动化回归的重点。
- 法规OBD认证：验证就绪状态、MIL点亮逻辑与排放相关DTC，强调标准一致性。
- HIL台架测试：在硬件在环环境中注入故障，验证ECU诊断逻辑与响应时序。
六、常见误区与复盘
初学者在ECU诊断自动化中容易踩以下坑：
- 忽略会话与安全状态：未进入扩展会话或未解锁就发0x2E，必然收到NRC 0x33/0x7E。
- 把0x78当失败：响应挂起是正常机制，应延长等待并重试，而非直接判错。
- 混淆物理寻址与功能寻址：功能寻址0x7DF用于广播，多数写入服务只支持物理寻址。
- 忽视总线负载与终端电阻：台架线束过长、终端缺失会导致随机丢帧，误判为ECU缺陷。
- 不做DTC清理与恢复：用例间状态污染，导致后续用例出现“幽灵故障”。
# 典型UDS请求-响应日志片段
TX -> 7E0 02 10 03 00 00 00 00 00 # 进入扩展会话
RX <- 7E8 06 50 03 00 32 01 F4 00 # P2=50ms, P2*=5000ms
TX -> 7E0 02 27 01 00 00 00 00 00 # 请求安全种子
RX <- 7E8 06 67 01 A1 B2 C3 D4 00 # 返回种子
TX -> 7E0 06 27 02 XX XX XX XX 00 # 发送密钥
RX <- 7E8 02 67 02 00 00 00 00 00 # 解锁成功
TX -> 7E0 03 22 F1 90 00 00 00 00 # 读取VIN
RX <- 7E8 10 14 62 F1 90 56 49 4E # 首帧，后续流控续传