SASETalk | 从功能安全到智驾新挑战：一位功能安全专家的十年进化之路

 

“SASETalk”是磐时打造的深度访谈栏目，通过与企业内资深技术专家对话，记录他们亲历的技术历程与行业观察，从个人视角解读行业发展变迁，共同探讨未来技术趋势与工程师成长路径。

 

 

本期嘉宾 PROFILE

Frank 文冬

资深功能安全专家

德国卡尔斯鲁厄理工学院机械工程硕士、武汉理工大学车辆工程学士。十余年汽车功能安全ISO 26262、ISO 21448方向工作经验；软件、智能驾驶安全专家。熟悉功能安全、预期功能安全、AI安全各项标准及落地实践，拥有丰富的L3&L4安全开发经验。

 

01

从德国求学到功能安全

 

您在德国卡尔斯鲁厄理工学院攻读机械工程硕士，这是一所德国精英理工大学。这段求学经历对您后来的功能安全职业生涯产生了怎样的影响？德国汽车工业对“安全”的理解，与国内有什么不同？

 

在KIT（德国卡尔斯鲁厄理工学院）的学习对我影响深远
 

首先，KIT（德国卡尔斯鲁厄理工学院）所在的卡尔斯鲁厄地区是德国汽车工业重镇之一，与奔驰、博世、西门子等企业联系紧密。学校非常强调系统思维——不仅仅是掌握某个零件的设计方法，而是理解一个复杂系统（比如整车）从需求、设计、验证、生产到全生命周期管理的内在逻辑。这种思维方式奠定了我后来做功能安全、分析系统失效模式的基础。

 

在其次，严谨的文档化和知识化的传统让我印象深刻。不管是质量管理、还是生产管理、设计或者验证都有相应的规范或者可遵循的标准。第一次接触到”V”模型也是在课堂中。每一个设计、每一次仿真或实验，都需要有清晰的依据和可追溯的记录。这恰好与功能安全标准（如ISO 26262）中对“可追溯性”和“工作产品”的要求高度契合。

 

国内在过去十年里经历了爆发式增长，更多体现为“敏捷响应+合规驱动”的模式。早期很多项目为了追赶智能化的窗口期，安全开发往往是“补作业”——先完成功能开发，再对照标准补安全文档。但近3-5年，随着高阶智驾落地、功能安全事故案例增加，以及主机厂对品牌声誉的重视，国内头部企业已经开始向“设计即安全（Safety by Design）”转变。一个典型的例子是，越来越多的国内主机厂要求在概念阶段就完成HARA，并将安全目标分解到各子系统——这个越来越规范，越来越偏向于"源头治理”。如今，在智能化、AI安全等新领域，国内甚至因为落地速度快而开始探索标准之外的实践。

 

02

从不同赛道谈安全重心

 

您曾在整车厂、芯片公司、国内头部智驾企业负责功能安全，经历了从整车厂到芯片公司再到智驾公司的不同角色。在不同类型的企业里，功能安全的重心有什么差异？哪种挑战最大？

 

具体来说：

 

整车厂：视角最宏观，核心挑战是需求分解与供应链安全管理。需要把整车级安全目标（如“避免非预期制动”）分解成可量化的子系统需求，同时审核Tier 1/Tier 2的安全案例是否完整。

难点在于：供应商交付的“黑盒”模块如何验证其安全性？多个供应商的系统交互是否存在安全漏洞？

 

芯片公司：视角最微观，核心挑战是随机硬件失效的量化控制。芯片是安全的基础承载层，必须证明其失效率（FIT）满足ASIL等级要求。典型工作是设计安全机制（如锁步CPU、ECC保护、BIST），并计算SPFM、LFM、PMHF。

难点在于：面积和功耗约束下如何实现足够的安全覆盖？如何为客户提供易用的Safety Manual和支持证据？

 

智驾公司：视角最前沿，核心挑战是系统复杂性与非确定性行为。智驾系统的感知输出是概率性的，决策规划依赖机器学习模型，传统基于确定性失效假设的方法不够用。SOTIF（ISO 21448）成为核心，需要分析“已知/未知的不安全场景”。

难点在于：如何将“场景”转化为可验证的测试用例？如何在有限里程内证明“残余风险可接受”？

 

从技术难度和方法论成熟度来看，智驾公司的挑战最大。原因：

 

标准滞后：ISO 26262已相当成熟，但针对L3/L4的SOTIF和AI安全仍在演进，很多问题没有标准答案。

不确定性本质：传统功能安全处理“故障”，而智驾要处理“能力不足”——传感器没坏但识别错了、算法没崩但决策不当——更难量化和验证。

验证手段受限：实车测试无法穷尽长尾场景，仿真覆盖率和真实性的trade-off尚未解决。

 

但从项目管理和合规压力来看，芯片公司也不轻松——一旦流片回来发现安全机制有bug，代价极其昂贵。整车厂则更大挑战在于组织协调：安全往往要推动多个部门（动力、底盘、智驾、座舱）配合，话语权不够时很吃力。

 

综合来看，智驾公司的技术挑战最大，但每个角色都有其独特的难点。

03

高阶自动驾驶双安全体系

 

 

您有丰富的L3&L4安全开发经验。对于高阶自动驾驶，功能安全（ISO 26262）和预期功能安全（ISO 21448）是如何协同工作的？能否用一个实际场景举例说明？

 

两者不是替代关系，而是互补关系：

 

ISO 26262（功能安全）：处理系统性失效和随机硬件失效——即“东西坏了”。

例如：传感器短路、内存bit翻转、代码bug。

 

ISO 21448（SOTIF）：处理功能不足和使用场景的触发条件——即“东西没坏，但能力不够或环境不合适”。

例如：摄像头没故障，但逆光导致识别失效；雷达工作正常，但把路牌误认为障碍物。

 

协同工作的核心逻辑：先做功能安全的设计基础（确保系统在“正常环境、无故障”下可靠），再做SOTIF的边界探索（找出能力边界并缩小它）。实践中两者交织迭代。

 

实际场景举例：自动变道辅助

假设一辆L3车辆在高速上自动从左侧车道变到中间车道。

功能安全关注的点（假设“东西坏了”）：

转向电机驱动电路短路 → 导致非预期转向 → 需要设计安全机制：监控电流、冗余关断路径

毫米波雷达CAN通信中断 → 丢失目标信息 → 需要设计fallback策略：降级、提醒接管

转角传感器输出错误值 → 闭环控制发散 → 需要合理性检查和冗余校验

SOTIF关注的点（假设“东西没坏，但能力不足”）：

感知算法在雨天+夜间场景下对拖车轮廓识别置信度低 → 属于“已知不安全场景” → 需要针对性训练、引入激光雷达融合

决策规划模块对相邻车道车辆急切入的响应不够平顺 → 需要优化预测模型

 

未知场景：比如某隧道出口处的光照突变导致车道线短暂丢失→ 需要设计监控机制（如定位+地图融合做兜底）和ODD限制

 

协同工作流程：

系统设计阶段：同时启动功能安全HARA和SOTIF危害辨识（两者共用初始危害列表）。

架构设计：功能安全要求冗余传感器满足ASIL D分解；SOTIF要求异构传感器（如摄像头+激光雷达+毫米波雷达）互补能力盲区。

验证阶段：功能安全做故障注入测试；SOTIF做场景泛化测试和边界搜索。

残余风险评估：功能安全给出PMHF值（如<10 FIT）；SOTIF给出“已知不安全场景覆盖率”和“残余风险论证”。

 

高阶自动驾驶中，SOTIF的安全工作量往往大于传统功能安全，因为“算法能力不足”发生的概率远高于“硬件随机故障”。但两者必须双轨并行——没有功能安全的可靠基础，SOTIF的分析会失去落脚点。

 

04

差异对比 —— 传统软件与 AI 安全

 

 

近年来AI安全成为行业热点。从功能安全视角看，AI算法（如感知模型、决策规划）的安全保障与传统软件有什么本质不同？您如何看待“可解释性”与“安全性”之间的关系？

 

传统软件安全关注“代码是否按规格实现了逻辑”，AI安全关注“模型在未见过的场景中是否仍然足够可靠”，本质是从确定性逻辑验证转向统计特性保证。

 

我的观点：可解释性是安全性的使能工具，而非安全性本身。

 

在开发阶段，可解释性对安全至关重要：当感知模型漏检了某个障碍物，如果我们不知道是“特征模糊”“光照变化”还是“训练数据偏差”导致的，就不知道如何针对性改进。可解释AI技术如SHAP值、注意力图可以帮助定位问题根源。

 

但在运行时，自动驾驶不能依赖“等模型解释完再决策”——实时性不允许，而且解释本身也可能错误。运行时安全可以更多依靠：监控（输入分布漂移检测、不确定性估计）、冗余（异构模型投票）、兜底策略（当不确定性高时触发最小风险状态）。

 

所以我认为一个可解释的模型不一定安全（解释很漂亮但泛化失败），一个安全的模型不一定完全可解释（集成模型、蒸馏后性能好但难解释）。两者目标不完全一致。

 

对于安全关键应用，我倾向采用混合架构：

 

需要泛化和复杂模式识别的模块（如感知），用深度学习（接受一定程度的不可解释性），但配合：
 

输入有效性检查、不确定性估计、可解释性分析用于离线验证和迭代改进、安全逻辑和fallback（如仲裁、诊断、降级），用确定性规则引擎或可验证的决策树。这样，可解释性在工具链中扮演安全卫士的角色，而不是运行时的必需品。