自动驾驶安全新突破:故障可运行架构与自动化依赖性分析
自动驾驶安全新突破：故障可运行架构与自动化依赖性分析随着自动驾驶技术从L2向L4/L5迈进，安全性与可用性成为横亘在量产道路上的两座大山。传统汽车电子系统在发生故障时往往采取“安全关闭”（fail-safe）策略，但对于无人驾驶车辆而言，系统一旦宕机，后果不堪设想——必须做到“故障可运行”（fail-operational）。近期，斯图加特大学博士Bülent Sarı在其博士论文中系统性地提出了面向ADAS/AD系统的故障可运行安全架构，并开发了一套基于模型的自动化依赖性失效分析（DFA）方法。本文将提炼其中的核心创新点，供行业同仁参考。
🚗 创新一：覆盖全处理链的故障可运行架构
现有研究多聚焦于单一ECU或传感器的冗余，而Sarı博士首次将视角扩展到完整的AD处理链——从传感器、高性能计算芯片到执行器，实现了端到端的故障可运行设计。1. 传感器多样性冗余
论文提出了一种传感器-功能映射矩阵：例如，纵向控制功能同时依赖长距雷达、激光雷达和摄像头，但不同路径采用不同权重的感知算法。即使某个传感器因暴雨或强光失效，另一条路径仍能维持基本感知能力。2. 硬件层级的三模/双模冗余
L3级适用方案：一个高性能芯片（GPU/CPU）+ 一个安全微控制器。当主芯片失效时，安全MCU接管关键决策，使车辆进入最小风险状态。L4/L5级推荐方案：2oo2D（双通道带诊断）或2oo3（三模冗余）架构。三条独立计算路径的结果通过多数表决，单一路径失效后系统仍能正常运行。3. 智能降级策略
第一路径：正常模式 → 遇到SOTIF限制（如下雨）则降速运行，待条件恢复后回到正常。第二路径：若第一路径硬件失效，切换到第二路径继续运行。第三路径：前两条均不可用时，执行“跛行回家”模式，确保车辆安全靠边停车。这一策略兼顾了安全与可用性，避免了因微小故障就立即停车的尴尬。
🔧 创新二：针对AD系统的ASIL分解新思路
ISO 26262允许将高ASIL（如ASIL D）的安全需求分解为较低ASIL的子需求，前提是子需求分配到足够独立的架构元素。但AD系统面临一个棘手问题：传感器和高性能芯片本身很难达到ASIL D等级。方法一：共享传感器，差异化处理
两条分解路径使用相同的传感器数据（如摄像头、雷达），但感知算法完全不同。例如：这样，即使某个传感器因电气故障输出错误，两条路径不会同时失效。方法二：监控路径替代冗余计算
第二条分解路径不再重复执行主控制逻辑，而是充当行为监控器。它根据输入信号预测期望的执行器输出，并与实际输出对比。若不一致，则判定主路径异常，切换至冗余路径。这种方法大幅降低了计算资源需求，尤其适合成本敏感的车型。
📐 创新三：基于模型的自动化DFA工具
依赖性失效分析（DFA）是ASIL分解的前提条件，但目前行业内普遍采用手动方式，不仅耗时，而且难以保证追溯性。Sarı博士基于EAST-ADL建模语言，开发了一套自动化DFA检查脚本，实现了五大规则的自动校验：检查项 | 作用 |
|---|
关系检查 | 验证安全目标是否被正确分配给安全需求和功能 |
ASIL检查 | 确认ASIL等级从目标到功能的继承一致性 |
独立性检查 | 判断分解后的功能是否分配到不同的CPU核心或硬件单元 |
信号检查 | 检查分解路径使用的输入/输出信号是否独立，信号ASIL是否达标 |
SOTIF检查 | 创新点：将天气、光照等触发事件纳入DFA，评估其是否同时影响两条分解路径 |
例如，若两条分解路径都依赖同一路车速信号（来自同一个CAN总线），脚本会自动标记“分解违规”。这种早期预警能力让工程师在设计阶段就能修正问题，避免后期返工。
🌧️ 创新四：将SOTIF纳入DFA框架
传统的DFA只关注硬件随机失效和系统性失效，而忽略了预期功能安全（SOTIF）中的技术局限性。Sarı博士扩展了依赖性失效的诱因列表，新增两类：传感器相关的SOTIF触发事件：如雨雪影响雷达、强光致盲摄像头。算法相关的触发事件：如环境感知算法在隧道出口处误判。通过将这些触发事件与传感器、算法进行关联建模，DFA脚本能够自动判断：某个触发事件是否会导致两条分解路径同时性能下降。如果是，则视为独立性不足，需要增加额外的安全措施。这一扩展使得DFA从纯硬件层面跃升至系统功能层面，更贴合AD系统的实际失效模式。
💡 总结与启示
Sarı博士的工作为自动驾驶安全领域提供了两把利器：一套完整的故障可运行架构方法论，覆盖传感器、计算平台和执行器，并给出了针对不同SAE等级的具体方案。一个实用的模型驱动DFA工具，将繁琐的手动分析转变为自动化检查，显著提升效率与可靠性。🚇 轨道车辆行业的观察与延伸思考：从"fail-safe"走向"fail-operational可控降级"铁路行业天然基因是 fail-safe（故障导向安全）：信号丢失→紧急制动→停车。这套逻辑在过去几十年被 EN 5012x / EN 50128 / EN 50159 等标准体系打磨到了极致，也是轨道交通安全口碑的来源。但当下有两个趋势正在倒逼我们重新审视："能不能别一出问题就全线停车？"1. GoA4（无人看守全自动运行）与高密度运营压力：乘客上下、折返、故障恢复都要求更高的 系统可用性（availability），而不仅仅是"不出事"。2. 车辆智能化叠加：新一代 TCMS/边缘计算节点、障碍物感知辅助、自动驾驶增强（ATO演进）、预测性维护……都在把"复杂软件+多传感器+集中/域控式架构"引入车厢，而这恰恰也是汽车行业今天碰到的那团复杂度。① "故障可运行"在轨道上不意味着学航空的 2oo3 无脑堆料
论文里提到的 2oo2D / 2oo3 等范式，在轨道语境下有一个更务实的译法——"可控降级 + 独立安全边界"：紧急制动/安全制动 仍然是 fail-safe：独立安全计算机（SSC）+ 硬线/独立总线 + 单点表决；不拿"感知融合"去赌刹车牵引/主辅逆变的可用性 更适合 fail-operational 冗余：主系-热备系、相桥臂冗余、多牵引控制单元互备——目标是"还能拉走/还能蠕行"，再由调度与防护层兜底GoA4 的"最小风险条件" 不是"继续高速自动驾驶"，而是 触发平台定义的 MRC：就近站台停车/指定避难线/受控惰行进站，并用独立 ATP/联锁把最坏情况锁死车载智能感知（毫米波/LiDAR/摄像头辅助） 定位要清楚：它是舒适性与运营效率的增程器，不能成为安全制动的单一依据；它的失效应只导致"降级模式"（例如限速运行、加大站间保护余量），而不触发全网急停一句话总结：轨道的 fail-operational 应读作"运营可降级、安全仍硬隔离"。② DFA 在轨道工程里最容易"流于形式"——而模型驱动是其解药
做 RAMS 的人对这句话一定不陌生："我们做了共因分析啊，FMEA 里写了'同一供应商批次'。"问题在于：当架构演进到 多核/域控/以太网骨干+TSN/虚拟化容器 时，真正的共因往往藏在：- 同一背板总线的时序抢占（而不是"哪个板子烧了"那么简单）
论文最有迁移价值的点，不在于 2oo3 本身，而在于它给出的那条路径：把 DFA 从PPT里的表格，变成可追溯的模型约束——谁和谁不能共用定时器/ADC/端口/镜像版本/刷新通道，脚本能帮你扫出来、留证据链。- 把"架构独立性论证"写成可验收产物：不只写"冗余"，而要写到"第几槽位-哪条硬线-哪个独立供电-哪套校验CRC-谁来做否决（veto）"。
- 让 Safety Case 与模型同步演化，而不是在项目尾声补材料。
③ SOTIF 思维对轨道尤其"对症"：环境不确定性≠E/E故障
铁路有个好处：运行在固定线路、受信号防护；但也有个软肋：场景驱动的"性能局限"更难用传统硬件失效率说话——- 站台风区/人群遮挡 → 车门-屏蔽门协同的边界条件
这些不是"板卡坏了"，却可能把系统推向危险行为。把论文里 SOTIF触发事件×分解路径独立性 的做法借过来，轨道行业能做的事很具体：- 给感知/定位链路建"性能降级阶梯"：全功能 → 降级可用（限速/加保护余量）→ 退出（交还给信号防护/人工接管/停靠预案）
- 把"天气/轨面/环境工况"当作独立变量放进验证矩阵，而不只在现场试验靠运气
- 明确划分：哪些功能允许依赖感知，哪些必须脱离感知也能安全收底（双簧管逻辑：ATP永远有一根不依赖AI的刹车弦）
汽车那篇论文给我们的真正启发，不是"把车的方法照搬到车上"，而是提醒轨道人——当复杂度越过拐点，"安全"会越来越像系统工程，而不是更多继电器。未来竞争的关键，未必是谁敢跑全自动，而是谁能把 可用性（别老趴窝）× 独立性证据链（别一起翻车）× 降级纪律（出事也别乱） 做成可交付的工程能力。轨道的浪漫，是让千百吨钢铁按毫秒级节拍安全起舞；轨道的成熟，是把这份浪漫写成可审计、可追溯、可复盘的体系。本文基于Bülent Sarı博士论文《Fail-operational Safety Architecture for ADAS/AD Systems and a Model-driven Approach for Dependent Failure Analysis》整理。关注「欧轨观察者」，获取更多轨道交通与智能驾驶安全前沿洞察。
10个月宝宝每天需要喝多少奶粉？
