安全标准与法规：ISO 26262、ISO 21448、UL 4600等标准对冗余设计的要求
在《全额支付高级别自动驾驶系统冗余设计》课程中，安全标准与法规构成了冗余设计的“底线逻辑”与“验收标尺”。对于L3级及以上自动驾驶系统，单一故障可能导致灾难性后果，因此冗余设计不再是可选项，而是强制性工程实践。ISO 26262（功能安全）、ISO 21448（预期功能安全，SOTIF）与UL 4600（自动驾驶产品安全评估）三大标准从不同维度对冗余提出了差异化要求：ISO 26262关注系统性故障与随机硬件失效的量化控制，ISO 21448关注因性能局限或场景理解不足引发的非故障类风险，UL 4600则从产品全生命周期安全论证角度要求冗余设计具备可追溯性与可验证性。理解三者的边界与交集，是构建合规冗余架构的前提。
4.1 ISO 26262：以量化指标驱动冗余架构设计
ISO 26262（道路车辆功能安全）是冗余设计最直接的工程约束来源。该标准将安全等级划分为ASIL A至ASIL D，其中ASIL D代表最高风险等级。对于L3级及以上自动驾驶系统，感知、决策、执行等核心功能通常被分解为ASIL D要求。冗余设计在此标准下的核心逻辑是：通过硬件架构指标（SPFM、LFM、PMHF）的量化计算，证明冗余方案能够将残余风险降低到可接受水平。
核心原理：从“单点可靠”到“系统安全”
ISO 26262对冗余的要求并非简单“双份硬件”，而是强调安全机制的有效性与架构的故障处理能力。具体而言，标准要求每个安全相关功能必须定义其安全目标（Safety Goal），并针对该目标设计相应的安全机制。冗余设计在此框架下表现为：当主路径发生失效时，冗余路径必须能够接管并维持安全状态。这要求冗余路径具备独立的供电、时钟、通信链路和故障检测机制，且两条路径之间不能存在共因失效（CCF）风险。
判断方法：FMEDA与DFA分析
在工程实践中，判断冗余设计是否满足ISO 26262要求，主要依赖以下分析工具：
- FMEDA（故障模式、影响与诊断分析）：对每个硬件组件进行故障模式枚举，计算其失效率（λ）、诊断覆盖率（DC）和安全故障占比（SFF），最终汇总得到SPFM（单点故障度量）和LFM（潜伏故障度量）。
- DFA（依赖失效分析）：专门识别冗余路径之间的共因失效和级联失效。例如，若主制动控制器与冗余制动控制器共用同一电源芯片，则该电源芯片的失效将同时影响两条路径，DFA会将其标记为“违反独立性要求”。
- PMHF（概率性硬件失效率）：用于评估整个系统在运行寿命内的随机硬件失效概率，ASIL D要求PMHF小于10-8/小时。冗余设计通过降低单点失效率来满足该指标。
| ASIL等级 | SPFM要求 | LFM要求 | PMHF要求 | 冗余设计典型策略 |
|---|---|---|---|---|
| ASIL D | ≥99% | ≥90% | <10-8/h | 双通道异构冗余+独立电源/时钟 |
| ASIL C | ≥97% | ≥80% | <10-7/h | 双通道同构冗余+共享电源域 |
| ASIL B | ≥90% | ≥60% | <10-7/h | 单通道+高诊断覆盖率安全机制 |
实战场景：某L3级自动驾驶系统采用“1个主计算平台+1个备份计算平台”的冗余架构。在FMEDA分析中发现，主平台与备份平台共用同一路12V电源输入，且电源芯片的失效率为50 FIT（1 FIT=10-9/h）。DFA分析指出该共因失效将导致SPFM无法达到99%的ASIL D要求。解决方案是增加一路独立的DC-DC电源模块，并配置电源监控芯片（如LM5060）实现电源域隔离。修改后SPFM从97.2%提升至99.3%，满足ASIL D要求。
常见误区与复盘
误区1：认为“双份硬件”即满足冗余要求。实际上，若两条路径使用相同型号的传感器、相同版本的软件或共享同一通信总线，则共因失效风险极高，DFA分析将直接否决该方案。
误区2：忽略诊断覆盖率对冗余有效性的影响。即使有冗余路径，若主路径的故障检测延迟过长（如超过500ms），在高速场景下可能已造成危险。ISO 26262要求故障响应时间（FTTI）必须小于系统安全状态维持时间。
4.2 ISO 21448：面向预期功能安全的冗余策略
ISO 21448（SOTIF）解决的是“没有故障，但功能表现不满足预期”的问题。例如，摄像头在逆光场景下无法识别行人、激光雷达在大雨中点云稀疏、算法在未知路口做出错误决策——这些并非硬件失效，而是功能性能局限。冗余设计在SOTIF框架下的核心任务是：通过多源信息融合、算法多样性和行为降级策略，覆盖单一感知或决策路径的性能盲区。
核心原理：从“故障安全”到“性能安全”
SOTIF将场景分为已知安全、已知不安全、未知不安全、未知安全四类。冗余设计的目标是扩大“已知安全”区域，缩小“未知不安全”区域。具体手段包括：
- 传感器异构冗余：摄像头+毫米波雷达+激光雷达的组合，利用不同物理原理的传感器互补性能边界。例如，摄像头在强光下性能下降时，毫米波雷达仍能稳定输出目标距离信息。
- 算法多样性：主路径采用深度学习目标检测，冗余路径采用传统几何特征匹配或基于规则的验证算法。当两者输出不一致时，触发仲裁机制。
- 最小风险策略（MRM）：当系统检测到自身性能不足以安全完成驾驶任务时，主动触发降级操作——如减速靠边停车、请求驾驶员接管。MRM本身也需要冗余设计，例如双通道制动系统确保降级操作可靠执行。
操作流程：SOTIF场景分析与冗余覆盖验证
- 场景清单构建：基于ODD（运行设计域）定义，枚举传感器性能边界场景（如隧道出入口、雨雪天气、夜间无照明等）。
- 性能缺口分析：对每个场景，评估单一传感器/算法的性能表现，标记“性能不足”项。
- 冗余覆盖映射：将性能不足项与冗余资源进行匹配，确认至少有一条替代路径能够在该场景下提供足够性能。
- 验证与迭代：通过仿真（如CARLA、VTD）和实车测试，验证冗余策略在边界场景下的有效性，并持续收集运营数据更新场景库。
案例拆解：某自动驾驶公司在城市道路测试中发现，当车辆通过高架桥下方时，GNSS信号丢失导致定位漂移超过1米，主路径的融合定位模块输出异常。由于系统设计了“GNSS+惯性导航+视觉里程计”三重定位冗余，当GNSS置信度低于阈值时，系统自动切换至“惯性+视觉”组合定位模式，定位误差控制在0.3米以内，车辆顺利完成通过。该案例说明，SOTIF冗余不仅关注硬件备份，更关注信息源的多样性——不同物理原理的定位方式对同一干扰（如信号遮挡）的敏感度不同，从而形成互补。
常见误区与总结
误区：将SOTIF冗余等同于“增加传感器数量”。实际上，若增加的传感器与现有传感器存在相同的性能局限（如两个摄像头在逆光下同时失效），则冗余无效。SOTIF要求冗余路径在性能特征上具有多样性，而非仅仅数量叠加。
4.3 UL 4600：以安全案例驱动冗余设计的全生命周期论证
UL 4600是面向自动驾驶产品的安全评估标准，其核心思想是要求制造商构建并维护一份“安全案例”（Safety Case），以结构化的方式论证产品在全生命周期内是安全的。与ISO 26262和ISO 21448相比，UL 4600更强调论证的完整性、可追溯性和持续更新性。冗余设计在此标准下不仅是技术方案，更是安全论证中的关键证据链。
核心原理：安全案例中的冗余论证框架
UL 4600要求安全案例包含以下要素：
- 安全目标分解：将顶层安全目标（如“避免与行人碰撞”）逐层分解为可验证的子目标，每个子目标对应具体的冗余设计措施。
- 冗余设计的证据链：每个冗余路径必须提供设计文档、分析报告、测试记录、运营数据等证据，证明其在特定场景下确实能够接管并维持安全。
- 变更管理：当冗余设计发生变更（如更换传感器型号、修改仲裁算法）时，必须重新评估安全案例，并更新相关论证。
- 现场监控与反馈：要求建立运营数据回传机制，将实际运行中发现的冗余失效或性能不足反馈至设计团队，形成闭环改进。
操作流程：构建冗余设计的安全论证
| 步骤 | 活动内容 | 输出物 | 关联标准 |
|---|---|---|---|
| 1 | 定义安全目标与冗余需求 | 安全目标清单、冗余需求规格 | ISO 26262 |
| 2 | 冗余架构设计与FMEDA/DFA分析 | 架构图、FMEDA报告、DFA报告 | ISO 26262 |
| 3 | SOTIF场景分析与冗余覆盖验证 | 场景库、性能缺口分析表 | ISO 21448 |
| 4 | 安全案例文档编制 | 安全案例主文档、证据索引 | UL 4600 |
| 5 | 独立安全审计与评审 | 审计报告、整改项清单 | UL 4600 |
| 6 | 运营数据监控与安全案例更新 | 运营报告、安全案例修订版 | UL 4600 |
实战场景：某自动驾驶卡车公司计划在高速公路上运营L4级自动驾驶卡车。其冗余设计包括双制动系统、双转向系统和双计算平台。在构建UL 4600安全案例时，审计团队发现：虽然每个子系统都有冗余，但冗余切换逻辑（即从主路径切换到冗余路径的仲裁算法）本身没有独立的故障检测机制。这意味着如果仲裁算法自身发生软件错误，可能导致系统无法正确切换。为此，团队增加了独立的“看门狗”模块，监控仲裁算法的运行状态，并在检测到异常时强制触发MRM。该案例说明，UL 4600要求冗余设计覆盖所有安全相关环节，包括冗余管理逻辑本身。
常见误区与总结
误区：认为UL 4600仅是一份文档要求，与工程实现无关。实际上，UL 4600的审计会深入检查冗余设计的实际实现细节，包括代码覆盖率、故障注入测试结果、现场数据统计等。如果安全案例中的论证与实际产品不符，将直接导致认证失败。
4.4 三大标准的协同应用与冗余设计综合策略
在实际项目中，ISO 26262、ISO 21448和UL 4600并非孤立应用，而是形成一套互补的安全体系。ISO 26262解决“硬件坏了怎么办”，ISO 21448解决“功能不够好怎么办”，UL 4600解决“如何证明整个系统是安全的”。冗余设计需要同时满足三者的要求，这意味着：
- 架构层面：冗余路径必须满足ISO 26262的独立性要求（如独立电源域、独立时钟、独立通信链路），同时具备ISO 21448所要求的性能多样性（如不同传感器类型、不同算法原理），并且这些设计决策需要在UL 4600的安全案例中清晰记录和论证。
- 验证层面：需要同时进行故障注入测试（验证ISO 26262的故障响应）、场景测试（验证ISO 21448的性能覆盖）和安全案例审计（验证UL 4600的论证完整性）。
- 运营层面：现场数据需要同时用于更新FMEDA失效率、扩充SOTIF场景库和修订安全案例，形成持续改进的闭环。
综合策略建议：在冗余设计初期，建议先建立“安全需求矩阵”，将三大标准的要求逐条映射到具体的冗余设计措施上。例如，对于“制动系统冗余”这一设计项，ISO 26262要求双通道独立供电（ASIL D），ISO 21448要求冗余路径在湿滑路面下仍能提供足够制动力（性能覆盖），UL 4600要求提供制动冗余的故障注入测试报告和实际运营中的制动失效统计数据。通过矩阵管理，可以确保冗余设计不遗漏任何标准的要求。
总结与复盘
三大标准对冗余设计的要求可归纳为三个关键词：量化、覆盖、论证。ISO 26262提供量化指标（SPFM/LFM/PMHF）驱动冗余架构的硬件设计；ISO 21448要求冗余策略覆盖感知、决策、执行全链路的性能盲区；UL 4600则要求将冗余设计转化为可追溯、可验证、可持续更新的安全论证。在工程实践中，冗余设计团队应建立跨标准的工作流程，将安全需求分解、设计实现、验证确认和运营反馈整合为统一体系。任何单一标准的满足都不足以支撑L3+级自动驾驶的安全目标，唯有三者的协同应用，才能构建真正可信赖的冗余系统。