1. 课程导入与量产验证全景

R-Car 座舱与 ADAS 量产验证，本质上不是“把功能跑通”，而是要在整车生命周期内，用可追溯的证据证明：在规定的环境、工况、边界和故障条件下，系统始终满足功能、性能、安全与法规要求。Renesas R-Car 系列（如 R-Car H3/M3/E3、R-Car V3H/V4H 等）通常作为座舱域或 ADAS 域的主控 SoC，向上承载 Android/QNX/Hypervisor 与中间件，向下连接摄像头、雷达、显示屏、音频功放、以太网/ CAN 等外设。量产验证要覆盖的，正是这条从芯片到整车、从正常功能到失效行为的完整链路。

先明确验证目标。第一是功能正确性：座舱侧的多屏显示、倒车影像、语音交互、导航投屏、OTA 升级等；ADAS 侧的前视/环视感知、车道保持、自动紧急制动、盲区监测等，都要在真实数据流下验证。第二是性能与实时性：例如倒车影像从摄像头出图到屏幕显示，端到端延迟通常要求小于 200 ms；ADAS 感知帧率需稳定在 30 fps，CPU/GPU/NPU 占用率不能长期超过 80%。第三是可靠性与安全性：包括 ISO 26262 功能安全（ASIL 等级）、AEC-Q100 器件可靠性、EMC、高低温、振动、电源跌落等。第四是合规与交付：满足主机厂（OEM）的验证规范、法规认证（如 GB/T、ECE）以及量产签署要求。

验证范围可以按“域—层—接口”三个维度展开。域包括座舱域、ADAS 域、网关与车身域；层包括芯片层、驱动/BSP 层、系统/中间件层、应用层；接口包括 MIPI CSI-2 摄像头输入、LVDS/eDP 显示输出、I2S/AVB 音频、CAN/CAN-FD、车载以太网、PCIe、USB、电源与时钟。量产验证必须同时覆盖单域功能和跨域交互，例如 ADAS 触发报警时，座舱 HMI 是否同步显示警示、音频是否优先播报。

交付物是验证工作的“证据链”。典型交付物包括：验证计划（DVP&R）、需求追溯矩阵（RTM）、测试用例库、自动化测试脚本、测试报告、缺陷清单与关闭记录、覆盖率报告、功能安全论证（Safety Case）、EMC/环境试验报告、量产签署包（PPAP 相关）。这些交付物不是形式文件，而是后续问题定位、变更影响分析和法规审计的依据。

团队角色方面，量产验证通常由验证经理统筹，下设系统验证工程师、软件测试工程师、硬件/信号完整性工程师、功能安全工程师、EMC/环境试验工程师、自动化测试开发工程师，以及与芯片原厂（Renesas FAE）、Tier1、OEM 的接口人。角色之间通过需求、缺陷、变更三条主线协同，避免“测试发现问题但无人闭环”。

完整 V 模型流程是本章的主线。左侧下行：整车需求 → 系统需求 → 子系统/域需求 → 软硬件详细设计 → 实现。右侧上行：单元测试 → 集成测试 → 系统测试 → 整车验证 → 验收与量产签署。每一层右侧验证都对应左侧同层需求，形成双向追溯。对 R-Car 项目而言，左侧要特别关注 SoC 资源分配、Hypervisor 分区、安全岛（如 R-Car 的锁步核）设计；右侧则要在 HIL、台架、实车三个层级逐步放大验证范围。

把 V 模型落到 R-Car 项目，关键是“左侧需求可分解、右侧验证可追溯”。例如整车要求“倒车影像 200 ms 内显示”，系统需求会分解为摄像头采集 ≤ 50 ms、SoC 图像处理 ≤ 80 ms、显示输出 ≤ 70 ms；右侧对应在单元测试验证 ISP 驱动、集成测试验证 MIPI 到 eDP 通路、系统测试用高速相机测量端到端延迟、整车验证在实车倒车场景复测。只有每一层都有对应证据，量产签署才站得住脚。