015、影像系统功能安全架构ISO 26262 ASIL-B/C在ISP链路中的硬件隔离设计去年年底有个项目车规级前视摄像头主芯片是某家旗舰SoCISP内置。客户提了个需求ISP链路里要过ASIL-B最好给C留余量。当时我们觉得问题不大毕竟芯片原厂说支持。结果一测A/B核之间共享DDR带宽A核跑ISP管线B核跑神经网络带宽一高ISP的统计引擎就丢数据直接触发安全机制整机复位。产线上一批板子有的好有的坏查了三天最后定位到是DDR仲裁策略在不同温度下时序漂移。你说这算功能安全设计问题还是硬件一致性问题都算。从那以后我就明白ISO 26262在ISP链路上落地不是画个框图、标个ASIL等级就完事是要跟芯片内部的物理隔离、总线仲裁、时钟域、甚至DDR的QoS策略死磕的。先泼盆冷水很多芯片原厂的Safety Manual写得天花乱坠但真正到ISP这条链路上你会发现所谓的“ASIL-B支持”往往是指标定的、配置的、统计的路径而像素数据通路本身——从sensor输入到ISP核心处理再到输出——经常是“QM”或者“ASIL-A”的灰色地带。为什么因为像素数据是流式的没法像CPU那样做lockstep也没法像GPU那样做CRC校验后重放。你只能做监控、做隔离、做降级但很难做完整的冗余计算。所以架构上第一刀就要切清楚哪些模块必须达到ASIL-B/C哪些模块可以接受QM但必须要有监控机制。我见过不少团队一上来就把整个ISP管线都要求成ASIL-B结果发现硬件资源根本不够或者延迟预算爆表。正确的做法是“功能安全分区”——把ISP链路拆成三块安全关键路径、安全相关监控路径、非安全路径。安全关键路径包括曝光控制、增益控制、黑电平校正、坏点校正、Gamma校正如果影响AEB或车道线检测、以及输出给安全ECU的YUV/RGB数据。安全相关监控路径包括帧丢失检测、像素数据CRC、统计引擎的校验、时钟和电源监控。非安全路径就是那些3A统计里的色彩偏好、降噪强度、HDR合成参数——这些错了不会直接导致安全事故但会影响体验所以可以放在QM域。硬件隔离设计上最核心的是“物理隔离优先于逻辑隔离”。什么意思如果芯片允许把安全关键模块放在独立的电源域、独立的时钟域、独立的总线主端口上。比如海思平台ISP的统计引擎和图像信号处理核心可以分属不同的AXI端口这样即使统计引擎被攻击或者出错也不会阻塞图像数据通路。高通Spectra这边你去看它的Safety Manual会提到“ISP Safe Mode”但这个模式是要牺牲性能的——它会把部分处理单元降频或者旁路换取更简单的数据流和更可预测的时序。别小看这个真到量产阶段你会发现“可预测的时序”比“高性能”值钱得多。这里踩过坑我们曾经在联发科Imagiq平台上做ASIL-B设计原厂说支持硬件隔离结果发现它的ISP和MDP显示处理共享同一个MMU页表。我们做了软件层面的地址隔离但硬件上如果MDP侧发生非法访问会污染TLB导致ISP的页表项被逐出然后ISP取指失败整个管线挂掉。最后没办法只能把MDP关掉用GPU做显示合成才勉强过了安全评审。所以做架构选型的时候一定要问原厂一个问题“ISP和哪些模块共享MMU共享总线仲裁器共享电源域”这三个问题的答案决定了你的隔离设计是纸面功夫还是真能落地。再说说ASIL-B和ASIL-C在ISP链路里的差异。ASIL-B要求单点故障度量SPFM≥90%潜在故障度量LFM≥60%ASIL-C要求SPFM≥97%LFM≥80%。听起来只是数字差别但落实到硬件上意味着ASIL-C需要更细粒度的监控。比如ASIL-B下你可以在ISP输出端做整帧CRC帧率30fps每帧校验一次够了。但ASIL-C下你可能需要在ISP管线内部的关键节点——比如黑电平校正之后、去马赛克之后、降噪之后——分别插入CRC或checksum而且这些校验逻辑本身也要有诊断覆盖。这就不是加几个寄存器的事了是要改RTL的。所以我的建议是除非客户强制要求ASIL-C否则ISP链路做到ASIL-B是性价比最高的。ASIL-C留给SoC外部的独立安全MCU去做最终决策比如AEB触发、EPS转向指令这些不在ISP内部做。硬件隔离设计里还有个容易忽略的点中断和DMA。ISP处理完一帧会通过DMA写到DDR然后发中断给CPU。如果这个中断路径被干扰或者DMA描述符被篡改CPU可能拿到错误的数据却以为是对的。所以安全架构里DMA描述符必须放在受保护的SRAM里并且要有独立的CRC保护。中断控制器那边要给ISP的安全关键中断分配独立的优先级和CPU亲和性别让它和普通中断混在一起。我们之前有个项目ISP的帧同步中断和GPU的中断共享同一个GIC分发器结果GPU负载高的时候中断延迟抖动达到几百微秒导致ISP的帧率不稳定触发了安全监控的看门狗。后来把ISP中断绑到独立CPU核上并且设置了不可屏蔽属性问题才解决。时钟和电源的隔离这个在车规里特别重要。ISP的像素时钟通常来自PLL如果PLL因为温度漂移或者电压波动产生抖动轻则图像条纹重则触发安全机制。ASIL-B设计里至少要有独立的时钟监控单元CMU实时检测ISP时钟的频率偏差超过±2%就要报错并降级。电源域方面如果ISP和GPU共享同一个PMIC的LDO那GPU的瞬态电流会拉低电压导致ISP的模拟电路比如ADC工作异常。我们量产时遇到过低温冷启动GPU初始化瞬间电流冲击ISP的暗电流校准值漂移导致图像偏色安全监控误报。后来在PMIC配置里把ISP的供电改成独立的buck并且加了软启动才算稳定。再讲一个实战里最容易被忽视的sensor和ISP之间的MIPI链路。这条链路是模拟前端最容易受电磁干扰。ASIL-B设计里MIPI的CRC和ECC是必须的但光有CRC不够——CRC只能检测错误不能纠正。如果CRC错误率超过阈值你要有降级策略比如从4 lane降到2 lane或者降低帧率或者切换到内部测试图案。我们有个项目客户要求ASIL-B但sensor是外购的MIPI的CRC实现有bug错误检测不到。最后我们只能在ISP侧加了额外的行缓冲校验用软件比对相邻行的像素统计特征才勉强满足诊断覆盖。所以选sensor的时候别只看分辨率和高动态范围一定要看它的MIPI输出是否支持完整的CRC和ECC以及错误上报机制是否符合ISO 26262的“安全机制”定义。软件层面隔离设计要配合“安全状态管理”。ISP链路里安全状态不是只有“正常”和“故障”两个状态而是要有多个降级等级。比如等级0全功能等级1关闭HDR和降噪只保留基础曝光和增益等级2切换到测试图案输出不再处理真实sensor数据等级3完全关闭ISP由外部安全MCU接管。每个等级之间的切换要有明确的触发条件和时间预算。我们设计时等级1的切换要在1帧内完成33ms等级2要在3帧内完成等级3要100ms内完成。这些时间预算要写进安全概念文档里并且通过故障注入测试验证。别信原厂说“支持快速降级”自己拿示波器量一下从故障发生到ISP输出稳定到底花了多少毫秒。最后说点个人经验。第一功能安全架构设计一定要在项目立项阶段就介入别等芯片选型定了再补。因为硬件隔离能力是芯片决定的软件只能做逻辑隔离而逻辑隔离在ASIL-B以上很难满足诊断覆盖。第二别迷信原厂的Safety Manual那东西是给认证机构看的不是给你做设计用的。你要自己画一张“ISP链路数据流图”标出每个节点的故障模式、检测机制、降级路径这张图才是你真正的设计依据。第三量产阶段一定要做“故障注入测试”不是只在实验室做要在产线上抽测。我们后来在产线上加了一个测试模式通过寄存器强制注入像素错误、DMA错误、时钟错误验证安全监控是否能在规定时间内响应。这个测试每台机器跑一遍大概多花3秒钟但能避免很多售后问题。功能安全在ISP链路上说白了就是“用硬件冗余换确定性用监控机制换诊断覆盖用降级策略换可用性”。别想着用软件补硬件的坑也别想着用硬件堆料掩盖架构的缺陷。先把数据流画清楚把故障模式列全再谈隔离设计。这条路没有捷径但走通了你的系统在产线上会非常稳。
015、影像系统功能安全架构ISO 26262 ASIL-B/C在ISP链路中的硬件隔离设计去年年底有个项目车规级前视摄像头主芯片是某家旗舰SoCISP内置。客户提了个需求ISP链路里要过ASIL-B最好给C留余量。当时我们觉得问题不大毕竟芯片原厂说支持。结果一测A/B核之间共享DDR带宽A核跑ISP管线B核跑神经网络带宽一高ISP的统计引擎就丢数据直接触发安全机制整机复位。产线上一批板子有的好有的坏查了三天最后定位到是DDR仲裁策略在不同温度下时序漂移。你说这算功能安全设计问题还是硬件一致性问题都算。从那以后我就明白ISO 26262在ISP链路上落地不是画个框图、标个ASIL等级就完事是要跟芯片内部的物理隔离、总线仲裁、时钟域、甚至DDR的QoS策略死磕的。先泼盆冷水很多芯片原厂的Safety Manual写得天花乱坠但真正到ISP这条链路上你会发现所谓的“ASIL-B支持”往往是指标定的、配置的、统计的路径而像素数据通路本身——从sensor输入到ISP核心处理再到输出——经常是“QM”或者“ASIL-A”的灰色地带。为什么因为像素数据是流式的没法像CPU那样做lockstep也没法像GPU那样做CRC校验后重放。你只能做监控、做隔离、做降级但很难做完整的冗余计算。所以架构上第一刀就要切清楚哪些模块必须达到ASIL-B/C哪些模块可以接受QM但必须要有监控机制。我见过不少团队一上来就把整个ISP管线都要求成ASIL-B结果发现硬件资源根本不够或者延迟预算爆表。正确的做法是“功能安全分区”——把ISP链路拆成三块安全关键路径、安全相关监控路径、非安全路径。安全关键路径包括曝光控制、增益控制、黑电平校正、坏点校正、Gamma校正如果影响AEB或车道线检测、以及输出给安全ECU的YUV/RGB数据。安全相关监控路径包括帧丢失检测、像素数据CRC、统计引擎的校验、时钟和电源监控。非安全路径就是那些3A统计里的色彩偏好、降噪强度、HDR合成参数——这些错了不会直接导致安全事故但会影响体验所以可以放在QM域。硬件隔离设计上最核心的是“物理隔离优先于逻辑隔离”。什么意思如果芯片允许把安全关键模块放在独立的电源域、独立的时钟域、独立的总线主端口上。比如海思平台ISP的统计引擎和图像信号处理核心可以分属不同的AXI端口这样即使统计引擎被攻击或者出错也不会阻塞图像数据通路。高通Spectra这边你去看它的Safety Manual会提到“ISP Safe Mode”但这个模式是要牺牲性能的——它会把部分处理单元降频或者旁路换取更简单的数据流和更可预测的时序。别小看这个真到量产阶段你会发现“可预测的时序”比“高性能”值钱得多。这里踩过坑我们曾经在联发科Imagiq平台上做ASIL-B设计原厂说支持硬件隔离结果发现它的ISP和MDP显示处理共享同一个MMU页表。我们做了软件层面的地址隔离但硬件上如果MDP侧发生非法访问会污染TLB导致ISP的页表项被逐出然后ISP取指失败整个管线挂掉。最后没办法只能把MDP关掉用GPU做显示合成才勉强过了安全评审。所以做架构选型的时候一定要问原厂一个问题“ISP和哪些模块共享MMU共享总线仲裁器共享电源域”这三个问题的答案决定了你的隔离设计是纸面功夫还是真能落地。再说说ASIL-B和ASIL-C在ISP链路里的差异。ASIL-B要求单点故障度量SPFM≥90%潜在故障度量LFM≥60%ASIL-C要求SPFM≥97%LFM≥80%。听起来只是数字差别但落实到硬件上意味着ASIL-C需要更细粒度的监控。比如ASIL-B下你可以在ISP输出端做整帧CRC帧率30fps每帧校验一次够了。但ASIL-C下你可能需要在ISP管线内部的关键节点——比如黑电平校正之后、去马赛克之后、降噪之后——分别插入CRC或checksum而且这些校验逻辑本身也要有诊断覆盖。这就不是加几个寄存器的事了是要改RTL的。所以我的建议是除非客户强制要求ASIL-C否则ISP链路做到ASIL-B是性价比最高的。ASIL-C留给SoC外部的独立安全MCU去做最终决策比如AEB触发、EPS转向指令这些不在ISP内部做。硬件隔离设计里还有个容易忽略的点中断和DMA。ISP处理完一帧会通过DMA写到DDR然后发中断给CPU。如果这个中断路径被干扰或者DMA描述符被篡改CPU可能拿到错误的数据却以为是对的。所以安全架构里DMA描述符必须放在受保护的SRAM里并且要有独立的CRC保护。中断控制器那边要给ISP的安全关键中断分配独立的优先级和CPU亲和性别让它和普通中断混在一起。我们之前有个项目ISP的帧同步中断和GPU的中断共享同一个GIC分发器结果GPU负载高的时候中断延迟抖动达到几百微秒导致ISP的帧率不稳定触发了安全监控的看门狗。后来把ISP中断绑到独立CPU核上并且设置了不可屏蔽属性问题才解决。时钟和电源的隔离这个在车规里特别重要。ISP的像素时钟通常来自PLL如果PLL因为温度漂移或者电压波动产生抖动轻则图像条纹重则触发安全机制。ASIL-B设计里至少要有独立的时钟监控单元CMU实时检测ISP时钟的频率偏差超过±2%就要报错并降级。电源域方面如果ISP和GPU共享同一个PMIC的LDO那GPU的瞬态电流会拉低电压导致ISP的模拟电路比如ADC工作异常。我们量产时遇到过低温冷启动GPU初始化瞬间电流冲击ISP的暗电流校准值漂移导致图像偏色安全监控误报。后来在PMIC配置里把ISP的供电改成独立的buck并且加了软启动才算稳定。再讲一个实战里最容易被忽视的sensor和ISP之间的MIPI链路。这条链路是模拟前端最容易受电磁干扰。ASIL-B设计里MIPI的CRC和ECC是必须的但光有CRC不够——CRC只能检测错误不能纠正。如果CRC错误率超过阈值你要有降级策略比如从4 lane降到2 lane或者降低帧率或者切换到内部测试图案。我们有个项目客户要求ASIL-B但sensor是外购的MIPI的CRC实现有bug错误检测不到。最后我们只能在ISP侧加了额外的行缓冲校验用软件比对相邻行的像素统计特征才勉强满足诊断覆盖。所以选sensor的时候别只看分辨率和高动态范围一定要看它的MIPI输出是否支持完整的CRC和ECC以及错误上报机制是否符合ISO 26262的“安全机制”定义。软件层面隔离设计要配合“安全状态管理”。ISP链路里安全状态不是只有“正常”和“故障”两个状态而是要有多个降级等级。比如等级0全功能等级1关闭HDR和降噪只保留基础曝光和增益等级2切换到测试图案输出不再处理真实sensor数据等级3完全关闭ISP由外部安全MCU接管。每个等级之间的切换要有明确的触发条件和时间预算。我们设计时等级1的切换要在1帧内完成33ms等级2要在3帧内完成等级3要100ms内完成。这些时间预算要写进安全概念文档里并且通过故障注入测试验证。别信原厂说“支持快速降级”自己拿示波器量一下从故障发生到ISP输出稳定到底花了多少毫秒。最后说点个人经验。第一功能安全架构设计一定要在项目立项阶段就介入别等芯片选型定了再补。因为硬件隔离能力是芯片决定的软件只能做逻辑隔离而逻辑隔离在ASIL-B以上很难满足诊断覆盖。第二别迷信原厂的Safety Manual那东西是给认证机构看的不是给你做设计用的。你要自己画一张“ISP链路数据流图”标出每个节点的故障模式、检测机制、降级路径这张图才是你真正的设计依据。第三量产阶段一定要做“故障注入测试”不是只在实验室做要在产线上抽测。我们后来在产线上加了一个测试模式通过寄存器强制注入像素错误、DMA错误、时钟错误验证安全监控是否能在规定时间内响应。这个测试每台机器跑一遍大概多花3秒钟但能避免很多售后问题。功能安全在ISP链路上说白了就是“用硬件冗余换确定性用监控机制换诊断覆盖用降级策略换可用性”。别想着用软件补硬件的坑也别想着用硬件堆料掩盖架构的缺陷。先把数据流画清楚把故障模式列全再谈隔离设计。这条路没有捷径但走通了你的系统在产线上会非常稳。
