011、车载影像系统架构：环视/前视/DMS/OMS多路输入管理与ISP资源调度

011、车载影像系统架构：环视/前视/DMS/OMS多路输入管理与ISP资源调度

昨晚在台架上调一个环视拼接的案子，客户报了个现象：车速过了60km/h，左右两侧的拼接缝就开始“呼吸”——亮度忽明忽暗，偶尔还闪一下。我第一反应是ISP的AE没锁住，查了一圈发现根本不是AE的问题，是ISP的带宽被前视的HDR占掉了，环视的tone mapping被挤到低优先级，每帧的曝光曲线都在抖。这种问题，你在单路摄像头的开发板上永远复现不出来，只有把四路环视、一路前视、一颗DMS、一颗OMS全挂上去，带宽一抢，问题就现形了。

车载影像和手机最大的区别在于：手机是单摄或多摄但同一时刻只有一两路在跑，车载是七路八路同时在线，每一路都有硬实时要求。环视要30fps不能掉帧，前视要60fps且延迟不能超过两个帧周期，DMS/OMS可以稍微宽松一点但也不能卡顿。这就逼着你在架构设计阶段就要把ISP的资源账算清楚，而不是等板子回来了再调。

多路输入管理的第一个坑：MIPI CSI端口的分配

高通平台一般有多个CSI接口，每个CSI又可以虚拟出多个virtual channel。海思的方案是MIPI_TX/RX的lane可以灵活配置，瑞芯微的CSI host数量有限但每个host支持多路复用。很多工程师上来就按芯片手册的推荐配置把端口分了，结果发现环视的四路摄像头因为sensor型号不同，有的输出RAW10，有的输出RAW12，导致CSI的data type不一致，virtual channel没法共用同一组lane。

我踩过的坑是：环视四路用了同一款sensor，但其中一路因为走线过长信号质量差，被迫把lane rate降下来，结果这一路的带宽占用反而比其它三路都高，因为降速率就得加blanking，实际有效带宽反而被吃掉了。后来改成把这一路单独分配一组CSI lane，其它三路共享一组，问题才解决。

所以端口分配的原则不是看sensor数量，而是看每路sensor的实际带宽需求、lane rate配置、以及是否支持virtual channel。别迷信参考设计，参考设计用的是理想走线，你的PCB不一定能复现。

ISP资源调度的核心：不是算力，是带宽和延迟

很多人以为ISP资源调度就是看TOPS或者Mpixels/s，实际量产中卡脖子的往往是三样东西：DDR带宽、ISP pipeline的帧间延迟、以及多路并发时的优先级抢占。

以高通的Spectra为例，它内部有多个ISP core，但共享同一套DDR总线。环视四路30fps 1080p，每路RAW10，算下来每帧大概4MB，四路就是16MB，30fps就是480MB/s的写入。前视如果是800万像素60fps RAW12，单路就要1.2GB/s。再加上DMS/OMS各一路720p，总共轻松超过2GB/s。这还没算ISP内部处理时的中间buffer读写，实际带宽需求要乘以2到3倍。

海思的平台稍微好一点，它的ISP有独立的DDR通道，但代价是内存分配要提前规划，不能动态申请。瑞芯微的RK3588在带宽上比较紧张，多路并发时经常要降分辨率或者降帧率来换带宽。

我的经验是：在架构设计阶段就要把每路sensor的带宽算清楚，然后留出30%的余量。别信芯片厂商说的“支持8路4K”，那是理论峰值，实际跑起来你连6路1080p都未必稳。

优先级抢占：前视永远最高，但环视不能饿死

车载影像的优先级排序一般是：前视（ADAS功能） > 环视（泊车/拼接） > DMS/OMS（驾驶员监控）。这个排序没错，但问题在于“饿死”现象——前视的HDR处理如果占用了太多ISP的tone mapping资源，环视的AE就会抖动，因为环视的ISP pipeline被降级了。

我见过一个案子，前视在强光场景下触发HDR的3帧合成，瞬间ISP负载飙到90%，环视的ISP被挤到只剩10%的资源，结果环视的画面亮度每帧都在跳，拼接缝的亮度差肉眼可见。

解决办法有两个方向：一是给环视单独分配一个ISP core（如果芯片支持），二是给环视的ISP pipeline设置固定的时间片或者带宽配额。高通平台可以用icb（interconnect）的QoS设置来限制前视的带宽占用上限，海思平台可以用ISP的sched策略来保证环视的最低帧率。

但这里有个坑：QoS设置不能一刀切。你把前视的带宽上限卡死了，前视在极端场景下可能丢帧，ADAS功能直接失效。所以要做动态调节——前视正常时给足带宽，前视触发HDR时临时提高上限，但环视的最低带宽保障不能破。

DMS/OMS的低功耗设计：别让它们抢主ISP

DMS和OMS通常不需要全时高帧率，但它们在行车过程中必须保持工作。很多架构师把DMS/OMS直接挂在主ISP上，简单省事，但代价是主ISP的功耗和带宽都被占掉一部分。

我的建议是：如果芯片有独立的低功耗ISP（比如高通的BCAM或者海思的IVP），优先把DMS/OMS挂上去。如果没有，就把DMS/OMS的分辨率降到720p，帧率降到15fps，并且用ROI裁剪只处理驾驶员面部区域。这样既满足功能需求，又不给主ISP添乱。

另一个坑是DMS/OMS的IR LED补光。IR LED的开关频率如果和ISP的曝光时间不同步，画面会出现频闪。这个在架构设计时就要考虑——IR LED的驱动信号最好由ISP的PWM输出控制，而不是由MCU或者AP直接控制，否则你调同步要调死。

多路sensor的同步问题：不是所有场景都需要硬件同步

环视拼接需要四路sensor的曝光时间严格同步，否则拼接处的运动物体会错位。前视和环视之间不需要同步，但前视和DMS之间可能需要时间戳对齐，因为ADAS的决策要融合驾驶员状态。

硬件同步的方案是用sensor的master/slave模式，master输出FSYNC，slave跟着走。这个在高通和海思平台上都有支持，但坑在于：不同sensor的FSYNC时序要求不一样，有的需要外部触发，有的需要内部PLL锁定。你混用不同型号的sensor时，同步信号可能对不上。

我踩过的坑是：环视四路用了同一款sensor，但其中一路的FSYNC走线过长，信号质量差，导致这一路的曝光时间偶尔跳变。后来在PCB layout时把FSYNC走线加粗、加屏蔽，问题才解决。

如果硬件同步实在搞不定，可以用软件同步——在ISP的VSYNC中断里做时间戳对齐，然后对图像做motion compensation。但这是下策，能硬件同步就别软件同步。

量产阶段的ISP资源调优：别只看实验室数据

实验室里跑得好好的，一到产线上就出问题，这是车载影像的常态。原因很简单：产线上的sensor个体差异大，ISP的调优参数如果太激进，就会在边缘sensor上翻车。

比如AE的收敛速度，实验室里用同一颗sensor调好了，产线上换一批sensor，可能因为暗电流差异导致AE在低照度下收敛慢。这时候你要么放宽AE的收敛阈值，要么在产线校准阶段对每颗sensor做单独的AE补偿。

ISP资源调度也一样。实验室里你用的是开发板，内存带宽充足，产线上用的是量产板，DDR频率可能被降了，或者内存颗粒的时序参数不一样，导致带宽实际比实验室低10%到15%。你按实验室的数据配的带宽配额，到产线上就可能不够用。

我的习惯是：在架构设计阶段就把量产余量算进去，带宽按80%的利用率设计，ISP负载按70%的峰值设计，剩下的余量留给产线差异和极端场景。

最后说点实在的

车载影像的ISP资源调度，本质上是做资源预算和优先级管理。你不需要把每个ISP的细节都吃透，但你必须清楚每路sensor的带宽需求、每路pipeline的延迟预算、以及芯片平台的优先级抢占机制。这三样搞清楚了，架构就不会出大问题。

如果你正在做多路车载影像的架构设计，我建议你先把下面这张表画出来：每路sensor的分辨率、帧率、RAW bit数、带宽需求、ISP pipeline的延迟预算、优先级、以及是否允许降级。画完这张表，你就能看出哪些路可以共享ISP资源，哪些路必须独占。

别一上来就堆算力，车载影像的瓶颈从来不是算力，是带宽和调度。算力不够可以降分辨率，带宽不够你连帧都送不进来。