1. R-Car平台与车载AI推理概览

在智能汽车从“分布式ECU”走向“中央计算+区域控制”的过程中，Renesas R-Car 系列承担了一个非常关键的角色：它既是车载信息娱乐与座舱域的主流SoC平台，也是承载摄像头感知、驾驶员监控、多模态融合与边缘AI推理的重要算力节点。理解R-Car平台与车载AI推理的关系，是后续所有工程实践的前提。

一、R-Car产品线的定位：从座舱到中央计算

R-Car并不是单一芯片，而是一条按算力、功能安全等级和集成度分层的SoC产品线。工程上通常按“代际+定位”来理解：

• R-Car H系列（如H3、H3e）：面向高性能座舱与多屏显示，集成多核Cortex-A、GPU与视频编解码，适合作为座舱域主控，也可承担轻量AI推理。
• R-Car M系列：中端定位，兼顾仪表、座舱与部分ADAS功能，功耗与成本更友好。
• R-Car V系列（如V3M、V3H、V4H）：面向ADAS/自动驾驶感知，内置专用图像处理与AI加速单元（如IMP-X5、CNN加速器），是车载AI推理的核心平台。
• R-Car S系列：面向车载网关与中央通信，强调网络与安全。
• R-Car X系列 / 新一代R-Car：面向软件定义汽车的中央计算架构，支持多域融合与更高AI算力。

对AI推理工程而言，最需要关注的是V系列与H系列：前者提供面向感知的专用加速器，后者提供通用CPU/GPU算力。两者在推理部署路径、内存带宽、算子支持上差异明显，选型时不能只看TOPS数字。

二、车载AI推理场景：不是“跑个模型”那么简单

车载AI推理与服务器推理的最大区别在于：输入是实时多路传感器，输出要直接参与车辆行为或人机交互，且必须在确定的时延、功耗和温度范围内稳定运行。典型场景包括：

• 前视感知：车道线、车辆、行人、交通标志检测，通常要求30fps以上、端到端时延低于100ms。
• 驾驶员监控（DMS）：视线、闭眼、打哈欠、分心识别，输入为红外摄像头，模型轻量但对帧率稳定性要求高。
• 舱内多模态：语音唤醒、手势识别、乘员检测，常与座舱SoC共享算力。
• 环视与泊车：鱼眼图像畸变校正+目标检测，对内存带宽和预处理要求高。
• 多传感器融合：摄像头+雷达+超声波，推理结果需与融合模块协同。

这些场景共同决定了R-Car上的AI推理必须解决三个工程问题：模型如何适配专用加速器、数据如何在CPU/GPU/NPU之间高效流动、结果如何以确定时延输出。

三、边缘计算在智能汽车中的角色

边缘计算在车内的本质，是把“感知—推理—决策”尽量放在数据产生的地方完成，而不是全部上传云端。原因有三：

1. 时延：刹车、避障等场景无法接受云端往返的数百毫秒延迟。
2. 带宽：多路高清摄像头原始数据量巨大，全部上传不现实。
3. 可靠性与隐私：隧道、地库等弱网环境下必须本地可用；舱内视频涉及隐私，不宜外传。

因此，R-Car在整车电子电气架构中通常处于“区域/域控制器”位置：向下连接摄像头、雷达、麦克风等传感器，向上通过车载以太网与中央计算或云端交互。AI推理就发生在这一层，形成“传感器→预处理→推理→后处理→控制/显示”的本地闭环。

四、课程整体工程目标

本课程不是泛泛介绍R-Car的规格，而是围绕“把AI模型真正部署到R-Car上并稳定运行”这一目标展开。学完后，你应当能够独立完成以下工程任务：

1. 选型与评估：根据场景的算力、时延、功耗和功能安全要求，判断该用V系列还是H系列，以及需要多少内存带宽。
2. 模型适配：把训练好的模型（如YOLO、MobileNet、轻量Transformer）转换为R-Car加速器支持的格式，完成量化、算子替换与精度校验。
3. 推理管线搭建：在R-Car上实现“摄像头采集→预处理→推理→后处理→输出”的完整链路，并控制各阶段耗时。
4. 性能调优：通过批处理、内存复用、多核调度、DMA等手段，把端到端时延压到目标范围内。
5. 验证与排障：用日志、时间戳、温度与功耗数据判断瓶颈，定位精度下降或帧率抖动的根因。

五、一个典型推理链路的耗时分解示例

为了建立“时延预算”的概念，下面给出一个前视感知场景的教学示例。假设输入为1920×1080@30fps，模型为INT8量化的轻量检测网络，部署在R-Car V系列上：

这张表的意义在于：当端到端时延超标时，你能快速判断是预处理太重、推理太慢，还是后处理拖了后腿，而不是盲目换芯片或降模型。后续章节会逐一展开每个阶段的实现与优化方法。