★ FEATURED ARTICLE 1. 自动驾驶视觉处理器的功能安全到底在解决什么问题1.1 从一个真实的失效场景说起前两年我跟一个做L2域控制器的团队聊他们遇到过一个很典型的问题车辆在高速上开启领航辅助前方有一辆静止的故障车视觉处理器把白色货车车厢和天空的边界识别错了导致AEB没有及时触发。好在驾驶员接管及时没出大事。事后复盘算法本身在离线数据集上的mAP并不低问题出在视觉处理链路在特定光照和对比度条件下出现了系统性误判而系统没有任何机制去发现“我现在可能看错了”。这就是功能安全要解决的核心命题不是让算法更准而是让系统在算法不准的时候依然不会造成不可接受的伤害。这两件事经常被混为一谈。很多做感知的工程师第一反应是“我把模型训得更好不就行了”但功能安全的逻辑是——你永远无法证明一个基于神经网络的感知系统在所有场景下都正确所以你必须在架构层面设计出容错、监控和降级的能力。自动驾驶视觉处理器通常指的是SoC里专门负责图像信号处理ISP、神经网络推理NPU、以及相关后处理的子系统。它可能是一颗独立的芯片也可能是大SoC里的一个IP核。功能安全Functional Safety针对的就是这个子系统在发生随机硬件故障或系统性失效时如何保证输出不会危害到整车安全。1.2 ISO 26262给视觉处理器划定的边界ISO 26262是道路车辆功能安全的国际标准它把安全相关系统按风险等级分为ASIL A到ASIL DD最高。视觉处理器在自动驾驶里通常承担的是环境感知功能这个功能失效的后果可能是漏检、误检进而导致错误的规划控制。按照危害分析和风险评估HARA感知失效通常会被定为ASIL B或ASIL D具体取决于车辆所处的自动驾驶等级和驾驶员是否作为后备。ASIL B是很多L2/L2视觉处理器的目标等级。为什么不是一律ASIL D因为ASIL D对硬件架构指标的要求极其苛刻比如单点故障度量SPFM要≥99%潜伏故障度量LFM要≥90%这对芯片面积、功耗、成本都是巨大压力。ASIL B的要求是SPFM≥90%LFM≥60%在工程上更可落地。很多视觉处理器会采用ASIL B(D)的标注方式意思是芯片本身按ASIL B开发但通过外部安全机制可以支持到ASIL D的系统。这里有个容易踩的坑芯片的ASIL等级不等于系统的ASIL等级。一颗ASIL B的视觉处理器如果外围没有足够的监控和冗余整个感知通道可能连ASIL B都达不到。我见过不少项目在选型时只看芯片手册上的ASIL B忽略了系统级的安全论证到认证阶段才发现要补大量工作。1.3 视觉处理器功能安全的三个核心支柱把视觉处理器的功能安全拆开本质上就三件事第一故障检测。处理器内部要有机制发现自己算错了、内存坏了、数据传输出错了。常见的手段包括锁步核Lockstep、ECC内存、CRC校验、看门狗、以及针对NPU的推理结果一致性检查。第二故障响应。检测到故障后系统要在规定的时间内做出反应通常是降级到安全状态。对于视觉处理器安全状态可能是切换到备用感知通道、限制车速、或者请求驾驶员接管。响应时间必须满足FTTI故障容错时间间隔这个值从HARA里推导出来通常是几百毫秒量级。第三安全论证。所有机制都要有证据链证明它确实能在需要的时候起作用。这包括FMEDA失效模式、影响及其诊断分析、安全案例、以及大量的测试验证。这三根支柱缺一不可。我见过团队把大量精力花在检测机制上结果响应策略没设计好检测到了故障但系统不知道该干什么等于白做。1.4 为什么现在这个话题特别热自动驾驶数据集越来越丰富模型越来越大视觉处理器的算力需求从几TOPS涨到几百TOPS。算力上去了芯片复杂度也上去了功能安全的难度随之指数级上升。以前一个ASIL B的MCU可能就几百万门电路现在一个视觉处理器SoC动辄几十亿晶体管还要集成NPU、ISP、DSP、安全岛FMEDA做起来工作量巨大。另一方面行业对自动驾驶的安全预期在提高。以前L2出事驾驶员背锅现在L2和L3的讨论里系统责任越来越大。视觉处理器作为感知的前端它的功能安全水平直接决定了整车能宣称的自动驾驶等级。这也是为什么ASIL B成了当前量产视觉处理器的主流目标而ASIL D是下一步的竞争焦点。2. 视觉处理器功能安全的核心技术点拆解2.1 硬件层面的安全机制从锁步到ECC视觉处理器里最基础的安全机制是锁步Lockstep。原理很简单两个相同的CPU核跑同样的指令每个周期比较输出不一致就报错。这个机制对随机硬件故障的覆盖率很高但代价是面积翻倍、功耗增加。在视觉处理器里锁步通常用在控制核上比如负责调度和安全监控的Cortex-R系列或类似内核。NPU阵列本身很少做全锁步因为面积代价太大取而代之的是选择性冗余和算法级校验。ECC纠错码是内存和总线的标配。视觉处理器里有很多SRAM缓存用来存特征图、权重、中间结果。这些SRAM如果发生位翻转可能导致推理结果完全错误。ECC能纠正单比特错误、检测双比特错误是ASIL B的硬性要求。我建议在选型时重点关注哪些内存有ECC哪些没有。有些芯片为了省面积只在关键路径上加ECC非关键路径用奇偶校验甚至裸奔这在做FMEDA时要特别小心。CRC循环冗余校验用在数据通路上。比如图像数据从ISP传到NPU中间经过总线如果总线出错CRC能发现。CRC的覆盖范围和多项式选择会影响诊断覆盖率通常需要和芯片厂商确认具体的实现细节。看门狗和超时监控是最容易被低估的机制。视觉处理器的推理任务有严格的时序要求如果某个任务超时可能意味着硬件卡死或软件跑飞。看门狗要能独立于主处理器运行最好放在安全岛里这样即使主处理器挂了看门狗还能触发复位或降级。2.2 NPU推理的安全校验一致性检查与范围监控NPU是视觉处理器里最“黑盒”的部分。神经网络推理的结果没有简单的解析式可以验证所以安全机制的设计思路和传统CPU不同。常见的做法有几种双核冗余推理。用两个NPU核跑同一个网络比较输出。如果输出差异超过阈值就报错。这个方案诊断覆盖率很高但算力翻倍功耗和成本都上去了。实际项目中通常不会对全网络做双核冗余而是对关键子网络做比如目标检测的置信度输出、车道线的拟合参数。时间冗余。同一个NPU跑两次中间间隔一段时间比较结果。这个方案省硬件但实时性差而且如果故障是持续性的两次都会错。通常作为辅助手段。范围监控。对推理输出的数值范围做检查。比如目标检测的边界框坐标应该在图像范围内置信度应该在0到1之间车道线的曲率应该在物理合理范围内。如果输出超出范围说明推理过程可能出了问题。这个机制成本低但只能发现部分故障。输入数据校验。在推理之前检查输入图像的质量。比如亮度是否在合理范围、是否有遮挡、帧率是否正常。如果输入本身有问题推理结果不可信系统应该降级。这个机制经常被忽略但实际上很重要——很多感知失效的根因是输入图像质量差而不是NPU算错了。2.3 安全岛与隔离设计视觉处理器通常有一个安全岛Safety Island里面跑一个独立的安全核负责监控主处理器的状态、执行安全机制、以及在故障时接管控制。安全岛的设计要点是独立性它要有自己的电源、时钟、内存不能和主处理器共享关键资源否则主处理器挂了安全岛也挂了。隔离设计还包括空间隔离和时间隔离。空间隔离是指不同安全等级的任务跑在不同的内存区域MMU/MPU要配置好防止低安全等级的任务篡改高安全等级的数据。时间隔离是指关键任务要有确定性的执行时间不能被非关键任务阻塞。视觉处理器里安全相关的任务比如故障检测、降级决策通常放在安全岛上用独立的RTOS调度确保实时性。我参与过一个项目安全岛和主处理器共享了DDR控制器结果主处理器的大量访存把安全岛的延迟拉高了导致故障响应超时。后来改成安全岛用独立的TCM紧耦合内存问题才解决。这个坑很典型共享资源是功能安全的隐形杀手。2.4 软件层面的安全机制从启动自检到运行时监控硬件机制是基础但软件层面的安全机制同样关键。视觉处理器的软件栈通常包括Bootloader、RTOS或Linux、驱动、中间件、感知算法。每一层都要有安全考虑。启动自检POST在系统上电时运行检查CPU、内存、总线、外设是否正常。POST要覆盖所有安全相关组件并且要有明确的通过/失败判据。我见过POST只检查了CPU没检查NPU结果NPU有故障但系统正常启动运行时才暴露。运行时监控包括任务执行时间监控、内存使用监控、通信超时监控、温度电压监控。这些监控数据要汇总到安全岛由安全岛判断系统是否处于安全状态。端到端保护是指从传感器输入到执行器输出的全链路保护。对于视觉处理器端到端保护意味着图像数据从摄像头到NPU、从NPU到规划控制每一步都要有校验。E2E保护通常用CRC或哈希配合时间戳和序列号防止数据被篡改或重放。安全状态管理是软件层面的核心。系统要定义清楚什么故障对应什么安全状态切换条件是什么切换时间是多少。安全状态可能是“降级到L1”、“限制最高车速”、“点亮故障灯请求接管”。这些策略要和整车厂一起定义不能由芯片或算法团队单方面决定。3. 从零搭建视觉处理器功能安全的实操路径3.1 第一步HARA与安全目标定义任何功能安全项目都从HARA开始。HARA的全称是危害分析和风险评估目的是识别出系统可能造成的危害评估其严重度S、暴露率E、可控性C然后推导出ASIL等级。对于视觉处理器典型的危害场景包括危害场景可能原因严重度暴露率可控性ASIL漏检前方静止车辆视觉误判S3E3C2B误检导致幽灵刹车视觉误判S2E4C2B车道线识别错误导致偏离视觉误判S3E3C2B处理器死机导致感知中断硬件故障S3E2C2B这个表是简化版实际HARA要考虑更多因素比如车速、道路类型、驾驶员状态。ASIL B是视觉处理器常见的目标但如果系统没有驾驶员作为后备比如L4严重度和可控性会上升可能要到ASIL D。安全目标是从HARA推导出来的顶层需求。比如“避免因视觉处理器失效导致非预期的紧急制动”对应的安全状态可能是“在检测到视觉处理器故障后在100ms内关闭AEB功能并点亮故障指示”。安全目标要可验证、可追溯后续的所有设计和测试都要围绕它展开。3.2 第二步技术安全需求分解安全目标确定后要分解成技术安全需求TSR。TSR是具体到硬件和软件层面的需求比如视觉处理器应能检测NPU推理结果的异常诊断覆盖率≥90%视觉处理器应在检测到故障后50ms内通知安全岛安全岛应在收到故障通知后100ms内执行降级策略视觉处理器的关键内存应具备ECC能纠正单比特错误TSR要分配到具体的组件上形成安全架构。这个阶段要和芯片厂商紧密合作因为很多安全机制是芯片内置的你需要知道它的诊断覆盖率、故障响应时间、以及如何配置。我建议在这个阶段做一个安全架构图把视觉处理器、安全岛、传感器、执行器、以及它们之间的通信路径画出来标注每条路径的安全机制和诊断覆盖率。这个图在后续的FMEDA和认证中会反复用到。3.3 第三步FMEDA与诊断覆盖率计算FMEDA是功能安全里最耗时的工作之一。它的目的是分析每个硬件组件的失效模式评估其对安全目标的影响以及现有安全机制能覆盖多少。对于视觉处理器FMEDA通常按模块划分CPU、NPU、ISP、内存、总线、外设。每个模块列出可能的失效模式永久故障、瞬态故障、间歇故障然后分析这个故障是否会导致违反安全目标现有安全机制能否检测到这个故障检测覆盖率是多少诊断覆盖率DC的计算公式是DC 被检测到的故障率 / 总故障率。ASIL B要求SPFM≥90%意味着单点故障和残余故障的总和不能超过10%。这里有个实操难点芯片厂商提供的FMEDA数据往往不完整。很多厂商只给一个汇总的DC值不提供模块级的细节。这时候你需要通过假设验证的方式补充先基于常见实践做假设然后通过故障注入测试来验证。故障注入可以用软件模拟比如篡改内存数据也可以用硬件手段比如激光注入、电压毛刺。后者成本高通常只在关键模块上做。3.4 第四步安全机制的实现与配置安全机制的实现分硬件配置和软件开发两部分。硬件配置方面以一颗典型的视觉处理器为例你需要配置锁步核使能锁步比较配置错误上报路径ECC使能所有安全相关内存的ECC配置错误阈值和上报方式CRC配置数据通路的CRC多项式使能校验看门狗配置超时时间使能独立时钟源安全岛配置安全核的启动流程、监控任务、降级策略软件开发方面你需要实现POST上电自检覆盖所有安全机制运行时监控周期性检查安全机制的状态故障处理故障分类、记录、上报、降级E2E保护在关键数据流上加CRC和序列号我建议在项目早期就搭建一个故障注入测试框架能模拟各种硬件故障验证安全机制是否按预期工作。这个框架在后续的认证测试中会大大节省时间。3.5 第五步验证与确认验证与确认是功能安全的最后一道关。验证是证明“我做对了”确认是证明“我做的是对的”。验证活动包括安全机制的功能测试、故障注入测试、诊断覆盖率测量、时序分析。确认活动包括安全案例评审、FMEDA评审、以及整车级的安全验证。对于视觉处理器特别要注意感知算法的安全验证。传统的软件测试方法比如分支覆盖、MC/DC对神经网络不适用。你需要用场景-based测试构造大量边缘场景corner case验证系统在这些场景下的行为符合安全目标。这些场景可以来自自动驾驶数据集也可以人工构造。我参与过一个项目用了一个包含10万场景的数据集做安全验证覆盖了白天、夜间、雨天、雾天、隧道、逆光等各种条件。这个工作量很大但它是证明视觉处理器功能安全的必要投入。4. 常见问题与排查技巧实录4.1 诊断覆盖率不达标怎么办这是最常见的问题。FMEDA做完发现SPFM只有85%离ASIL B的90%差一点。这时候有几个方向可以补第一增加安全机制。比如原来NPU没有输出范围检查加上之后能覆盖一部分故障。或者原来内存只有奇偶校验换成ECC。第二细化故障分析。有时候DC低是因为故障分类太粗把一些实际不会导致安全目标违反的故障也算进去了。重新分析失效模式排除那些“安全无关”的故障DC会上升。第三用软件测试补充。有些故障硬件检测不到但软件可以通过周期性自检发现。比如定期跑一个已知的推理任务比较输出是否在预期范围内。第四和芯片厂商确认。有时候厂商的FMEDA数据是保守估计实际DC更高。让他们提供更详细的分析报告。我个人的经验是不要等到FMEDA做完才发现DC不够。在安全架构设计阶段就要估算DC留出余量。如果目标90%设计时按95%去规划。4.2 故障响应时间超了怎么排查FTTI通常是几百毫秒听起来很宽裕但实际上很容易超。我见过一个项目从NPU报错到安全岛执行降级花了300ms超过了200ms的FTTI。排查思路测量每一段的延迟故障检测延迟、故障上报延迟、安全岛处理延迟、降级执行延迟。找出瓶颈在哪。检查通信路径如果故障上报走的是低速总线比如CAN延迟可能很大。考虑用高速通路或专用中断。检查安全岛负载安全岛如果同时处理多个监控任务可能被阻塞。优化任务优先级确保故障处理最高优先级。检查降级策略有些降级策略本身就很耗时比如需要和整车其他ECU协商。考虑预定义更快的降级路径。注意FTTI是从故障发生到安全状态达成的时间不是从检测到故障开始算。所以故障检测本身的延迟也要算进去。很多团队漏算了这一块。4.3 安全岛和主处理器共享资源导致的问题前面提过共享DDR控制器的坑。类似的还有共享时钟、共享电源、共享中断控制器。共享资源的问题在于主处理器的行为会影响安全岛的确定性。排查方法资源隔离检查列出安全岛使用的所有资源确认哪些是独占的哪些是共享的。共享的要评估影响。压力测试在主处理器满负载的情况下测试安全岛的响应时间。如果明显变慢说明共享资源有干扰。独立通道关键的安全信号比如故障中断要用独立通道不经过共享总线。我现在的做法是安全岛的资源清单里任何共享资源都要有备份方案。比如共享DDR安全岛要有自己的TCM共享时钟安全岛要有备用RC振荡器。4.4 神经网络推理的安全验证怎么做这是视觉处理器功能安全最特殊的地方。传统软件的安全验证方法不适用你需要一套针对神经网络的验证策略。我的建议是分层验证第一层单元级。对NPU的硬件安全机制做故障注入验证检测和响应。这部分和传统硬件验证类似。第二层算法级。用对抗样本、边缘场景、噪声注入等方法测试感知算法的鲁棒性。记录失效模式分析是否在安全目标可接受的范围内。第三层系统级。在整车或HIL台上用真实场景数据回放验证系统在感知失效时的降级行为。这部分要覆盖HARA里识别的所有危害场景。提示自动驾驶数据集是安全验证的重要资源。但要注意公开数据集和实际道路场景有分布差异。最好用自己采集的数据做补充特别是那些罕见但危险的场景。4.5 认证过程中的常见坑功能安全认证是个系统工程我总结几个常见的坑文档追溯性不足。安全目标、TSR、安全机制、测试用例之间要有完整的追溯链。很多团队做到一半发现追溯断了回头补文档很痛苦。建议从项目开始就用需求管理工具每一条需求都关联到上下游。安全案例写得太晚。安全案例是认证的核心交付物应该在项目早期就开始写随着项目进展不断更新。等到认证前才写会发现很多证据没收集。忽略确认措施。确认措施是独立于开发团队的评估用来证明安全案例的可信度。很多团队只做验证不做确认认证时被要求补做。供应商管理不到位。视觉处理器通常是外购的供应商的功能安全能力直接影响你的认证。选型时要评估供应商的FMEDA质量、安全手册完整性、以及技术支持能力。我见过因为供应商不给FMEDA细节导致项目卡住的案例。4.6 常见问题速查表问题现象可能原因排查方向解决建议SPFM不达标安全机制不足或故障分类过粗重新分析FMEDA增加机制或细化分析FTTI超时通信延迟或安全岛阻塞分段测量延迟优化路径或提高优先级安全岛响应慢共享资源干扰压力测试资源隔离或独立通道推理结果异常NPU故障或输入问题故障注入增加一致性检查认证被拒文档追溯断链追溯性检查需求管理工具供应商数据缺失供应商能力不足评估供应商更换或补充测试5. 视觉处理器功能安全的未来演进与个人实践体会5.1 从ASIL B到ASIL D的路径ASIL B是当前量产的主流但L3和L4的需求会推动视觉处理器向ASIL D演进。ASIL D的挑战在于SPFM≥99%LFM≥90%这意味着几乎所有的单点故障都要被检测到而且潜伏故障也要有很高的覆盖率。技术上ASIL D需要更激进的冗余双核锁步可能不够需要三核或四核冗余NPU可能需要全双核冗余内存需要更强的ECC比如纠错双比特安全岛需要独立供电和时钟。这些都会推高成本和功耗。我个人的判断是ASIL D不会在短期内全面替代ASIL B。更可能的路径是混合架构关键感知通道用ASIL D非关键通道用ASIL B通过系统级的安全论证来平衡安全和成本。5.2 自动驾驶数据集在安全验证中的角色自动驾驶数据集不仅是训练算法的资源也是安全验证的宝库。用数据集做安全验证的关键是场景分类和覆盖度分析。你需要知道数据集里有哪些场景类型每种类型的样本量以及是否覆盖了HARA里识别的所有危害场景。我建议建立一个场景库按危害类型、环境条件、交通参与者等维度分类。每次算法更新都用场景库做回归测试确保安全性能不退化。这个做法在功能安全里叫“安全回归测试”是持续保证安全性的重要手段。5.3 我踩过的几个坑和体会第一个坑过早优化。项目初期就纠结于把DC从92%提到95%花了很多时间。后来发现先把安全架构搭起来把主要机制实现DC自然就上去了。过早优化细节反而耽误整体进度。第二个坑忽视软件安全。硬件机制做得很好但软件没有正确配置和使用等于白做。比如ECC使能了但错误上报路径没配故障发生了系统不知道。软件层面的安全设计和硬件同等重要。第三个坑安全文化不足。功能安全不是几个人的事是整个团队的事。如果开发人员没有安全意识写出的代码可能引入新的失效模式。我现在的做法是定期做安全培训把安全需求纳入代码评审 checklist让每个人都对安全负责。第四个坑低估认证工作量。功能安全认证需要大量的文档、测试、评审。我建议在项目计划里给认证留出至少20%的工作量不要等到最后才发现时间不够。5.4 给新入行者的建议如果你刚开始接触视觉处理器的功能安全我的建议是先搞懂ISO 26262的框架不用一开始就钻细节。理解HARA、安全目标、TSR、FMEDA、安全案例这条主线。找一个实际项目练手哪怕是一个小模块的FMEDA。纸上得来终觉浅实际做一遍就懂了。多和芯片厂商的FAE聊他们见过很多项目知道常见的坑在哪里。关注自动驾驶数据集和场景库这是安全验证的弹药库。保持敬畏心。功能安全关乎人命任何侥幸心理都可能酿成大祸。这个领域还在快速演进标准在更新芯片在迭代算法在进步。保持学习保持谨慎是我在这个领域最大的体会。
阅读完成 · 觉得有帮助？
