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四路就是16MB30fps就是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设置固定的时间片或者带宽配额。高通平台可以用icbinterconnect的QoS设置来限制前视的带宽占用上限海思平台可以用ISP的sched策略来保证环视的最低帧率。但这里有个坑QoS设置不能一刀切。你把前视的带宽上限卡死了前视在极端场景下可能丢帧ADAS功能直接失效。所以要做动态调节——前视正常时给足带宽前视触发HDR时临时提高上限但环视的最低带宽保障不能破。DMS/OMS的低功耗设计别让它们抢主ISPDMS和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输出FSYNCslave跟着走。这个在高通和海思平台上都有支持但坑在于不同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资源哪些路必须独占。别一上来就堆算力车载影像的瓶颈从来不是算力是带宽和调度。算力不够可以降分辨率带宽不够你连帧都送不进来。