车载测试学习指南
已学 0/0 ✎ 自测
第 10 篇

车联网域——OTA

本篇共 15 个小节，覆盖 相关的术语、OTA 测试的测试点、升级的底层链路 ★、下载阶段核心逻辑、主要测试场景、OTA 专项特性测试。

相关的术语OTA 测试的测试点升级的底层链路 ★下载阶段核心逻辑主要测试场景OTA 专项特性测试

11.1 相关的术语

名词解释
OTAOver-the-Air Technology，空中下载技术
ECUElectronic Control Unit，电子控制单元
VINVehicle Identification Number，车辆识别代码（17 位字符串）
OTA 模式指在执行 OTA 刷写前，车辆各零部件需预先进入的状态

OTA 与 HMI 对应流程

OTAHMI说明
版本检测检测新版本手动检测/自动检测新版本
软件下载下载升级软件包检测到新版本时，静默下载升级软件包
安装升级预约安装预约时间安装软件包

根据升级内容分为 SOTA 和 FOTA：SOTA 主要指车机中的软件部分（多媒体、地图等）；FOTA 主要指固件升级（ADAS、车灯、车窗等控制器）。目前已不怎么区分 SOTA 和 FOTA，一般统称 FOTA 升级。

1.1 整车固件升级 FOTA

  • 升级 ECU 底层程序：车身、底盘、动力、智驾、网关、BMS、VCU、MCU；
  • 修复硬件底层 BUG、优化电控逻辑、提升动力/能耗/平顺性；
  • 支持分区升级、断点续传、差分升级。

1.2 软件应用升级 SOTA

  • 车机系统、桌面、UI 界面、主题、壁纸；
  • 车载 APP、导航、音乐、视频、小程序；
  • 语音助手、娱乐生态、小程序商城更新。

11.2 OTA 测试的测试点

OTA 测试是车载领域的核心测试模块，覆盖升级全流程、多场景适配、车端稳定性、功能一致性四大核心维度，还需重点关注车载专属的安全、合规、断连续传等要点，结合量产车实际使用场景（行车/驻车、网络波动、低电量）设计测试。核心分为基础流程测试、异常场景测试、功能验证测试、专项特性测试四大类，同时需兼顾 OTA 的全链路安全和车载环境适配。

2.1 基础升级流程测试

覆盖 OTA 最常规的完整链路，验证正常场景下升级的可行性、准确性、完整性，核心关注流程无卡顿、版本准确生效、数据无丢失。

1. 升级前校验

  • a. 车端升级提示（弹窗/消息）的展示时机、内容准确性（版本号、升级包大小、预估时间）；
  • b. 升级包合法性校验（签名验证、包完整性校验、版本号匹配，防止篡改包/低版本刷高版本）；
  • c. 车端升级条件判定（如电量阈值、驻车/行车限制、网络类型限制，需匹配车企设定，如电量 <20% 禁止升级）；
  • d. 手机 APP/车机端升级预约/立即升级操作的响应性、权限校验（如车主账号鉴权）。

2. 升级中执行

  • a. 升级包下载速度、进度条准确性（不同网络下：4G/5G/WiFi，无进度卡死、跳变）；
  • b. 升级包断点续传（正常网络中断后恢复，从断点继续而非重新下载）；
  • c. 升级过程中车端状态（屏幕显示、灯光/喇叭等外设无异常、无死机/重启）；
  • d. 多模块协同升级（如智驾域+座舱域同时升级）的顺序合理性、无资源抢占。

3. 升级后生效

  • a. 车端自动重启/手动重启的可行性，重启后无异常卡死、蓝屏；
  • b. 版本号全局一致性校验（车机设置、诊断仪、后台管理系统的版本号完全匹配）；
  • c. 升级包安装完整性（无文件缺失、模块未升级成功的情况，如仅升级多媒体、智驾模块未更新）；
  • d. 升级后基础功能正常（点火、挂挡、刹车等核心行车功能无异常，优先于座舱功能验证）。

11.3 升级的底层链路 ★

（确保各个 ECU 之间基线保持一致，如 24R3、24R1、24R2U1）

  1. 云端配置升级包，云端获取车辆最新版本信息与配置的最新升级包进行对比（车辆上电后自动触发向 TSP 请求，TSP 向 OTA 发送请求车辆 VIN，请求全量 ECU 清单）；
  2. 当有差异时，车端发出请求，云端通过 MQTT 协议（消息队列遥测传输，基于发布/订阅模式的轻量级消息传输协议，专为低带宽、不稳定网络环境设计，广泛应用于物联网，支持设备间实时数据传输）发给车辆上的 TBOX；TBOX 通过网关发给对应 ECU 进行升级；
  3. 刷写过程中会有不同的总线（如 CAN、LIN），通过不同总线对应的不同协议去刷写；刷写完成后按原路返回给网关，网关把最新版本信息给 TBOX，TBOX 再通过 MQTT 协议给到云端；
  4. 云端将车辆升级后的版本信息与配置的版本信息再进行对比，无差异说明升级成功。

链路示意：云端（①升级包部署 → OTA 云平台；②安全连接建立；③升级包推送与安全传输）→ 车端（④升级包拆包、分发与执行 → ECU A/B/C）。

升级操作流程

  1. 测试车需调通 OTA 链路（产线生产的车辆自动接入云端的生产环境；TSP 分演示环境（测试）和生产环境，建立车档信息，确保车云链路互通，上云证书）；
  2. 管理员上传版本到 OTA 云平台；
  3. 在 OTA 云平台配置升级策略：不同车型、不同版本的升级任务；单车升级（需提供车型、单车 VIN 码），根据车辆池多车升级；
  1. 下发（撤回）升级推送；
  1. 车端或手机 APP 端收到对应的推送；
  2. 用户选择不同的升级方式：立即升级和预约升级；
  3. 选择升级后会有一个签名的校验，以及前置条件的检查。

简化总结：1. 管理员上传版本到 OTA 云平台 → 2. 配置升级策略（不同车型、不同版本的升级任务）→ 3. 下发升级推送 → 4. 车端或手机 APP 端收到推送 → 5. 用户选择不同的升级方式。

3.1 车云通讯

  • 车云通讯主要是车端 IG_ON 之后 Tbox 唤醒状态，车自动检测本车所有可升级 ECU 版本信息，获取后将版本信息发送云端服务器；
  • 云端收到车端发送的数据，检查是否符合升级需要（源版本中有没有本车的 ECU 源版本）；
  • 符合升级条件，给这台车发送升级推送。

3.2 升级的主要流程

  1. 以上流程主要展示升级的基本流程，需要 OTA 测试工程师重点关注车端 OTA 部分的场景。
  2. 升级包下载时，升级包下载到 Android 系统中的存储空间，下载时进行签名认证；
  3. 安装时再次进行签名认证；
  4. 安装过程中，将下载下来的软件包更新到不同 ECU 上，主要使用 UDS 的方式。

3.3 证书—安全验证

下载升级包及安装升级包时都会有对应的安全认证，主要安全认证方式有：

  1. 数字签名验证：最常见的方法。制造商用私钥对安装包签名，车辆软件系统通过预存公钥验证签名；签名验证成功说明安装包由可信来源发布且未被修改。
  2. 哈希校验：制造商对安装包生成哈希值（如 SHA-256）并与安装包一起发送；车辆接收后重新计算哈希值，两个哈希值匹配则验证通过。
  3. 证书链验证：类似数字签名，但使用证书链进一步增强安全性（多个证书，每个由上一级证书授权，形成信任链）。

11.4 下载阶段核心逻辑

4.1 断点续传

  • 断网/熄火/断电重启，恢复后继续下载不重头来；
  • 升级包按分片地址记录已下载字节位置（不记录整体进度），中断后重启直接从断开位置接续下载，不从头重下。
  • 触发中断场景：车机断开 4G/5G/WiFi 网络；车辆熄火下电、整车休眠；车机重启、APP 退出、后台进程被杀；隧道/地下车库信号弱断连。
  • 恢复逻辑：网络恢复/车辆上电后，自动读取本地下载记录，接续剩余数据包。
  • 测试点：1. 下载中途断网，联网后验证是否续传；2. 下载一半熄火锁车，次日上电继续下载；3. 反复启停车辆，不重置下载进度；4. 断电久放后，进度不丢失。

4.2 流量管控

  • 区分 WiFi/移动网络，可设置仅 WiFi 下载；区分局域网 WiFi 和蜂窝移动流量双链路管控。

+

  1. 任意网络下载：WiFi/流量均可自由下载；2. 流量限额：超出车主设定流量，自动暂停 OTA 下载。
  2. 测试点：1. 切流量→切 WiFi，下载自动启停；2. 关闭移动数据，下载直接暂停；3. 验证流量提醒、流量超限弹窗。

4.3 分包校验（CRC/MD5 校验）

  • 数据包 CRC/MD5 校验，丢包、错包自动重传。
  • 工作流程：1. 云端把大升级包拆成多个小分包下发；2. 每一包附带唯一 CRC32/MD5 校验值；3. 车端接收完单包立刻比对校验码；4. 不一致判定：丢包、错包、篡改包；5. 自动向上层请求重新下发错误分包，不整体重下；6. 全部分包接收校验通过，再合并成完整升级包。
  • 作用：防数据包丢失、网络传输错乱、恶意篡改升级包。
  • 测试点：1. 人为干扰丢包，验证自动重传；2. 篡改分包数据，校验失败拒绝接收；3. 完整合并后整体全量哈希校验。

4.4 后台静默下载

  • 不弹窗、不打扰用车，后台低优先级静默完成下载。
  • 运行规则：1. 行车中、听歌、导航、用车机娱乐不弹窗打断；2. 仅状态栏微小图标提示下载，不强制用户操作；3. 优先占用闲置带宽，不抢占导航、通话网络；4. 满足下载条件自动启动，无需用户手动点击；5. 锁屏、息屏、待机状态依旧持续后台下载。
  • 限制条件：静默下载只负责下载，不自动安装。
  • 测试点：1. 开车导航时后台正常下载；2. 车机全屏观影无弹窗干扰；3. 息屏锁车后台依旧跑下载；4. 多应用并发，下载不卡车机。

11.5 主要测试场景

5.1 HMI 交互

  • 升级包下载都放在车机中的 Android 系统内；一般使用 adb 命令相对多一些（参考：远程升级-OTA 测试手册 V4.0-0705、M18 整车 OTA HMI 需求文档 V4.2_20230528）。
  • 测试点：推送弹框、下载弹框、升级弹框、多任务弹框（云端发布 1.0 版本车端收到推送，同时云端发布 2.0 版本车端在不同场景下的反应：1.0 推送关闭 / 1.0 正在下载 / 1.0 正在升级）、任务中止。
  • 测试过程中需要关注整车的电源状态以及对应车速（IG_ON、有车速/没有车速）。
  • HMI 交互测试主要测试人机操作的逻辑和每个步骤；HMI 测试没问题后，可以对升级方式进行测试。
  • 升级方式：主动升级、预约升级、强制升级、静默升级。

5.2 主动升级

主动升级即云端配置好对应的升级任务并下发推送，车端收到推送进行正常升级。

  • 需要重点了解：
  • 源版本：云端配置 OTA 升级任务时，指定哪些版本可以进行升级（例：iPhone 有 6s（IOS12）、15（IOS17），最新 IOS18，可升级的版本即源版本）；
  • 目标版本：云端配置任务升级成功之后的版本；
  • 车端版本：当前车辆上运行的版本。
  • 云端配置界面：源版本 v1.00.01 / v1.02.01 / v1.03.01（指定可以升级的版本），目标版本 v2.00.1（升级成功的版本）。车端版本在源版本中才能收到推送；如果源版本为空，所有跟目标版本不一致的版本都可以升级。
  • 升级成功/失败场景：升级成功 → 升级包删掉，备份包保留；升级失败 → 升级包保留，备份包也保留。
  • 测试过程中使用 adb 命令进入 shell，找到对应安装包的存放路径检查安装包；软件包日志路径：mnt/ext_sdcard/jmcotards/ota_pkg。

5.3 预约升级

  • 预约更新/立即更新选项；新版本特性示例：1. 升级了 ADAS CNOA 城市领航；2. 添加 AVP 待客泊车功能。
  • 预约升级可在当前时间 24 小时以内设置升级时间；"今晚升级"和"预约升级"都指在将来某个时刻自动升级（今晚升级一般是凌晨 2:00-3:00 自动升级）。
  • 主要测试点：1. 整车分别在休眠状态和唤醒状态下符合升级条件，验证能够正常升级；2. 预约升级设置错误升级包，期望结果为升级失败，云端有对应的升级结果，并且升级包保留、备份包保留。

5.4 静默升级

  • 静默升级是在用户不知道的情况下进行的更新：不推送，版本更新成功之后也不会有任何提示。
  • 主要测试点：1. 发布静默升级任务时，IG_ON 收到升级任务，到达指定静默升级时间 IG_OFF 情况下自动升级；如果 IG_ON 则继续等下一个静默时间点升级；2. IG_OFF 未收到升级任务，到达指定静默升级时间 IG_OFF 情况下不会自动升级；3. 发布静默升级任务时，IG_OFF 状态一直持续到任务有效期结束，IG_ON 也不会收到升级任务。

5.5 强制升级

  • 也有更新提醒，但只有一个更新选项；弹窗提示"本次更新必须进行，否则不能使用！！"，用户只能点"确定"。

5.6 升级的前提条件

  • 档位 P；
  • 电池电量 20%；
  • 车门、车窗上锁状态；
  • 充电口关闭，不能充电（个别车型可以通过原装充电桩充电时升级）；
  • 电源状态 IG_OFF。
  • 立即升级之前会检查升级条件，如果升级条件不满足，则退出升级流程。

11.6 OTA 专项特性测试

针对车载 OTA 的专属特性和高级功能设计，适配车企的 OTA 能力（如分阶段升级、差分升级），同时验证长期使用稳定性。

1. 差分升级专项

  • a. 差分包下载/安装可行性，与全量包升级后的版本、功能完全一致；
  • b. 差分包完整性校验，无因差分包缺失导致的功能异常；
  • c. 低版本跨多个版本差分升级（如 V1.0→V1.2，跳过 V1.1），流程正常、版本生效准确。
  • 差分方式：
  • 文件差分：改了哪个文件更新哪个文件，以"单个文件"为最小更新单位；
  • 区域块差分：整个系统分区差分，以"存储分区（Partition）"为整体单位进行二进制级别差分；
  • 版本增量差分：版本升级的差量，以"特定版本节点（A 版本 → B 版本）"为基准差分；
  • 组件模块化差分：按功能模块单独更新，以"独立的功能组件/业务模块"为单位升级。
  • 参考用例：文件差分（File-level Delta）测试用例.docx

2. 分阶段/分区域升级

  • a. 后台定向推送升级包（如仅推送给某一地区/某一批次车辆），车端仅目标车辆收到提示，非目标车辆无推送；
  • b. 分阶段升级（如先推座舱域，再推智驾域），各阶段升级流程独立、无相互影响，全部完成后版本一致。

3. 回滚/降级测试

  • a. 升级后功能异常时，手动/后台触发回滚的可行性，回滚后恢复至原版本，功能无异常；
  • b. 回滚过程中的稳定性（无死机、断电，回滚后无文件残留）；
  • c. 主动降级（如高版本刷回低版本）的校验逻辑（车企是否允许，允许则流程正常，禁止则提示明确）。

4. 批量升级测试

  • a. 多车辆同时接收升级推送（模拟量产批量升级），后台无卡顿、车端下载/安装无冲突；
  • b. 批量升级中部分车辆升级失败，后台可精准识别失败车辆、原因，并支持重推。

5. 长期稳定性测试

  • a. 连续多次升级/回滚（如 5 次以上），车端无硬件损耗、存储无碎片、功能无异常；
  • b. 升级后车辆长时间运行（72h 以上），无偶发死机、重启、功能闪退。

11.7 实车异常场景测试

车载 OTA 的高频故障场景，核心模拟用户实际使用中的各种异常，验证 OTA 的鲁棒性，是区分 OTA 测试质量的关键。所有异常场景均需验证"无行车安全风险、可恢复、无硬件损坏"。

1. 网络异常

  • a. 下载/安装中网络断连（4G/5G 切飞行模式、WiFi 断开），车端提示准确性、无卡死；
  • b. 下载中网络切换（WiFi↔4G/5G、弱网/满格网切换），断点续传正常、无包损坏；
  • c. 弱网环境（网络速率 < 1Mbps）下，升级包下载的稳定性，无超时、包校验失败。

2. 车端状态异常

  • a. 行车中升级：验证车企限制逻辑（如禁止升级/暂停升级/弹窗提醒），无强制升级导致的车机卡死；
  • b. 低电量升级：电量低于阈值（如 20%）时禁止升级的校验；升级中电量耗尽，车端可正常下电、再次上电无异常，升级包不损坏；
  • c. 升级中强制操作：升级中点火、熄火、挂挡/驻车切换、锁车/解锁，车端无异常、升级状态可保留/回滚；
  • d. 升级中外设操作：操作空调、多媒体、灯光等，车端无卡顿、升级流程不中断。

3. 系统异常

  • a. 升级中车机死机/强制重启/断电，再次上电后车端可识别升级状态（继续升级/回滚至原版本），无砖机风险；
  • b. 多任务并行（如导航+音乐+下载升级包），升级流程无资源不足、下载失败；
  • c. 升级包损坏/篡改/不匹配（如错刷其他车型包、低版本包），车端可校验失败、提示明确，无安装尝试。

4. 硬件异常

  • a. 升级中插拔 U 盘/手机互联，升级流程不中断、无包损坏；
  • b. 车端存储不足（如车机内存 < 升级包大小），升级前的校验提示、禁止下载的逻辑。

11.8 性能测试

  1. 性能测试：测试不同网络（4G/5G/Wi-Fi）下的下载速度、安装耗时；验证多车辆（百台/千台级）同时升级时云端平台的并发处理能力，车端无下载卡顿；
  2. 量产覆盖测试：选用不同配置、不同批次、不同地区的测试车，验证升级一致性；测试多语言、不同运营商网络（移动/联通/电信）下的适配性；
  3. 低功耗测试：验证车端在待机状态下检查升级包、后台下载时，电瓶功耗在合理范围，无亏电风险。

11.9 OTA 测试的常用方法

  1. 模块化测试：将 OTA 系统拆分为"云端平台、车端客户端、升级包、ECU"四个模块，先单独测试每个模块的功能，再联调，降低问题定位难度；
  2. 异常场景自动化：将高频异常场景（如断网、低电压）制作成自动化测试脚本（如基于 Python/CANoe），提升测试效率；
  3. 多环境交叉验证：同一用例在仿真、台架、实车环境各验证一次，确保结果一致；
  4. 长期稳定性测试：对核心域升级，完成升级后进行长期路试（如 1000km），验证升级后车辆的长期稳定性，无隐性故障；
  5. 跨版本升级；
  6. 自升级。

11.10 安装升级核心逻辑

  1. 分区安装：娱乐域 SOTA 快速装，电控域 FOTA 分时静默装；
  2. 顺序升级：网关优先 → 域控 → 子 ECU，严格升级时序；
  3. 双备份分区：A/B 分区冗余，升级失败自动切回旧版本；
  4. 整车静默休眠升级：锁车下电后后台自动安装，不占用用车时间；
  5. 禁止打断：终止升级并回滚。

11.11 失败处理逻辑（重中之重）

  1. 自动回滚：刷写断电、报文异常、校验失败，立刻恢复原程序；
  2. 故障保护：升级失败不锁车、不抛死故障、保留基础行车功能；
  3. 重试机制：轻度失败自动重试，多次失败弹窗提示；
  4. 日志留存：全程记录失败原因、阶段、报文，便于定位问题。

11.12 OTA 常见问题

  1. 硬件号不一致：ECU 硬件号与 BSS 系统中不存在该硬件/该硬件零件号（详见原图"硬件号不一致，BSS 中不存在该硬件/零件号"示例表格，部分条目匹配成功）；
  1. 车云环境不一致：车端与云端环境数据不一致（详见原图日志）；
  1. OTA 下载 Fail，调 glros_other 服务超时：下载报错（如"No ocsp certificate information available"），云端网络错误导致下载失败，重新申请下载任务后恢复（详见原图日志：INSTALLATION-STARTED → 校验包成功 → 切网成功 → 证书校验 → 车辆重启进入 mode Convenience → 启动后台应用 → 首次发送安装包 → 配置高压/低压柜组 → 分区信息校验 OK → 安装包校验通过）。

11.13 OTA 升级失败原因

车载 OTA 升级失败的原因集中在网络链路、车端环境、升级包、车端软硬件、云端后台、安全校验六大核心维度，多数失败可通过"车端日志 + 后台日志 + 分步复现"快速定位。

13.1 网络链路问题

升级包下载/鉴权依赖车端-云端的网络交互，车载环境网络波动、制式限制是核心诱因，多发生在下载阶段。

  • 高频原因：1. 车端网络弱/断连（4G/5G 信号差、WiFi 掉线、地下车库/隧道无信号）；2. 网络制式限制（车企限定 WiFi 升级，车端误连 4G 被拦截；或 4G/5G 带宽不足）；3. 云端网络链路拥堵（批量升级时云端服务器带宽被占，推送/下载超时）；4. 网络劫持/干扰（车载网络被外部信号干扰，升级包传输丢包）。
  • 专属排查方法：1. 车端侧：查看车机网络状态（信号格、网速测试），切换网络（WiFi/4G/5G）复现，验证是否仅特定网络下失败（ping）；2. 后台侧：查看云端日志，确认是否有下载超时、丢包率过高、网络连接中断日志；3. 环境侧：验证车辆是否在网络盲区，移至开阔地/满格信号区重试；4. 批量升级排查：多车同时失败时排查云端服务器带宽/负载，考虑分批次推送。

13.2 车端环境不满足

车企为保障升级安全设置车端升级前置条件，条件不满足会被系统直接拦截，多发生在升级启动阶段。

  • 高频原因：1. 电量未达阈值（多数车企要求电量 ≥20%/30%，低电量禁止升级）；2. 车辆状态不符（行车中/挂挡状态，未驻车/熄火；部分车型要求手刹拉起）；3. 车端存储不足（车机 ROM/RAM 剩余空间 < 升级包大小，含差分包/全量包）；4. 车端外设/进程占用（高负载进程如高清导航+4K 视频，或外设占用存储/接口）。
  • 专属排查方法：1. 快速校验：按车企要求检查车辆状态（驻车/熄火/手刹）、电量、存储剩余空间，逐一满足后复现；2. 进程清理：关闭车机非核心进程/外设（行车记录仪、手机互联、多媒体），释放资源后重试；3. 日志定位：查看车端升级日志，是否有"电量不足""车辆状态非法""存储不足"明确提示；4. 特殊场景：混动/纯电车需验证高压电池/低压电瓶是否正常，电瓶电压波动也会触发环境校验失败。

13.3 升级包异常

升级包是 OTA 核心载体，包本身的损坏、不匹配、签名错误会导致车端校验/安装失败，可发生在下载后校验、安装阶段。

  • 高频原因：1. 包损坏/丢包（网络传输丢包导致完整性校验失败）；2. 包不匹配（错刷车型/配置/硬件版本，如低配车刷高配包、老款车刷新款包）；3. 签名/加密异常（无签名、签名错误、加密包解密失败）；4. 差分包异常（跨版本差分升级包缺失、差分包与基础包不匹配，如 V1.0→V1.2 跳过 V1.1）；5. 包版本逻辑错误（低版本包刷高版本、重复刷同版本，触发版本校验拦截）。
  • 专属排查方法：1. 包校验：车端/后台校验升级包 MD5/SHA 值，与云端原始包比对（不一致则包损坏）；2. 包匹配性：核对升级包的车型码、配置码、硬件版本号与测试车辆完全匹配；3. 签名验证：排查云端签名服务器是否正常，升级包是否完成合规签名/加密，无签名包直接拒绝；4. 差分包专项：验证跨版本差分升级是否按车企规范执行，是否补充中间版本包；5. 包重推：后台删除车端异常包，重新推送原始完整包，验证是否可正常安装。

13.4 车端软硬件故障

车端底层软硬件问题会导致升级流程卡死，多发生在安装阶段、重启生效阶段，部分会导致"半砖"（需回滚/刷机）。

  • 高频原因：1. 车机 ECU/域控制器故障（智驾域/座舱域控制器死机、硬件损坏，无法执行安装指令）；2. 车机系统异常（安卓/QNX 系统卡顿、闪退、注册表损坏，无法识别升级包）；3. 硬件兼容性问题（新款升级包适配新硬件，老硬件不支持导致安装失败）；4. 总线通信异常（CAN/LIN 总线故障，升级指令无法在模块间传递）。
  • 专属排查方法：1. 基础硬件检测：通过诊断仪读取车机 ECU/域控制器状态，确认无硬件故障码；2. 系统恢复：车端执行软重启/恢复出厂设置（注意备份数据），清除系统异常后重试；3. 总线检测：验证 CAN/LIN 总线核心信号（升级指令、版本信号）是否正常交互，无丢包/延迟；4. 单模块测试：若为分域升级，单独升级某一域（如仅座舱域），定位是否为特定域控制器故障；5. 硬刷验证：若软升级失败，通过线下刷机（如 U 盘）验证，仍失败则判定为硬件故障。

13.5 云端后台问题

云端是 OTA 的控制中心，后台配置、服务器、推送逻辑错误会导致车端无推送/升级失败，多发生在推送阶段、鉴权阶段。

  • 高频原因：1. 后台配置错误（推送范围、车型、版本号配置错误，车端未收到推送/收到错误包）；2. 服务器故障（鉴权/推送/存储服务器死机、宕机，车端无法鉴权/下载）；3. 推送逻辑异常（批量升级时推送队列堵塞、重推机制失效，部分车辆未收到包）；4. 车端-云端数据不一致（后台记录的车辆版本与车端实际版本不符，触发鉴权失败）。
  • 专属排查方法：1. 后台配置核对：检查云端推送配置，确认车型、版本、地区、批次与目标车辆一致；2. 服务器状态：查看云端服务器监控面板，确认鉴权/推送/存储服务器无宕机、负载正常；3. 数据同步：车端手动触发版本同步/心跳包，使车端与云端数据一致后重新鉴权；4. 单台车推送：批量失败时，后台单独向一台测试车推送升级包，验证是否为推送逻辑问题。

13.6 安全校验拦截

车载 OTA 需匹配 ISO/SAE 21434 信息安全要求，安全校验不通过会被系统直接拦截，多发生在鉴权、包校验阶段。

  • 高频原因：1. 身份鉴权失败（非车主账号/未授权设备触发升级、车端-云端双向鉴权失败）；2. 权限不足（普通用户触发高危升级如智驾域/底盘域升级，无管理员/车主授权）；3. 安全策略拦截（升级包未通过车端入侵检测系统 IDS，被判定为恶意包）。
  • 专属排查方法：1. 身份鉴权：使用车主授权账号登录车机/手机 APP，重新触发升级验证鉴权；2. 权限校验：高危模块升级需完成二次确认/车主授权，核对权限配置是否正确；3. 安全策略：排查车端 IDS 系统，确认升级包未被误判为恶意包，调整安全策略。

13.7 分级排查流程

按"快速排查（5 分钟）→ 精准定位（30 分钟）→ 深度排查（数小时）"分级执行，优先排除简单易复现的问题。

  • 一级：快速排查：1. 检查车端网络、电量、车辆状态、存储四大基础条件；2. 车端软重启，清除临时进程/异常，重新触发升级；3. 查看车端升级日志，是否有明确失败提示（如电量不足、包不匹配）。
  • 二级：精准定位：1. 切换网络（WiFi/4G/5G）、更换环境（开阔地）复现，排除网络问题；2. 后台核对升级包匹配性、MD5 值、推送配置，排除包和后台问题；3. 车端与云端手动同步版本，重新鉴权，排除数据不一致问题。
  • 三级：深度排查：1. 通过诊断仪读取车机 ECU/域控制器故障码、总线信号，排除硬件/总线问题；2. 云端检查服务器状态、负载、推送逻辑，排除后台服务问题。

11.14 面试问题

Q1：OTA 测试过程中用到过哪些 ADB 命令？

测试下载弹框和升级弹框时，如果已经下载完成，再次检查新版本会弹出升级弹框；如需重新测试下载弹框功能，需要用 adb 命令进入 shell，删除原来下载好的版本，重新进行操作。

Q2：OTA 测试过程中发现 bug 怎么处理？举一个工作中的情景。

例：测试主动升级 BLE 蓝牙模块升级时，先在云端配置指定的源版本和目标版本，并将对应升级包上传云端服务器；车端版本在源版本中，期望收到版本更新推送，但连续重启好几次都没收到。此时不确定是车端 OTA 程序还是云端服务器问题，将问题记录下来并把相关日志发给开发。车端 OTA 程序运行日志在 Android 车机内，通过 adb 命令进入 shell 查看相关日志，并用 adb pull 命令将日志下载下来。

日志查看技巧：出现上述问题，若是车端问题，可能是车端没有获取 BLE 的版本信息，或没有将这些版本信息同步到云端（日志中有获取 ECU 版本信息的日志以及上传日志，通过日志可以知道）；车端没有问题一般就是服务器问题，通过 ssh 登录远程服务器找到日志文件查看内容，一般根据车端发送日志的时间来看。

Q3：你们的车哪些 ECU 支持升级（哪些件支持 OTA）？

  1. ACM（Audio Control Module）音频控制模块——控制车辆音频系统，包括音响输出和音频信号处理；
  2. VCU（Vehicle Control Unit）整车控制单元——负责整车控制和监控，涉及驱动控制、能量管理等功能；
  3. SCU（Steering Control Unit）转向控制单元——控制方向盘动力助力；
  4. RCM（Restraint Control Module）约束控制模块——管理安全带和气囊系统；
  5. MCU（Motor Control Unit）电机控制单元——电动车驱动电机功率和控制；
  6. IPM（Image Processing Module）图像处理模块——处理车辆摄像头图像数据，用于辅助驾驶/自动驾驶；
  7. MRR（Mid-Range Radar）中距离雷达——用于碰撞预警和车道保持辅助；
  8. PAM（Park Assist Module）泊车辅助模块——停车时检测障碍物并自动调整车辆位置；
  9. AFS（Adaptive Front-lighting System）自适应前照灯系统——自动调整前灯方向和强度；
  10. SRR_L / SRR_R（Short Range Radar）短距离雷达——监控车辆左右短距离区域，常用于盲点检测和交通流监控；
  11. EPS（Electric Power Steering）电动助力转向——减少驾驶员的转向努力；
  12. AVM（Audio/Video Module）音视频模块——管理车辆音频和视频输出设备。

Q4：OTA 压测是怎么做的？

版本升级时支持的源版本有多个（如 V1.0、V1.1、V1.2、V1.3 都可升级到 V1.5）。压测先把车子版本恢复到 V1.0，测试能否更新到 1.5；再刷到 1.1 测试能否正常更新到 1.5；再依次刷到 1.2、1.3 测试，通过这种方式进行压测。

  • 在线更新：通过云端服务器发布新的更新任务来升级；
  • 离线刷写：通过 UDS 方式本地刷写，公司内部有上位机（选择要刷的版本、选择对应要刷的 ECU 直接刷包）；也可使用 CANoe 或周立功自己用 UDS 方式刷写（主要用到的 UDS 服务见下文）。

11.15 附：UDS 刷写流程（ECU 离线刷写）

（刷写客户端示例：智能驾驶系统 Dolp 客户端，选择 ECU、服务器 IP/端口、Security Access、安全校验、UDS 命令物理寻址发送、按文件诊断、文件刷写、获取/写入文件，日志可见路由激活、10 03、27 03/04、31 01 等指令交互）

  1. 刷写前：
  2. 10 03 进入扩展会话；
  3. 31 服务进行升级之前的条件检查，检查没有问题；
  4. 85 02 关闭 DTC 记录（可让刷写速度更快）。
  5. 刷写中：
  6. 10 02 进入编程会话；
  7. 27 服务进行安全解锁；
  8. 31 01 启动例程，删除 ECU 中原来的数据；
  9. 34 请求下载，将新的版本下载到 ECU 中；
  10. 31 服务进行检查，检查是否下载完成；
  11. 如果刷写整个流程出现问题，都有回滚机制（回滚流程：a. 重新使用 31 服务删除当前版本的存储空间；b. 34 服务下载备份包中的版本；c. 下载完成之后 31 服务再次检查）；
  12. 刷写完成。
  13. 刷写后：
  14. 85 01 打开 DTC 记录；
  15. 11 01 重启 ECU，完成刷写。

_文档整理完毕。素材来源：《车身测试》《车身需求》（车身域 BODY CAN）、《TBOX》《OTA》（车联网域）。_