SASETalk | 当智能驾驶驶入未知场景：谈谈关于SOTIF、AI安全与工程落地的思考

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

本期嘉宾：张策

资深预期功能安全专家

7年汽车预期功能安全相关项目经验，熟知ISO 21448标准，深耕智能驾驶预期功能安全领域。发表多篇SCI/EI及核心期刊论文，涵盖驾驶场景知识图谱、车道检测、制动系统可靠性等方向，多次获得世界智能驾驶挑战赛奖项。

学术起点与技术积累

Q1：您在博士阶段为何选择 SOTIF 作为研究方向？当时对智能驾驶安全有哪些判断，后来又有哪些被实践验证或推翻？

选择预期功能安全（SOTIF），与导师的研究背景和判断有很大关系。我的导师是可靠性领域的专家，他较早意识到，随着智能驾驶技术的发展，智能驾驶系统的稳定性、可靠性以及运行过程中的安全问题会越来越受到关注，因此建议我围绕相关方向收集资料、梳理课题。

2019年，发布的SOTIF早期草案版本（后于2022年发布ISO 21448正式版）确立了预期功能安全核心框架和基本方法。研究后我发现，SOTIF所关注的问题与智能驾驶的发展趋势高度相关：系统不一定要发生硬件或软件故障才会产生风险------即使系统处于正常工作状态，也可能因为功能性能不足、环境条件复杂，或实际使用场景超出设计边界而出现不安全行为。基于此，我决定以该标准为基础，开展预期功能安全方向的课题研究。

回头看当时的行业环境，智能驾驶系统大多还采用基于规则的算法。那时，行业普遍认为，不断完善和迭代规则，有助于逐步提升系统安全性。但随着人工智能技术的发展，智能驾驶的技术路线很快发生了变化------尤其是在2020年后，随着Transformer框架和BEV感知方案的兴起，基于数据和模型的算法逐渐取代了传统的纯规则式算法，完全依靠人工提炼和编写规则的智能驾驶系统已越来越少。行业发生的这一转变，恰恰印证了当初的判断：单靠规则迭代不足以应对智能驾驶的安全挑战，系统在复杂环境、未知场景下的能力边界问题，正是SOTIF所要解决的核心问题。

Q2：从智能驾驶竞赛到 ADAS 测试、自动驾驶样机开发，您经历过哪些让自己印象深刻的技术转折点？这些经历如何塑造了今天的工程方法？

第一次参加智能驾驶挑战赛的越野挑战赛的时候，车辆在比赛开始后几乎没有正常运行，直接"趴窝"了。整个团队在现场焦急地排查，却始终没能让车动起来，最终只能遗憾弃赛。那段时间团队士气受到了很大打击。

然而，随后我们又参加了城市挑战赛，同一套智能驾驶系统在城市道路环境中却能够正常运行。面对两场比赛截然不同的结果，我们最初也感到困惑：车辆本身并没有发生明显变化，为什么在一个场景中无法运行，在另一个场景中却表现正常？

后来复盘发现，问题并不只是某个零部件或单一算法出现故障，更重要的是系统在不同环境和场景下表现出的稳定性、可靠性存在差异。越野场景中的道路条件、地形变化和环境特征，可能超出了系统原有的设计能力和适用范围。也就是说，系统并未发生硬件或软件故障，但在特定场景下并没有表现出预期的功能能力。

正是这种"系统没坏却跑不起来"的现象，让我第一次直观地认识到，智能驾驶安全不仅是故障后的安全保障，也包括系统在复杂场景下能否正确理解环境并作出合理响应。后来，结合导师在可靠性领域的研究方向，我逐渐将关注点从单一功能的实现，转向系统在不同场景下的能力边界和不安全表现，也最终确定将 SOTIF 作为主要研究方向。

SOTIF工程落地与体系协同

Q3：在 SOTIF 工程落地过程中，最容易被低估、却最考验团队能力的环节是什么？

严格来说，SOTIF 在工程实践中真正困难的往往不是理解标准框架本身，而是如何将框架转化为可执行的工程动作。标准提供了整体框架和基本方法，却没有对每一个工程环节给出足够细致、统一的操作路径。因此，不同团队在理解和执行时容易形成不同的方法，最终导致同样是做 SOTIF，具体做法却不一样。

目前来看，至少有三个环节比较考验团队的工程能力。

一、触发条件的识别

以触发条件分析为例，有的团队更强调少而精准，希望优先识别对系统安全影响最大的关键条件；有的团队则倾向于穷举，通过扩大场景范围来降低遗漏风险。这两种思路各有合理性，但目前对识别粒度、覆盖范围和充分性判断，行业尚未完全形成共识。

二、改进措施的制定

措施过于笼统难以落地，过于具体又可能无法适配不同系统。比如，同样是针对某一类感知风险，有的改进措施可能涉及算法优化，有的可能需要增加传感器融合、调整 ODD 边界，或者设计相应的监控和降级策略。如何在足够具体、能够执行和保持通用、便于应用之间找到平衡，对团队的系统理解能力和工程经验提出了很高要求。

三、测试验证与闭环

许多 SOTIF 风险属于低概率、边界场景，例如半截悬挂的树枝，它既不同于正常道路障碍物，也不一定符合常规测试场景的定义，却可能对感知、决策或车辆控制产生影响。类似这样的边界场景，往往很难在现实道路中稳定复现，也很难通过有限的实车测试直接覆盖。因此需要结合实车、仿真、场景库、场景生成及边界条件注入，并根据验证结果持续更新分析和措施。

总体来看，SOTIF 工程落地最具挑战的是如何把触发条件识别、改进措施制定和测试验证有效衔接，而且这种衔接不是线性的，而是需要在验证结果反馈后不断迭代，持续修正前序环节的分析结论。目前这几个环节仍存在诸多问题，也正因为如此，SOTIF 不仅考验团队对标准的理解，更考验其将方法转化为工程实践的能力。

Q4：功能安全与预期功能安全常被视为两套不同的方法论。在真实项目中，二者如何协同？工程师最容易陷入哪些误区？

在实际项目中，功能安全和预期功能安全需要协同开展，但不能简单合并为一套体系。以 GB 47955-2026 为例，强标从功能安全和预期功能安全两个维度作出了技术规定，这说明二者虽然存在交集，但关注的问题和分析视角并不完全相同。

功能安全主要面向传统汽车电子电气系统，关注系统性失效和随机硬件失效。随着软件、人工智能算法和复杂功能大量进入汽车，即使没有明确的软硬件故障，系统也可能因算法能力不足、环境变化或设计边界不充分而产生风险。传统功能安全难以覆盖这类问题，预期功能安全因此逐渐形成了相对独立的方法体系。

两者可以在项目定义、危害识别、风险分析、安全需求、风险缓解和验证确认等环节协同推进，共享系统边界、功能范围、使用场景等基础信息。但分析时必须保持各自视角：功能安全关注系统发生故障后的风险，预期功能安全关注系统无明显故障时的功能能力。

不过，工程师在实践中比较容易陷入一个误区：直接将功能安全的分析结论同步到预期功能安全中。某项功能在功能安全分析中被判定为 QM，并不意味着它在 SOTIF 中不存在风险。QM 只能说明其无需按 ASIL 要求处理，预期功能安全仍需结合具体场景，重新评估可控性、暴露程度和严重程度，再决定是否制定改进措施。

更合理的做法是：以统一的系统和功能定义为基础，分别从系统发生故障 和系统功能能力不足两个角度开展分析，再对两类风险进行关联、协调和闭环管理。

简单来说，功能安全主要回答系统发生故障后是否安全 ，预期功能安全则进一步回答**系统没有明显故障，但在特定场景下能力不足时是否安全，**只有将两种视角结合起来才能更全面地覆盖智能驾驶风险。

AI 时代的新挑战

Q5：面对端到端智驾和大模型，您认为 SOTIF 最需要调整的是什么？又有哪些原则，无论技术怎样变化都必须坚守？

SOTIF 首先需要加强对人工智能安全的覆盖。

SOTIF 标准较早提出时，已经关注到人工智能算法可能带来的安全风险，但当时人工智能在智能驾驶中的应用还没有发展到今天的规模和复杂程度，因此相关内容较为框架化，覆盖范围和分析方法存在一定局限。面对如今应用于感知、决策和交互的端到端模型及大模型，传统方法需要与 ISO/PAS 8800:2024（道路车辆 ------ 安全与人工智能）等人工智能安全标准结合使用。

但是，SOTIF 所坚持的基本原则不能因标准和技术的发展而改变。首先，安全不能只建立在模型"通常表现良好"的基础上，而要持续识别系统在不同场景下的能力边界；其次，不能只关注已知问题，还要通过测试、仿真和运行数据不断发现标准中所定义的"未知不安全场景"；再次，所有安全判断都需要有充分的分析依据、验证证据和可追溯记录，不能因为系统采用了端到端模型或大模型，就降低对安全论证的要求。

技术架构和算法可以变化，但围绕场景、风险、边界和验证建立闭环，以及对风险保持敬畏、持续验证能力、明确安全责任，始终不能改变。

安全不是可选项，而是技术伦理必须坚守的底线。

跨界视角 ------ 从高校到产业

Q6：从高校研究到产业工程，您如何看待技术研究与实际交付之间的距离？对于希望进入智能驾驶安全领域的年轻工程师，最想分享的一条建议是什么？

从高校研究走向产业工程后，我经常会受到客户这样的反馈：SOTIF 分析本身没有问题，但更多是从理论和方法出发，与项目实际落地之间仍然存在一定距离。

解决这一问题，需要深入了解客户的产品需求、系统架构和工程约束，把分析结果落实到具体功能、模块和工程动作中，提出有针对性的措施。

对于希望进入智能驾驶安全领域的年轻工程师，我最想分享的一条建议是：扎扎实实地研读标准，打好基础。

我之所以特别强调这一点，是因为自己刚入行时，导师曾带着我对 ISO 21448 标准进行了从头到尾、逐字逐句的解读和分析，这让我建立了对标准结构、核心概念和方法逻辑的系统理解。在此基础上，再将标准中的抽象方法拆解为具体的分析表格、验证用例，并在实际项目中反复验证和修正理解。只有真正读懂标准，才能理解其要解决的问题，并将方法转化为工程实践。