049、车载Camera系统设计：HDR与LED闪烁抑制、ISO 26262功能安全与ASIL等级

049、车载Camera系统设计HDR与LED闪烁抑制、ISO 26262功能安全与ASIL等级去年夏天某Tier1客户半夜打来电话说他们的环视系统在隧道出口遇到对向车道的大众车LED尾灯在图像上直接消失了。不是变暗是彻底消失像被PS掉一样。我第一反应是HDR融合出了问题但看了log才发现问题出在LED闪烁抑制和HDR曝光策略的冲突上。这种问题在实验室很难复现因为实验室的LED灯是直流供电的而车灯用的是PWM调光频率从90Hz到400Hz不等。车载Camera和手机Camera最大的区别在于手机拍坏了可以重拍车载每一帧都是生死攸关的证据。HDR在这里不是为了让照片更好看而是为了让系统在极端动态场景下依然能看清路况。但HDR的多帧合成策略恰恰和LED闪烁抑制存在天然矛盾。HDR与LED闪烁抑制的博弈车载HDR通常采用交错式长短曝光方案。长帧负责暗部细节短帧负责高光区域。问题在于LED灯以PWM方式工作一个周期内亮灭交替。如果长帧曝光时间覆盖了多个PWM周期LED的亮度会被平均化看起来还算正常。但短帧曝光时间短可能只拍到LED的亮态或灭态这就导致合成后的图像里LED要么过曝成一片白要么完全消失。我见过最坑的方案是某供应商把短帧曝光时间设成1/10000秒正好和某些车型的LED尾灯PWM频率形成拍频。结果就是每隔几帧LED就消失一次像在闪烁。这种问题在车规级测试里属于严重缺陷因为后车尾灯是前车状态的重要指示。解决思路有两个方向。一是让所有帧的曝光时间都大于LED的PWM周期但这会限制HDR的动态范围。二是采用相位对齐技术让曝光窗口和LED的亮态对齐。实际工程中我们更倾向于第一种方案的变种——用长帧做主要成像短帧只用来恢复高光区域的纹理不参与LED区域的合成。这里有个关键点需要在ISP里做LED区域检测把LED灯的位置标记出来单独处理。代码层面LED闪烁抑制的算法通常放在HDR融合之前。伪代码大概长这样// 这里踩过坑先做LED检测再做HDR融合否则融合后的伪影会干扰检测voidhdr_with_led_mitigation(uint16_t*short_frame,uint16_t*long_frame,uint16_t*output){// 别这样写直接对全图做HDR融合// 应该先检测LED区域led_mask_tled_maskdetect_led_regions(long_frame);for(inty0;yheight;y){for(intx0;xwidth;x){if(led_mask.data[y][x]){// LED区域只用长帧数据避免短帧的闪烁output[y][x]long_frame[y][x];}else{// 非LED区域正常HDR融合output[y][x]hdr_merge(short_frame[y][x],long_frame[y][x]);}}}}这个方案的问题在于LED区域检测的准确率直接影响效果。如果误检会把正常的高光区域也当成LED导致细节丢失。如果漏检LED闪烁问题依然存在。我们最终采用了一种基于时域统计的方法连续多帧检测LED的亮度变化模式只有符合PWM特征的区域才被标记。ISO 26262功能安全与ASIL等级说到功能安全我得坦白刚入行时觉得这就是一堆文档和流程和实际调试关系不大。直到有一次一个客户的ADAS系统在高速上因为Camera的ISP输出了一帧全黑图像导致AEB没有触发。虽然最后查出来是电源纹波问题但整个项目组被功能安全审计折腾了三个月。ISO 26262把汽车功能安全分为ASIL A、B、C、D四个等级D是最严格的。车载Camera系统通常要求ASIL B或ASIL C具体取决于应用场景。环视系统一般是ASIL B前视ADAS摄像头可能要求ASIL C甚至ASIL D。功能安全的核心不是让系统不出错而是让系统在出错时能安全地降级或报警。对于Camera系统这意味着需要监控sensor、ISP、传输链路等各个环节的健康状态。sensor级别的安全机制包括像素失效检测、帧同步丢失检测、温度监控。ISP级别的安全机制包括数据完整性校验CRC、处理延迟监控、输出一致性检查。传输链路的安全机制包括MIPI的CRC校验、数据重传机制。实际项目中我们遇到最多的问题是sensor的帧同步丢失。车载环境电磁干扰严重MIPI信号容易受干扰。一旦帧同步丢失ISP会输出乱码或者重复上一帧。功能安全要求在这种情况下系统必须在100ms内检测到异常并发出警告。检测方法是在每一帧的帧头插入一个特定的同步码ISP收到后校验。如果连续几帧都校验失败就判定为帧同步丢失。这里有个细节同步码不能太简单否则容易被噪声模仿。我们用的是伪随机序列每帧变化。// 这里踩过坑同步码不能固定否则容易被干扰信号冒充uint32_tgenerate_sync_code(uint32_tframe_id){// 别这样写return 0xAAAAAAAA;// 应该用frame_id做种子生成伪随机序列uint32_tseedframe_id^0x5A5A5A5A;returnpseudo_random(seed);}boolcheck_sync_code(uint32_treceived,uint32_texpected){if(received!expected){// 记录错误但不立即触发安全机制防止误报error_counter;if(error_counterSYNC_ERROR_THRESHOLD){// 触发安全降级trigger_safety_degradation();returnfalse;}}else{error_counter0;}returntrue;}ASIL等级的确定不是拍脑袋的需要做危害分析和风险评估HARA。比如前视Camera如果失效可能导致AEB不工作危害等级高所以要求ASIL C。环视Camera失效驾驶员还能通过后视镜观察危害等级低ASIL B就够了。但实际项目中很多客户会要求所有Camera都做到ASIL B以上因为供应链统一管理方便。这导致成本上升但没办法车规级的东西安全第一。系统设计的权衡车载Camera系统设计本质上是在性能、成本、安全之间找平衡。HDR和LED闪烁抑制的冲突就是性能和安全的博弈。功能安全要求冗余和监控这增加了芯片面积和功耗。我见过一个极端的案例某供应商为了满足ASIL C在ISP里加了三个独立的监控模块结果芯片面积增加了30%功耗增加了50%散热成了大问题。最后不得不降级到ASIL B因为散热问题在车载环境里更致命。实际调试中我总结了几条经验HDR的曝光策略要根据应用场景调整。前视Camera需要更大的动态范围120dB以上因为要应对隧道出入口。环视Camera动态范围可以小一些100dB左右但需要更好的LED闪烁抑制。LED闪烁抑制不能只靠算法硬件上也要配合。选择sensor时要看它的HDR模式是否支持LED闪烁抑制。有些sensor有专门的LED闪烁抑制模式通过调整曝光时序来实现。功能安全的实现要分层次。sensor层、ISP层、系统层各司其职。不要试图在一个层次解决所有问题否则会导致系统过于复杂反而降低可靠性。最后也是最重要的所有功能安全的机制都要经过实际路测验证。实验室里跑一万次没问题上路可能第一次就出问题。车载环境太复杂了电磁干扰、温度变化、振动这些因素在实验室很难完全模拟。有一次我们在吐鲁番做高温路测环境温度45度车内温度70度。sensor的温度保护机制触发了自动降低了帧率。功能安全模块检测到帧率异常以为是故障触发了安全降级整个系统重启了。这就是典型的过度设计安全机制之间没有做好协调。所以做车载Camera系统既要懂技术也要懂场景。HDR不是越强越好功能安全不是越严格越好。一切都要回归到实际应用场景回归到驾驶员和乘客的安全。